Re: [PATCH v9 3/6] mfd: Add RTL8231 core device

[Sander Vanheule <sander@svanheule.net>]

Hi Krzysztof,

On Fri, 2025-12-26 at 13:19 +0100, Krzysztof Kozlowski wrote:
> On 26/12/2025 12:59, Sander Vanheule wrote:
> > > kismet warnings: (new ones prefixed by >>)
> > > > > kismet: WARNING: unmet direct dependencies detected for MDIO_BUS when
> > > > > selected by REGMAP_MDIO
> > >    WARNING: unmet direct dependencies detected for MDIO_BUS
> > >      Depends on [n]: NETDEVICES [=n]
> > >      Selected by [y]:
> > >      - REGMAP_MDIO [=y]
> > 
> > I'm a bit puzzled on how to solve this one. The issue detected here is that
> > my
> > driver (MFD_RTL8231) selects REGMAP_MDIO, which in turn selects MDIO_BUS.
> > The
> > latter is dependent on NETDEVICES, which is not selected in this test. 
> > The kernel does not yet have any other consumers of REGMAP_MDIO, which is
> > probably the reason the dependency issue has gone undetected until now.
> > 
> > REGMAP_MDIO is not a visible symbol, so it must be selected by drivers.
> 
> Reminds me old problem, probably the same:
> 
> https://lore.kernel.org/all/20250515140555.325601-2-krzysztof.kozlowski@linaro.org/
> 
> https://lore.kernel.org/all/20250516141722.13772-1-afd@ti.com/
> 
> Exactly the same MDIO here and there.
> > [...]
> Rather fix the same way Andrew did it. Or maybe his patch was not merged?

Andrew's patch was merged, that's the code I'm seeing now. I think by
placing the dependency under REGMAP_MDIO (or REGMAP_IRQ) instead of
REGMAP, it just made the circular dependency less visible.

Making PINCTRL_RTL8231 "depends on GPIOLIB", like the GPIO drivers, only
shortens the circular dependency loop:

   error: recursive dependency detected!
   	symbol IRQ_DOMAIN is selected by MFD_CORE
   	symbol MFD_CORE is selected by MFD_RTL8231
   	symbol MFD_RTL8231 depends on MDIO_BUS
   	symbol MDIO_BUS is selected by PHYLIB
   	symbol PHYLIB is selected by ARC_EMAC_CORE
   	symbol ARC_EMAC_CORE is selected by EMAC_ROCKCHIP
   	symbol EMAC_ROCKCHIP depends on OF_IRQ
   	symbol OF_IRQ depends on IRQ_DOMAIN

Of these symbols, IRQ_DOMAIN and OF_IRQ are hidden symbols, so they must be
selected by another symbol to be used. As shown above, OF_IRQ *depends* on
IRQ_DOMAIN, which means some other symbol *must* select it for the dependency to
be satisfied, as IRQ_DOMAIN also cannot be selected directly by the user. OF_IRQ
also appears to be the only symbol in the kernel to depend on, rather than
select, IRQ_DOMAIN.

Turning the dependency of OF_IRQ on IRQ_DOMAIN around resolves the dependency
loop here, and ensures the hidden IRQ_DOMAIN symbol is selected whenever any
other symbol selects OF_IRQ.

The same reasoning was actually used in 2023 to suggest this change as well:
https://lore.kernel.org/lkml/20230213041535.12083-3-rdunlap@infradead.org/

I found some follow-up, but it didn't look like it actually got wrapped up:
https://lore.kernel.org/lkml/20230313023935.31037-1-rdunlap@infradead.org/

Randy, do you happen to recall if/why this stalled? Should we just try to invert
the dependency again if there is no pressing need for the "proper" clean-up?


Best,
Sander