netdev - Re: Re: realtek PHY commit bbc4d71d63549 causes regression

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:   Sat, 14 Nov 2020 11:09:53 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Sumit Garg <sumit.garg@...aro.org>,
        Alex Bennée <alex.bennee@...aro.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Steve McIntyre <steve@...val.com>,
        "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
        <netdev@...r.kernel.org>, Willy Liu <willy.liu@...ltek.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Sasha Levin <sashal@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Masahisa Kojima <masahisa.kojima@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>
Subject: Re: Re: realtek PHY commit bbc4d71d63549 causes regression

On Sat, 14 Nov 2020 at 01:40, Andrew Lunn <andrew@...n.ch> wrote:
>
> > One question that still has not been answered is how many actual
> > platforms were fixed by backporting Realtek's follow up fix to
> > -stable. My suspicion is none. That by itself should be enough
> > justification to revert the backport of that change.
>
> I think i've already said that would be a good idea. It makes the
> problem less critical. But the problem is still there, we are just
> kicking the can down the road. I've not seen much activity actually
> fixing the broken DT. So i suspect when we catch up with the can, we
> will mostly still be in the same place. Actually, maybe worse, because
> broken DTs have been copy/pasted for new boards?
>

I don't see how that matters. If the new board ships with a stable
kernel, things should simply work as they did before. If the new board
ships with a new kernel, things won't work in the first place, so it
is unlikely to cause a regression in the field.