On 2020-12-03, Andrew Lunn <and...@lunn.ch> wrote: >> So I can avoid my local hack to macb_main.c by doing a doing a local >> hack to macb_main.c? > > User space drivers were never supported in any meaningful way. The > IOCTL call is basically there for mii-tool, and nothing much more.
I probably wouldn't call a single ioctl() to check the link status a user-space-driver, but I guess that's what it is. If it's good enough for the mii-tool, it's good enough for me. > The way to avoid your local hack is to move your drivers into the > kernel, along side all the other drivers for devices on MDIO busses. I don't think I can justify the additional effort to devlope and maintain a custom kern-space driver. We've already got a custom macb driver, and writing a spearate driver in order to remove a handful of lines from the macb driver just isn't worth it. What has confused me all along was Florian Fainelli's post: >> [I modified the macb driver to support fixed PHY plus mdio access] > > 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. But to do that, I have to modify the macb driver to support a fixed PHY plus mdio access. What would be the advantage of that modification over the modification I've already made and tested? Alternatively, I could write a seperate kernel driver that would "own" the macb's mdio bus and provide some something equivalent to the existing SIOC[SG]MIIREG ioctl() calls to access the devices on that mdio bus. Thanks for clearing this up for me. BTW Andrew, we're still shipping plenty of product that running eCos. :) -- Grant
