netdev - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEM6a9wZKqqLjVACa+SHkdd0L6rRNcZCNjNNsmC-QxoxA@mail.gmail.com>
Date:   Sun, 25 Oct 2020 15:34:06 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     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>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        "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 Sun, 25 Oct 2020 at 15:29, Andrew Lunn <andrew@...n.ch> wrote:
>
> On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > > However, that leaves the question why bbc4d71d63549bcd was backported,
> > > > although I understand why the discussion is a bit trickier there. But
> > > > if it did not fix a regression, only broken code that never worked in
> > > > the first place, I am not convinced it belongs in -stable.
> > >
> > > Please ask Serge Semin what platform he tested on. I kind of expect it
> > > worked for him, in some limited way, enough that it passed his
> > > testing.
> > >
> >
> > I'll make a note here that a rather large number of platforms got
> > broken by the same fix for the Realtek PHY driver:
> >
> > https://lore.kernel.org/lkml/?q=bbc4d71d6354
> >
> > I seriously doubt whether disabling TX/RX delay when it is enabled by
> > h/w straps is the right thing to do here.
>
> The device tree is explicitly asking for rgmii. If it wanted the
> hardware left alone, it should of used PHY_INTERFACE_MODE_NA.
>

Would you suggest that these DTs remove the phy-mode instead? As I
don't see anyone proposing that.

> But we might be able to compromise for a cycle or two. As far as i
> understand the hardware, we can read the strapping. If we find the
> strapping resisters are present, but rgmii is in DT, print a warning
> that the device tree needs upgrading, and ignore the DT mode. We can
> add this to stable, but not net-next.
>

That sounds reasonable, given how many different platforms seem to be
affected, and production ones may be running stable distro kernels,
and not expecting their Ethernet to fail without warning.