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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 17 Oct 2020 20:11:24 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
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

On Sat, 17 Oct 2020 at 20:04, Andrew Lunn <andrew@...n.ch> wrote:
>
> > I have tried this, and it seems to fix the issue. I will send out a
> > patch against the netsec driver.
>
> Please also fix the firmware so it does not pass rgmii.
>
> If there are pure DT systems, which do require phy-mode to be used, we
> will need to revert your proposed change in order to make the MAC
> driver work as it should, rather than work around the broken firmware.
>

What do you mean by 'pure' DT system? Only EDK2 based firmware exists
for this platform, and it can be configured to boot either in DT or in
ACPI mode. In both cases, it will pass the same, incorrect PHY mode,
and in both cases, the firmware will already have configured the PHY
correctly.

So what I propose to do is drop the handling of the [mandatory]
phy-mode device property from the netsec driver (which is really only
used by this board). As we don't really need a phy-mode to begin with,
and given that firmware exists in the field that passes the wrong
value, the only option I see for passing a value here is to use a
different, *optional* DT property (force-phy-mode or
phy-mode-override) that takes the place of phy-mode. For ACPI boot,
you will just need to fix your firmware if you are using a different
PHY configuration.

Powered by blists - more mailing lists