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 mergedIt 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