Thread (3 messages) 3 messages, 2 authors, 2025-12-26

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

From: Sander Vanheule <sander@svanheule.net>
Date: 2025-12-26 14:52:29
Also in: linux-devicetree, linux-gpio, linux-leds, lkml, oe-kbuild-all

Hi Krzysztof,

On Fri, 2025-12-26 at 13:19 +0100, Krzysztof Kozlowski wrote:
On 26/12/2025 12:59, Sander Vanheule wrote:
quoted
quoted
kismet warnings: (new ones prefixed by >>)
quoted
quoted
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/ (local)

https://lore.kernel.org/all/20250516141722.13772-1-afd@ti.com/ (local)

Exactly the same MDIO here and there.
quoted
[...]
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/ (local)

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/ (local)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help