From: Samuel Holland <samuel@sholland.org>
To: Icenowy Zheng <icenowy@aosc.io>
Cc: andrew@lunn.ch, 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: Tue, 27 Oct 2020 21:46:04 -0500 [thread overview]
Message-ID: <6f75be3f-90d7-982e-0f43-e742f04bb26e@sholland.org> (raw)
In-Reply-To: <20201026121257.GB836546@lunn.ch>
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
prev parent reply other threads:[~2020-10-29 2:00 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
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 [this message]
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=6f75be3f-90d7-982e-0f43-e742f04bb26e@sholland.org \
--to=samuel@sholland.org \
--cc=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.