Re: [PATCH] gpiolib: handle probe deferrals better

[Alexander Stein <alexander.stein@xxxxxxxxxxxxxxxxxxxxx>]

On Friday 01 April 2016 17:03:08, Grygorii Strashko wrote:
> > So in my case, I would expect that gpio-keys probe fails due to missing
> > IRQ
> > parent and gets deferred. Once the IRQ parent happen to be probed
> > successfully at some point gpio-keys is probed again and succeeds.
> 
> I assume in your case It's devm_gpio_request_one() first of all, which
> follows by gpio_to_irq.

I think nothing is wrong with that. The problem is that the former succeeds 
while the latter doesn't although from a device view point the GPIO chip is 
already there.

> > Consider the following cascading GPIO chips:
> >   /-------\                /---------\                 /--------\
> > |
> > |MCP23S17 + Pin1 <--> IRQ-+ PCA9555 + Pin 1 <--> IRQ + MCP23S17 +
> > |
> >   \-------/                 \-------/                  \--------/
> > 
> > Probing should still work for this scenario. This is something modprobe
> > cannot fix.
> 
> What I can see from my boot log is that at module loading time log output
> from many drivers is mixed which makes me think that this parallel process
> (udev) - and no I've not hit this issue..yet.

I think parallel device probing is expectable and reasonable. I guess to hit 
this issue you need a device which requires GPIOs and their corresponding IRQ 
and probing of that must be done while GPIO chip is attached but not it's IRQ 
chip.

Best regards,
Alexander

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html