- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Remove the hardcoded limit for the number of gpio_pins that can be used.
Allocate it dynamically.

Approved by: adrian (mentor)

Fix an off-by-one bug in ar71xx_gpio and bcm2835_gpio which makes the last
pin unavailable.

Reported and tested by: sbruno (ar71xx)
Approved by: adrian (mentor)
Pointy hat to: loos

Add a missing break.

Teach the GPIO code about the AR934x GPIO register and pin counts.

Add the AR933x SoC GPIO pin count limitation.

Fix undefined behaviour in several gpio_pin_setflags() routines (under
sys/arm and sys/mips), squelching the clang 3.3 warnings about this.

Noticed by: tinderbox and many irate spectators
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
PR: kern/177759
MFC after: 3 days

The GPIO drivers were initialising their mutexes with type of
MTX_NETWORK_LOCK. This is wrong since these mutexes have nothing to do
with networking.

Allow for a default GPIO pin "high", which is required for some boards
which tie the USB device enable to a GPIO line.

Submitted by: Stefan Bethke <stb@lassitu.de>

Remove these locks - they aren't strictly needed and cause measurable
performance issues.

* Access to the GPIO bus is already locked by requesting
and releasing the bus - thus the lock isn't really needed
for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
the i2c bus code is already doing this by calling the upper
layer callback to request/release the bus. This thus locks
the bus for the entirety of the transaction.

TODO:

* Further verify that everything is correctly requesting/
releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
potentially by locking/unlocking the bus at the gpiobus
layer.

Re-jiggle the GPIO code a little to remove the hard-coded AR71xx GPIO
config and function mask setup.

* "gpiomask" now specifies which GPIO pins to enable, for devices to bind to.
* "function_set" allows bits in the function register to be set at GPIO setup.
* "function_clear" allows bits in the function register to be cleared at
GPIO setup.

The function_set/function_clear bits allow for individual GPIO pins to either
drive a GPIO line or an alternate function - eg USB, JTAG, etc. This allows
for things like CS1/CS2 be enabled for those boards w/ >1 SPI device connected,
or disabling JTAG for the AR7240 (which is apparently needed ..)

I've verified this on the AR71xx.

Fix GPIO_MAXPINS calculation for the AR71xx, AR724x, AR913x SoC.

Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>

- Fix values of CS1_EN and CS2_EN flags
- Unbreak kernel build by fixing naming convention of
GPIO_FUNC flags

Spotted by: Luiz Otavio O Souza, Andrew Thompson

Add AR71XX GPIO bus driver.