[0/6] net: migrate NO_NET out of the networking stack choice

[Simon Glass]

Hi Quentin,

On Tue, 21 Apr 2026 at 23:06, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Simon,
>
> On 4/20/26 9:51 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On 2026-04-20T11:36:06, Quentin Schulz <foss+uboot at 0leil.net> wrote:
> >
> >> This series introduces a new NET umbrella symbol with NET_LEGACY and NET_LWIP underneath.
> >
> > Thanks for this cleanup!
> >
> > Re SYS_RX_ETH_BUFFER, how about moving the extern for net_rx_packets[]
> > to net-legacy.h ? (is it used with lwip?)
> >
>
> That's not the only thing making use of SYS_RX_ETH_BUFFER.
>
> - drivers/net/fsl_enetc.h uses it as value for ENETC_BD_CNT which is
> used in drivers/net/fsl_enetc.c,
> - drivers/net/rtl8169.c uses it (if defined, otherwise defaults to 4) to
> create a static buffer, see NUM_RX_DESC,
> - include/net-common.h sets PKTBUFSRX to it, this in turn is used in
> *many* places, including many network (assumed Ethernet controller)
> drivers, net/lwip/net-lwip.c, net/net-common.c (with net_rx_packets
> array, used all over the place), net/net.c, and net/tcp.c.
>
> So seems to be used for both NET_LEGACY and NET_LWIP.
>
> Simply guarding the "#include <net-common.h>" with
> CONFIG_IS_ENABLED(NET) won't do as many files currently expect some
> functions/macros/constants from that header to be defined.
>
> Another option is to ifdef PKTBUFSRX contant and net_rx_packets array in
> include/net-common.h. But it's used in arch/sandbox/include/asm/eth.h
> and drivers/dma/ti/k3-udma.c which aren't clearly dpeending on NET being
> set. All defconfigs enabling CONFIG_TI_K3_NAVSS_UDMA do not modify the
> default CONFIG_SYS_RX_ETH_BUFFER which is 4 (according to
> ./tools/qconfig.py -l -f CONFIG_TI_K3_NAVSS_UDMA
> '~CONFIG_SYS_RX_ETH_BUFFER=4') so it should be fine for this driver not
> to have PKTBUFSRX defined (as UDMA_RX_DESC_NUM will then default to 4).
> According to ./tools/qconfig.py -l -f CONFIG_SANDBOX CONFIG_NO_NET, all
> sandbox defconfigs have network enabled so maybe
> arch/sandbox/include/asm/eth.h is not an issue either (or rather, for
> later :) ).
>
> With
>
> diff --git a/include/net-common.h b/include/net-common.h
> index 69b6316c1ec..0c260873c2c 100644
> --- a/include/net-common.h
> +++ b/include/net-common.h
> @@ -20,7 +20,9 @@
>    *    alignment in memory.
>    *
>    */
> +#if CONFIG_IS_ENABLED(NET)
>   #define PKTBUFSRX     CONFIG_SYS_RX_ETH_BUFFER
> +#endif
>   #define PKTALIGN      ARCH_DMA_MINALIGN
>
>   /* IPv4 addresses are always 32 bits in size */
> @@ -132,7 +134,9 @@ static inline void net_set_state(enum net_loop_state
> state)
>   }
>
>   extern int            net_restart_wrap;       /* Tried all network devices */
> +#if CONFIG_IS_ENABLED(NET)
>   extern uchar          *net_rx_packets[PKTBUFSRX]; /* Receive packets */
> +#endif
>   extern const u8               net_bcast_ethaddr[ARP_HLEN];    /* Ethernet broadcast
> address */
>   extern struct in_addr net_ip;         /* Our    IP addr (0 = unknown) */
>   /* Indicates whether the pxe path prefix / config file was specified
> in dhcp option */
> diff --git a/net/Kconfig b/net/Kconfig
> index e712a0dd2ac..deab340f26b 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -279,8 +279,6 @@ config TFTP_BLOCKSIZE
>           almost-MTU block sizes.
>           You can also activate CONFIG_IP_DEFRAG to set a larger block.
>
> -endif   # if NET
> -
>   config SYS_RX_ETH_BUFFER
>           int "Number of receive packet buffers"
>           default 4
> @@ -289,3 +287,6 @@ config SYS_RX_ETH_BUFFER
>             controllers it is recommended to set this value to 8 or even
> higher,
>             since all buffers can be full shortly after enabling the
> interface on
>             high Ethernet traffic.
> +
> +endif   # if NET
> +
>
>
> And building sandbox_defconfig with CONFIG_NO_NET=y, the build finishes
> without any issue. So maybe that's the way forward? I think this would
> be better as a separate series though, what do you think?

Yes that approach seems good, definitely a separate series as you say.

Regards,
Simon