From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: Hayes Wang <hayeswang@realtek.com>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
nic_swsd <nic_swsd@realtek.com>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>
Subject: Re: [RFC PATCH 0/4] r8169: support dash
Date: Fri, 3 Dec 2021 17:32:03 -0800 [thread overview]
Message-ID: <20211203173203.285dc75f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20211204010829.7796-1-alexandr.lobakin@intel.com>
On Sat, 4 Dec 2021 02:08:29 +0100 Alexander Lobakin wrote:
> > Ah, I've only spotted the enable/disable knob in the patch.
> > If you're exchanging arbitrary binary data with the FW we
> > can't help you. It's not going to fly upstream.
>
> Uhm. I'm not saying sysfs is a proper way to do that, not at all,
> buuut...
> We have a ton of different subsystems providing a communication
> channel between userspace and HW/FW. Chardevices all over the
> tree, highly used rpmsg for remoteproc, uio.
Not in Ethernet.
> We have register dump in Ethtool,
Read only.
> as well as get/set for EEPROM, I'd count them as well.
EEPROM writes are supposed to update FW images, not send random
messages.
> So it probably isn't a bad idea to provide some standard API for
> network drivers to talk to HW/FW from userspace, like get/set or
> rx/tx (when having enough caps for sure)? It could be Devlink ops
> or Ethtool ops, the latter fits more to me.
I'm not saying it's wrong to merge shim drivers into the kernel and
let the user space talk to device FW. I'm saying it's counter to what
netdev's policy has always been and counter to my personal interests.
What is a standard API for custom, proprietary FW message interface?
We want standards at a functional level. Once you open up a raw FW
write interface there is no policing of what goes thru it.
I CCed Intel since you also have the (infamous) ME, but I never heard
of the need to communicate from the OS to the ME via the netdev
driver... Not sure why things are different for Realtek.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC PATCH 0/4] r8169: support dash
Date: Fri, 3 Dec 2021 17:32:03 -0800 [thread overview]
Message-ID: <20211203173203.285dc75f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20211204010829.7796-1-alexandr.lobakin@intel.com>
On Sat, 4 Dec 2021 02:08:29 +0100 Alexander Lobakin wrote:
> > Ah, I've only spotted the enable/disable knob in the patch.
> > If you're exchanging arbitrary binary data with the FW we
> > can't help you. It's not going to fly upstream.
>
> Uhm. I'm not saying sysfs is a proper way to do that, not at all,
> buuut...
> We have a ton of different subsystems providing a communication
> channel between userspace and HW/FW. Chardevices all over the
> tree, highly used rpmsg for remoteproc, uio.
Not in Ethernet.
> We have register dump in Ethtool,
Read only.
> as well as get/set for EEPROM, I'd count them as well.
EEPROM writes are supposed to update FW images, not send random
messages.
> So it probably isn't a bad idea to provide some standard API for
> network drivers to talk to HW/FW from userspace, like get/set or
> rx/tx (when having enough caps for sure)? It could be Devlink ops
> or Ethtool ops, the latter fits more to me.
I'm not saying it's wrong to merge shim drivers into the kernel and
let the user space talk to device FW. I'm saying it's counter to what
netdev's policy has always been and counter to my personal interests.
What is a standard API for custom, proprietary FW message interface?
We want standards at a functional level. Once you open up a raw FW
write interface there is no policing of what goes thru it.
I CCed Intel since you also have the (infamous) ME, but I never heard
of the need to communicate from the OS to the ME via the netdev
driver... Not sure why things are different for Realtek.
next prev parent reply other threads:[~2021-12-04 1:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 10:13 [RFC PATCH 0/4] r8169: support dash Hayes Wang
2021-11-29 10:13 ` [RFC PATCH 1/4] r8169: remove the relative code about dash Hayes Wang
2021-11-29 10:13 ` [RFC PATCH 2/4] r8169: add type2 access functions Hayes Wang
2021-11-29 10:13 ` [RFC PATCH 3/4] r8169: support CMAC Hayes Wang
2021-11-29 15:47 ` kernel test robot
2021-11-29 20:46 ` Heiner Kallweit
2021-12-03 7:57 ` Hayes Wang
2021-12-03 11:37 ` Heiner Kallweit
2021-11-29 10:13 ` [RFC PATCH 4/4] r8169: add sysfs for dash Hayes Wang
2021-12-03 15:15 ` Heiner Kallweit
2021-12-07 6:53 ` Hayes Wang
2021-12-07 7:38 ` Heiner Kallweit
2021-12-07 8:20 ` Hayes Wang
2021-11-29 17:59 ` [RFC PATCH 0/4] r8169: support dash Jakub Kicinski
2021-11-29 17:59 ` [Intel-wired-lan] " Jakub Kicinski
2021-12-01 2:57 ` Hayes Wang
2021-12-01 2:57 ` [Intel-wired-lan] " Hayes Wang
2021-12-01 3:09 ` Jakub Kicinski
2021-12-01 3:09 ` [Intel-wired-lan] " Jakub Kicinski
2021-12-03 7:57 ` Hayes Wang
2021-12-03 7:57 ` [Intel-wired-lan] " Hayes Wang
2021-12-03 15:04 ` Jakub Kicinski
2021-12-03 15:04 ` [Intel-wired-lan] " Jakub Kicinski
2021-12-04 1:08 ` Alexander Lobakin
2021-12-04 1:08 ` [Intel-wired-lan] " Alexander Lobakin
2021-12-04 1:32 ` Jakub Kicinski [this message]
2021-12-04 1:32 ` Jakub Kicinski
2021-12-07 7:28 ` Hayes Wang
2021-12-07 7:28 ` [Intel-wired-lan] " Hayes Wang
2021-12-08 4:21 ` Jakub Kicinski
2021-12-08 4:21 ` [Intel-wired-lan] " Jakub Kicinski
2021-12-08 7:53 ` Hayes Wang
2021-12-08 7:53 ` [Intel-wired-lan] " Hayes Wang
2021-12-08 21:37 ` Jakub Kicinski
2021-12-08 21:37 ` [Intel-wired-lan] " Jakub Kicinski
2021-12-09 7:14 ` Hayes Wang
2021-12-09 7:14 ` [Intel-wired-lan] " Hayes Wang
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=20211203173203.285dc75f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=alexandr.lobakin@intel.com \
--cc=hayeswang@realtek.com \
--cc=hkallweit1@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.