Thread (41 messages) flat view 41 messages, 6 authors, 2020-11-14

Re: realtek PHY commit bbc4d71d63549 causes regression

From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: 2020-10-17 16:14:42

Hi Ard, 

On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote:
On Sat, 17 Oct 2020 at 17:11, Andrew Lunn [off-list ref] wrote:
quoted
On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
quoted
On Sat, 17 Oct 2020 at 16:44, Andrew Lunn [off-list ref] wrote:
quoted
On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
quoted
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.
quoted
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.
Indeed, the firmware should have set this up.
Would EDK2 take care of the RGMII Rx/Tx delays even when configured to 
use a DT instead of ACPI?
This would mean we could > do this in the driver: it currently uses

priv->phy_interface = device_get_phy_mode(&pdev->dev);

Can we just assign that to PHY_INTERFACE_MODE_NA instead?
Thanks
/Ilias
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help