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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a844934b105136f576ab46a5779cf57ef0cc7bbb.camel@svanheule.net>
Date: Fri, 26 Dec 2025 15:52:25 +0100
From: Sander Vanheule <sander@...nheule.net>
To: Krzysztof Kozlowski <krzk@...nel.org>, kernel test robot
 <lkp@...el.com>,  Lee Jones <lee@...nel.org>, Pavel Machek
 <pavel@...nel.org>, Linus Walleij <linus.walleij@...aro.org>,  Michael
 Walle <mwalle@...nel.org>, Bartosz Golaszewski <brgl@...ev.pl>, Mark Brown
 <broonie@...nel.org>,  Andrew Lunn <andrew@...n.ch>, Heiner Kallweit
 <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>,  "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Randy Dunlap
 <rdunlap@...radead.org>
Cc: Paul Gazzillo <paul@...zz.com>, Necip Fazil Yildiran	
 <fazilyildiran@...il.com>, oe-kbuild-all@...ts.linux.dev, 
	linux-leds@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
 netdev@...r.kernel.org,  Rob Herring <robh@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>
Subject: Re: [PATCH v9 3/6] mfd: Add RTL8231 core device

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