Re: [PATCH 1/2] [v2] net: ethernet: ti-cpsw: fix linking built-in code to modules

From: Paolo Abeni
Date: Thu Apr 18 2024 - 09:34:30 EST


On Wed, 2024-04-17 at 10:43 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@xxxxxxxx>
>
> There are six variants of the cpsw driver, sharing various parts of
> the code: davinci-emac, cpsw, cpsw-switchdev, netcp, netcp_ethss and
> am65-cpsw-nuss.
>
> I noticed that this means some files can be linked into more than
> one loadable module, or even part of vmlinux but also linked into
> a loadable module, both of which mess up assumptions of the build
> system.
>
> Change this back to having separate modules for each portion that
> can be linked standalone, exporting symbols as needed:
>
> - ti-cpsw-common.ko now contains both cpsw-common.o and
> davinci_cpdma.o as they are always used together
>
> - ti-cpsw-priv.ko contains cpsw_priv.o, cpsw_sl.o and cpsw_ethtool.o,
> which are the core of the cpsw and cpsw-new drivers.
>
> - ti-cpsw-sl.ko contains the cpsw-sl.o object and is used on
> ti-am65-cpsw-nuss.ko in addition to the two other cpsw variants.
>
> - ti-cpsw-ale.o is the one standalone module that is used by all
> except davinci_emac.
>
> Each of these will be built-in if any of its users are built-in,
> otherwise it's a loadable module if there is at least one module
> using it. I did not bring back the separate Kconfig symbols for
> this, but just handle it using Makefile logic.
>
> Note: ideally this is something that Kbuild complains about, but
> usually we just notice when something using THIS_MODULS misbehaves
> in a way that a user notices.
>
> Fixes: 99f6297182729 ("net: ethernet: ti: cpsw: drop TI_DAVINCI_CPDMA config option")
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> ---
> v2: rebase on top of v6.9-rc

Does not apply cleanly to net (nor to net-next FWIW).

You should rebase on top of:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/ main

Also, please don't send patches targeting the net and net-next trees in
the same series. If the net-next patch depends on the net one, you have
to wait until the first is applied and the 'net' tree is merged back
into the 'net-next' tree before submitting the latter (usually after
the next thu).

Thanks,

Paolo