On 2020-12-02, Andrew Lunn <and...@lunn.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
