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
| ||
|
Date: Thu, 3 Dec 2020 15:07:58 -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-03, Andrew Lunn <andrew@...n.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
Powered by blists - more mailing lists