On Thu, Dec 07, 2023 at 07:37:54PM +0100, Bartosz Golaszewski wrote: > On Tue, Nov 28, 2023 at 11:47 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > [snip] > > > > > Because years of technical debt, that's why. :) > > > > Speaking of technical debt: you may have noticed that despite stating > I'm almost done last week, I still haven't submitted my locking > rework. > > The reason for that is that I'm stuck on some corner-cases related to > the GPIO <-> pinctrl interaction. Specifically the fact that we have > GPIOLIB API functions that may be called from atomic context which may > end up calling into pinctrl where a mutex will be acquired. > > An example of that is any of the GPIO chips that don't set the > can_sleep field in struct gpio_chip but still use > gpiochip_generic_config() (e.g. tegra186). We can then encounter the > following situation: > > irq_handler() // in atomic context > gpiod_direction_output() // line is open-drain > gpio_set_config() > gpiochip_generic_config() > pinctrl_gpio_set_config() > mutex_lock() I don't know of any case (at least on Tegra) where we would change direction in atomic context. In fact, I would argue that configuration like this should never happen in atomic context. Thierry
Attachment:
signature.asc
Description: PGP signature
