On Sat, Oct 05, 2024 at 11:42:34AM +0200, Bartosz Golaszewski wrote: > On Sat, Oct 5, 2024 at 9:46 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > > On Fri, Oct 04, 2024 at 04:43:26PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > > > 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? > > > > Theoretically? Well, yes... In practice I don't think this would > matter. But I understand the concern and won't insist if it's a > deal-breaker for you. > I don't like that correctness depends on timing, so this is a deal breaker for me as it stands. I would like to see the relevant state passed via the notifier chain, rather than assuming it can be pulled from the desc when the notifier is eventually called. Cheers, Kent. > Ideally we'd switch to an atomic notifier but I don't have a good idea > on how to handle pinctrl_gpio_can_use_line(). It digs deep into the > pinctrl code and it's all synchronized with a mutex. Unlike GPIO, it > doesn't make any sense to spend days converting pinctrl to SRCU for a > single corner-case. > > I wanted to use in_atomic() to determine whether we can emit the event > immediately or (if we're in interrupt or with a spinlock taken) we > should use a workqueue as a fallback but checkpatch.pl is very adamant > about it being an error (in capital reds). > > Bart