sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

gpio: Remove unused devclass arguments to DRIVER_MODULE.

Remove unused iicbb_devclass.

Revert "Define PNP info after defining driver modules"

This reverts commit aa37baf3d7cf51da92fd367476182802e71838ae.

The reverted commit was motivated by a problem observed on stable/12,
but it turns out that a better solution was committed in r348309 but not
MFCed. So, revert this change since it is unnecessary and not really
correct: it assumes that the order in which module metadata records is
defined determines their order in the output linker set. While this
seems to hold in my testing, it is not guaranteed.

Reported by: cem
Discussed with: imp
MFC after: 3 days

Define PNP info after defining driver modules

PNP info definitions currently have an unfortunate requirement in that
they must follow the associated module definition in the module metadata
linker set. Otherwise devmatch can segfault while processing the linker
hints file since kldxref maintains the order in the linker set.

A number of drivers violate this requirement. In some cases this can
cause devmatch(8) to segfault when processing the linker hints file.
Work around the problem for now simply by adjusting the drivers.

Reviewed by: imp
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D28260

gpioiic: never drive lines active high

I2C communication is done by a combination of driving a line low or
letting it float, so that it is either pulled up or driven low by
another party.

r355276 besides the stated goal of the change -- using the new GPIO API
-- also changed the logic, so that active state is signaled by actively
driving a line.

That worked with iicbb prior to r362042, but stopped working after that
commit on at least some hardware. My guess that the breakage was
related to getting an ACK bit. A device expected to be able to drive
SDA actively low, but controller was actively driving it high for some
time.

Anyway, this change seems to fix the problem.
Tested using gpioiic on Orange Pi PC Plus with HTU21 sensor.

Reported by: Nick Kostirya <nikolay.kostirya@i11.co>
Reviewed by: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25684

gpioiic_attach: fix a NULL pointer crash on hints-based systems

The attach method uses GPIO_GET_BUS() to get a "newbus" device
that provides a pin. But on hints-based systems a GPIO controller
driver might not be fully initialized yet and it does not know gpiobus
hanging off it. Thus, GPIO_GET_BUS() cannot be called yet.
The reason is that controller drivers typically create a child gpiobus
using gpiobus_attach_bus() and that leads to the following call chain:
gpiobus_attach_bus() -> gpiobus_attach() ->
bus_generic_attach(gpiobus) -> gpioiic_attach().
So, gpioiic_attach() is called before gpiobus_attach_bus() returns.

I observed this bug with nctgpio driver on amd64.
I think that the problem was introduced in r355276.

The fix is to avoid calling GPIO_GET_BUS() from the attach method.
Instead, we know that on hints-based systems only the parent gpiobus can
provide the pins.
Nothing is changed for FDT-based systems.

MFC after: 1 week

Remove "all rights reserved" from copyright after getting a response from
Luiz that he also was not intentionally asserting that right, it was already
there when he added his name.

Fix leading whitespace (spaces->tabs) in comments; no functional change.

Rewrite gpioiic(4) to use the gpio_pin_* API, and to conform to the modern
FDT bindings document for gpio-i2c devices.

Using the gpio_pin_* functions to acquire/release/manipulate gpio pins
removes the constraint that both gpio pins must belong to the same gpio
controller/bank, and that the gpioiic instance must be a child of gpiobus.
Removing those constraints allows the driver to be fully compatible with
the modern dts bindings for a gpio bitbanged i2c bus.

For hinted attachment, the two gpio pins still must be on the same gpiobus,
and the device instance must be a child of that bus. This preserves
compatibility for existing installations that have use gpioiic(4) with hints.

gpioiic: set output after switching to output mode if presetting it failed

Some controllers cannot preset future output value while the pin is in
input mode. This adds a fallback for those controllers. The new code
assumes that a controller reports an error in that case.

For example, all hardware supported by nctgpio behaves in that way.

This is a temporary measure. In the future we will use
GPIO_PIN_PRESET_LOW / GPIO_PIN_PRESET_HIGH to preset the output either
in hardware, if supported, or in software (e.g., in
gpiobus_pin_setflags).

While here, I extracted common functionality of gpioiic_set{sda,scl} and
gpioiic_get{sda,scl} to gpioiic_setpin and gpioiic_getpin respectively.

MFC after: 2 weeks

gpioiic: add the detach method

bus_generic_detach was not enough, we also need to clean up the iicbus
child device.

MFC after: 1 week

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Sort and remove a couple of unnecessary headers.

Get rid of two consumers of gpiobus acquire/release.

The GPIO hardware should not be owned by a single device, this defeats any
chance of use of the GPIO controller as an interrupt source.

ow(4) is now the only consumer of this 'feature' before we can remove it
for good.

Discussed with: ian, bsdimp

Use a better prefix for defines, return BUS_PROBE_DEFAULT for probe routine.

Refuse to attach if the number of given pins is not enough for our needs.

Use DEVMETHOD_END instead of its value to indicate end of methods table

Fix IIC "how" argument dereferencing on big-endian platforms

"how" argument is passed as value of int* pointer to callback
function but dereferenced as char* so only one byte taken into
into account. On little-endian systems it happens to work because
first byte is LSB that contains actual value, on big-endian it's
MSB and in this case it's always equal zero

PR: 207786
Submitted by: chadf@triularity.org

Fix the gpiobus locking by using a more sane model where it isn't necessary
hold the gpiobus lock between the gpio calls.

gpiobus_acquire_lock() now accepts a third parameter which tells gpiobus
what to do when the bus is already busy.

When GPIOBUS_WAIT wait is used, the calling thread will be put to sleep
until the bus became free.

With GPIOBUS_DONTWAIT the calling thread will receive EWOULDBLOCK right
away and then it can act upon.

This fixes the gpioiic(4) locking issues that arises when doing multiple
concurrent access on the bus.

Add a bounds verification to the SCL and SDA pin values.

At attach, print the SCL and SDA pin numbers.

Remove a stray blank line.

Remove the GPIOBUS locking from gpioiic_reset(), it is already called with
this lock held. This fixes a crash when you try to scan the iicbus with
i2c(8).

Add OFW support to the in tree gpio compatible devices: gpioiic(4) and
gpioled(4).

Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for
the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx)
used as reference for a non OFW-based system.

Update the gpioled(4) and gpioiic(4) man pages with some details and
examples about the FDT/OFW support.

Some compatibility details pointed out by imp@ will follow in subsequent
commits.

Approved by: adrian (mentor, implicit)

Remove unnecessary includes and an unused softc variable. While here apply
two minor style(9) fixes.

Approved by: adrian (mentor)

Fix broken locking that I introduced in the previous commit.

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.

Modify the GPIO i2c bus code to allow for arbitrary data/clock
pins, rather than defaulting to 0 and 1.

This way the pin order can be reversed. It is reversed with the
TP-Link TL-WR1043nd.

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

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Fix legal staff in GPIO sources:
- license clause now contains "AUTHOR AND CONTRIBUTORS"
instead of just "AUTHOR"
- Add license/copyright to gpioc.c

Spotted by: Edward Tomasz Napierala, Andrew Turner

Initial GPIO bus support. Includes:
- GPIO bus controller interface
- GPIO bus interface
- Implementation of GPIO led(4) compatible device
- Implementation of iic(4) bus over GPIO (author: Luiz Otavio O Souza)

Tested by: Luiz Otavio O Souza, Alexandr Rybalko