src/sys/dev/gpio, branch release/12.3.0

gpioc_detach: fix freeing of wrong pointers

2021-05-03T20:14:49Z

MFC after: 1 week (cherry picked from commit 3c6b59567f61277ed487320aa9ad130c6894ad7a)

MFC 368585:

2020-12-16T17:09:38Z

Provide userland notification of gpio pin changes ("userland gpio interrupts"). This is an import of the Google Summer of Code 2018 project completed by Christian Kramer (and, sadly, ignored by us for two years now). The goals stated for that project were: FreeBSD already has support for interrupts implemented in the GPIO controller drivers of several SoCs, but there are no interfaces to take advantage of them out of user space yet. The goal of this work is to implement such an interface by providing descriptors which integrate with the common I/O system calls and multiplexing mechanisms. The initial imported code supports the following functionality: - A kernel driver that provides an interface to the user space; the existing gpioc(4) driver was enhanced with this functionality. - Implement support for the most common I/O system calls / multiplexing mechanisms: - read() Places the pin number on which the interrupt occurred in the buffer. Blocking and non-blocking behaviour supported. - poll()/select() - kqueue() - signal driven I/O. Posting SIGIO when the O_ASYNC was set. - Many-to-many relationship between pins and file descriptors. - A file descriptor can monitor several GPIO pins. - A GPIO pin can be monitored by multiple file descriptors. - Integration with gpioctl and libgpio. I added some fixes (mostly to locking) and feature enhancements on top of the original gsoc code. The feature ehancements allow the user to choose between detailed and summary event reporting. Detailed reporting provides a record describing each pin change event. Summary reporting provides the time of the first and last change of each pin, and a count of how many times it changed state since the last read(2) call. Another enhancement allows the recording of multiple state change events on multiple pins between each call to read(2) (the original code would track only a single event at a time). The phabricator review for these changes timed out without approval, but I cite it below anyway, because the review contains a series of diffs that show how I evolved the code from its original state in Christian's github repo for the gsoc project to what is being commited here. (In effect, the phab review extends the VC history back to the original code.) Submitted by: Christian Kramer Obtained from: https://github.com/ckraemer/freebsd/tree/gsoc2018 Differential Revision: https://reviews.freebsd.org/D27398

MFC r364145: gpiokeys: add evdev support

2020-09-07T06:14:42Z

Only linux,code is supported as it maps 1:1 to evdev key codes. No reverse mapping for freebsd,code yet.

MFC r363382: gpioiic: never drive lines active high

2020-07-30T14:01:54Z

Few drivers support GPIO_PIN_OPENDRAIN.

MFC r362492: gpiobus_release_pin: remove incorrect prefix from error messages

2020-07-30T13:17:01Z

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

2020-05-22T12:05:01Z

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 r355206, r355212, r355257, r355271: tty nits

2019-12-22T19:06:45Z

r355206: tty_pts: don't rely on tty header pollution for sys/mutex.h r355212: tty_rel_gone: add locking assertion r355257: usb: remove some extraneous tty.h includes r355271: Remove more needless includes

MFC r355467, r355499, r355531-r355533, r355535, r355540, r355548-r355551, r355565

2019-12-22T18:51:05Z

r355467: Implement bus_rescan for gpiobus(4). This allows on-the-fly reconfiguration of gpio devices by using kenv to add hints for a new device and then do 'devctl rescan gpiobus4' to make the new device(s) attach. It's not particularly easy to detect whether the 'at' hint has been deleted for a child device that's currently attached, so this doesn't handle that. But the user can use devctl commands to manually detach an existing device. r355499: Add module build stuff for gpioths(4), a driver for DHT11/DHT22 sensors. r355531: Several small fixes for the gpioths (temp/humidity sensor) driver. At the end of a read cycle, set the gpio pin to INPUT rather than OUTPUT. The state of the single-wire "bus" when idle should be high; setting the pin to input allows the external pullup to pull the line high. Setting it to output (and leaving it driving low) was leading a good read cycle followed by one that would fail, and it just continued like that forever, effectively reading the sensor once every 10 seconds instead of 5. In the attach function, do an initial read from the device before registering the sysctls for accessing the last-read values, to prevent reading spurious values for the first 5 seconds after the driver attaches. Do a callout_drain() in the detach function to prevent crashes after unloading the module. r355532: Simplify sysctl stuff in the gpioths driver. There is no need to use local functions to handle the sysctls, they all just access simple readonly integer variables. There's no need to track the oids of the ones we add, since the teardown is done by newbus code, not the driver itself. Also remove the DDB code, because it just provides access to the same data that the sysctls already provide. r355533: Add support for more chips to the gpioths driver. Previously the driver supported the DHT11 sensor. Now it supports DHT11, DHT12, DHT21, DHT22, AM3201, AM3202. All these chips are similar, differing primarily in supported temperature and humidity ranges and accuracy (and, presumably, cost). There are two basic data formats reported by the various chips, and it is possible to figure out at runtime which format to use for decoding the data based on the range of values in a single byte of the humidity measurement. (which is detailed in a comment block, so I won't recapitulate it here). r355535: Add a MODULE_DEPEND() for the gpioths driver. Also, note that the prior commit changed the sysctl format for the temperature from "I" to "IK", and correspondingly changed the units from integer degrees C to decikelvin. For access via sysctl(8) the output will be the same except that now decimal fractions will be shown when available. r355540: Add FDT support to the gpioths driver. It now uses the newer gpio_pin_*() API and can attach based on either hints or fdt data. r355548: Add a man page for the gpioths(4) driver. r355549: Add myself to the copyright list. Also add an SPDX tag. And finally, fix a missing word and a spelling error in a comment. r355550: Paste things correctly so that I'm added to the *end* of the copyright list. r355551: Connect the gpioths(4) manpage to the build. r355565: Switch gpioths(4) from using a callout to a taskqueue for periodic polling of the sensor hardware. Part of the polling process involves signalling the chip then waiting 20 milliseconds. This was being done with DELAY(), which is a pretty rude thing to do in a callout. Now a taskqueue_thread task is scheduled to do the polling, and because sleeping is allowed in the task context, pause_sbt() replaces DELAY() for the 20ms wait.

MFC r355796-r355797, r355799: kbd: defaults for get_fkeystr/diag

2019-12-22T17:15:48Z

The genkbd version of these remains exposed for stable branches, but keyboard drivers that just want to use the defaults can simply not provide their own. There shouldn't be any unset in the wild. r355796: kbd: provide default implementations of get_fkeystr/diag Most keyboard drivers are using the genkbd implementations as it is; formally use them for any that aren't set. r355797: chrome_kb: remove default get_fkeystr/diag implementations This file was missed in r355796, but no harm would have come from this. r355799: kbd: patch linker set methods, too This is needed after r355796. Some double-registration of kbd drivers needs to be sorted out, then this sysinit will simply add these drivers into the normal list and kill off any other bits in the driver that are aware of the linker set, for simplicity.

MFC r355793: kbd drivers: use kbdd_* indirection for diag invocation

2019-12-22T17:06:56Z