All of lore.kernel.org
 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: 33+ 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  8:28                                   ` Alexander Dahl
2020-12-04  8:28                                   ` Alexander Dahl
2020-12-04 13:42                                   ` Grant Edwards
2020-12-04 17:36                                   ` Andrew Lunn
2020-12-04 17:36                                     ` Andrew Lunn
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 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.