On Sat, 17 Oct 2020 at 20:04, Andrew Lunn <and...@lunn.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.
