From: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Tobias Waldekranz <tobias@waldekranz.com>,
netdev@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com
Subject: Re: MDIO Debug Interface
Date: Fri, 10 Jul 2020 01:20:35 +0200 [thread overview]
Message-ID: <20200709232035.GE1014141@lunn.ch> (raw)
In-Reply-To: <20200709225725.xwmyhny4hmiyb5nt@skbuf>
> 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 :)
They do. But it means you have to use their kernel, or at least their
kernel module. That will put off some people. But if they can claim it
works on any kernel after v5.9, it makes the marketing much easier.
Like i said, it is a trade off.
> 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.
And i would like a better understanding of this use case. It seems odd
you are putting the driver for a PHY in the VM. Is the MAC driver also
in the VM? As you said, VM context switches are expensive, so it would
seem to make more sense to let the host drive the hardware, which it
can do without all these context switches, and export a much simpler
and efficient API to the VM.
Andrew
next prev parent reply other threads:[~2020-07-09 23:20 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
2020-07-09 22:57 ` Vladimir Oltean
2020-07-09 23:20 ` Andrew Lunn [this message]
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=20200709232035.GE1014141@lunn.ch \
--to=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--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).