On Wed, Nov 29, 2023 at 11:20:25AM +0000, Russell King (Oracle) wrote: > On Wed, Nov 29, 2023 at 11:37:56AM +0100, Christian Marangi wrote: > > On Wed, Nov 29, 2023 at 09:53:00AM +0000, Russell King (Oracle) wrote: > > > On Wed, Nov 29, 2023 at 03:12:18AM +0100, Christian Marangi wrote: > > > > diff --git a/drivers/net/phy/qcom/Makefile b/drivers/net/phy/qcom/Makefile > > > > index 6a68da8aaa7b..43e4d14df8ea 100644 > > > > --- a/drivers/net/phy/qcom/Makefile > > > > +++ b/drivers/net/phy/qcom/Makefile > > > > @@ -1,2 +1,3 @@ > > > > # SPDX-License-Identifier: GPL-2.0 > > > > -obj-$(CONFIG_AT803X_PHY) += at803x.o > > > > +obj-$(CONFIG_AT803X_PHY) += at803x.o common.o > > > > +obj-$(CONFIG_QCA83XX_PHY) += qca83xx.o common.o > > > > > > These PHY drivers can be built as modules. You will end up with several > > > modules - at803x.ko, qca83xx.ko and common.ko. You don't mark any > > > functions in common.c as exported, no module license, no author, no > > > description. common.ko is way too generic a name as well. > > > > > > Please think about this more and test building these drivers as a > > > module. > > > > > > > Had some fear about this... > > > > What would be the preferred way for this? > > > > Having a .ko that EXPORT symbol or making the PHY driver .ko to compile > > the common.o in it? > > I think the former, otherwise we end up with common.o duplicated in > each module, which becomes unnecessary bloat. This is how the Broadcom > stuff (which also has a "library") does it. > > > Honestly I would like the second option since I would prefer not to > > create a .ko with shared function and EXPORT lots of symbols. On SoC it's > > expected to have only one of the PHY (at max 2 when the qca807x PHY will > > be implemented, with the at808x also present) so the size increase is > > minimal. > > > > (just to be more clear, talking about this makefile implementation) > > > > at803x-objs += common.o > > obj-$(CONFIG_AT803X_PHY) += at803x.o > > qca83xx-objs += common.o > > obj-$(CONFIG_QCA83XX_PHY) += qca83xx.o > > qca808x-objs += common.o > > obj-$(CONFIG_QCA808X_PHY) += qca808x.o > > That won't work - the -objs needs to list the corresponding .o file > as well, and it needs to be a different name (you can't do this: > > qca808x-objs += common.o qca808x.o > > it has to be something like: > > qca808x-phy-objs += common.o qca808x.o > obj-$(CONFIG_QCA808X_PHY) += qca808x-phy.o > > However, I don't like this because it means each module ends up with > a copy of common.o in it. > Ok will do the .ko library approach np. > > For name of common.c, is qcom_ethphy_common.c a better name? > > or qcom-phy-lib.c which follows what we have for Broadcom. > Think we have to add some reference that it's about ethernet somewhere. There are already lots of qcom-phy .ko outside net/ qcom-ethphy-lib.c ? -- Ansuel
