On 04/01/2016 04:42 PM, Alexander Stein wrote: > On Friday 01 April 2016 15:03:40, Linus Walleij wrote: >> On Fri, Apr 1, 2016 at 2:16 PM, Alexander Stein >> >> <alexander.stein@xxxxxxxxxxxxxxxxxxxxx> wrote: >>> I noticed you fiddle with late_initcall_sync. Sorry, I did not mention it: >>> gpio_mcp23s08 as well as gpio_keys are loaded as modules, so >>> late_initcall_* should not affect it. >> >> I don't get this. I think probe deferral is only used to defer >> initcalls used for built-in drivers. It doesn't. Deferred probing expected to work for modules also. > > To my understanding probe deferral is for the case when the parent or some > other required resource like DT nodes (e.g. panel node for graphics driver) is > not available yet. IIRC all deffered device are probed once a device was > probed sucessfully, no? true. > 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. > >> If there are dependencies among things compiled as modules, >> doesn't depmod/modprobe make sure that they are probed in >> the right order? Could it be that some module alias thingofabob >> is missing? >> >> Or is modprobe failing because it (correctly) see that there is >> no symbol dependencies between the gpio_mcp23s08 and >> gpio-keys modules? (Not that I know how depmod works...) > > I don't think modprobe can or even should do any dependencies here. > 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. > >> If nothing else works, I guess marking mcp23s08 as bool >> and building it into the kernel will work, right? > > This would merely be a workaround and I guess there might be scenarios and/or > random device probing where even this fails. > -- regards, -grygorii -- 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
