[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12c98c7c8bead26a61764e3e9611badf2cdfcac5.camel@svanheule.net>
Date: Fri, 26 Dec 2025 12:59:40 +0100
From: Sander Vanheule <sander@...nheule.net>
To: 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>
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>, Krzysztof Kozlowski
<krzk@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH v9 3/6] mfd: Add RTL8231 core device
Adding the netdev and regmap maintainers for extra input.
On Mon, 2025-12-22 at 09:43 +0100, kernel test robot wrote:
> url: https://github.com/intel-lab-lkp/linux/commits/Sander-Vanheule/dt-bindings-leds-Binding-for-RTL8231-scan-matrix/20251216-015552
> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-fixes
> patch link: https://lore.kernel.org/r/20251215175115.135294-4-sander%40svanheule.net
> patch subject: [PATCH v9 3/6] mfd: Add RTL8231 core device
> config: alpha-kismet-CONFIG_MDIO_BUS-CONFIG_REGMAP_MDIO-0-0 (https://download.01.org/0day-ci/archive/20251222/202512220956.FVakrdhV-lkp@intel.com/config)
> reproduce: (https://download.01.org/0day-ci/archive/20251222/202512220956.FVakrdhV-lkp@intel.com/reproduce)
>
For context: these patches introduce a new MFD with pinctrl and led subdevices.
The RTL8231 MFD is attached to an MDIO bus, but it can also be attached to an
I2C bus (not currently supported). The drivers use regmap to provide a bus
abstraction.
> 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.
Other REGMAP_XYZ symbols (almost) exclusively use "depends on XYZ", but if I
change REGMAP_MDIO to "depends on", the warning just changes to:
WARNING: unmet direct dependencies detected for REGMAP_MDIO
Depends on [n]: MDIO_BUS [=n]
Selected by [y]:
- MFD_RTL8231 [=y] && HAS_IOMEM [=y]
Trying to make MFD_RTL8231 also depend on MDIO_BUS, like .e.g I2C dependent
devices do, results in a recursive dependency:
error: recursive dependency detected!
symbol GPIOLIB is selected by PINCTRL_RTL8231
symbol PINCTRL_RTL8231 depends on 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
symbol IRQ_DOMAIN is selected by GENERIC_IRQ_CHIP
symbol GENERIC_IRQ_CHIP is selected by GPIO_MVEBU
symbol GPIO_MVEBU depends on GPIOLIB
The 'quick fix' appears to be to add "select NETDEVICES" to REGMAP_MDIO. The
platforms that use the RTL8231 MFD are typically ethernet switches, so they
would have NETDEVICES enabled anway, but that feels very heavy handed and
automatically pulls in a lot of extra stuff. Would this be acceptable or is
there a more desirable approach I'm not seeing here?
Best,
Sander
Powered by blists - more mailing lists