On Sun, Oct 18, 2020 at 06:36:25PM +0200, Ard Biesheuvel wrote:
> Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), the Realtek PHY driver will override any TX/RX delay
> set by hardware straps if the phy-mode device property does not match.
>
> This is causing problems on SynQuacer based platforms (the only SoC
> that incorporates the netsec hardware), since many were built with
> this Realtek PHY, and shipped with firmware that defines the phy-mode
> as 'rgmii', even though the PHY is configured for TX and RX delay using
> pull-ups.
>
> >From the driver's perspective, we should not make any assumptions in
> the general case that the PHY hardware does not require any initial
> configuration. However, the situation is slightly different for ACPI
> boot, since it implies rich firmware with AML abstractions to handle
> hardware details that are not exposed to the OS. So in the ACPI case,
> it is reasonable to assume that the PHY comes up in the right mode,
> regardless of whether the mode is set by straps, by boot time firmware
> or by AML executed by the ACPI interpreter.
>
> So let's ignore the 'phy-mode' device property when probing the netsec
> driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA,
> which should work with any PHY provided that it is configured by the
> time the driver attaches to it. While at it, document that omitting
> the mode is permitted for DT probing as well, by setting the phy-mode
> DT property to the empty string.
>
> Cc: Jassi Brar <jaswinder.si...@linaro.org>
> Cc: Ilias Apalodimas <ilias.apalodi...@linaro.org>
> Cc: Masami Hiramatsu <mhira...@kernel.org>
> Cc: Andrew Lunn <and...@lunn.ch>
> Cc: Willy Liu <willy....@realtek.com>
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: Jakub Kicinski <k...@kernel.org>
> Cc: Masahisa Kojima <masahisa.koj...@linaro.org>
> Cc: Serge Semin <fancer.lan...@gmail.com>
> Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
> Signed-off-by: Ard Biesheuvel <a...@kernel.org>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Andrew
