On Sat, 17 Oct 2020 at 20:11, Ard Biesheuvel <a...@kernel.org> wrote: > > 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.
... or add a property that makes 'phy-mode' take effect, and default to ignoring it.
