linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Oliver Neukum <oneukum@suse.com>
Cc: hayeswang@realtek.com, grundler@chromium.org,
	davem@davemloft.net, netdev@vger.kernel.org,
	linux-usb@vger.kernel.org, Roland Dreier <roland@kernel.org>
Subject: Re: [PATCHv2 1/3] usbnet: specify naming of usbnet_set/get_link_ksettings
Date: Tue, 26 Jan 2021 14:34:45 +0100	[thread overview]
Message-ID: <YBAadd6iuN0Ov2Ba@lunn.ch> (raw)
In-Reply-To: <3da2bd93f8da246d9032f4b07dff53a1b3648ccd.camel@suse.com>

On Tue, Jan 26, 2021 at 10:42:09AM +0100, Oliver Neukum wrote:
> Am Freitag, den 22.01.2021, 02:10 +0100 schrieb Andrew Lunn:
> > On Thu, Jan 21, 2021 at 01:57:29PM +0100, Oliver Neukum wrote:
> > > The old generic functions assume that the devices includes
> > > an MDIO interface. This is true only for genuine ethernet.
> > > Devices with a higher level of abstraction or based on different
> > > technologies do not have it. So in preparation for
> > > supporting that, we rename the old functions to something specific.
> > > 
> > > v2: adjusted to recent changes
> > 
> > Hi Oliver
> > 
> > It  looks like my comment:
> > 
> > https://www.spinics.net/lists/netdev/msg711869.html
> > 
> > was ignored. Do you not like the name mii?
> 
> Hi,
> 
> sorry for not replying earlier.
> 
> It was my understanding that on the hardware level of the
> networking devices we are using MII, but to control MII we
> use MDIO, don't we?
> So it seems to me that hardware could use MII but not
> MDIO, yet for this purpose we require MDIO. So could
> you please explain your reasoning about networking stuff?

Hi Oliver

To some extent, it is a terminology problem. First off, MII includes
the two MDIO pins. MDIO is a subset of MII.

However, the bigger issue is Linux has two different bits of code
which can be used to talk to the PHY. There is the old mii code,
driver/net/mii.c. This code assumes the PHY exactly follows 802.3
clause 22.

Then we have drivers/net/mdio, drivers/net/phy, phylib, and a
collection of PHYs drivers. The MDIO drivers implement the MDIO bus,
allowing transfers over the bus. And the PHY drivers then handle the
devices on this bus. These PHY drivers can handle nearly any quirk the
PHY might have which deviate from C22. It also allows drivers to use
C45, the alternative register set PHYs can use. And it allows for
added extras, like temperature sensors, cable diagnostics and
statistics, none of which is standardised.

The code you are changing makes use of the older mii code.  There are
however some USB devices which use phylib. By using the postfix _mii
for these ops, it makes it clear it is using the older mii code. In
the future, there might be _phylib versions of these ops. It is very
unlikely any USB device driver will directly use an MDIO bus drivers,
so _mdio does not really make sense, from the perspective of Linux
code.

    Andrew

  reply	other threads:[~2021-01-26 13:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 12:57 [PATCHv2 0/3] usbnet: speed reporting for devices without MDIO Oliver Neukum
2021-01-21 12:57 ` [PATCHv2 1/3] usbnet: specify naming of usbnet_set/get_link_ksettings Oliver Neukum
2021-01-22  1:10   ` Andrew Lunn
2021-01-26  9:42     ` Oliver Neukum
2021-01-26 13:34       ` Andrew Lunn [this message]
2021-01-21 12:57 ` [PATCHv2 2/3] usbnet: add method for reporting speed without MDIO Oliver Neukum
2021-01-22  1:35   ` Grant Grundler
2021-01-22  2:56   ` Grant Grundler
2021-01-21 12:57 ` [PATCHv2 3/3] CDC-NCM: record speed in status method Oliver Neukum
2021-01-22  3:02   ` Grant Grundler
2021-01-22  1:29 ` [PATCHv2 0/3] usbnet: speed reporting for devices without MDIO Andrew Lunn
2021-01-22  2:10   ` Grant Grundler
2021-02-09 23:47     ` Grant Grundler

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=YBAadd6iuN0Ov2Ba@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=grundler@chromium.org \
    --cc=hayeswang@realtek.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=roland@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).