pt., 20 mar 2020 o 11:59 Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> napisał(a): > > Hi Bartosz, > > On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > > > We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken > > as it takes a mutex internally. Let's move the call before taking the > > spinlock and store the return value. > > > > This isn't perfect - there's a moment between calling > > pinctrl_gpio_can_use_line() and taking the spinlock where the situation > > can change but it isn't a regression either: previously this part wasn't > > protected at all and it only affects the information user-space is > > seeing. > > > > Reported-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> > > Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo") > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > Thanks for your patch! > > > --- a/drivers/gpio/gpiolib.c > > +++ b/drivers/gpio/gpiolib.c > > @@ -1154,8 +1154,19 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc, > > struct gpioline_info *info) > > { > > struct gpio_chip *chip = desc->gdev->chip; > > + bool ok_for_pinctrl; > > unsigned long flags; > > > > + /* > > + * This function takes a mutex so we must check this before taking > > + * the spinlock. > > + * > > + * FIXME: find a non-racy way to retrieve this information. Maybe a > > + * lock common to both frameworks? > > + */ > > + ok_for_pinctrl = pinctrl_gpio_can_use_line( > > + chip->base + info->line_offset); > > Note that this is now called unconditionally, while before it was only called > if all previous steps in the ||-pipeline failed. > Is this a problem though? Doesn't seem so. Am I missing something? Bart