All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <danilokrummrich@dk-develop.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	davem@davemloft.net, hkallweit1@gmail.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	jeremy.linton@arm.com
Subject: Re: [PATCH 2/2] net: mdio: support c45 peripherals on c22 busses
Date: Mon, 5 Apr 2021 20:58:07 +0200	[thread overview]
Message-ID: <YGtdv++nv3H5K43E@arch-linux> (raw)
In-Reply-To: <YGsRwxwXILC1Tp2S@lunn.ch>

On Mon, Apr 05, 2021 at 03:33:55PM +0200, Andrew Lunn wrote:
> On Sun, Apr 04, 2021 at 09:23:55PM +0200, Danilo Krummrich wrote:
> > So currently every driver should check for the flag MII_ADDR_C45 and report an
> > error in case it's unsupported.
> > 
> > What do you think about checking the bus' capabilities instead in
> > mdiobus_c45_*()? This way the check if C45 is supported can even happen before
> > calling the driver at all. I think that would be a little cleaner than having
> > two places where information of the bus' capabilities are stored (return value
> > of read/write functions and the capabilities field).
> > 
> > I think there are not too many drivers setting their capabilities though, but
> > it should be easy to derive this information from how and if they handle the
> > MII_ADDR_C45 flag.
> 
> I actually don't think anything needs to change. The Marvell PHY
> probably probes due to its C22 IDs. The driver will then requests C45
> access which automagically get converted into C45 over C22 for your
> hardware, but remain C45 access for bus drivers which support C45.
> 
Thanks Andrew - I agree, for the Marvell PHY to work I likly don't need any
change, since I also expect that it will probe with the C22 IDs. I'll try
this soon.

However, this was about something else - Russell wrote:
> > > We have established that MDIO drivers need to reject accesses for
> > > reads/writes that they do not support [..]
The MDIO drivers do this by checking the MII_ADDR_C45 flag if it's a C45 bus
request. In case they don't support it they return -EOPNOTSUPP. So basically,
the bus drivers read/write functions (should) encode the capability of doing
C45 transfers.

I just noted that this is redundant to the bus' capabilities field of
struct mii_bus which also encodes the bus' capabilities of doing C22 and/or C45
transfers.

Now, instead of encoding this information of the bus' capabilities at both
places, I'd propose just checking the mii_bus->capabilities field in the
mdiobus_c45_*() functions. IMHO this would be a little cleaner, than having two
places where this information is stored. What do you think about that?
> 	  Andrew

  reply	other threads:[~2021-04-05 18:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-31 14:17 net: mdio: support c45 peripherals on c22 only capable mdio controllers Danilo Krummrich
2021-03-31 14:17 ` [PATCH 1/2] net: mdio: rename mii bus probe_capabilities Danilo Krummrich
2021-03-31 14:17 ` [PATCH 2/2] net: mdio: support c45 peripherals on c22 busses Danilo Krummrich
2021-03-31 16:27   ` Andrew Lunn
2021-03-31 17:58     ` danilokrummrich
2021-03-31 18:35       ` Russell King - ARM Linux admin
2021-04-01  1:23         ` danilokrummrich
2021-04-01  8:48           ` Russell King - ARM Linux admin
2021-04-02  1:10             ` Danilo Krummrich
2021-04-02 12:28               ` Andrew Lunn
2021-04-04 18:25                 ` Danilo Krummrich
2022-02-08 16:30                   ` Geert Uytterhoeven
2022-02-08 22:52                     ` Danilo Krummrich
2021-04-02 12:58               ` Russell King - ARM Linux admin
2021-04-04 19:23                 ` Danilo Krummrich
2021-04-05 13:33                   ` Andrew Lunn
2021-04-05 18:58                     ` Danilo Krummrich [this message]
2021-04-05 19:27                       ` Andrew Lunn
2021-04-05 22:30                         ` Danilo Krummrich
2021-04-06  7:21                           ` Danilo Krummrich
2021-04-05 21:12                       ` Russell King - ARM Linux admin
2021-04-07 13:26                         ` Danilo Krummrich

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=YGtdv++nv3H5K43E@arch-linux \
    --to=danilokrummrich@dk-develop.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --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.