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

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

Message-Id: <C42TDW0HKHP7.1W0IVO67UCM4R@wkz-x280>
Date:   Fri, 10 Jul 2020 10:51:40 +0200
From:   "Tobias Waldekranz" <tobias@...dekranz.com>
To:     "Andrew Lunn" <andrew@...n.ch>
Cc:     <netdev@...r.kernel.org>, <f.fainelli@...il.com>,
        <hkallweit1@...il.com>
Subject: Re: MDIO Debug Interface

On Fri Jul 10, 2020 at 2:39 AM CEST, 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.

I'd be hesitant to claim any causality between those two statements
though. The way I see it, userspace drivers make sense for
"leaf-devices" i.e. devices which can be used by applications
directly. PHYs are not leaf-devices as they're intimately tied to a
netdev. Switches are doable as leaf-devices, which is why we have
vendor SDKs, but as the plethora of switchdev-ready applications grows
any single vendor won't be able to keep up with the community.

It is not the stick but the carrots that will kill the vendor SDKs.

> 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.

Five years ago I would have signed on to that. No vendor had even
heard of switchdev and you were laughed out of the room for suggesting
they take that route. These days, they'll typically show switchdev
support as a target on marketing slides etc. Their primary target is
still their own SDK (which makes sense since that's where most of
their customers are), but they see the writing on the wall.

> 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.

Yes! I really like this part of devlink as well. I see it as a great
way to add production safe ways of extracting debug information.

> 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.

Agreed. The drawback is that they are really only geared towards
non-destructive debugging. Sometimes, especially during development,
that is not enough.

> Andrew