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

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

On Thu, Sep 21, 2017 at 01:05:57PM -0700, Florian Fainelli 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.

Apologies, I know this thread is a few 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.

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.

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

[Unfortunately, the performance of the 5.4 kernel on an ARM926 is so
bad I don't think we're going to be able to use it.]

--
Grant