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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.