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: <CAMj1kXEY5jK7z+_ezDX733zbtHnaGUNCkJ_gHcPqAavOQPOzBQ@mail.gmail.com>
Date:   Sun, 18 Oct 2020 00:19:25 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>,
        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@...val.com
Cc:     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

(cc'ing some folks who may care about functional networking on SynQuacer)

On Sat, 17 Oct 2020 at 21:49, Andrew Lunn <andrew@...n.ch> wrote:
>
> > So we can fix this firmware by just setting phy-mode to the empty
> > string, right?
>
> I've never actually tried it, but i think so. There are no DT files
> actually doing that, so you really do need to test it and see. And
> there might be some differences between device_get_phy_mode() and
> of_get_phy_mode().
>

Yes, that works fine. Fixed now in the latest firmware build [0]

But that still leaves the question whether and how to work around this
for units in the field. Ignoring the PHY mode in the driver would
help, as all known hardware ships with firmware that configures the
PHY with the correct settings, but we will lose the ability to use
other PHY modes in the future, in case the SoC is ever used with DT
based minimal firmware that does not configure networking.

Since ACPI implies rich firmware, we could make ACPI probing of the
driver ignore the phy-mode setting in the DSDT. But if we don't do the
same for DT, it would mean DT users are forced to upgrade their
firmware, and hopefully do so before upgrading to a kernel that breaks
networking. (These boxes are often used headless, so this can be
annoying)

[0] http://snapshots.linaro.org/components/kernel/leg-96boards-developerbox-edk2/83/