diff mbox series

net: phy: realtek: omit setting PHY-side delay when "rgmii" specified

Message ID 20201025085556.2861021-1-icenowy@aosc.io (mailing list archive)
State Not Applicable
Delegated to: Netdev Maintainers
Headers show
Series net: phy: realtek: omit setting PHY-side delay when "rgmii" specified | expand

Commit Message

Icenowy Zheng Oct. 25, 2020, 8:55 a.m. UTC
Currently there are many boards that just set "rgmii" as phy-mode in the
device tree, and leave the hardware [TR]XDLY pins to set PHY delay mode.

In order to keep old device tree working, omit setting delay for just
"RGMII" without any internal delay suffix, otherwise many devices are
broken.

The definition of "rgmii" in the DT binding document is "RX and TX
delays are added by MAC when required", which at least literally do not
forbid the PHY to add delays.

Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 drivers/net/phy/realtek.c | 8 --------
 1 file changed, 8 deletions(-)

Comments

Andrew Lunn Oct. 25, 2020, 2:18 p.m. UTC | #1
On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
> Currently there are many boards that just set "rgmii" as phy-mode in the
> device tree, and leave the hardware [TR]XDLY pins to set PHY delay mode.
> 
> In order to keep old device tree working, omit setting delay for just
> "RGMII" without any internal delay suffix, otherwise many devices are
> broken.

Hi Icenowy

We have been here before with the Atheros PHY. It did not correctly
implement one of the delay modes, until somebody really did need that
mode. So the driver was fixed. And we then found a number of device
trees were also buggy. It was painful for a while, but all the device
trees got fixed.

We should do the same here. Please submit patches for the device tree
files.

   Andrew
Icenowy Zheng Oct. 25, 2020, 2:27 p.m. UTC | #2
于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn <andrew@lunn.ch> 写到:
>On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
>> Currently there are many boards that just set "rgmii" as phy-mode in
>the
>> device tree, and leave the hardware [TR]XDLY pins to set PHY delay
>mode.
>> 
>> In order to keep old device tree working, omit setting delay for just
>> "RGMII" without any internal delay suffix, otherwise many devices are
>> broken.
>
>Hi Icenowy
>
>We have been here before with the Atheros PHY. It did not correctly
>implement one of the delay modes, until somebody really did need that
>mode. So the driver was fixed. And we then found a number of device
>trees were also buggy. It was painful for a while, but all the device
>trees got fixed.

1. As the PHY chip has hardware configuration for configuring delays,
we should at least have a mode that respects what's set on the hardware.
2. As I know, at least Fedora ships a device tree with their bootloader, and
the DT will not be updated with kernel. This enforces compatibility
with old DTs even if they're broken.

Personally I think if someone wants a mode that explicitly disable delays
in the PHY, a new mode may be created now, maybe called "rgmii-noid".

>
>We should do the same here. Please submit patches for the device tree
>files.
>
>   Andrew
Andrew Lunn Oct. 25, 2020, 2:36 p.m. UTC | #3
On Sun, Oct 25, 2020 at 10:27:05PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn <andrew@lunn.ch> 写到:
> >On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
> >> Currently there are many boards that just set "rgmii" as phy-mode in
> >the
> >> device tree, and leave the hardware [TR]XDLY pins to set PHY delay
> >mode.
> >> 
> >> In order to keep old device tree working, omit setting delay for just
> >> "RGMII" without any internal delay suffix, otherwise many devices are
> >> broken.
> >
> >Hi Icenowy
> >
> >We have been here before with the Atheros PHY. It did not correctly
> >implement one of the delay modes, until somebody really did need that
> >mode. So the driver was fixed. And we then found a number of device
> >trees were also buggy. It was painful for a while, but all the device
> >trees got fixed.
> 
> 1. As the PHY chip has hardware configuration for configuring delays,
> we should at least have a mode that respects what's set on the hardware.

Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "". Or
for most MAC drivers, don't list a phy-mode at all.

> 2. As I know, at least Fedora ships a device tree with their bootloader, and
> the DT will not be updated with kernel.

I would check that. Debian does the exact opposite, the last time i
looked. It always uses the DT that come with the kernel because it
understands DT can have bugs, like all software.

      Andrew
Icenowy Zheng Oct. 25, 2020, 4:51 p.m. UTC | #4
于 2020年10月25日 GMT+08:00 下午10:36:08, Andrew Lunn <andrew@lunn.ch> 写到:
>On Sun, Oct 25, 2020 at 10:27:05PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn <andrew@lunn.ch> 写到:
>> >On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote:
>> >> Currently there are many boards that just set "rgmii" as phy-mode
>in
>> >the
>> >> device tree, and leave the hardware [TR]XDLY pins to set PHY delay
>> >mode.
>> >> 
>> >> In order to keep old device tree working, omit setting delay for
>just
>> >> "RGMII" without any internal delay suffix, otherwise many devices
>are
>> >> broken.
>> >
>> >Hi Icenowy
>> >
>> >We have been here before with the Atheros PHY. It did not correctly
>> >implement one of the delay modes, until somebody really did need
>that
>> >mode. So the driver was fixed. And we then found a number of device
>> >trees were also buggy. It was painful for a while, but all the
>device
>> >trees got fixed.
>> 
>> 1. As the PHY chip has hardware configuration for configuring delays,
>> we should at least have a mode that respects what's set on the
>hardware.
>
>Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "". Or
>for most MAC drivers, don't list a phy-mode at all.

However, we still need to tell the MAC it's RGMII mode that is in use, not
MII/RMII/*MII. So the phy-mode still needs to be something that
contains rgmii.

>
>> 2. As I know, at least Fedora ships a device tree with their
>bootloader, and
>> the DT will not be updated with kernel.
>
>I would check that. Debian does the exact opposite, the last time i
>looked. It always uses the DT that come with the kernel because it
>understands DT can have bugs, like all software.
>
>      Andrew
Andrew Lunn Oct. 25, 2020, 5:28 p.m. UTC | #5
> >> 1. As the PHY chip has hardware configuration for configuring delays,
> >> we should at least have a mode that respects what's set on the
> >hardware.
> >
> >Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "". Or
> >for most MAC drivers, don't list a phy-mode at all.
> 
> However, we still need to tell the MAC it's RGMII mode that is in use, not
> MII/RMII/*MII. So the phy-mode still needs to be something that
> contains rgmii.

So for this MAC driver, you are going to have to fix the device tree.
And for the short turn, maybe implement the workaround discussed in
the other thread.

    Andrew
Icenowy Zheng Oct. 26, 2020, 7:44 a.m. UTC | #6
于 2020年10月26日 GMT+08:00 上午1:28:48, Andrew Lunn <andrew@lunn.ch> 写到:
>> >> 1. As the PHY chip has hardware configuration for configuring
>delays,
>> >> we should at least have a mode that respects what's set on the
>> >hardware.
>> >
>> >Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "".
>Or
>> >for most MAC drivers, don't list a phy-mode at all.

By referring to linux/phy.h, NA means not applicable. This surely
do not apply when RGMII is really in use.

>> 
>> However, we still need to tell the MAC it's RGMII mode that is in
>use, not
>> MII/RMII/*MII. So the phy-mode still needs to be something that
>> contains rgmii.
>
>So for this MAC driver, you are going to have to fix the device tree.
>And for the short turn, maybe implement the workaround discussed in
>the other thread.

I think no document declares RGMII must have all internal delays
of the PHY explicitly disabled. It just says RGMII.

I think the situation that RGMII is in use and PHY has the right to
decide whether to add delay or not surely matches "rgmii", and
to explicitly disable internal delays we need some other thing
like "rgmii-noid".

>
>    Andrew
Andrew Lunn Oct. 26, 2020, 12:12 p.m. UTC | #7
> By referring to linux/phy.h, NA means not applicable. This surely
> do not apply when RGMII is really in use.

It means the PHY driver should not touch the mode, something else has
set it up. That could be strapping, the bootloader, ACPI firmware,
whatever.

> I think no document declares RGMII must have all internal delays
> of the PHY explicitly disabled. It just says RGMII.

Please take a look at all the other PHY drivers. They should all
disable delays when passed PHY_INTERFACE_MODE_RGMII.

	Andrew
Samuel Holland Oct. 28, 2020, 2:46 a.m. UTC | #8
Icenowy,

On 10/26/20 7:12 AM, Andrew Lunn wrote:
>> By referring to linux/phy.h, NA means not applicable. This surely
>> do not apply when RGMII is really in use.
> 
> It means the PHY driver should not touch the mode, something else has
> set it up. That could be strapping, the bootloader, ACPI firmware,
> whatever.
> 
>> I think no document declares RGMII must have all internal delays
>> of the PHY explicitly disabled. It just says RGMII.
> 
> Please take a look at all the other PHY drivers. They should all
> disable delays when passed PHY_INTERFACE_MODE_RGMII.

Documentation/networking/phy.rst also makes this clear:

PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any internal
delay by itself, it assumes that either the Ethernet MAC (if capable or the PCB
traces) insert the correct 1.5-2ns delay

Regards,
Samuel
diff mbox series

Patch

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index fb1db713b7fb..7d32db1c789f 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -189,11 +189,6 @@  static int rtl8211f_config_init(struct phy_device *phydev)
 	phy_modify_paged_changed(phydev, 0xa43, RTL8211F_PHYCR1, val, val);
 
 	switch (phydev->interface) {
-	case PHY_INTERFACE_MODE_RGMII:
-		val_txdly = 0;
-		val_rxdly = 0;
-		break;
-
 	case PHY_INTERFACE_MODE_RGMII_RXID:
 		val_txdly = 0;
 		val_rxdly = RTL8211F_RX_DELAY;
@@ -253,9 +248,6 @@  static int rtl8211e_config_init(struct phy_device *phydev)
 
 	/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
 	switch (phydev->interface) {
-	case PHY_INTERFACE_MODE_RGMII:
-		val = RTL8211E_CTRL_DELAY | 0;
-		break;
 	case PHY_INTERFACE_MODE_RGMII_ID:
 		val = RTL8211E_CTRL_DELAY | RTL8211E_TX_DELAY | RTL8211E_RX_DELAY;
 		break;