[net-next PATCH RFC] net: dsa: qca8k: move driver to qca dir

[net-next PATCH RFC] net: dsa: qca8k: move driver to qca dir

[Christian Marangi]

Move qca8k driver to qca dir in preparation for code split and
introduction of ipq4019 switch based on qca8k.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---

Posting this as a RFC to discuss the problems of such change.

This is needed as in the next future the qca8k driver will be split
to a common code. This needs to be done as the ipq4019 is based on qca8k
but will have some additional configuration thing and other phylink
handling so it will require different setup function. Aside from these
difference almost all the regs are the same of qca8k.

For this reason keeping the driver in the generic dsa dir would create
some caos and I think it would be better to move it the dedicated qca
dir.

This will for sure creates some problems with backporting patch.

So the question is... Is this change acceptable or we are cursed to
keeping this driver in the generic dsa directory?

Additional bonus question, since the ethernet part still requires some
time to get merged, wonder if it's possible to send the code split with
qca8k as the only user (currently) and later just add the relevant
ipq4019 changes.

(this ideally is to prepare stuff and not send a big scary series when
it's time to send ipq4019 changes)

 drivers/net/dsa/Kconfig           | 8 --------
 drivers/net/dsa/Makefile          | 1 -
 drivers/net/dsa/qca/Kconfig       | 8 ++++++++
 drivers/net/dsa/qca/Makefile      | 1 +
 drivers/net/dsa/{ => qca}/qca8k.c | 0
 drivers/net/dsa/{ => qca}/qca8k.h | 0
 6 files changed, 9 insertions(+), 9 deletions(-)
 rename drivers/net/dsa/{ => qca}/qca8k.c (100%)
 rename drivers/net/dsa/{ => qca}/qca8k.h (100%)

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 702d68ae435a..d8ae0e8af2a0 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -60,14 +60,6 @@ source "drivers/net/dsa/sja1105/Kconfig"
 
 source "drivers/net/dsa/xrs700x/Kconfig"
 
-config NET_DSA_QCA8K
-	tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
-	select NET_DSA_TAG_QCA
-	select REGMAP
-	help
-	  This enables support for the Qualcomm Atheros QCA8K Ethernet
-	  switch chips.
-
 source "drivers/net/dsa/realtek/Kconfig"
 
 config NET_DSA_RZN1_A5PSW
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index b32907afa702..16eb879e0cb4 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -8,7 +8,6 @@ endif
 obj-$(CONFIG_NET_DSA_LANTIQ_GSWIP) += lantiq_gswip.o
 obj-$(CONFIG_NET_DSA_MT7530)	+= mt7530.o
 obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
-obj-$(CONFIG_NET_DSA_QCA8K)	+= qca8k.o
 obj-$(CONFIG_NET_DSA_RZN1_A5PSW) += rzn1_a5psw.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
diff --git a/drivers/net/dsa/qca/Kconfig b/drivers/net/dsa/qca/Kconfig
index 13b7e679b8b5..ba339747362c 100644
--- a/drivers/net/dsa/qca/Kconfig
+++ b/drivers/net/dsa/qca/Kconfig
@@ -7,3 +7,11 @@ config NET_DSA_AR9331
 	help
 	  This enables support for the Qualcomm Atheros AR9331 built-in Ethernet
 	  switch.
+
+config NET_DSA_QCA8K
+	tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
+	select NET_DSA_TAG_QCA
+	select REGMAP
+	help
+	  This enables support for the Qualcomm Atheros QCA8K Ethernet
+	  switch chips.
diff --git a/drivers/net/dsa/qca/Makefile b/drivers/net/dsa/qca/Makefile
index 274022319066..40bb7c27285b 100644
--- a/drivers/net/dsa/qca/Makefile
+++ b/drivers/net/dsa/qca/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_NET_DSA_AR9331)	+= ar9331.o
+obj-$(CONFIG_NET_DSA_QCA8K)	+= qca8k.o
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca/qca8k.c
similarity index 100%
rename from drivers/net/dsa/qca8k.c
rename to drivers/net/dsa/qca/qca8k.c
diff --git a/drivers/net/dsa/qca8k.h b/drivers/net/dsa/qca/qca8k.h
similarity index 100%
rename from drivers/net/dsa/qca8k.h
rename to drivers/net/dsa/qca/qca8k.h
-- 
2.36.1

Re: [net-next PATCH RFC] net: dsa: qca8k: move driver to qca dir

[Vladimir Oltean]

On Thu, Jun 30, 2022 at 03:46:06PM +0200, Christian Marangi wrote:
> Move qca8k driver to qca dir in preparation for code split and
> introduction of ipq4019 switch based on qca8k.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> 
> Posting this as a RFC to discuss the problems of such change.
> 
> This is needed as in the next future the qca8k driver will be split
> to a common code. This needs to be done as the ipq4019 is based on qca8k
> but will have some additional configuration thing and other phylink
> handling so it will require different setup function. Aside from these
> difference almost all the regs are the same of qca8k.
> 
> For this reason keeping the driver in the generic dsa dir would create
> some caos and I think it would be better to move it the dedicated qca
> dir.
> 
> This will for sure creates some problems with backporting patch.
> 
> So the question is... Is this change acceptable or we are cursed to
> keeping this driver in the generic dsa directory?
> 
> Additional bonus question, since the ethernet part still requires some
> time to get merged, wonder if it's possible to send the code split with
> qca8k as the only user (currently) and later just add the relevant
> ipq4019 changes.
> 
> (this ideally is to prepare stuff and not send a big scary series when
> it's time to send ipq4019 changes)

I think we discussed this before. You can make the driver migration but
you need to be willing to manually backport bug fixes if/when the stable
team reports that backporting to a certain kernel failed. It has been
done before, see commit a9770eac511a ("net: mdio: Move MDIO drivers into
a new subdirectory") as an example. I think "git cherry-pick" has magic
to detect file movement, while "git am" doesn't. Here I'm not 100%
certain which command is used to backport to stable. If it's by cherry
picking it shouldn't even require manual intervention.

Re: [net-next PATCH RFC] net: dsa: qca8k: move driver to qca dir

[Greg Kroah-Hartman]

On Wed, Jul 06, 2022 at 06:39:04PM +0300, Vladimir Oltean wrote:
> On Thu, Jun 30, 2022 at 03:46:06PM +0200, Christian Marangi wrote:
> > Move qca8k driver to qca dir in preparation for code split and
> > introduction of ipq4019 switch based on qca8k.
> > 
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > 
> > Posting this as a RFC to discuss the problems of such change.
> > 
> > This is needed as in the next future the qca8k driver will be split
> > to a common code. This needs to be done as the ipq4019 is based on qca8k
> > but will have some additional configuration thing and other phylink
> > handling so it will require different setup function. Aside from these
> > difference almost all the regs are the same of qca8k.
> > 
> > For this reason keeping the driver in the generic dsa dir would create
> > some caos and I think it would be better to move it the dedicated qca
> > dir.
> > 
> > This will for sure creates some problems with backporting patch.
> > 
> > So the question is... Is this change acceptable or we are cursed to
> > keeping this driver in the generic dsa directory?
> > 
> > Additional bonus question, since the ethernet part still requires some
> > time to get merged, wonder if it's possible to send the code split with
> > qca8k as the only user (currently) and later just add the relevant
> > ipq4019 changes.
> > 
> > (this ideally is to prepare stuff and not send a big scary series when
> > it's time to send ipq4019 changes)
> 
> I think we discussed this before. You can make the driver migration but
> you need to be willing to manually backport bug fixes if/when the stable
> team reports that backporting to a certain kernel failed. It has been
> done before, see commit a9770eac511a ("net: mdio: Move MDIO drivers into
> a new subdirectory") as an example. I think "git cherry-pick" has magic
> to detect file movement, while "git am" doesn't. Here I'm not 100%
> certain which command is used to backport to stable. If it's by cherry
> picking it shouldn't even require manual intervention.

People move files around in the kernel all the time, it's not a big deal
and should never be an issue (i.e. don't worry about stable backports.)
Normally we can handle the move easily, and if not, we will punt to the
developer and ask if they want to do the backport if they feel it is
necessary.

So this should not be an issue for anything here.

thanks,

greg k-h