[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65671f5b.050a0220.83136.4ea5@mx.google.com>
Date: Wed, 29 Nov 2023 12:21:40 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-arm-msm@...r.kernel.org
Subject: Re: [net-next PATCH 13/14] net: phy: qcom: deatch qca83xx PHY driver
from at803x
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
Powered by blists - more mailing lists