netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev@vger.kernel.org
Subject: Re: net: macb: fail when there's no PHY
Date: Wed, 2 Dec 2020 12:24:35 -0600	[thread overview]
Message-ID: <X8fb4zGoxcS6gFsc@grante> (raw)
In-Reply-To: <6a9c1d4a-ed73-3074-f9fa-158c697c7bfe@gmail.com>

[Sorry for sending my previous message twice, it was rejected by the
list server the first time because it contained both plaintext and
HTML alternatives].

On Wed, Dec 02, 2020 at 10:10:37AM -0800, Florian Fainelli wrote:
> On 12/2/2020 9:50 AM, Grant Edwards wrote:
>
> > I know this thread is a couple years old, but I finally got around
> > to working with a newer kernel (5.4) that has the "fixed phy"
> > support.  Unfortunately, the existing "fixed phy" support is
> > unusable for us. It doesn't just present a fake, fixed, PHY. It
> > replaces the entire mii (mdio/mdc) bus with a fake bus. That means
> > our code loses the ability to talk to the devices that /are/
> > attached to the macb's mdio management bus.
> 
> You did not indicate this was a requirement.

Indeed, I should have done so. It didn't occur to me since I was
discussing adding a fake PHY, not a fake bus.

>> So, I ended up porting my hack from the 2.6.33 macb.c driver to the
>> 5.4 macb.c driver. [...]
> 
> That should be unnecessary see below.

> &eth0 {
> 	fixed-link {
> 		speed = <1000>;
> 		full-duplex;
> 	};
> 	mdio {
> 		phy0: phy@0 {
> 			reg = <0>;
> 		};
> 	};
> };

Thanks! I may try that if we can resolve the performance issues with
the newer kernels.

When using the SIOC[SG]MIIREG ioctl() call, how does one control
whether the fake fixed-link bus is accessed or the real macb-mdio bus
is accessed? Do different phy_ids automatically get mapped to the two
busses? That requires that a particular id can only exist on one bus
(which isn't a problem).

> The key thing here is to support a "mdio" bus container node which is
> optional and is used as a hint that you need to register the MACB MDIO
> bus controller regardless of MII probing having found devices or not.

How does the macb driver decide which bus/id combination to use as
"the phy" that controls the link duplex/speed settting the the MAC?

[Feel free to point me at appropriat documentation for this.]

--
Grant

  reply	other threads:[~2020-12-02 18:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21 19:59 net: macb: fail when there's no PHY Grant Edwards
2017-09-21 20:05 ` Florian Fainelli
2017-09-21 20:36   ` Grant Edwards
2017-09-21 21:35     ` Brandon Streiff
2017-09-29  7:05       ` Harini Katakam
     [not found]   ` <CAK=1mW6Gti0QpUjirB6PfMCiQvnDjkbb56pVKkQmpCSkRU6wtA@mail.gmail.com>
2020-12-02 18:10     ` Florian Fainelli
2020-12-02 18:24       ` Grant Edwards [this message]
2020-12-02 18:35         ` Andrew Lunn
2020-12-02 19:16           ` Grant Edwards
2020-12-02 21:11             ` Andrew Lunn
2020-12-02 21:23               ` Grant Edwards
2020-12-03  2:39                 ` Andrew Lunn
2020-12-03  3:03               ` Grant Edwards
2020-12-03  3:42                 ` Florian Fainelli
2020-12-03  3:54                   ` Grant Edwards
2020-12-03  4:07                     ` Andrew Lunn
2020-12-03 15:07                       ` Grant Edwards
2020-12-03 21:17                         ` Andrew Lunn
2020-12-03 21:39                           ` Grant Edwards
2020-12-03 21:49                             ` Andrew Lunn
2020-12-03 22:20                               ` Grant Edwards
2020-12-04  8:28                                 ` Alexander Dahl
2020-12-04 17:36                                   ` Andrew Lunn
2020-12-04 16:47                     ` Florian Fainelli
2020-12-05  2:52                       ` Grant Edwards
2020-12-05  3:06                         ` Florian Fainelli
2020-12-03  4:00                 ` Andrew Lunn
2020-12-02 18:10   ` Grant Edwards

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=X8fb4zGoxcS6gFsc@grante \
    --to=grant.b.edwards@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.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 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).