arch/arm64/configs/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to
ensure the Ethernet driver is available early in the boot process. This
is necessary for platforms mounting the root filesystem via NFS, as the
driver must be available before the root filesystem is accessed.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
With this change, the Renesas RZ/V2H EVK board can boot from NFS
which has the DWMAC IP.
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2dd75c799848..38d1c2ff3aa9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -379,7 +379,7 @@ CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_SNI_AVE=y
CONFIG_SNI_NETSEC=y
-CONFIG_STMMAC_ETH=m
+CONFIG_STMMAC_ETH=y
CONFIG_DWMAC_MEDIATEK=m
CONFIG_DWMAC_TEGRA=m
CONFIG_TI_K3_AM65_CPSW_NUSS=y
--
2.49.0On Tue, 6 May 2025 at 12:47, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to
> ensure the Ethernet driver is available early in the boot process. This
> is necessary for platforms mounting the root filesystem via NFS, as the
> driver must be available before the root filesystem is accessed.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> With this change, the Renesas RZ/V2H EVK board can boot from NFS
> which has the DWMAC IP.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.17.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 23/05/2025 13:39, Geert Uytterhoeven wrote: > On Tue, 6 May 2025 at 12:47, Prabhakar <prabhakar.csengg@gmail.com> wrote: >> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> >> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to >> ensure the Ethernet driver is available early in the boot process. This >> is necessary for platforms mounting the root filesystem via NFS, as the >> driver must be available before the root filesystem is accessed. >> >> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> --- >> With this change, the Renesas RZ/V2H EVK board can boot from NFS >> which has the DWMAC IP. > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > i.e. will queue in renesas-devel for v6.17. With my Nacked, please. Best regards, Krzysztof
Hi Geert, On 23/05/2025 12:54, Krzysztof Kozlowski wrote: > On 23/05/2025 13:39, Geert Uytterhoeven wrote: >> On Tue, 6 May 2025 at 12:47, Prabhakar <prabhakar.csengg@gmail.com> wrote: >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >>> >>> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to >>> ensure the Ethernet driver is available early in the boot process. This >>> is necessary for platforms mounting the root filesystem via NFS, as the >>> driver must be available before the root filesystem is accessed. >>> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >>> --- >>> With this change, the Renesas RZ/V2H EVK board can boot from NFS >>> which has the DWMAC IP. >> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> >> i.e. will queue in renesas-devel for v6.17. > > With my Nacked, please. I was surprised to see this change in -next. We also use NFS for testing and we use the dwmac drivers. To date we are explictly building these drivers into the initramfs but I noticed that that is now failing because this driver is no longer a module by default. This is easy for us to fix. I do agree that if we start to build every networking driver into the kernel it is going to bloat. Yes I do see the kernel image growing regardless of this, but nonetheless it seems better to just build as a module IMO. Jon -- nvpublic
Hi Jon,
CC Arnd
On Thu, 12 Jun 2025 at 14:20, Jon Hunter <jonathanh@nvidia.com> wrote:
> On 23/05/2025 12:54, Krzysztof Kozlowski wrote:
> > On 23/05/2025 13:39, Geert Uytterhoeven wrote:
> >> On Tue, 6 May 2025 at 12:47, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >>>
> >>> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to
> >>> ensure the Ethernet driver is available early in the boot process. This
> >>> is necessary for platforms mounting the root filesystem via NFS, as the
> >>> driver must be available before the root filesystem is accessed.
> >>>
> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >>> ---
> >>> With this change, the Renesas RZ/V2H EVK board can boot from NFS
> >>> which has the DWMAC IP.
> >>
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> i.e. will queue in renesas-devel for v6.17.
> >
> > With my Nacked, please.
>
> I was surprised to see this change in -next. We also use NFS for testing
> and we use the dwmac drivers. To date we are explictly building these
> drivers into the initramfs but I noticed that that is now failing
> because this driver is no longer a module by default. This is easy for
Oops, sorry for that...
> us to fix.
Good ;-)
> I do agree that if we start to build every networking driver into the
> kernel it is going to bloat. Yes I do see the kernel image growing
> regardless of this, but nonetheless it seems better to just build as a
> module IMO.
Not _every_ networking driver, of course. AFAIK, making network
drivers built-in for systems where development is done using nfsroot
has always been acceptable for the arm64 defconfig before. For things
not critical for booting, modular is indeed the preferred way.
BTW, we have other low-hanging fruit to fix, though:
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SOC=y
CONFIG_SND_SOC_SAMSUNG=y (Krzysztof? ;-)
CONFIG_USB=y
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Jun 12, 2025 at 02:34:32PM +0200, Geert Uytterhoeven wrote: > Hi Jon, > > CC Arnd > > On Thu, 12 Jun 2025 at 14:20, Jon Hunter <jonathanh@nvidia.com> wrote: > > On 23/05/2025 12:54, Krzysztof Kozlowski wrote: > > > On 23/05/2025 13:39, Geert Uytterhoeven wrote: > > >> On Tue, 6 May 2025 at 12:47, Prabhakar <prabhakar.csengg@gmail.com> wrote: > > >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > >>> > > >>> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to > > >>> ensure the Ethernet driver is available early in the boot process. This > > >>> is necessary for platforms mounting the root filesystem via NFS, as the > > >>> driver must be available before the root filesystem is accessed. > > >>> > > >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > >>> --- > > >>> With this change, the Renesas RZ/V2H EVK board can boot from NFS > > >>> which has the DWMAC IP. > > >> > > >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > > >> i.e. will queue in renesas-devel for v6.17. > > > > > > With my Nacked, please. > > > > I was surprised to see this change in -next. We also use NFS for testing > > and we use the dwmac drivers. To date we are explictly building these > > drivers into the initramfs but I noticed that that is now failing > > because this driver is no longer a module by default. This is easy for > > Oops, sorry for that... > > > us to fix. > > Good ;-) > > > I do agree that if we start to build every networking driver into the > > kernel it is going to bloat. Yes I do see the kernel image growing > > regardless of this, but nonetheless it seems better to just build as a > > module IMO. > > Not _every_ networking driver, of course. AFAIK, making network > drivers built-in for systems where development is done using nfsroot > has always been acceptable for the arm64 defconfig before. For things > not critical for booting, modular is indeed the preferred way. Last time I tried to merge something like this I was told that we shouldn't bloat the kernel for everyone just for our own convenience. I tend to agree with this now. It's trivial to make local adjustments for things like this. In fact, that's what I do all the time. I will use defconfig as a base line and if I want the convenience of having network drivers included because I don't want to update the initramfs every time I update the kernel, I'll just change the driver to built-in in my local .config. I think of the defconfig as more of a reference for what a typical development system would need. So it gives you reasonable build coverage and such for a wide variety of boards. If we start building too many things into the kernel, then at some point it's going to become uselessly large for everyone. That's essentially trading everyone's convenience for your own. > BTW, we have other low-hanging fruit to fix, though: > > CONFIG_SOUND=y > CONFIG_SND=y > CONFIG_SND_SOC=y > CONFIG_SND_SOC_SAMSUNG=y (Krzysztof? ;-) > CONFIG_USB=y Yeah, there's probably a lot of options that could be changed to modules to improve things. But perhaps we can start by not making things worse. Thierry
On Thu, 12 Jun 2025 at 16:30, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Thu, Jun 12, 2025 at 02:34:32PM +0200, Geert Uytterhoeven wrote:
> > On Thu, 12 Jun 2025 at 14:20, Jon Hunter <jonathanh@nvidia.com> wrote:
> > > On 23/05/2025 12:54, Krzysztof Kozlowski wrote:
> > > > On 23/05/2025 13:39, Geert Uytterhoeven wrote:
> > > >> On Tue, 6 May 2025 at 12:47, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > > >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > >>>
> > > >>> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to
> > > >>> ensure the Ethernet driver is available early in the boot process. This
> > > >>> is necessary for platforms mounting the root filesystem via NFS, as the
> > > >>> driver must be available before the root filesystem is accessed.
> > > >>>
> > > >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > >>> ---
> > > >>> With this change, the Renesas RZ/V2H EVK board can boot from NFS
> > > >>> which has the DWMAC IP.
> > > >>
> > > >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > >> i.e. will queue in renesas-devel for v6.17.
> > > >
> > > > With my Nacked, please.
> > >
> > > I was surprised to see this change in -next. We also use NFS for testing
> > > and we use the dwmac drivers. To date we are explictly building these
> > > drivers into the initramfs but I noticed that that is now failing
> > > because this driver is no longer a module by default. This is easy for
> >
> > Oops, sorry for that...
> >
> > > us to fix.
> >
> > Good ;-)
> >
> > > I do agree that if we start to build every networking driver into the
> > > kernel it is going to bloat. Yes I do see the kernel image growing
> > > regardless of this, but nonetheless it seems better to just build as a
> > > module IMO.
> >
> > Not _every_ networking driver, of course. AFAIK, making network
> > drivers built-in for systems where development is done using nfsroot
> > has always been acceptable for the arm64 defconfig before. For things
> > not critical for booting, modular is indeed the preferred way.
>
> Last time I tried to merge something like this I was told that we
> shouldn't bloat the kernel for everyone just for our own convenience. I
> tend to agree with this now. It's trivial to make local adjustments for
> things like this. In fact, that's what I do all the time. I will use
> defconfig as a base line and if I want the convenience of having network
> drivers included because I don't want to update the initramfs every time
> I update the kernel, I'll just change the driver to built-in in my local
> .config.
>
> I think of the defconfig as more of a reference for what a typical
> development system would need. So it gives you reasonable build coverage
> and such for a wide variety of boards.
>
> If we start building too many things into the kernel, then at some point
> it's going to become uselessly large for everyone. That's essentially
> trading everyone's convenience for your own.
As discussed with Arnd on #armlinux, I will drop this patch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 12/06/2025 14:34, Geert Uytterhoeven wrote: >> I do agree that if we start to build every networking driver into the >> kernel it is going to bloat. Yes I do see the kernel image growing >> regardless of this, but nonetheless it seems better to just build as a >> module IMO. > > Not _every_ networking driver, of course. AFAIK, making network > drivers built-in for systems where development is done using nfsroot > has always been acceptable for the arm64 defconfig before. For things > not critical for booting, modular is indeed the preferred way. > > BTW, we have other low-hanging fruit to fix, though: > > CONFIG_SOUND=y > CONFIG_SND=y > CONFIG_SND_SOC=y > CONFIG_SND_SOC_SAMSUNG=y (Krzysztof? ;-) You cannot boot without sound :). Uh, I am on it. Best regards, Krzysztof
On 06/05/2025 12:47, Prabhakar wrote: > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to > ensure the Ethernet driver is available early in the boot process. This > is necessary for platforms mounting the root filesystem via NFS, as the > driver must be available before the root filesystem is accessed. > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Same comments as for previous patches like this (even the same?): you are supposed to use initramfs for your arm74 boards. Even armv7 boards use initramfs, so network driver does not have to be built in. For example all of our setups use it thus we do not have to populate all other vendors with our own drivers. Sorry, but I am strongly against such change. Kernel is already way too big and with KASAN it does not fit to boot partitions in some of the devices (and I cannot change the boot partition size, at least not without big effort). Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
Hi Krzysztof,
CC arnd
On Tue, 6 May 2025 at 12:52, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 06/05/2025 12:47, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to
> > ensure the Ethernet driver is available early in the boot process. This
> > is necessary for platforms mounting the root filesystem via NFS, as the
> > driver must be available before the root filesystem is accessed.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Same comments as for previous patches like this (even the same?): you
> are supposed to use initramfs for your arm74 boards. Even armv7 boards
> use initramfs, so network driver does not have to be built in.
Are we? When has that policy changed? Why are lots of network drivers
still built-in? Making network drivers built-in for systems where
development is done using nfsroot has always been acceptable for the
arm64 defconfig before. For things not critical for booting, modular
is indeed the preferred way.
arm64/defconfig is for development and testing, not for production
(which famous kernel developer said that before?)
> For example all of our setups use it thus we do not have to populate all
> other vendors with our own drivers.
>
> Sorry, but I am strongly against such change. Kernel is already way too
The kernel will grow without this (it will just take a few more weeks ;-),
so that is IMHO not a good argument.
> big and with KASAN it does not fit to boot partitions in some of the
> devices (and I cannot change the boot partition size, at least not
> without big effort).
arm64/defconfig does not have KASAN enabled?
> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Doh...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 06/05/2025 14:42, Geert Uytterhoeven wrote: > Hi Krzysztof, > > CC arnd > > On Tue, 6 May 2025 at 12:52, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> On 06/05/2025 12:47, Prabhakar wrote: >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >>> >>> Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to >>> ensure the Ethernet driver is available early in the boot process. This >>> is necessary for platforms mounting the root filesystem via NFS, as the >>> driver must be available before the root filesystem is accessed. >>> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >> >> Same comments as for previous patches like this (even the same?): you >> are supposed to use initramfs for your arm74 boards. Even armv7 boards >> use initramfs, so network driver does not have to be built in. > > Are we? When has that policy changed? Why are lots of network drivers > still built-in? Making network drivers built-in for systems where I would be happy to make them modules, but it is different thing to accept new patch like that than change existing workflow. > development is done using nfsroot has always been acceptable for the > arm64 defconfig before. For things not critical for booting, modular > is indeed the preferred way. And this is not critical for booting. System boots perfectly fine, all critical SoCs are working, serial is working, clocks/interconnects kick in, kernel mounts initramfs and you can probe the network/USB/storage to mount rootfs. > > arm64/defconfig is for development and testing, not for production > (which famous kernel developer said that before?) And we all for testing use initramfs, don't we? I really do not understand the problem being solved here - all of our setups are supposed to have initramfs already. My simple, private CI even has it, so if such little fella like me is able to use initramfs, I am sure that SoC vendor can adjust their CI as well. > >> For example all of our setups use it thus we do not have to populate all >> other vendors with our own drivers. >> >> Sorry, but I am strongly against such change. Kernel is already way too > > The kernel will grow without this (it will just take a few more weeks ;-), > so that is IMHO not a good argument. I meant, kernel built out of defconfig. Yes, it will grow and my comments are, hopefully, slowing that growth so I can still work with kernel defconfig. Otherwise why Renesas usecase of defconfig - built in modules, because initramfs is too difficult (???) - is more important than my usecase of small defconfig for my development? And there is a consensus: use initramfs, just like we all are supposed to use since years. > >> big and with KASAN it does not fit to boot partitions in some of the >> devices (and I cannot change the boot partition size, at least not >> without big effort). > > arm64/defconfig does not have KASAN enabled? Does not have, but I want to be able to toggle KASAN and boot the kernel, without going through 1000 kernel options which I could disable or toggle to module to get the kernel fit into boot partition. > >> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Doh... Sorry that it feels harsh. I do not create the policy, but lack of my words of objection are then used again in many discussions, e.g. via "someone added patch like this, so I can add as well". I won't feel offended if you take the patch with my Nacked tag. Best regards, Krzysztof
Hi Krzysztof, On Tue, May 6, 2025 at 11:52 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 06/05/2025 12:47, Prabhakar wrote: > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > > Enable `CONFIG_STMMAC_ETH` as built-in (`y`) instead of a module (`m`) to > > ensure the Ethernet driver is available early in the boot process. This > > is necessary for platforms mounting the root filesystem via NFS, as the > > driver must be available before the root filesystem is accessed. > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Same comments as for previous patches like this (even the same?): you > are supposed to use initramfs for your arm74 boards. Even armv7 boards > use initramfs, so network driver does not have to be built in. > > For example all of our setups use it thus we do not have to populate all > other vendors with our own drivers. > > Sorry, but I am strongly against such change. Kernel is already way too > big and with KASAN it does not fit to boot partitions in some of the > devices (and I cannot change the boot partition size, at least not > without big effort). > Thanks for the feedback. I understand your concerns, and I agree with your comments regarding the use of initramfs and the impact on kernel size. I'll drop this change and avoid adding the driver as built-in. Cheers, Prabhakar
© 2016 - 2025 Red Hat, Inc.