index : openwrt/upstream	attitude_adjustment barrier_breaker chaos_calmer lede-17.01 less-old-master master old-master openwrt-18.06 openwrt-19.07 upstream
	upstream openwrt	James

aboutsummaryrefslogtreecommitdiffstats

log msg author committer range

path: root/target/linux/ar71xx/files/arch

	Commit message (Collapse)	Author	Age	Files	Lines
...
*	ar71xx: remove the built-in MTD maps of several boards	Gabor Juhos	2012-03-27	8	-324/+8
| | | | | | | | | | | | | | | | | | |	We are passing the MTD layout via the kernel command line, so it makes no sense to duplicate it in mach-* files. The patch removes the built-in MTD maps of the following boards: * AP113 * ALFA N2/N5 * DIR-600 * DIR-615 * DIR-825 * TEW-6{3,5}2BRP * TEW-673GRU * WHR-G301N * WHR-HP-GN * WHR-HP-G300N SVN-Revision: 31108
*	ar71xx: fix button polarity on TL-WR703N and TL-WR741N v4	Gabor Juhos	2012-03-27	2	-3/+3
| | | |	SVN-Revision: 31102
*	ar71xx: add initial support for RB750GL	Gabor Juhos	2012-03-19	2	-0/+125
| | | |	SVN-Revision: 31025
*	ar71xx: make rb750_latch_change 'static void'	Gabor Juhos	2012-03-19	2	-15/+3
| | | |	SVN-Revision: 31024
*	ar71xx: add latch_change field to rb750_led_platform_data	Gabor Juhos	2012-03-19	2	-5/+5
| | | |	SVN-Revision: 31023
*	ar71xx: add platform data for the RB750 NAND driver	Gabor Juhos	2012-03-19	2	-7/+28
| | | |	SVN-Revision: 31022
*	ar71xx: add AR934x specific interface speed setup for ge0	Gabor Juhos	2012-03-19	1	-4/+9
| | | |	SVN-Revision: 31017
*	ar71xx: add support for the jjPlus JA76PF2 board	Gabor Juhos	2012-03-16	1	-0/+76
| | | |	SVN-Revision: 30957
*	ar71xx: change LED name prefix on the jjplus boards	Gabor Juhos	2012-03-16	1	-3/+3
| | | |	SVN-Revision: 30956
*	ar71xx: reset the switch on AR934x before ethernet device registration	Gabor Juhos	2012-03-13	1	-0/+4
| | | |	SVN-Revision: 30922
*	ar71xx: use a dummy callback for interfaces with fixed speed	Gabor Juhos	2012-03-12	1	-28/+7
| | | |	SVN-Revision: 30913
*	ar71xx: merge ar934x_bo_ddr_flush patch	Gabor Juhos	2012-03-12	1	-12/+5
| | | |	SVN-Revision: 30912
*	ar71xx: fix WPS button polarity on TL-WR2543N	Gabor Juhos	2012-03-07	1	-0/+1
| | | |	SVN-Revision: 30849
*	ar71xx: merge files-3.2 to files	Gabor Juhos	2012-02-10	65	-0/+9472
| | | |	SVN-Revision: 30405
*	ar71xx: move arch specific files to files-2.6.39	Gabor Juhos	2012-01-22	104	-15552/+0
| | | |	SVN-Revision: 29867
*	ar71xx: change board id of the UniFi board	Gabor Juhos	2012-01-22	1	-1/+1
| | | |	SVN-Revision: 29849
*	ar71xx: move irq_to_gpio and gpio_to_irq into gpio.c	Gabor Juhos	2012-01-11	2	-12/+14
| | | |	SVN-Revision: 29713
*	ar71xx: add initial support for the TL-WR2543N/ND board	Gabor Juhos	2012-01-07	4	-0/+140
| | | | | |	The WLAN LEDs are not working yet. SVN-Revision: 29680
*	ar71xx: local mac support on the wndr3700	Gabor Juhos	2012-01-07	1	-2/+13
| | | | | | | | | | | | | |	The wndr3700 at least has no eth0 mac address and usually leverages the first wireless device's mac when in a bridged scenario. If, however, you want to route, and not bridge the interfaces, you need a unique mac address for it. This patch sets the local bit on the mac address pulled from the wireless chip and uses the resulting address for eth0. Patch-by: Dave Taht <dave.taht@gmail.com> SVN-Revision: 29675
*	ar71xx: add support for Redwave RW2458N	Gabor Juhos	2012-01-06	4	-0/+112
| | | | | |	Signed-off-by: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> SVN-Revision: 29669
*	ar71xx: add inital support for the ALFA Network AP96 board	Gabor Juhos	2012-01-04	4	-0/+165
| | | | | | | |	The microSD slot and the Real Time Clock is not working yet. The miniPCIe interface is not tested due to the lack of a suitable card. SVN-Revision: 29662
*	ar71xx: allow to use the command line hack on compex devices	Gabor Juhos	2012-01-04	1	-29/+31
| | | |	SVN-Revision: 29659
*	ar71xx: use the TL-MR3x20 code for the TL-WR841N/ND v7	Gabor Juhos	2012-01-04	2	-12/+33
| | | | | | |	These models are based on the AP99 reference board, and uses the AR7241 SoC. SVN-Revision: 29658
*	ar71xx: allow to use LAN LED on the TL-WA901N/ND boards	Gabor Juhos	2012-01-04	1	-0/+11
| | | |	SVN-Revision: 29653
*	ar71xx: add support for TP-Link TL-MR3020	Gabor Juhos	2012-01-04	4	-0/+133
| | | | | | | | | | | | | | | | | | | | | | | |	This patch adds support for the TP-Link device TL-MR3020 which is very similiar to the TL-WR703N. The TL-MR3020 uses 5 LEDs, 1 push button and a switch with 3 positions. Only four LEDs can be controlled via GPIO. The power LED is connected to the power supply. The WPS push button has been mapped to KEY_WPS_BUTTON. The two GPIO signals of the sliding switch have been mapped to BTN_0 and BTN_1. I have also setup a wiki page with details here: http://wiki.openwrt.org/toh/tp-link/tl-mr3020 USB is working and has been tested with USB mass storage and USB UMTS stick. Wifi also seems to work. Ethernet is working too. Signed-off-by: Christian Cier-Zniewski <c.cier@gmx.de> SVN-Revision: 29651
*	ar71xx: add support for the ALFA Network N2/N5 boards	Gabor Juhos	2012-01-01	4	-0/+169
| | | |	SVN-Revision: 29635
*	ar71xx: define LAN/WAN LEDs for the TL-WR741N/ND boards	Gabor Juhos	2011-12-31	2	-5/+68
| | | |	SVN-Revision: 29631
*	ar71xx: fix LEDs on the WRT400N	Gabor Juhos	2011-12-31	1	-11/+12
| | | |	SVN-Revision: 29624
*	the mach file of the WZR-HP-G300NH2 accidentally claimed the mach id of the ↵	Jo-Philipp Wich	2011-12-21	1	-1/+1
| | | | | |	WZR-HP-AG300H, correct the id (#10649) SVN-Revision: 29593
*	ar71xx: add missing wireless led changes for wzr-hp-g300nh2	Felix Fietkau	2011-12-19	1	-6/+1
| | | |	SVN-Revision: 29568
*	ar71xx: add support for the wzr-hp-g300nh2	Felix Fietkau	2011-12-18	4	-0/+206
| | | | | |	Signed-off-by: Mark Deneen <mdeneen@gmail.com> SVN-Revision: 29567
*	ar71xx: connect GMAC0 to the internal switch on DB120	Gabor Juhos	2011-12-15	1	-1/+29
| | | | | | | |	Because the external switch has no driver yet, connect GMAC0 to the PHY4 of the internal switch for now. This allows to use the DB120 board as a router with 4LAN+1WAN ports. SVN-Revision: 29557
*	ar71xx: add defines for the AR934X GMAC interface	Gabor Juhos	2011-12-15	1	-0/+21
| | | |	SVN-Revision: 29556
*	ar71xx: fix GMAC1 interface speed on the DB120 board	Gabor Juhos	2011-12-15	1	-1/+1
| | | |	SVN-Revision: 29555
*	ar71xx: ag71xx: allow to connect PHY4 to the CPU on AR934X	Gabor Juhos	2011-12-15	1	-1/+1
| | | |	SVN-Revision: 29553
*	ar71xx: allow to attach the internal switch for AR934x	Gabor Juhos	2011-12-15	1	-0/+2
| | | |	SVN-Revision: 29550
*	ar71xx: introduce ar71xx_switch_data	Gabor Juhos	2011-12-15	3	-3/+12
| | | |	SVN-Revision: 29549
*	ar71xx: fix mac addresses on jjPlus devices	Gabor Juhos	2011-12-15	2	-0/+4
| | | |	SVN-Revision: 29538
*	ar71xx: add support for ALFA Network's Hornet-UB board	Gabor Juhos	2011-12-14	4	-0/+145
| | | |	SVN-Revision: 29535
*	ar71xx: add GPIO function bit defines for AR933X	Gabor Juhos	2011-12-14	1	-0/+21
| | | |	SVN-Revision: 29534
*	ar71xx: fix gpio count for ar7241/ar7242	Felix Fietkau	2011-12-14	2	-2/+6
| | | |	SVN-Revision: 29532
*	ar71xx: register extra leds behind the wireless mac on wzr-hp-g450h	Felix Fietkau	2011-12-14	3	-0/+26
| | | |	SVN-Revision: 29531
*	ar71xx: fix wireless led on wzr-hp-g450h	Felix Fietkau	2011-12-13	1	-0/+1
| | | |	SVN-Revision: 29515
*	ar71xx: enable AR9341 support at setup.c	Gabor Juhos	2011-12-13	1	-0/+6
| | | | | |	Patch-by: dyq <729650915@qq.com> SVN-Revision: 29514
*	ar71xx: Build images for Netgear WNDRMAC and WNDRMACv2	Gabor Juhos	2011-12-13	2	-2/+3
| | | | | | | | | | | | | | | | | | |	The WNDRMAC is a WNDR3700v2 (64MB RAM, 16MB flash) in a white case. The WNDRMACv2 is a WNDR3800 (128MB RAM, 16MB flash) in a WNDRMAC case. The WNDRMAC case doesn't have "holes" or labels for the 2.4GHz LED or switch ports 2-4. The stock firmware uses a single LED (in the 5GHz position) to indicate the status of both radios, and a single LED (in the switch port 1 position) to indicate the status of all LAN ports. The "missing" LEDs are present on the board, and easily shine through the case. Unlike the stock firmware, OpenWrt will use these "hidden" LEDs. I've tested the WNDRMACv2 image. I don't have a v1 WNDRMAC, but assume that this is sufficient to build a fully-functional image. Signed-off-by: Mark Mentovai <mark@moxienet.com> SVN-Revision: 29513
*	ar71xx: add gpios and usb for wzr-hp-g450h	Felix Fietkau	2011-12-13	1	-2/+73
| | | |	SVN-Revision: 29509
*	ar71xx: use RedBoot parser on PB44	Gabor Juhos	2011-12-11	1	-0/+10
| | | |	SVN-Revision: 29501
*	ar71xx: use correct mac on the lan interface on several TP-LINK devices	Gabor Juhos	2011-12-05	3	-6/+6
| | | |	SVN-Revision: 29458
*	ar71xx: allow to pass negative offset values for ar71xx_init_mac	Gabor Juhos	2011-12-05	2	-3/+3
| | | |	SVN-Revision: 29457
*	ar71xx: don't register PCI controller on AR934x if PCIE_RC bit is not set	Gabor Juhos	2011-12-05	1	-2/+7
| | | |	SVN-Revision: 29456

• [prev]
• [next]

generated by cgit v1.2.3 (git 2.25.1) at 2025-09-27 14:32:11 +0000

# Advanced googletest Topics

<!-- GOOGLETEST_CM0016 DO NOT DELETE -->

## Introduction

Now that you have read the [googletest Primer](primer.md) and learned how to
write tests using googletest, it's time to learn some new tricks. This document
will show you more assertions as well as how to construct complex failure
messages, propagate fatal failures, reuse and speed up your test fixtures, and
use various flags with your tests.

## More Assertions

This section covers some less frequently used, but still significant,
assertions.

### Explicit Success and Failure

These three assertions do not actually test a value or expression. Instead, they
generate a success or failure directly. Like the macros that actually perform a
test, you may stream a custom failure message into them.

```c++
SUCCEED();
```

Generates a success. This does **NOT** make the overall test succeed. A test is
considered successful only if none of its assertions fail during its execution.

NOTE: `SUCCEED()` is purely documentary and currently doesn't generate any
user-visible output. However, we may add `SUCCEED()` messages to googletest's
output in the future.

```c++
FAIL();
ADD_FAILURE();
ADD_FAILURE_AT("file_path", line_number);
```

`FAIL()` generates a fatal failure, while `ADD_FAILURE()` and `ADD_FAILURE_AT()`
generate a nonfatal failure. These are useful when control flow, rather than a
Boolean expression, determines the test's success or failure. For example, you
might want to write something like:

```c++
switch(expression) {
  case 1:
     ... some checks ...
  case 2:
     ... some other checks ...
  default:
     FAIL() << "We shouldn't get here.";
}
```

NOTE: you can only use `FAIL()` in functions that return `void`. See the
[Assertion Placement section](#assertion-placement) for more information.

### Exception Assertions

These are for verifying that a piece of code throws (or does not throw) an
exception of the given type:

Fatal assertion                            | Nonfatal assertion                         | Verifies
------------------------------------------ | ------------------------------------------ | --------
`ASSERT_THROW(statement, exception_type);` | `EXPECT_THROW(statement, exception_type);` | `statement` throws an exception of the given type
`ASSERT_ANY_THROW(statement);`             | `EXPECT_ANY_THROW(statement);`             | `statement` throws an exception of any type
`ASSERT_NO_THROW(statement);`              | `EXPECT_NO_THROW(statement);`              | `statement` doesn't throw any exception

Examples:

```c++
ASSERT_THROW(Foo(5), bar_exception);

EXPECT_NO_THROW({
  int n = 5;
  Bar(&n);
});
```

**Availability**: requires exceptions to be enabled in the build environment

### Predicate Assertions for Better Error Messages

Even though googletest has a rich set of assertions, they can never be complete,
as it's impossible (nor a good idea) to anticipate all scenarios a user might
run into. Therefore, sometimes a user has to use `EXPECT_TRUE()` to check a
complex expression, for lack of a better macro. This has the problem of not
showing you the values of the parts of the expression, making it hard to
understand what went wrong. As a workaround, some users choose to construct the
failure message by themselves, streaming it into `EXPECT_TRUE()`. However, this
is awkward especially when the expression has side-effects or is expensive to
evaluate.

googletest gives you three different options to solve this problem:

#### Using an Existing Boolean Function

If you already have a function or functor that returns `bool` (or a type that
can be implicitly converted to `bool`), you can use it in a *predicate
assertion* to get the function arguments printed for free:

<!-- mdformat off(github rendering does not support multiline tables) -->

| Fatal assertion                   | Nonfatal assertion                | Verifies                    |
| --------------------------------- | --------------------------------- | --------------------------- |
| `ASSERT_PRED1(pred1, val1)`       | `EXPECT_PRED1(pred1, val1)`       | `pred1(val1)` is true       |
| `ASSERT_PRED2(pred2, val1, val2)` | `EXPECT_PRED2(pred2, val1, val2)` | `pred2(val1, val2)` is true |
| `...`                             | `...`                             | `...`                       |

<!-- mdformat on-->
In the above, `predn` is an `n`-ary predicate function or functor, where `val1`,
`val2`, ..., and `valn` are its arguments. The assertion succeeds if the
predicate returns `true` when applied to the given arguments, and fails
otherwise. When the assertion fails, it prints the value of each argument. In
either case, the arguments are evaluated exactly once.

Here's an example. Given

```c++
// Returns true if m and n have no common divisors except 1.
bool MutuallyPrime(int m, int n) { ... }

const int a = 3;
const int b = 4;
const int c = 10;
```

the assertion

```c++
  EXPECT_PRED2(MutuallyPrime, a, b);
```

will succeed, while the assertion

```c++
  EXPECT_PRED2(MutuallyPrime, b, c);
```

will fail with the message

```none
MutuallyPrime(b, c) is false, where
b is 4
c is 10
```

> NOTE:
>
> 1.  If you see a compiler error "no matching function to call" when using
>     `ASSERT_PRED*` or `EXPECT_PRED*`, please see
>     [this](faq.md#the-compiler-complains-no-matching-function-to-call-when-i-use-assert-pred-how-do-i-fix-it)
>     for how to resolve it.

#### Using a Function That Returns an AssertionResult

While `EXPECT_PRED*()` and friends are handy for a quick job, the syntax is not
satisfactory: you have to use different macros for different arities, and it
feels more like Lisp than C++. The `::testing::AssertionResult` class solves
this problem.

An `AssertionResult` object represents the result of an assertion (whether it's
a success or a failure, and an associated message). You can create an
`AssertionResult` using one of these factory functions:

```c++
namespace testing {

// Returns an AssertionResult object to indicate that an assertion has
// succeeded.
AssertionResult AssertionSuccess();

// Returns an AssertionResult object to indicate that an assertion has
// failed.
AssertionResult AssertionFailure();

}
```

You can then use the `<<` operator to stream messages to the `AssertionResult`
object.

To provide more readable messages in Boolean assertions (e.g. `EXPECT_TRUE()`),
write a predicate function that returns `AssertionResult` instead of `bool`. For
example, if you define `IsEven()` as:

```c++
::testing::AssertionResult IsEven(int n) {
  if ((n % 2) == 0)
     return ::testing::AssertionSuccess();
  else
     return ::testing::AssertionFailure() << n << " is odd";
}
```

instead of:

```c++
bool IsEven(int n) {
  return (n % 2) == 0;
}
```

the failed assertion `EXPECT_TRUE(IsEven(Fib(4)))` will print:

```none
Value of: IsEven(Fib(4))
  Actual: false (3 is odd)
Expected: true
```

instead of a more opaque

```none
Value of: IsEven(Fib(4))
  Actual: false
Expected: true
```

If you want informative messages in `EXPECT_FALSE` and `ASSERT_FALSE` as well
(one third of Boolean assertions in the Google code base are negative ones), and
are fine with making the predicate slower in the success case, you can supply a
success message:

```c++
::testing::AssertionResult IsEven(int n) {
  if ((n % 2) == 0)
     return ::testing::AssertionSuccess() << n << " is even";
  else
     return ::testing::AssertionFailure() << n << " is odd";
}
```

Then the statement `EXPECT_FALSE(IsEven(Fib(6)))` will print

```none
  Value of: IsEven(Fib(6))
     Actual: true (8 is even)
  Expected: false
```

#### Using a Predicate-Formatter

If you find the default message generated by `(ASSERT|EXPECT)_PRED*` and
`(ASSERT|EXPECT)_(TRUE|FALSE)` unsatisfactory, or some arguments to your
predicate do not support streaming to `ostream`, you can instead use the
following *predicate-formatter assertions* to *fully* customize how the message
is formatted:

Fatal assertion                                  | Nonfatal assertion                               | Verifies
------------------------------------------------ | ------------------------------------------------ | --------
`ASSERT_PRED_FORMAT1(pred_format1, val1);`       | `EXPECT_PRED_FORMAT1(pred_format1, val1);`       | `pred_format1(val1)` is successful
`ASSERT_PRED_FORMAT2(pred_format2, val1, val2);` | `EXPECT_PRED_FORMAT2(pred_format2, val1, val2);` | `pred_format2(val1, val2)` is successful
`...`                                            | `...`                                            | ...