linux-kernel - Re: [PATCH net-next] r8152; preserve device list format

lists.openwall.net		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] [day] [month] [year] [list]

Date:   Fri, 13 Jan 2023 11:54:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Greg KH <greg@...ah.com>, Andre Przywara <andre.przywara@....com>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] r8152; preserve device list format

On Fri, 13 Jan 2023 11:16:47 +0100 Bjørn Mork wrote:
> There is no point backporting to anything older than v5.15 since the
> patch depend on significant driver changes between v5.10 and v5.15.  The
> good news is that those changes also modified the macro in question so
> any device ID patch for v5.10 or older will have to be fixed up in any
> case.  So we don't lose anything by ignoring the older longterm kernels
> here.
> 
> IIUC the special netdev stable rules are gone.  But if this is going to
> stable, then I believe it still has to go to "net" first.
> 
> David/Jakub - Would you please pick
> 
>   ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
>   69649ef84053 ("cdc_ether: no need to blacklist any r8152 devices")
> 
> from net-next to net?  With a "CC: stable" preferably.  Or do you prefer
> some other solution?

Well.. we already shipped the patch from this thread as is to Linus.
Greg will be able to take be53771c87f4 into stable directly, with 
no dependencies.

And now the refactoring won't cherry-pick cleanly :(
Maybe let's leave it be?

I'll keep in mind that Greg is okay with taking this sort of
refactoring in in the future. I made an unnecessary commotion here.