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: <20201017151132.GK456889@lunn.ch>
Date:   Sat, 17 Oct 2020 17:11:32 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
        <netdev@...r.kernel.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.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, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 16:44, Andrew Lunn <andrew@...n.ch> wrote:
> >
> > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > > Hello all,
> > >
> > > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> > > connectivity.
> >
> > Hi Ard
> >
> > Please could you point me at the DT files.
> >
> > > This box has a on-SoC socionext 'netsec' network controller wired to
> > > a Realtek 80211e PHY, and this was working without problems until
> > > the following commit was merged
> >
> > It could be this fix has uncovered a bug in the DT file. Before this
> > fix, if there is an phy-mode property in DT, it could of been ignored.
> > Now the phy-handle property is correctly implemented. So it could be
> > the DT has the wrong value, e.g. it has rgmii-rxid when maybe it
> > should have rgmii-id.
> >
> 
> This is an ACPI system. The phy-mode device property is set to 'rgmii'

Hi Ard

Please try rgmii-id.

Also, do you have the schematic? Can you see if there are any
strapping resistors? It could be, there are strapping resistors to put
it into rgmii-id. Now that the phy-mode properties is respected, the
reset defaults are being over-written to rgmii, which breaks the link.
Or the bootloader has already set the PHY mode to rgmii-id.

You can also use '' as the phy-mode, which results in
PHY_INTERFACE_MODE_NA, which effectively means, don't touch the PHY
mode, something else has already set it up. This might actually be the
correct way to go for ACPI. In the DT world, we tend to assume the
bootloader has done the absolute minimum and Linux should configure
everything. The ACPI takes the opposite view, the firmware will do the
basic hardware configuration, and Linux should not touch it, or ask
ACPI to modify it.

      Andrew