From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
"Network Development" <netdev@vger.kernel.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Russell King" <rmk+kernel@armlinux.org.uk>
Subject: Re: Race between "Generic PHY" and "bcm53xx" drivers after -EPROBE_DEFER
Date: Mon, 20 Sep 2021 21:58:56 +0300 [thread overview]
Message-ID: <20210920185856.4mffcj7rifslxyil@skbuf> (raw)
In-Reply-To: <e010a9da-417d-e4b2-0f2f-b35f92b0812f@gmail.com>
On Mon, Sep 20, 2021 at 11:10:39AM -0700, Florian Fainelli wrote:
> > But even so, what's a "pseudo PHY" exactly? I think that's at the bottom
> > of this issue. In the Linux device model, a device has a single driver.
> > In this case, the same MDIO device either has a switch driver, if you
> > accept it's a switch, or a PHY driver, if you accept it's a PHY.
> > I said it's "broken" because the expectation seems to be that it's a switch,
> > but it looks like it's treated otherwise. Simply put, the same device
> > can't be both a switch and a PHY.
>
> A pseudo-PHY is a device that can snoop and respond to MDIO bus
> requests. I understand it cannot be both, just explaining to you how the
> people at Broadcom have been seeing the world from their perspective.
> Anything that is found at MDIO address 0x1e/30 is considered a MDIO
> attached switch, that's all.
Nothing wrong with that per se, at NXP we've been thinking about RevMII
as well, and having a switch expose itself as a PHY over MDIO, in any
case something a bit richer/more interactive than a fixed-link.
One way to bypass that limitation is to access the switch registers
through a different device compared to the PHY device. At the very
least, a different MDIO address. Even better, not over MDIO at all, but
something faster, SPI, PCIe etc.
prev parent reply other threads:[~2021-09-21 2:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 12:52 Race between "Generic PHY" and "bcm53xx" drivers after -EPROBE_DEFER Rafał Miłecki
2021-09-20 16:36 ` Florian Fainelli
2021-09-20 17:03 ` Vladimir Oltean
2021-09-20 17:14 ` Florian Fainelli
2021-09-20 17:40 ` Vladimir Oltean
2021-09-20 17:46 ` Florian Fainelli
2021-09-20 18:02 ` Vladimir Oltean
2021-09-20 18:10 ` Florian Fainelli
2021-09-20 18:17 ` Vladimir Oltean
2021-09-20 18:25 ` Florian Fainelli
2021-09-20 18:36 ` Vladimir Oltean
2021-09-21 9:45 ` Rafał Miłecki
2021-09-21 10:52 ` Rafał Miłecki
2021-09-20 18:58 ` Vladimir Oltean [this message]
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=20210920185856.4mffcj7rifslxyil@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
--cc=zajec5@gmail.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.