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
