From: Arnd Bergmann <arnd@arndb.de>

The newly added dsa driver attempts to enable the corresponding PHY driver,
but that one has additional dependencies that may not be available:

WARNING: unmet direct dependencies detected for MAXLINEAR_GPHY
  Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && (HWMON [=m] || HWMON [=m]=n [=n])
  Selected by [y]:
  - NET_DSA_MXL862 [=y] && NETDEVICES [=y] && NET_DSA [=y]
aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_probe':
mxl-gpy.c:(.text.gpy_probe+0x13c): undefined reference to `devm_hwmon_device_register_with_info'
aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_hwmon_read':
mxl-gpy.c:(.text.gpy_hwmon_read+0x48): undefined reference to `polynomial_calc'

There is actually no compile-time dependency, as DSA correctly uses the
PHY abstractions. Remove the 'select' statement to reduce the complexity.

Fixes: 23794bec1cb6 ("net: dsa: add basic initial driver for MxL862xx switches")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/dsa/mxl862xx/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/dsa/mxl862xx/Kconfig b/drivers/net/dsa/mxl862xx/Kconfig
index 4db7bab21a71..3e772298cc89 100644
--- a/drivers/net/dsa/mxl862xx/Kconfig
+++ b/drivers/net/dsa/mxl862xx/Kconfig
@@ -2,7 +2,6 @@
 config NET_DSA_MXL862
 	tristate "MaxLinear MxL862xx"
 	depends on NET_DSA
-	select MAXLINEAR_GPHY
 	select NET_DSA_TAG_MXL_862XX
 	help
 	  This enables support for the MaxLinear MxL862xx switch family.
-- 
2.39.5

On Mon, Feb 16, 2026 at 11:55:17AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The newly added dsa driver attempts to enable the corresponding PHY driver,
> but that one has additional dependencies that may not be available:
> 
> WARNING: unmet direct dependencies detected for MAXLINEAR_GPHY
>   Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && (HWMON [=m] || HWMON [=m]=n [=n])
>   Selected by [y]:
>   - NET_DSA_MXL862 [=y] && NETDEVICES [=y] && NET_DSA [=y]
> aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_probe':
> mxl-gpy.c:(.text.gpy_probe+0x13c): undefined reference to `devm_hwmon_device_register_with_info'
> aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_hwmon_read':
> mxl-gpy.c:(.text.gpy_hwmon_read+0x48): undefined reference to `polynomial_calc'

I assume this happens in case CONFIG_MAXLINEAR_GPHY=y and
CONFIG_HWMON=m, right?

None of the PHY drivers seem to adequately prevent such situations,
which in my opinion would be worth correcting, ie. by preventing any
PHY driver using HWMON from being built-in while CONFIG_HWMON=m.

> 
> There is actually no compile-time dependency, as DSA correctly uses the
> PHY abstractions. Remove the 'select' statement to reduce the complexity.
> 
> Fixes: 23794bec1cb6 ("net: dsa: add basic initial driver for MxL862xx switches")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

As there is no compile-time dependency, this change is fine.

Reviewed-by: Daniel Golle <daniel@makrotopia.org>

> ---
>  drivers/net/dsa/mxl862xx/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mxl862xx/Kconfig b/drivers/net/dsa/mxl862xx/Kconfig
> index 4db7bab21a71..3e772298cc89 100644
> --- a/drivers/net/dsa/mxl862xx/Kconfig
> +++ b/drivers/net/dsa/mxl862xx/Kconfig
> @@ -2,7 +2,6 @@
>  config NET_DSA_MXL862
>  	tristate "MaxLinear MxL862xx"
>  	depends on NET_DSA
> -	select MAXLINEAR_GPHY
>  	select NET_DSA_TAG_MXL_862XX
>  	help
>  	  This enables support for the MaxLinear MxL862xx switch family.
> -- 
> 2.39.5
>

On 2/16/26 04:15, Daniel Golle wrote:
> On Mon, Feb 16, 2026 at 11:55:17AM +0100, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> The newly added dsa driver attempts to enable the corresponding PHY driver,
>> but that one has additional dependencies that may not be available:
>>
>> WARNING: unmet direct dependencies detected for MAXLINEAR_GPHY
>>    Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && (HWMON [=m] || HWMON [=m]=n [=n])
>>    Selected by [y]:
>>    - NET_DSA_MXL862 [=y] && NETDEVICES [=y] && NET_DSA [=y]
>> aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_probe':
>> mxl-gpy.c:(.text.gpy_probe+0x13c): undefined reference to `devm_hwmon_device_register_with_info'
>> aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_hwmon_read':
>> mxl-gpy.c:(.text.gpy_hwmon_read+0x48): undefined reference to `polynomial_calc'
> 
> I assume this happens in case CONFIG_MAXLINEAR_GPHY=y and
> CONFIG_HWMON=m, right?
> 
> None of the PHY drivers seem to adequately prevent such situations,
> which in my opinion would be worth correcting, ie. by preventing any
> PHY driver using HWMON from being built-in while CONFIG_HWMON=m.
> 

Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
and with it MAXLINEAR_GPHY=y.

Maybe it is time to implement dummy functions for hwmon API calls
to avoid all this.

Guenter

>>
>> There is actually no compile-time dependency, as DSA correctly uses the
>> PHY abstractions. Remove the 'select' statement to reduce the complexity.
>>
>> Fixes: 23794bec1cb6 ("net: dsa: add basic initial driver for MxL862xx switches")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> As there is no compile-time dependency, this change is fine.
> 
> Reviewed-by: Daniel Golle <daniel@makrotopia.org>
> 
>> ---
>>   drivers/net/dsa/mxl862xx/Kconfig | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mxl862xx/Kconfig b/drivers/net/dsa/mxl862xx/Kconfig
>> index 4db7bab21a71..3e772298cc89 100644
>> --- a/drivers/net/dsa/mxl862xx/Kconfig
>> +++ b/drivers/net/dsa/mxl862xx/Kconfig
>> @@ -2,7 +2,6 @@
>>   config NET_DSA_MXL862
>>   	tristate "MaxLinear MxL862xx"
>>   	depends on NET_DSA
>> -	select MAXLINEAR_GPHY
>>   	select NET_DSA_TAG_MXL_862XX
>>   	help
>>   	  This enables support for the MaxLinear MxL862xx switch family.
>> -- 
>> 2.39.5
>>
>

On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
> On 2/16/26 04:15, Daniel Golle wrote:
>
> Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
> on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
> and with it MAXLINEAR_GPHY=y.
>
> Maybe it is time to implement dummy functions for hwmon API calls
> to avoid all this.

I had considered this when I found the build failure, but
I think removing the 'select' here is much better: this
simplifies the dependencies, and allows a valid configuration
with hwmon and gphy support in a loadable module that would
otherwise be impossible.

     Arnd

On 2/16/26 07:34, Arnd Bergmann wrote:
> On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
>> On 2/16/26 04:15, Daniel Golle wrote:
>>
>> Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
>> on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
>> and with it MAXLINEAR_GPHY=y.
>>
>> Maybe it is time to implement dummy functions for hwmon API calls
>> to avoid all this.
> 
> I had considered this when I found the build failure, but
> I think removing the 'select' here is much better: this
> simplifies the dependencies, and allows a valid configuration
> with hwmon and gphy support in a loadable module that would
> otherwise be impossible.
> 

Makes sense. I think I'll move forward with the dummy functions anyway
because with that the #ifdefs in drivers are no longer necessary
and the "depends on HWMON || HWMON=n" becomes optional.

Guenter

On Mon, Feb 16, 2026 at 08:20:41AM -0800, Guenter Roeck wrote:
> On 2/16/26 07:34, Arnd Bergmann wrote:
> > On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
> > > On 2/16/26 04:15, Daniel Golle wrote:
> > > 
> > > Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
> > > on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
> > > and with it MAXLINEAR_GPHY=y.
> > > 
> > > Maybe it is time to implement dummy functions for hwmon API calls
> > > to avoid all this.
> > 
> > I had considered this when I found the build failure, but
> > I think removing the 'select' here is much better: this
> > simplifies the dependencies, and allows a valid configuration
> > with hwmon and gphy support in a loadable module that would
> > otherwise be impossible.
> > 
> 
> Makes sense. I think I'll move forward with the dummy functions anyway
> because with that the #ifdefs in drivers are no longer necessary
> and the "depends on HWMON || HWMON=n" becomes optional.

Yes, that would be great and eliminate that whole class of obstacles
with some inline no-op stubs in the header.

On Mon, Feb 16, 2026, at 17:22, Daniel Golle wrote:
> On Mon, Feb 16, 2026 at 08:20:41AM -0800, Guenter Roeck wrote:
>> On 2/16/26 07:34, Arnd Bergmann wrote:
>> > On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
>> > > On 2/16/26 04:15, Daniel Golle wrote:
>> > > 
>> > > Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
>> > > on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
>> > > and with it MAXLINEAR_GPHY=y.
>> > > 
>> > > Maybe it is time to implement dummy functions for hwmon API calls
>> > > to avoid all this.

I think I misread this bit earlier, sorry

>> > I had considered this when I found the build failure, but
>> > I think removing the 'select' here is much better: this
>> > simplifies the dependencies, and allows a valid configuration
>> > with hwmon and gphy support in a loadable module that would
>> > otherwise be impossible.
>> > 
>> 
>> Makes sense. I think I'll move forward with the dummy functions anyway
>> because with that the #ifdefs in drivers are no longer necessary
>> and the "depends on HWMON || HWMON=n" becomes optional.
>
> Yes, that would be great and eliminate that whole class of obstacles
> with some inline no-op stubs in the header.

What I meant above is that I had considered and rejected the extra
dependencies in the ethernet driver. I don't think there is a good
way to add inline helpers. Technically, one could use IS_REACHABLE()
here, to stub out the functions when the caller is built-in, but
I find that even worse because it replaces a trivial build-time
failure with very subtle runtime bug.

      Arnd

On 2/16/26 08:27, Arnd Bergmann wrote:
> On Mon, Feb 16, 2026, at 17:22, Daniel Golle wrote:
>> On Mon, Feb 16, 2026 at 08:20:41AM -0800, Guenter Roeck wrote:
>>> On 2/16/26 07:34, Arnd Bergmann wrote:
>>>> On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
>>>>> On 2/16/26 04:15, Daniel Golle wrote:
>>>>>
>>>>> Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
>>>>> on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
>>>>> and with it MAXLINEAR_GPHY=y.
>>>>>
>>>>> Maybe it is time to implement dummy functions for hwmon API calls
>>>>> to avoid all this.
> 
> I think I misread this bit earlier, sorry
> 
>>>> I had considered this when I found the build failure, but
>>>> I think removing the 'select' here is much better: this
>>>> simplifies the dependencies, and allows a valid configuration
>>>> with hwmon and gphy support in a loadable module that would
>>>> otherwise be impossible.
>>>>
>>>
>>> Makes sense. I think I'll move forward with the dummy functions anyway
>>> because with that the #ifdefs in drivers are no longer necessary
>>> and the "depends on HWMON || HWMON=n" becomes optional.
>>
>> Yes, that would be great and eliminate that whole class of obstacles
>> with some inline no-op stubs in the header.
> 
> What I meant above is that I had considered and rejected the extra
> dependencies in the ethernet driver. I don't think there is a good
> way to add inline helpers. Technically, one could use IS_REACHABLE()
> here, to stub out the functions when the caller is built-in, but
> I find that even worse because it replaces a trivial build-time
> failure with very subtle runtime bug.
> 

Lots of kernel APIs have dummy implementations. hwmon isn't really that
different to those. Also, arguably, that would not be a subtle runtime
bug but a feature.

In this context:

If NET_DSA_MXL862 is enabled but MAXLINEAR_GPHY isn't, does the system
still work ?

Guenter

On Sat, Feb 21, 2026, at 02:25, Guenter Roeck wrote:
> On 2/16/26 08:27, Arnd Bergmann wrote:
>> On Mon, Feb 16, 2026, at 17:22, Daniel Golle wrote:
>>> On Mon, Feb 16, 2026 at 08:20:41AM -0800, Guenter Roeck wrote:
>> 
>> What I meant above is that I had considered and rejected the extra
>> dependencies in the ethernet driver. I don't think there is a good
>> way to add inline helpers. Technically, one could use IS_REACHABLE()
>> here, to stub out the functions when the caller is built-in, but
>> I find that even worse because it replaces a trivial build-time
>> failure with very subtle runtime bug.
>> 
>
> Lots of kernel APIs have dummy implementations. hwmon isn't really that
> different to those. Also, arguably, that would not be a subtle runtime
> bug but a feature.

I would argue that all of them are wrong. I currently count 33 uses
of IS_REACHABLE() in header files, which is not a lot, but I would
prefer replacing these with proper Kconfig dependencies than to
add more for cases we already handle correctly.

     Arnd

On Fri, Feb 20, 2026 at 05:25:06PM -0800, Guenter Roeck wrote:
> On 2/16/26 08:27, Arnd Bergmann wrote:
> > On Mon, Feb 16, 2026, at 17:22, Daniel Golle wrote:
> > > On Mon, Feb 16, 2026 at 08:20:41AM -0800, Guenter Roeck wrote:
> > > > On 2/16/26 07:34, Arnd Bergmann wrote:
> > > > > On Mon, Feb 16, 2026, at 16:17, Guenter Roeck wrote:
> > > > > > On 2/16/26 04:15, Daniel Golle wrote:
> > > > > > 
> > > > > > Technically, with "select MAXLINEAR_GPHY", NET_DSA_MXL862 should depend
> > > > > > on "depends on HWMON || HWMON=n". That would prevent NET_DSA_MXL862=y
> > > > > > and with it MAXLINEAR_GPHY=y.
> > > > > > 
> > > > > > Maybe it is time to implement dummy functions for hwmon API calls
> > > > > > to avoid all this.
> > 
> > I think I misread this bit earlier, sorry
> > 
> > > > > I had considered this when I found the build failure, but
> > > > > I think removing the 'select' here is much better: this
> > > > > simplifies the dependencies, and allows a valid configuration
> > > > > with hwmon and gphy support in a loadable module that would
> > > > > otherwise be impossible.
> > > > > 
> > > > 
> > > > Makes sense. I think I'll move forward with the dummy functions anyway
> > > > because with that the #ifdefs in drivers are no longer necessary
> > > > and the "depends on HWMON || HWMON=n" becomes optional.
> > > 
> > > Yes, that would be great and eliminate that whole class of obstacles
> > > with some inline no-op stubs in the header.
> > 
> > What I meant above is that I had considered and rejected the extra
> > dependencies in the ethernet driver. I don't think there is a good
> > way to add inline helpers. Technically, one could use IS_REACHABLE()
> > here, to stub out the functions when the caller is built-in, but
> > I find that even worse because it replaces a trivial build-time
> > failure with very subtle runtime bug.
> > 
> 
> Lots of kernel APIs have dummy implementations. hwmon isn't really that
> different to those. Also, arguably, that would not be a subtle runtime
> bug but a feature.
> 
> In this context:
> 
> If NET_DSA_MXL862 is enabled but MAXLINEAR_GPHY isn't, does the system
> still work ?

The switches supported by NET_DSA_MXL862 come with 5 or 8 twistedpair
ports provided by built-in PHYs. For the ports to (fully) work the
MAXLINEAR_GPHY driver is required, as without it they would be detected
as "Generic PHY".

This is similar to the situation on other DSA switches, and there is
apparently no clear rule whether this (runtime) dependency should be
treated as depedency in Kconfig which is typically used only to express
linking dependencies.

On Mon, Feb 16, 2026, at 13:15, Daniel Golle wrote:
> On Mon, Feb 16, 2026 at 11:55:17AM +0100, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>> 
>> The newly added dsa driver attempts to enable the corresponding PHY driver,
>> but that one has additional dependencies that may not be available:
>> 
>> WARNING: unmet direct dependencies detected for MAXLINEAR_GPHY
>>   Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && (HWMON [=m] || HWMON [=m]=n [=n])
>>   Selected by [y]:
>>   - NET_DSA_MXL862 [=y] && NETDEVICES [=y] && NET_DSA [=y]
>> aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_probe':
>> mxl-gpy.c:(.text.gpy_probe+0x13c): undefined reference to `devm_hwmon_device_register_with_info'
>> aarch64-linux-ld: drivers/net/phy/mxl-gpy.o: in function `gpy_hwmon_read':
>> mxl-gpy.c:(.text.gpy_hwmon_read+0x48): undefined reference to `polynomial_calc'
>
> I assume this happens in case CONFIG_MAXLINEAR_GPHY=y and
> CONFIG_HWMON=m, right?
>
> None of the PHY drivers seem to adequately prevent such situations,
> which in my opinion would be worth correcting, ie. by preventing any
> PHY driver using HWMON from being built-in while CONFIG_HWMON=m.

As far as I can tell, the dependency in MAXLINEAR_GPHY does
address this correctly.  We are however a bit inconsistent in
how we pick the PHY drivers in general. Almost all ethernet
drivers expect the user to enable the correct phy separately,
but there are a couple of exceptions that force a specific one:

drivers/net/dsa/Kconfig:        select BCM7XXX_PHY
drivers/net/dsa/Kconfig:        select MEDIATEK_GE_PHY
drivers/net/dsa/Kconfig:        select VITESSE_PHY
drivers/net/dsa/realtek/Kconfig:        select REALTEK_PHY
drivers/net/ethernet/8390/Kconfig:      select AX88796B_PHY
drivers/net/ethernet/broadcom/Kconfig:  select BCM7XXX_PHY
drivers/net/ethernet/hisilicon/Kconfig: select MARVELL_PHY
drivers/net/ethernet/hisilicon/Kconfig: select MOTORCOMM_PHY
drivers/net/ethernet/hisilicon/Kconfig: select REALTEK_PHY
drivers/net/ethernet/micrel/Kconfig:    select MICREL_PHY
drivers/net/ethernet/micrel/Kconfig:    select MICREL_PHY
drivers/net/ethernet/realtek/Kconfig:   select REALTEK_PHY
drivers/net/ethernet/smsc/Kconfig:      select SMSC_PHY
drivers/net/ethernet/stmicro/stmmac/Kconfig:    select MOTORCOMM_PHY
drivers/net/ethernet/wangxun/Kconfig:   select MARVELL_10G_PHY
drivers/net/usb/Kconfig:        select MICROCHIP_PHY
drivers/net/usb/Kconfig:        select AX88796B_PHY
drivers/net/usb/Kconfig:        select SMSC_PHY

We could probably drop most or all of those as well, but that risks
regressions with existing defconfig files.

      Arnd