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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux