On Fri, Oct 04, 2024 at 04:43:26PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > We currently only notify user-space about line config changes that are > made from user-space. Any kernel config changes are not signalled. > > Let's improve the situation by emitting the events closer to the source. > To that end let's call the relevant notifier chain from the functions > setting direction, gpiod_set_config(), gpiod_set_consumer_name() and > gpiod_toggle_active_low(). This covers all the options that we can > inform the user-space about. > > There is a problem with gpiod_direction_output/input(), namely the fact > that they can be called both from sleeping as well as atomic context. We > cannot call the blocking notifier from atomic and we cannot switch to > atomic notifier because the pinctrl functions we call higher up the stack > take a mutex. Let's instead use a workqueue and schedule a task to emit > the event from process context on the unbound system queue for minimal > latencies. > So now there is a race between the state of the desc changing and the notified reading it? Cheers, Kent. > In tests, I typically get around 5 microseconds between scheduling the > work and it being executed. That could of course differ during heavy > system load but in general it should be enough to not miss direction > change events which typically are not in hot paths. > > Let's also add non-notifying wrappers around the direction setters in > order to not emit superfluous reconfigure events when requesting the > lines. > > We can also now make gpiod_line_state_notify() static. > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>