On Fri, Aug 29, 2025 at 8:35 AM Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > Hi Rob, > > On 2025年8月29日 at 14:25, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > On Fri, Aug 29, 2025 at 5:37 AM Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > A Raspberry Pi user recently asked us why I2C wasn't working in their > > > custom kernel build. The primary change they had made was to trim the > > > number of enabled drivers, make them all built-in, and to remove > > > CONFIG_MODULES=y. The end result of this is that the pin muxing > > > required for I2C to work was not being applied, leaving the interface > > > talking to thin air. > > > > > > I eventually traced the failure back to this change: > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/pinctrl/devicetree.c?h=next-20250829&id=d19c5e79d46efdf89306be99f3c8824cf58e35f6 > > > It introduces a requirement for CONFIG_MODULES to be enabled in order > > > to get an EPROBE_DEFER in the event that the pinctrl driver has not > > > yet been probed. Without CONFIG_MODULES, the pinctrl requirements are > > > waived. Removing the IS_ENABLED(CONFIG_MODULES) clause allows the > > > probing of the I2C driver to be deferred, fixing the user's problem. > > > > > > Is this requirement for supporting modules reasonable? > > > > That's not the requirement. If CONFIG_MODULES=n, then we only defer > > probes until late_initcall because after that point no more drivers > > are going to load. If CONFIG_MODULES=y, then deferring probe is based > > on a timeout which can be disabled. > > Thanks for replying. I'm probably missing something here, but if the > pinctrl and I2C drivers are both regular platform drivers, what is to > stop the I2C driver being probed first? Nothing, but it should defer unless you've reached late initcall or you've set "pinctrl-use-default". Rob