Re: [PATCH v4] gpio: Return EPROBE_DEFER if gc->to_irq is NULL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bartosz Golaszewski <brgl@xxxxxxxx> writes:

> My email address changed in September, that's why I didn't see the
> email you sent in November to my old one.

Hi Bart,

thanks for the prompt reply and sorry for the wrong email address.

> gpiod_to_irq() can be used in context other than driver probing, I'm
> worried existing users would not know how to handle it. Also: how come
> you can get the GPIO descriptor from the provider but its interrupts
> are not yet set up?

I'm definitely some context here, as its been quite a while.
Shreeya, feel free to pitch in. :)

This is one of the races we saw in gpiochip_add_irqchip, depending on
the probe order.  The gc is already visible while partially initialized,
if pinctrl-amd hasn't been probed yet.  Another device being probed can
hit an -ENXIO here if to_irq is yet uninitialized or enter .to_irq() and
oops.  Shreeya's patch workarounds the first issue, but is not a
solution for the second.

There is another patch that has been flying around to address the Oops.

https://lkml.org/lkml/2021/11/8/900

She's been working on a proper solution for that one, which might
actually address this too and replace the current patch.  Maybe you
could help us get to a proper solution there?  I'm quite unfamiliar with
this code myself :)

-- 
Gabriel Krisman Bertazi



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux