- Copy stable/10@296371 to releng/10.3 in preparation for 10.3-RC1
builds.
- Update newvers.sh to reflect RC1.
- Update __FreeBSD_version to reflect 10.3.
- Update default pkg(8) configuration to use the quarterly branch.

Approved by: re (implicit)

MFC r274670, r274671, r276168:

Moves all the duplicate code to a single function.

Verify for invalid modes and unwanted flags before pass the new flags to
driver.

Make gpio_default_map_gpios() static. No functional changes.

Improves the GPIO API description a little bit.

gpio_pin_max must return the maximum supported pin number and not the total
number of pins on the system.

MFC r273799:

Make the GPIO children attach to the first unit available and not only to
unit 0.

This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.

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.