netdev - Re: net: macb: fail when there's no PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <X8fb4zGoxcS6gFsc@grante>
Date:   Wed, 2 Dec 2020 12:24:35 -0600
From:   Grant Edwards <grant.b.edwards@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: net: macb: fail when there's no PHY

[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