[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C3279C11-EE7F-49FA-9BB3-ACA797B7B690@aosc.io>
Date: Mon, 26 Oct 2020 15:44:32 +0800
From: Icenowy Zheng <icenowy@...c.io>
To: andrew@...n.ch, Andrew Lunn <andrew@...n.ch>
CC: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Willy Liu <willy.liu@...ltek.com>,
Jernej Skrabec <jernej.skrabec@...l.net>,
Rob Herring <robh+dt@...nel.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: Re: [linux-sunxi] Re: [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified
于 2020年10月26日 GMT+08:00 上午1:28:48, Andrew Lunn <andrew@...n.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
Powered by blists - more mailing lists