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: <rq8p74$2l0$1@ciao.gmane.io>
Date:   Wed, 2 Dec 2020 19:16:52 -0000 (UTC)
From:   Grant Edwards <grant.b.edwards@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: net: macb: fail when there's no PHY

On 2020-12-02, Andrew Lunn <andrew@...n.ch> wrote:
>> 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?
>
> As far as i remember, that ioctl is based on the interface name.

Right.

> So it will access the MDIO bus of the PHY that is attached to the
> MAC.

If that's the case, wouldn't the ioctl() calls "just work" even when
only the fixed-phy mdio bus and fake PHY are declared in the device
tree?  There must have been something else going on that caused our
user-space code to be unable to talk to the devices on the mdio
bus. We assumed it was because there was only one mdio bus (the fake
one) in the device tree. I'm beginning to suspect that's not the
reason.

> I guess you have user space drivers using the IOCTL to access
> devices on the real bus?

Yes.

> A switch?

There is a switch, but it's not on the mdio bus (on some models, the
switch is access via memory-mapped registers, on others the switch is
accessed via SPI). The PHYs that are attached to the "other" ports of
the switch are on the macb mdio bus.

> Can you swap to a DSA driver?

Possibly. It looks like DSA uses frame tagging. We have two slightly
different platforms. One doesn't have any tagging capabilities. The
other does, but the tags are reserved for use by another chunk of
custom code we've added to the macb.c driver to provide MAC-level
access for a userspace protocol stack which operates in parallel with
the kernel's network stack. It's almost, but not quite, as ugly as it
sounds.

>> 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?
>
> phy-handle points to a PHY.

OK, I think I've got a vague idea of how that would be done.

[When it comes to device-tree stuff, I've learned that "a vague idea"
is pretty much the best I can manage. Nothing ever works the way I
think it's going to the first time, but with enough guesses I usually
get there.]

--
Grant