K 10
svn:author
V 3
ian
K 8
svn:date
V 27
2019-12-07T17:10:03.797907Z
K 7
svn:log
V 3841
MFC r355214, r355239, r355274, r355276-r355277, r355295, r355298

r355214:
Ignore "gpio-hog" nodes when instantiating ofw_gpiobus children.  Also,
in ofw_gpiobus_probe() return BUS_PROBE_DEFAULT rather than 0; we are not
the only possible driver to handle this device, we're just slightly better
than the base gpiobus (which probes at BUS_PROBE_GENERIC).

In the time since this code was first written, the gpio controller bindings
aquired the concept of a "hog" node which could be used to preset one or
more gpio pins as input or output at a specified level.  This change doesn't
fully implement the hogging concept, it just filters out hog nodes when
instantiating child devices by scanning for child nodes in the fdt data.

The whole concept of having child nodes under the controller node is not
supported by the standard bindings, and appears to be a freebsd extension,
probably left over from the days when we had no support for cross-tree
phandle references in the fdt data.

r355239:
Add an OFWBUS_PNP_INFO() macro for devices that hang directly off the root
ofwbus.  Also, apply some style(9) whitespace fixing to the
SIMPLEBUS_PNP_INFO() macro (no functional change).

r355274:
Move most of the gpio_pin_* functions from ofw_gpiobus.c to gpiobus.c so
that they can be used by drivers on non-FDT-configured systems.  Only the
functions related to acquiring pins by parsing FDT data remain in
ofw_gpiobus.  Also, add two new functions for acquiring gpio pins based on
child device_t and index, or on the bus device_t and pin number.  And
finally, defer reserving pins for gpiobus children until they acquire the
pin, rather than reserving them as soon as the child is added (before it's
even known whether the child will attach).

This will allow drivers configured with hints (or any other mechanism) to
use the same code as drivers configured via FDT data.  Until now, a hinted
driver and an FDT driver had to be two completely different sets of code,
because hinted drivers could only use gpiobus calls to manipulate pins,
while fdt-configured drivers could not use that API (due to not always being
children of the bus that owns the pins) and had to use the newer
gpio_pin_xxxx() functions.  Now drivers can be written in the more
traditional form, where most of the code is shared and only the resource
acquisition code at attachment time changes.

r355276:
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.

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

r355295:
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.

r355298:
Do not initialize the flags field in struct gpiobus_pin from the flags in
struct gpio_pin.  It turns out these two sets of flags are completely
unrelated to each other.

Also, update the comment for GPIO_ACTIVE_LOW to reflect the fact that it
does get set, somewhat unobviously, by code that parses FDT data.  The bits
from the FDT cell containing flags are just copied to gpiobus_pin.flags, so
there's never any obvious reference to the symbol GPIO_ACTIVE_LOW being
stored into the flags field.

END