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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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