Cfg80211/nl80211: Add Api For Mac
On Fri, Sep 25, 2009 at 09:53:35AM -0700, Luis R. Rodriguez wrote: On Fri, Sep 25, 2009 at 9:47 AM, Kalle Valo wrote: But we want to export two strings to user space (at least for now), is it really worth the effort to add ethtool support for such a minor feature? Also I have understood that ethtool is implemented only for ethernet drivers, I don't feel comfortable that we use ethernet driver interfaces with 802.11 device drivers. They are so much different that there isn't that much common functionality.
Mar 15, 2015 - Mac80211 is a driver API that supports only software MAC devices. As another example, adding a new network protocol should ideally not. The kernel, and the corresponding handler in the kernel is nl80211 in cfg80211.
That's why I prefer nl80211 over ethtool. What do people think? So for Wake-on-Wireless I ran into the same, ethtool just did not offer the same wake up events needed for wireless. I could have technically used ethtool and expanded it to support wireless but it just seemed dirty. I agree that using ethtool seems overkill compared to the patches you posted. I think you either overestimate the amount of trouble for implementing (minimal) ethtool support or you underestimate the amount of functionality available through that interface.
That, or you just don't like using something named 'eth'tool for wireless - but hey, let's be honest about the frames we send/receive to/from the kernel.:-) The ethtool interface provides functionality for viewing and modifying eeprom contents, dumping registers, trigger self-tests, basic driver info, getting and setting message reporting levels, external card identification (hey, could be useful!), and some other bits like checksum offload that might(?) be useful in the future. I understand regarding the WoW vs. WoL issue but probably the answer is just to add a new method for WoW.? I'll post a patch series based on what Kalle sent but using ethtool instead of nl80211. John - John W. Linville Someday the world will need a hero, and you might be all we have. To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at John W.
Linville 30/9/2009, 18:19 น. From: Kalle Valo Set firmware and hardware version in wiphy so that user space can access it. (Modification from original in favor of cfg80211 ethtool support. JWL) Cc: Kalle Valo Signed-off-by: John W. On Wed, 2009-09-30 at 21:19 -0400, John W. Linville wrote:.
+void cfg80211getdrvinfo(struct netdevice.dev, struct ethtooldrvinfo.info) + + struct wirelessdev.wdev = dev-ieee80211ptr; + + strncpy(info-driver, wiphydev(wdev-wiphy)-driver-name+ sizeof(info-driver)); + info-driversizeof(info-driver) - 1 = ' 0';. Use strlcpy instead of these two statements. Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at Ben Hutchings 30/9/2009, 18:32 น. On Wed, 2009-09-30 at 21:19 -0400, John W.
Linville wrote:. + len = sizeof(wiphy-fwversion); + snprintf(wiphy-fwversion, len, '%d.%d.%d-%d'+ priv-fwversion.major, priv-fwversion.minor+ priv-fwversion.patch, priv-fwversion.build); + /. null terminate the strings in case they were truncated./ + wiphy-fwversionlen - 1 = ' 0';. This last statement is unnecessary; snprintf always null-terminates (unless the length is zero).
Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.
To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at Johannes Berg 1/10/2009, 1:51 น. Linville' writes: On Fri, Sep 25, 2009 at 09:53:35AM -0700, Luis R. Rodriguez wrote: So for Wake-on-Wireless I ran into the same, ethtool just did not offer the same wake up events needed for wireless. I could have technically used ethtool and expanded it to support wireless but it just seemed dirty. I agree that using ethtool seems overkill compared to the patches you posted.
I think you either overestimate the amount of trouble for implementing (minimal) ethtool support or you underestimate the amount of functionality available through that interface. I'm not worried about the implementation complexity, and as your patches show it was easy.
My concern is the overall design for wireless devices. Instead of using nl80211 for everything, with some features we would use nl80211/iw and with some ethtool. That's just confusing and I don't like that. I would prefer that nl80211 provides everything, it makes things so much easier. That, or you just don't like using something named 'eth'tool for wireless - but hey, let's be honest about the frames we send/receive to/from the kernel.:-) I don't have a problem with the name:) But ethernet is still so much different from 802.11 that there isn't that much to share and we in wireless will need different features. One example is the hw version, ethtool only provides u32 to userspace and moves the burden of translating hw id to the user.
For us a string is much better choise because when debuggin we need to often (or always?) know the chip version. But this is not something I will start fighting about. If you still think that ethtool is the way to go, I'm perfectly fine with it. The ethtool interface provides functionality for viewing and modifying eeprom contents, dumping registers, trigger self-tests, basic driver info, getting and setting message reporting levels, external card identification (hey, could be useful!), and some other bits like checksum offload that might(?) be useful in the future. I understand regarding the WoW vs. WoL issue but probably the answer is just to add a new method for WoW.? I took a look at ethtool help output from debian unstable and I think this is the set of features we can use in wireless: ethtool -i -driver DEVNAME Show driver information ethtool -d -register-dump DEVNAME Do a register dump raw on off file FILENAME ethtool -e -eeprom-dump DEVNAME Do a EEPROM dump raw on off offset N length N ethtool -E -change-eeprom DEVNAME Change bytes in device EEPROM magic N offset N value N ethtool -p -identify DEVNAME Show visible port identification (e.g.
Blinking) TIME-IN-SECONDS ethtool -t -test DEVNAME Execute adapter self test online offline But here are the features which I doubt we will ever use: ethtool -s -change DEVNAME Change generic options speed%%d duplex half full port tp aui bnc mii fibre autoneg on off advertise%%x phyad%%d xcvr internal external wol p u m b a g s d. Ben Hutchings writes: On Wed, 2009-09-30 at 21:19 -0400, John W. Linville wrote:. + len = sizeof(wiphy-fwversion); + snprintf(wiphy-fwversion, len, '%d.%d.%d-%d'+ priv-fwversion.major, priv-fwversion.minor+ priv-fwversion.patch, priv-fwversion.build); + /. null terminate the strings in case they were truncated./ + wiphy-fwversionlen - 1 = ' 0';. This last statement is unnecessary; snprintf always null-terminates (unless the length is zero). Yes, the extra null termination is unnecessary.
This was my mistake in the first patchset I sent. Kalle Valo - To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at John W. Linville 1/10/2009, 8:18 น. On Thu, 2009-10-01 at 11:18 -0400, John W.
Linville wrote:. But here are the features which I doubt we will ever use: ethtool -s -change DEVNAME Change generic options speed%%d duplex half full port tp aui bnc mii fibre autoneg on off advertise%%x phyad%%d xcvr internal external wol p u m b a g s d. sopass%%x:%%x:%%x:%%x:%%x:%%x msglvl%%d ethtool -a -show-pause DEVNAME Show pause options ethtool -A -pause DEVNAME Set pause options autoneg on off rx on off tx on off I agree that the above are ethernet-specific. Message level isn't and WoL arguably isn't.
It's a shame that these original ethtool settings are still bundled together. Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at Kalle Valo 1/10/2009, 9:20 น. Linville' writes: On Thu, Oct 01, 2009 at 05:18:33PM +0300, Kalle Valo wrote: I'm not worried about the implementation complexity, and as your patches show it was easy. My concern is the overall design for wireless devices.
Instead of using nl80211 for everything, with some features we would use nl80211/iw and with some ethtool. Mac duggal 062d0fa 924927 ieena for mac. That's just confusing and I don't like that. I would prefer that nl80211 provides everything, it makes things so much easier.
Well, if the hw/fw version numbers were the only thing then I'd probably say it's not a big deal. But having ethtool support is nice in that it makes a familiar tool work for us. Among other thingsthis probably helps with some distro scripts that don't work quite right without it. Plus, there is lots of debugging stuff that could be turned-on without having to write new tools. Agreed, maybe expect the distro scripts part. To me that just sounds as a bug in the scripts.
I suppose I understand the 'one API' idea, but why duplicate functionality? Just because the common functionality in this case isn't high enough. I'm worried that we will use 10% of the functionality in nl80211 and the rest 90% will be something we can't use and have to reimplement in nl80211. Anyway, adding a couple of ioctl calls isn't a big deal. Sure, but we need to support this forever. If, say after two years, we decide that ethtool is not the way to go, it's very difficult to remove it. The less interfaces we have, the easier it is to maintain them.
Cfg80211/nl80211: Add Api For Mac Mac
And don't forget, we are still network drivers too. I hope ethtool isn't a strict requirement for a network driver, at least I haven't heard about that. One example is the hw version, ethtool only provides u32 to userspace and moves the burden of translating hw id to the user. For us a string is much better choise because when debuggin we need to often (or always?) know the chip version. Look at the way most drivers set the version (using each byte as a field). Yes, that's how it is also with wl1251.
A number like '0x7030101' is just not that user friendly. If you want prettier output, adding a parser to the userland ethtool is fairly trivial. It looks something like the patch below. Oh wow, that's cool and a truly useful feature.
One complaint less from me:) Maybe, or maybe not. We will only find out within the next few years. And what will we do if the parameters are actually a bit different? Is it ok to extend ethtool for supporting wireless or do we later on have to add separate support to nl80211? The latter would suck big time. ethtool -g -show-ring DEVNAME Query RX/TX ring parameters ethtool -G -set-ring DEVNAME Set RX/TX ring parameters rx N rx-mini N rx-jumbo N tx N Wireless devices have ring buffers, no? Yes, there is hardware which have them but again the question is this relevant for wireless devices.
In ethernet the hardware is the bottleneck but in 802.11 the wireless medium is the bottleneck, so the parameters we need to configure are usually different. ethtool -r -negotiate DEVNAME Restart N-WAY negotation Ethernet-specific.might could be overloaded for wireless to trigger reassoc.? Please no, I don't want to see any reassociation or anything else 802.11 state related in ethtool, nl80211 was created for this. This is something I would object loudly:) Anyway, it doesn't really matter if we don't use the whole API - many older ethernet devices don't support all these features. The point is that the API exists and has some overlap with our needs. It is a driver-oriented API, with nitty-gritty stuff that need not clutter a configuraiton API like cfg80211.
There is even the potential of us adding our own extensions (e.g. WoW) that are also device-oriented. Anyway, between the link detection and making distro scripts work plus enabling a familiar tool for basic driver info I think this is a win. So much the better if some drivers move to ethtool for register dumping, setting message verbosity, querying/changing eeprom valuesetc, etc. Sounds good enough.
As I said in my earlier email, I'm not going argue about this for too long. You know this better than I do. So let's go forward with ethtool. Thanks for listening to my concerns. Kalle Valo - To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at John W. Linville 1/10/2009, 9:56 น.
On Thu, Oct 01, 2009 at 04:33:19PM +0100, Ben Hutchings wrote: On Thu, 2009-10-01 at 11:18 -0400, John W. Linville wrote:. But here are the features which I doubt we will ever use: ethtool -s -change DEVNAME Change generic options speed%%d duplex half full port tp aui bnc mii fibre autoneg on off advertise%%x phyad%%d xcvr internal external wol p u m b a g s d. sopass%%x:%%x:%%x:%%x:%%x:%%x msglvl%%d ethtool -a -show-pause DEVNAME Show pause options ethtool -A -pause DEVNAME Set pause options autoneg on off rx on off tx on off I agree that the above are ethernet-specific.
Message level isn't and WoL arguably isn't. It's a shame that these original ethtool settings are still bundled together. Missed those in the noise.
John - John W. Linville Someday the world will need a hero, and you might be all we have. To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at John W. Linville 1/10/2009, 10:07 น. On Thu, Oct 01, 2009 at 07:20:09PM +0300, Kalle Valo wrote: 'John W.
Linville' writes: On Thu, Oct 01, 2009 at 05:18:33PM +0300, Kalle Valo wrote: Anyway, adding a couple of ioctl calls isn't a big deal. Sure, but we need to support this forever. If, say after two years, we decide that ethtool is not the way to go, it's very difficult to remove it. The less interfaces we have, the easier it is to maintain them. Just to be clear, I was taling about adding ioctl calls to a userland application (if you didn't want to use the ethtool utility).
The required ioctls are already defined for ethtool in the kernel. ethtool -r -negotiate DEVNAME Restart N-WAY negotation Ethernet-specific.might could be overloaded for wireless to trigger reassoc.? Please no, I don't want to see any reassociation or anything else 802.11 state related in ethtool, nl80211 was created for this. This is something I would object loudly:) Well, it was just a thought.:-) Anyway, between the link detection and making distro scripts work plus enabling a familiar tool for basic driver info I think this is a win. So much the better if some drivers move to ethtool for register dumping, setting message verbosity, querying/changing eeprom valuesetc, etc.
Sounds good enough. As I said in my earlier email, I'm not going argue about this for too long. You know this better than I do. So let's go forward with ethtool. Thanks for listening to my concerns.
And FWIW, I don't predict a huge problem if there are valid extensions required for use by wireless drivers in the future. But for now, I'd like to see us make use of some of the debugging facilities available in the ethtool API - hopefully the iwlwifi guys are listening.;-) John - John W.
Linville Someday the world will need a hero, and you might be all we have. To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at Inaky Perez-Gonzalez 1/10/2009, 13:12 น. On Thu, 2009-10-01 at 13:56 -0600, Luis R.
Rodriguez wrote: On Thu, Oct 1, 2009 at 5:07 PM, John W. Linville wrote: I don't predict a huge problem if there are valid extensions required for use by wireless drivers in the future. But for now, I'd like to see us make use of some of the debugging facilities available in the ethtool API - hopefully the iwlwifi guys are listening.;-) Does the same apply to wimax then? Ethtool for 802.11 and wimax?
Not really - WiMAX is not eth-frame based, but IP based. The WiMAX stack doesn't require any type of framing/network device typing requirement. That is left up to the device driver writer (although yes, emulating eth is easier). - Inaky - To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at Luis R. Rodriguez 1/10/2009, 12:56 น.
On Thu, Oct 1, 2009 at 5:07 PM, John W. Linville wrote: I don't predict a huge problem if there are valid extensions required for use by wireless drivers in the future. But for now, I'd like to see us make use of some of the debugging facilities available in the ethtool API - hopefully the iwlwifi guys are listening.;-) Does the same apply to wimax then? Ethtool for 802.11 and wimax? Luis - To unsubscribe from this list: send the line 'unsubscribe netdev' in the body of a message to More majordomo info at.