From: Tiezhu Yang <yangtiezhu@loongson.cn> Date: 2026-09-15 07:32:17
Currently, there is no network connectivity when upgrading to the
latest upstream mainline kernel on certain Loongson machines such
as Loongson-3C6000 server, because the driver for the onboard NIC
is not enabled.
Enable the Motorcomm PCI DWMAC driver as a module by default when
building for the Loongson-64 platform.
This ensures out-of-the-box support for Motorcomm YT6801 Ethernet
controllers on Loongson machines, enabling demand-loading without
increasing the core kernel image size.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Yao Zi <me@ziyao.cc> Date: 2026-09-16 16:50:07
On Tue, Sep 15, 2026 at 03:32:06PM +0800, Tiezhu Yang wrote:
Currently, there is no network connectivity when upgrading to the
latest upstream mainline kernel on certain Loongson machines such
as Loongson-3C6000 server, because the driver for the onboard NIC
is not enabled.
Enable the Motorcomm PCI DWMAC driver as a module by default when
building for the Loongson-64 platform.
This ensures out-of-the-box support for Motorcomm YT6801 Ethernet
controllers on Loongson machines, enabling demand-loading without
increasing the core kernel image size.
YT6801 isn't a Loongson-specific peripheral, it's already shipped in
many other PCIe addon cards, and some x86 laptops iirc, thus it just
seems wrong to do this in the driver's Kconfig entry. I would NAK this
patch.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
From: Maxime Chevallier <maxime.chevallier@bootlin.com> Date: 2026-09-16 16:54:58
Hi
On 9/15/26 09:32, Tiezhu Yang wrote:
quoted hunk
Currently, there is no network connectivity when upgrading to the
latest upstream mainline kernel on certain Loongson machines such
as Loongson-3C6000 server, because the driver for the onboard NIC
is not enabled.
Enable the Motorcomm PCI DWMAC driver as a module by default when
building for the Loongson-64 platform.
This ensures out-of-the-box support for Motorcomm YT6801 Ethernet
controllers on Loongson machines, enabling demand-loading without
increasing the core kernel image size.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Tiezhu Yang <yangtiezhu@loongson.cn> Date: 2026-09-17 01:01:54
On 2026/9/17 上午12:54, Maxime Chevallier wrote:
Hi
On 9/15/26 09:32, Tiezhu Yang wrote:
quoted
Currently, there is no network connectivity when upgrading to the
latest upstream mainline kernel on certain Loongson machines such
as Loongson-3C6000 server, because the driver for the onboard NIC
is not enabled.
Enable the Motorcomm PCI DWMAC driver as a module by default when
building for the Loongson-64 platform.
This ensures out-of-the-box support for Motorcomm YT6801 Ethernet
controllers on Loongson machines, enabling demand-loading without
increasing the core kernel image size.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
1 file changed, 1 insertion(+)
I agree with Yao Zi, this belongs in your .config, maybe your
defconfig, but not in the stmmac Kconfig.
Thanks for the constructive suggestions.
Before moving forward, I'd like to share an alternative thought.
As noted in the earlier review, this network controller could be
used across multiple architectures. To avoid the redundant churn
in the defconfigs of every single architecture, I am wondering if
we could unconditionally set it to default m in the Kconfig instead.
Please let me know whether it makes sense:
From: Andrew Lunn <andrew@lunn.ch> Date: 2026-09-17 14:45:58
Before moving forward, I'd like to share an alternative thought.
As noted in the earlier review, this network controller could be
used across multiple architectures. To avoid the redundant churn
in the defconfigs of every single architecture, I am wondering if
we could unconditionally set it to default m in the Kconfig instead.
~/linux/drivers/net/ethernet/stmicro/stmmac$ grep default Kconfig
default n
default y
default STMMAC_PLATFORM
default ARC
default MACH_INGENIC
default ARCH_QCOM
default ARCH_LPC18XX
default ARCH_MESON
default ARCH_MA35
default ARCH_QCOM
default ARCH_RENESAS
default ARCH_ROCKCHIP
default ARCH_RZN1
default ARCH_S32
default ARCH_INTEL_SOCFPGA
default m if ARCH_SOPHGO
default m if ARCH_SPACEMIT
default m if ARCH_STARFIVE
default ARCH_STI
default ARCH_STM32
default ARCH_SUNXI
default ARCH_SUNXI
default ARCH_SUNXI
default ARCH_MXC
default MACH_LOONGSON32
default ARCH_VISCONTI
default X86
default MACH_LOONGSON64
No other glue driver does this. Why is this one special?
Andrew
From: Tiezhu Yang <yangtiezhu@loongson.cn> Date: 2026-09-18 06:48:56
On 2026/9/17 下午10:45, Andrew Lunn wrote:
quoted
Before moving forward, I'd like to share an alternative thought.
As noted in the earlier review, this network controller could be
used across multiple architectures. To avoid the redundant churn
in the defconfigs of every single architecture, I am wondering if
we could unconditionally set it to default m in the Kconfig instead.
~/linux/drivers/net/ethernet/stmicro/stmmac$ grep default Kconfig
default n
default y
default STMMAC_PLATFORM
default ARC
default MACH_INGENIC
default ARCH_QCOM
default ARCH_LPC18XX
default ARCH_MESON
default ARCH_MA35
default ARCH_QCOM
default ARCH_RENESAS
default ARCH_ROCKCHIP
default ARCH_RZN1
default ARCH_S32
default ARCH_INTEL_SOCFPGA
default m if ARCH_SOPHGO
default m if ARCH_SPACEMIT
default m if ARCH_STARFIVE
default ARCH_STI
default ARCH_STM32
default ARCH_SUNXI
default ARCH_SUNXI
default ARCH_SUNXI
default ARCH_MXC
default MACH_LOONGSON32
default ARCH_VISCONTI
default X86
default MACH_LOONGSON64
No other glue driver does this. Why is this one special?
If it is not proper to change Kconfig,
I am fine to modify the arch-specific defconfig instead.
But by the way, I noticed that there are the following code:
$ grep -rnw "default m" drivers/net/ethernet/
drivers/net/ethernet/stmicro/stmmac/Kconfig:221: default m if ARCH_SOPHGO
drivers/net/ethernet/stmicro/stmmac/Kconfig:233: default m if ARCH_SPACEMIT
drivers/net/ethernet/stmicro/stmmac/Kconfig:245: default m if ARCH_STARFIVE
drivers/net/ethernet/spacemit/Kconfig:21: default m if ARCH_SPACEMIT
drivers/net/ethernet/marvell/octeontx2/Kconfig:54: default m
drivers/net/ethernet/hisilicon/Kconfig:106: default m
drivers/net/ethernet/hisilicon/Kconfig:134: default m
drivers/net/ethernet/sun/Kconfig:77: default m
drivers/net/ethernet/sun/Kconfig:81: default m
drivers/net/ethernet/sun/Kconfig:89: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:37: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:47: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:67: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:86: default m
Thanks,
Tiezhu
From: Yao Zi <me@ziyao.cc> Date: 2026-09-18 07:11:04
On Fri, Sep 18, 2026 at 02:48:45PM +0800, Tiezhu Yang wrote:
On 2026/9/17 下午10:45, Andrew Lunn wrote:
quoted
quoted
Before moving forward, I'd like to share an alternative thought.
As noted in the earlier review, this network controller could be
used across multiple architectures. To avoid the redundant churn
in the defconfigs of every single architecture, I am wondering if
we could unconditionally set it to default m in the Kconfig instead.
~/linux/drivers/net/ethernet/stmicro/stmmac$ grep default Kconfig
default n
default y
default STMMAC_PLATFORM
default ARC
default MACH_INGENIC
default ARCH_QCOM
default ARCH_LPC18XX
default ARCH_MESON
default ARCH_MA35
default ARCH_QCOM
default ARCH_RENESAS
default ARCH_ROCKCHIP
default ARCH_RZN1
default ARCH_S32
default ARCH_INTEL_SOCFPGA
default m if ARCH_SOPHGO
default m if ARCH_SPACEMIT
default m if ARCH_STARFIVE
default ARCH_STI
default ARCH_STM32
default ARCH_SUNXI
default ARCH_SUNXI
default ARCH_SUNXI
default ARCH_MXC
default MACH_LOONGSON32
default ARCH_VISCONTI
default X86
default MACH_LOONGSON64
No other glue driver does this. Why is this one special?
If it is not proper to change Kconfig,
I am fine to modify the arch-specific defconfig instead.
I'm against both of the ideas. From the aspect of a distribution
maintainer, there are too many stuff missing from architecture
defconfigs, so only enabling one or two drivers by default doesn't even
improve the situation much, costs (kernel) maintainers' time.
From the aspect of a kernel developer, a bloated defconfig/default only
further lengthen the compilation process, forcing ones that don't have a
good enough machine to spend more time on turning off one and another
options their platforms don't need.
But by the way, I noticed that there are the following code:
$ grep -rnw "default m" drivers/net/ethernet/
drivers/net/ethernet/stmicro/stmmac/Kconfig:221: default m if ARCH_SOPHGO
drivers/net/ethernet/stmicro/stmmac/Kconfig:233: default m if ARCH_SPACEMIT
drivers/net/ethernet/stmicro/stmmac/Kconfig:245: default m if ARCH_STARFIVE
drivers/net/ethernet/spacemit/Kconfig:21: default m if ARCH_SPACEMIT
drivers/net/ethernet/marvell/octeontx2/Kconfig:54: default m
drivers/net/ethernet/hisilicon/Kconfig:106: default m
drivers/net/ethernet/hisilicon/Kconfig:134: default m
drivers/net/ethernet/sun/Kconfig:77: default m
drivers/net/ethernet/sun/Kconfig:81: default m
drivers/net/ethernet/sun/Kconfig:89: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:37: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:47: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:67: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:86: default m
Thanks,
Tiezhu
From: Andrew Lunn <andrew@lunn.ch> Date: 2026-09-18 11:54:03
drivers/net/ethernet/marvell/octeontx2/Kconfig:54: default m
drivers/net/ethernet/hisilicon/Kconfig:106: default m
drivers/net/ethernet/hisilicon/Kconfig:134: default m
drivers/net/ethernet/sun/Kconfig:77: default m
drivers/net/ethernet/sun/Kconfig:81: default m
drivers/net/ethernet/sun/Kconfig:89: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:37: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:47: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:67: default m
drivers/net/ethernet/mellanox/mlxsw/Kconfig:86: default m
Look deeper at these. Apart from the sun cases, which are very old,
default m is only used for optional parts of a module, not the module
as a whole.
Andrew