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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <rqav0e$4m3$1@ciao.gmane.io>
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