From: Andrew Lunn <andrew@lunn.ch>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: netdev@vger.kernel.org, f.fainelli@gmail.com, hkallweit1@gmail.com
Subject: Re: MDIO Debug Interface
Date: Fri, 10 Jul 2020 00:39:36 +0200 [thread overview]
Message-ID: <20200709223936.GC1014141@lunn.ch> (raw)
In-Reply-To: <C42DZQLTPHM5.2THDSRK84BI3T@wkz-x280>
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
next prev parent reply other threads:[~2020-07-09 22:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 20:47 MDIO Debug Interface Tobias Waldekranz
2020-07-09 22:18 ` Vladimir Oltean
2020-07-09 22:48 ` Andrew Lunn
2020-07-10 7:51 ` Tobias Waldekranz
2020-07-09 22:36 ` Florian Fainelli
2020-07-10 8:29 ` Tobias Waldekranz
2020-07-09 22:39 ` Andrew Lunn [this message]
2020-07-09 22:57 ` Vladimir Oltean
2020-07-09 23:20 ` Andrew Lunn
2020-07-09 23:33 ` Vladimir Oltean
2020-07-10 9:30 ` Tobias Waldekranz
2020-07-10 9:45 ` Vladimir Oltean
2020-07-10 13:35 ` Andrew Lunn
2020-07-10 15:47 ` Ioana Ciornei
2020-07-10 8:51 ` Tobias Waldekranz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200709223936.GC1014141@lunn.ch \
--to=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=tobias@waldekranz.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).