netdev - Re: [linux-sunxi] Re: [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6f75be3f-90d7-982e-0f43-e742f04bb26e@sholland.org>
Date:   Tue, 27 Oct 2020 21:46:04 -0500
From:   Samuel Holland <samuel@...lland.org>
To:     Icenowy Zheng <icenowy@...c.io>
Cc:     andrew@...n.ch, 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

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