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-next>] [day] [month] [year] [list]

Message-ID: <6a9c1d4a-ed73-3074-f9fa-158c697c7bfe@gmail.com>
Date:   Wed, 2 Dec 2020 10:10:37 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Grant Edwards <grant.b.edwards@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: net: macb: fail when there's no PHY

+Andrew,

On 12/2/2020 9:50 AM, Grant Edwards wrote:
> On Thu, Sep 21, 2017 at 3:06 PM Florian Fainelli <f.fainelli@...il.com
> <mailto:f.fainelli@...il.com>> wrote:
> 
>     On 09/21/2017 12:59 PM, Grant Edwards wrote:
>     > Several years back (circa 2.6.33) I had to hack up macb.c to work on
>     > an at91 board that didn't have a PHY connected to the macb controller.
>     > [...] 
>     > It looks like the macb driver still can't handle boards that don't
>     > have a PHY.  Is that correct?
> 
>     Not since:
>     dacdbb4dfc1a1a1378df8ebc914d4fe82259ed46 ("net: macb: add fixed-link
>     node support")
> 
>     > What's the right way to deal with this?
> 
>     Declaring a fixed PHY that will present an emulated link UP, with a
>     fixed speed/duplex etc. is the way to go.
> 
> 
> 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.

> 
> So, I ended up porting my hack from the 2.6.33 macb.c driver to the 5.4
> macb.c driver. It presents a fake PHY at one address on the mdio bus,
> but still allows normal communication with devices at other addresses on
> the bus. We use SIOC[SG]MIIREG ioctl() calls from userspace to talk to
> those "real" devices. Adding a fake PHY to the macb's mdio bus takes a
> total of about two dozen lines of code.

That should be unnecessary see below.

> 
> Was there some other way I should have done this with a 5.4 kernel that
> I was unable to discover?

You should be able to continue having the macb MDIO bus controller be
registered with no PHY/MDIO devices represented in Device Tree such that
user-space can continue to use it for ioctl() *and* you can point the
macb node to a fixed PHY for the purpose of having fixed link parameters.

There are various drivers that support exactly this mode of operation
where they use a fixed PHY for the Ethernet MAC link parameters, yet
their MDIO bus controller is used to interface with other devices such
as Ethernet switches over MDIO. Example of drivers supporting that are
stmmac, fec, mtk_star_emac and ag71xx. The way it ends up looking like
in Device Tree is the following:

&eth0 {
	fixed-link {
		speed = <1000>;
		full-duplex;
	};

	mdio {
		phy0: phy@0 {
			reg = <0>;
		};
	};
};

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.
-- 
Florian