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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
