With this commit any of the GPIO pins can now be programmed to act as an
interrupt source for GPIO devices (i.e. limited to devices directly
attached to gpiobus - at least for now).
Differential Revision: https://reviews.freebsd.org/D1000
Allocate all four, we will use them soon.
Simplificate the allocation of memory and interrupt resources with a single
bus_alloc_resources() call instead of doing them separately.
Destroy the mutex in case of errors.
With this change, it is now possible to verify the pin function and level
of reserved pins (but not set them).
The use of reserved pins on Raspberry pi can lead to short circuits and
real damage to the SoC.
While here, remove duplicated code, make use of OF_getencprop_alloc()
instead of using fixed sized variables and reduce the dmesg spam by
printing reserved pin ranges (when possible) instead of printing each pin
in the range.
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
change the gpio children can be described as directly connected to the GPIO
controller without the need of describing the OFW GPIO bus itself on the
DTS file.
With this commit the OFW GPIO bus is fully functional on BBB and RPi.
GPIO controllers which want to use the OFW GPIO bus will need similar
changes.
Approved by: adrian (mentor, implicit)
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
really need it. That would be almost everywhere it was included. Add
it in a couple files that really do need it and were previously getting
it by accident via another header.
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