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
| ||
|
Date: Thu, 29 Oct 2020 15:42:48 +0100 From: Ard Biesheuvel <ardb@...nel.org> To: Andrew Lunn <andrew@...n.ch> Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>, 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> Subject: Re: realtek PHY commit bbc4d71d63549 causes regression On Thu, 29 Oct 2020 at 15:39, Andrew Lunn <andrew@...n.ch> wrote: > > > What about reverting the realtek PHY commit from stable? > > As Ard said it doesn't really fix anything (usage wise) and causes a bunch of > > problems. > > > > If I understand correctly we have 3 options: > > 1. 'Hack' the drivers in stable to fix it (and most of those hacks will take > > a long time to remove) > > 2. Update DTE of all affected devices, backport it to stable and force users to > > update > > 3. Revert the PHY commit > > > > imho [3] is the least painful solution. > > The PHY commit is correct, in that it fixes a bug. So i don't want to > remove it. > > Backporting it to stable is what is causing most of the issues today, > combined with a number of broken DT descriptions. So i would be happy > for stable to get a patch which looks at the strapping, sees ID is > enabled via strapping, warns the DT blob is FUBAR, and then ignores > the requested PHY-mode. That gives developers time to fix their broken > DT. > IIRC there is no public documentation for this PHY, right? So most people that are affected by this are not actually able to implement this workaround, even if they wanted to.
Powered by blists - more mailing lists