[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220706153904.jtu2qxczjjcgcoty@skbuf>
Date: Wed, 6 Jul 2022 18:39:04 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Jens Axboe <axboe@...nel.dk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH RFC] net: dsa: qca8k: move driver to qca dir
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@...il.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.
Powered by blists - more mailing lists