lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Jul 2022 18:39:04 +0300
From:   Vladimir Oltean <>
To:     Christian Marangi <>
Cc:     Andrew Lunn <>,
        Vivien Didelot <>,
        Florian Fainelli <>,
        "David S. Miller" <>,
        Eric Dumazet <>,
        Jakub Kicinski <>,
        Paolo Abeni <>, Jens Axboe <>,
        Greg Kroah-Hartman <>,,
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 <>
> ---
> 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