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? Phil