From: Andrew Lunn <andrew@lunn.ch>
To: Icenowy Zheng <icenowy@aosc.io>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Willy Liu <willy.liu@realtek.com>,
Jernej Skrabec <jernej.skrabec@siol.net>,
Rob Herring <robh+dt@kernel.org>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-sunxi@googlegroups.com
Subject: Re: [linux-sunxi] Re: [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified
Date: Sun, 25 Oct 2020 15:36:08 +0100 [thread overview]
Message-ID: <20201025143608.GD792004@lunn.ch> (raw)
In-Reply-To: <77AAA8B8-2918-4646-BE47-910DDDE38371@aosc.io>
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
next prev parent reply other threads:[~2020-10-25 14:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-25 8:55 [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified Icenowy Zheng
2020-10-25 14:18 ` Andrew Lunn
2020-10-25 14:27 ` [linux-sunxi] " Icenowy Zheng
2020-10-25 14:36 ` Andrew Lunn [this message]
2020-10-25 16:51 ` Icenowy Zheng
2020-10-25 17:28 ` Andrew Lunn
2020-10-26 7:44 ` Icenowy Zheng
2020-10-26 12:12 ` Andrew Lunn
2020-10-28 2:46 ` Samuel Holland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201025143608.GD792004@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=hkallweit1@gmail.com \
--cc=icenowy@aosc.io \
--cc=jernej.skrabec@siol.net \
--cc=kuba@kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=willy.liu@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).