netdev - Re: [PATCH 1/3] ARM: dts: imx51: ZII: Add missing phy-mode

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230410100012.esudvvyik3ck7urr@skbuf>
Date:   Mon, 10 Apr 2023 13:00:12 +0300
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Andrew Lunn <andrew@...n.ch>,
        Russell King <rmk+kernel@...linux.org.uk>
Cc:     shawnguo@...nel.org, s.hauer@...gutronix.de,
        arm-soc <arm@...nel.org>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/3] ARM: dts: imx51: ZII: Add missing phy-mode

On Fri, Apr 07, 2023 at 06:10:31PM +0200, Andrew Lunn wrote:
> On Fri, Apr 07, 2023 at 06:41:59PM +0300, Vladimir Oltean wrote:
> > In theory, an MII MAC-to-MAC connection should have phy-mode = "mii" on
> > one end and phy-mode = "rev-mii" on the other, right?
> 
> In theory, yes. As far as i understand, it makes a difference to where
> the clock comes from. rev-mii is a clock provider i think.
> 
> But from what i understand of the code, and the silicon, this property
> is going to be ignored, whatever value you give it. phy-mode is only
> used and respected when the port can support 1000Base-X, SGMII, and
> above, or use its built in PHY. For MII, GMII, RMII, RGMII the port
> setting is determined by strapping resistors.
> 
> The DSA core however does care that there is a phy-mode, even if it is
> ignored. I hope after these patches land we can turn that check into
> enforce mode, and that then unlocks Russell to make phylink
> improvement.

Actually, looking at mv88e6xxx_translate_cmode() right now, I guess it's
not exactly true that the value is going to be ignored, whatever it is.
A CMODE of MV88E6XXX_PORT_STS_CMODE_MII_PHY is not going to be translated
into "rev-mii", but into "mii", same as MV88E6XXX_PORT_STS_CMODE_MII.
Same for MV88E6XXX_PORT_STS_CMODE_RMII_PHY ("rmii" and not "rev-rmii").
So, when given "rev-mii" or "rev-rmii" as phy modes in the device tree,
the generic phylink validation procedure should reject them for being
unsupported.

This means either the patch set moves forward with v1, or the driver is
fixed to accept the dedicated PHY modes for PHY roles.

Russell, what do you think?