All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Jeremy Linton <jeremy.linton@arm.com>,
	netdev@vger.kernel.org, davem@davemloft.net,
	f.fainelli@gmail.com, hkallweit1@gmail.com,
	madalin.bucur@oss.nxp.com, calvin.johnson@oss.nxp.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC 08/11] net: phy: Allow mdio buses to auto-probe c45 devices
Date: Mon, 25 May 2020 15:43:47 +0200	[thread overview]
Message-ID: <20200525134347.GA752669@lunn.ch> (raw)
In-Reply-To: <20200525082510.GH1551@shell.armlinux.org.uk>

> > > So i think it would be better to have
> > > 
> > > 	enum {
> > > 		MDIOBUS_UNKNOWN = 0,
> > > 		MDIOBUS_C22,
> > > 		MDIOBUS_C45,
> > > 		MDIOBUS_C45_C22,
> > > 	} bus_capabilities;
> > > 
> > > Describe just what the bus master can support.
> > 
> > Yes, the naming is reasonable and I will update it in the next patch. I went
> > around a bit myself with this naming early on, and the problem I saw was
> > that a C45 capable master, can have C45 electrical phy's that only respond
> > to c22 requests (AFAIK).
> 
> If you have a master that can only generate clause 45 cycles, and
> someone is daft enough to connect a clause 22 only PHY to it, the
> result is hardware that doesn't work - there's no getting around
> that.  The MDIO interface can't generate the appropriate cycles to
> access the clause 22 PHY.  So, this is not something we need care
> about.
> 
> > So the MDIOBUS_C45 (I think I was calling it
> > C45_ONLY) is an invalid selection. Not, that it wouldn't be helpful to have
> > a C45_ONLY case, but that the assumption is that you wouldn't try and probe
> > c22 registers, which I thought was a mistake.
> 
> MDIOBUS_C45 means "I can generate clause 45 cycles".
> MDIOBUS_C22 means "I can generate clause 22 cycles".
> MDIOBUS_C45_C22 means "I can generate both clause 45 and clause 22
> cycles."
> 
> Notice carefully the values these end up with - MDIOBUS_C22 = BIT(0),
> MDIOBUS_C45 = BIT(1), MDIOBUS_C45_C22 = BIT(0) | BIT(1).  I suspect
> that was no coincidence in Andrew's suggestion.

Hi Russell

What was a nice side affect. Since i doubt Jeremy is going to go
through every MDIO driver and set the capabilities correctly, i wanted
0 to have a safe meaning. In the code we should treat MDIOBUS_UNKNOWN
and MDIOBUS_C22 identically. But maybe some time in the distant
future, we can make 0 issue a warning.

  Andrew

  reply	other threads:[~2020-05-25 13:44 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22 21:30 [RFC 00/11] Make C45 autoprobe more robust Jeremy Linton
2020-05-22 21:30 ` [RFC 01/11] net: phy: Don't report success if devices weren't found Jeremy Linton
2020-05-23 18:20   ` Russell King - ARM Linux admin
2020-05-25  2:46     ` Jeremy Linton
2020-05-25  9:45       ` Russell King - ARM Linux admin
2020-05-25 21:02         ` Jeremy Linton
2020-05-25 21:07           ` Russell King - ARM Linux admin
2020-05-25 21:59             ` Jeremy Linton
2020-05-22 21:30 ` [RFC 02/11] net: phy: Simplify MMD device list termination Jeremy Linton
2020-05-23 18:36   ` Russell King - ARM Linux admin
2020-05-25  2:48     ` Jeremy Linton
2020-05-25  8:09       ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 03/11] net: phy: refactor c45 phy identification sequence Jeremy Linton
2020-05-23 15:28   ` Andrew Lunn
2020-05-23 17:16     ` Jeremy Linton
2020-05-23 17:32     ` Jeremy Linton
2020-05-23 19:12       ` Russell King - ARM Linux admin
2020-05-23 18:30   ` Russell King - ARM Linux admin
2020-05-23 19:51     ` Andrew Lunn
2020-05-23 20:01       ` Russell King - ARM Linux admin
2020-05-25  2:37         ` Jeremy Linton
2020-05-22 21:30 ` [RFC 04/11] net: phy: Handle c22 regs presence better Jeremy Linton
2020-05-23 18:37   ` Russell King - ARM Linux admin
2020-05-25  3:34     ` Jeremy Linton
2020-05-25  9:53       ` Russell King - ARM Linux admin
2020-05-25 10:06       ` Russell King - ARM Linux admin
2020-05-25 21:51         ` Jeremy Linton
2020-05-25 22:01           ` Russell King - ARM Linux admin
2020-05-25 22:22             ` Jeremy Linton
2020-05-25 23:09               ` Russell King - ARM Linux admin
2020-05-25 23:22                 ` Jeremy Linton
2020-05-25 23:33                   ` Russell King - ARM Linux admin
2020-05-25 23:42                     ` Jeremy Linton
2020-05-25 23:46                       ` Andrew Lunn
2020-05-25 23:57                       ` Russell King - ARM Linux admin
2020-05-25 23:16             ` Jeremy Linton
2020-05-25 23:30               ` Russell King - ARM Linux admin
2020-05-25 22:06           ` Andrew Lunn
2020-05-25 22:17             ` Jeremy Linton
2020-05-25 23:06               ` Andrew Lunn
2020-05-25 23:07               ` Russell King - ARM Linux admin
2020-05-25 23:12                 ` Andrew Lunn
2020-05-25 23:46                   ` Jeremy Linton
2020-05-25 23:47                     ` Andrew Lunn
2020-05-22 21:30 ` [RFC 05/11] net: phy: Scan the entire MMD device space Jeremy Linton
2020-05-22 21:30 ` [RFC 06/11] net: phy: Hoist no phy detected state Jeremy Linton
2020-05-22 21:30 ` [RFC 07/11] net: phy: reset invalid phy reads of 0 back to 0xffffffff Jeremy Linton
2020-05-23 18:44   ` Russell King - ARM Linux admin
2020-05-25  4:20     ` Jeremy Linton
2020-05-25  8:20       ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 08/11] net: phy: Allow mdio buses to auto-probe c45 devices Jeremy Linton
2020-05-24 14:44   ` Andrew Lunn
2020-05-25  4:28     ` Jeremy Linton
2020-05-25  8:25       ` Russell King - ARM Linux admin
2020-05-25 13:43         ` Andrew Lunn [this message]
2020-05-25 22:09         ` Jeremy Linton
2020-05-25 22:41           ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 09/11] net: phy: Refuse to consider phy_id=0 a valid phy Jeremy Linton
2020-05-22 21:30 ` [RFC 10/11] net: example acpize xgmac_mdio Jeremy Linton
2020-05-23 18:48   ` Russell King - ARM Linux admin
2020-05-22 21:30 ` [RFC 11/11] net: example xgmac enable extended scanning Jeremy Linton

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=20200525134347.GA752669@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=calvin.johnson@oss.nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=madalin.bucur@oss.nxp.com \
    --cc=netdev@vger.kernel.org \
    /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.