netdev - Re: MDIO Debug Interface

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: <20200709225725.xwmyhny4hmiyb5nt@skbuf>
Date:   Fri, 10 Jul 2020 01:57:25 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>, netdev@...r.kernel.org,
        f.fainelli@...il.com, hkallweit1@...il.com
Subject: Re: MDIO Debug Interface

Hi Andrew,

On Fri, Jul 10, 2020 at 12:39:36AM +0200, Andrew Lunn wrote:
> On Thu, Jul 09, 2020 at 10:47:54PM +0200, Tobias Waldekranz wrote:
> > Hi netdev,
> > 
> > TL;DR: Is something like https://github.com/wkz/mdio-tools a good
> > idea?
> > 
> > The kernel does not, as far as I know, have a low-level debug
> > interface to MDIO devices. I.e. something equivalent to i2c-dev or
> > spi-dev for example.
> 
> Hi Tobias
> 
> These APIs exist to allow user space drivers. I don't know how much
> that happens now a days, there seems to be a lot of kernel space
> drivers for SPI and I2C, but it is still possible to write user space
> drivers.
> 
> We have never allowed user space drivers for MDIO devices. As a
> result, we have pretty good kernel support for PHYs and quite a few L2
> switches, and the numbers keep increasing.
> 
> But the API you are suggesting sounds like it becomes an easy way for
> vendors to run their SDKs in user space, with a small bit of glue code
> to this new API. That is something we should avoid.
> 
> It is a difficult trade off. Such an API as you suggest does allow for
> nice debug tools for driver developers. And i have no problems with
> such a tool existing, being out of tree for any developer to use. But
> i'm not too happy with it being in mainline because i suspect it will
> get abused by vendors.
> 
> Something i'm want to look at soon is dumping more of the internal
> state of the mv88e6xxx switches. The full ATU and VTU, TCAM etc. I
> think devlink region could work for this. And i think the ethtool -d
> command could be made a lot better now we have a netlink API. The old
> API assumed a single address space. It would be nice to support
> multiple address spaces.
> 
> The advantage of these APIs is that they cannot be abused by vendors
> to write user space drivers. But we can still have reasonably powerful
> debug tools built on top of them.
> 
>        Andrew

Fear not, the lack of a mainline UAPI for MDIO access will not prevent
any vendor from adding a sysfs mdio_read and mdio_write, if they need it
for their user space SDK :)

The reverse also seems true: if there are things that only the kernel
can do, then there should be a kernel driver for that respective
MDIO/SPI/I2C device, regardless of whether there is also a raw UAPI
available. It is not unheard of for a user space solution to finally get
converted to a kernel implementation.

Virtualization is a reasonable use case in my opinion and it would need
something like this, for the guest kernel to have access to its PHY.

Whereas things like "devlink region" for the ATU, VTU, etc could be kept
more high-level than the interface Tobias is proposing. There is no
clash between the 2.

-Vladimir