From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
shawnguo@kernel.org, s.hauer@pengutronix.de,
arm-soc <arm@kernel.org>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 1/3] ARM: dts: imx51: ZII: Add missing phy-mode
Date: Mon, 10 Apr 2023 11:37:15 +0100 [thread overview]
Message-ID: <ZDPm28C7xXulpG1L@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230410100012.esudvvyik3ck7urr@skbuf>
On Mon, Apr 10, 2023 at 01:00:12PM +0300, Vladimir Oltean wrote:
> 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?
I'm afraid I didn't bother trying to understand all the *MII modes
that Marvell document poorly in their functional specification,
especially when they document that e.g. RMII_PHY mode can also be
used to connect to a PHY. I took their table with a pinch of salt
and did what I thought was best.
It is entirely possible that some are wrong, especially as we don't
document what the various PHY_INTERFACE_MODE_* mean in the kernel
(remember that I started doing that).
As far as phylink, it treats REV*MII and the corresponding *MII
mode the same way in terms of their capabilities, but as you say
it will determine which mode will be acceptable.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-04-10 10:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 15:25 [PATCH 0/3] Add missing DSA properties for marvell switches Andrew Lunn
2023-04-07 15:25 ` [PATCH 1/3] ARM: dts: imx51: ZII: Add missing phy-mode Andrew Lunn
2023-04-07 15:41 ` Vladimir Oltean
2023-04-07 16:10 ` Andrew Lunn
2023-04-07 16:50 ` Vladimir Oltean
2023-04-07 17:06 ` Andrew Lunn
2023-04-10 10:00 ` Vladimir Oltean
2023-04-10 10:37 ` Russell King (Oracle) [this message]
2023-04-10 15:24 ` Vladimir Oltean
2023-04-10 11:59 ` Andrew Lunn
2023-04-10 12:35 ` Andrew Lunn
2023-04-10 13:11 ` Vladimir Oltean
2023-04-10 14:56 ` Andrew Lunn
2023-04-07 15:25 ` [PATCH 2/3] ARM: dts: imx6qdl: Add missing phy-mode and fixed links Andrew Lunn
2023-04-07 15:25 ` [PATCH 3/3] ARM64: dts: freescale: ZII: Add missing phy-mode Andrew Lunn
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=ZDPm28C7xXulpG1L@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=arm@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=vladimir.oltean@nxp.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.