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
| ||
|
Date: Sat, 4 Dec 2021 02:08:29 +0100 From: Alexander Lobakin <alexandr.lobakin@...el.com> To: Jakub Kicinski <kuba@...nel.org> Cc: Alexander Lobakin <alexandr.lobakin@...el.com>, Hayes Wang <hayeswang@...ltek.com>, "hkallweit1@...il.com" <hkallweit1@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, nic_swsd <nic_swsd@...ltek.com>, "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org> Subject: Re: [RFC PATCH 0/4] r8169: support dash From: Jakub Kicinski <kuba@...nel.org> Date: Fri, 3 Dec 2021 07:04:10 -0800 > On Fri, 3 Dec 2021 07:57:08 +0000 Hayes Wang wrote: > > Jakub Kicinski <kuba@...nel.org> > > > I'm not sure how relevant it will be to you but this is the > > > documentation we have: > > > > > > https://www.kernel.org/doc/html/latest/networking/devlink/index.html > > > https://www.kernel.org/doc/html/latest/networking/devlink/devlink-params.ht > > > ml > > > > > > You'll need to add a generic parameter (define + a short description) > > > like 325e0d0aa683 ("devlink: Add 'enable_iwarp' generic device param") > > > > > > In terms of driver changes I think the most relevant example to you > > > will be: > > > > > > drivers/net/ethernet/ti/cpsw_new.c > > > > > > You need to call devlink_alloc(), devlink_register and > > > devlink_params_register() (and the inverse functions). > > > > I have studied the devlink briefly. > > > > However, I find some problems. First, our > > settings are dependent on the design of > > both the hardware and firmware. That is, > > I don't think the others need to do the > > settings as the same as us. The devlink > > seems to let everyone could use the same > > command to do the same setting. However, > > most of our settings are useless for the > > other devices. > > > > Second, according to the design of our > > CMAC, the application has to read and > > write data with variable length from/to > > the firmware. Each custom has his own > > requests. Therefore, our customs would > > get different firmware with different > > behavior. Only the application and the > > firmware know how to communicate with > > each other. The driver only passes the > > data between them. Like the Ethernet > > driver, it doesn't need to know the > > contend of the packet. I could implement > > the CMAC through sysfs, but I don't > > know how to do by devlink. > > > > In brief, CMAC is our major method to > > configure the firmware and get response > > from the firmware. Except for certain information, > > the other settings are not standard and useless > > for the other vendors. > > > > Is the devlink the only method I could use? > > Actually, we use IOCTL now. We wish to > > convert it to sysfs for upstream driver. > > 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. We have register dump in Ethtool, as well as get/set for EEPROM, I'd count them as well. 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. Al
Powered by blists - more mailing lists