mac80211 ethtool support

mac80211 ethtool support

[Zhu Yi]

Hi,

I want to add ethtool .get_eeprom and .get_eeprom_len support for
iwlwifi. But it seems mac80211 hides the netdev structure from the
driver. What's the suggested way for doing so (i.e dump EEPROM) for
mac80211 devices?

Thanks,
-yi

Re: mac80211 ethtool support

[Michael Buesch]

On Tuesday 11 December 2007 09:17:28 Zhu Yi wrote:
> I want to add ethtool .get_eeprom and .get_eeprom_len support for
> iwlwifi. But it seems mac80211 hides the netdev structure from the
> driver. What's the suggested way for doing so (i.e dump EEPROM) for
> mac80211 devices?

In ssb we simply create a sysfs file for this.

-- 
Greetings Michael.

Re: mac80211 ethtool support

[Zhu Yi]

On Tue, 2007-12-11 at 13:50 +0100, Michael Buesch wrote:
> On Tuesday 11 December 2007 09:17:28 Zhu Yi wrote:
> > I want to add ethtool .get_eeprom and .get_eeprom_len support for
> > iwlwifi. But it seems mac80211 hides the netdev structure from the
> > driver. What's the suggested way for doing so (i.e dump EEPROM) for
> > mac80211 devices?
> 
> In ssb we simply create a sysfs file for this.

Yeah, we can do this also. But the users want a standard way, especially
when there is already such kernel interface and user space tools ready
there. Any chance mac80211 supports ethtool or something similar?

Thanks,
-yi

Re: mac80211 ethtool support

[Michael Buesch]

On Wednesday 12 December 2007 02:13:08 Zhu Yi wrote:
> 
> On Tue, 2007-12-11 at 13:50 +0100, Michael Buesch wrote:
> > On Tuesday 11 December 2007 09:17:28 Zhu Yi wrote:
> > > I want to add ethtool .get_eeprom and .get_eeprom_len support for
> > > iwlwifi. But it seems mac80211 hides the netdev structure from the
> > > driver. What's the suggested way for doing so (i.e dump EEPROM) for
> > > mac80211 devices?
> > 
> > In ssb we simply create a sysfs file for this.
> 
> Yeah, we can do this also. But the users want a standard way, especially
> when there is already such kernel interface and user space tools ready
> there. Any chance mac80211 supports ethtool or something similar?

You could write a patch.
Add a callback to mac80211 that mac80211 uses to register the eeprom
ethtool interface.

-- 
Greetings Michael.

Re: mac80211 ethtool support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]


> > Yeah, we can do this also. But the users want a standard way, especially
> > when there is already such kernel interface and user space tools ready
> > there. Any chance mac80211 supports ethtool or something similar?
> 
> You could write a patch.
> Add a callback to mac80211 that mac80211 uses to register the eeprom
> ethtool interface.

NACK. Which virtual interface should get this? wmaster sounds like the
"obvious" candidate but we want to get rid of it ASAP. And the others
ones are pretty wrong because you can, technically, have a wiphy without
any virtual interfaces on it.

Maybe it should live in cfg80211's sysfs...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 ethtool support

[Tomas Winkler]

On Dec 12, 2007 7:45 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > > Yeah, we can do this also. But the users want a standard way, especially
> > > when there is already such kernel interface and user space tools ready
> > > there. Any chance mac80211 supports ethtool or something similar?
> >
> > You could write a patch.
> > Add a callback to mac80211 that mac80211 uses to register the eeprom
> > ethtool interface.
>
> NACK. Which virtual interface should get this? wmaster sounds like the
> "obvious" candidate but we want to get rid of it ASAP. And the others
> ones are pretty wrong because you can, technically, have a wiphy without
> any virtual interfaces on it.
>
Just a thought. What if all virtual interfaces will quasi implements
it. It doesn't matter if all the interfaces answers the same. Since
these are get only operations the mutual exclusion shouldn't be so
hard. All interfaces will support equally the handlers.  But I'm not
sure about other ethool handlers.
If wmaster goes will be all virtual interfaces equal citizens ?

> Maybe it should live in cfg80211's sysfs...

This is also a viable option

>
> johannes
>

Re: mac80211 ethtool support

[John W. Linville]

On Thu, Dec 13, 2007 at 01:23:55AM +0200, Tomas Winkler wrote:
> On Dec 12, 2007 7:45 PM, Johannes Berg <johannes@sipsolutions.net> wrote:

> > NACK. Which virtual interface should get this? wmaster sounds like the
> > "obvious" candidate but we want to get rid of it ASAP. And the others
> > ones are pretty wrong because you can, technically, have a wiphy without
> > any virtual interfaces on it.
> >
> Just a thought. What if all virtual interfaces will quasi implements
> it. It doesn't matter if all the interfaces answers the same. Since
> these are get only operations the mutual exclusion shouldn't be so
> hard. All interfaces will support equally the handlers.  But I'm not
> sure about other ethool handlers.
> If wmaster goes will be all virtual interfaces equal citizens ?

Has anyone taken the trouble to analyze the various ethtool operations
to see which ones even make sense for wireless devices?  That might
make a better starting point for discussing how to implement whatever
remains.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: mac80211 ethtool support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]


> Has anyone taken the trouble to analyze the various ethtool operations
> to see which ones even make sense for wireless devices?  That might
> make a better starting point for discussing how to implement whatever
> remains.

Most, except very few hardware-specific like the EEPROM under discussion
and a few driver-specific (get driver version etc) don't make any sense,
like WOL, GSO, pause, UFO, ...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 ethtool support

[Tomas Winkler]

On Dec 13, 2007 1:38 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > Has anyone taken the trouble to analyze the various ethtool operations
> > to see which ones even make sense for wireless devices?  That might
> > make a better starting point for discussing how to implement whatever
> > remains.
>
> Most, except very few hardware-specific like the EEPROM under discussion
> and a few driver-specific (get driver version etc) don't make any sense,
> like WOL, GSO, pause, UFO, ...

I've checked that too and I agree it looks like we need ethool brother
for wireless some wifitool.  But it looks like
cfg80211 can provide this functionality

BTW iwl HW supports WOL  :)

> johannes
>

Re: mac80211 ethtool support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 137 bytes --]


> BTW iwl HW supports WOL  :)

How the..?! You can't keep an association up for long enough without
mac80211, can you?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 ethtool support

[Pavel Roskin]

On Thu, 2007-12-13 at 01:23 +0200, Tomas Winkler wrote:

> > NACK. Which virtual interface should get this? wmaster sounds like the
> > "obvious" candidate but we want to get rid of it ASAP. And the others
> > ones are pretty wrong because you can, technically, have a wiphy without
> > any virtual interfaces on it.
> >
> Just a thought. What if all virtual interfaces will quasi implements
> it. It doesn't matter if all the interfaces answers the same.

I think The True Linux Way (c) would be to have EEPROM support for
devices (those that live in /sys/device) without tying it to network
interfaces or cfg80211.

See __ATTR in include/linux/device.h, although I'm not sure if
attributes are suitable for EEPROM as is.

Maybe EEPROM should even be a separate class of devices connected to
other devices.

Of course, the topic would be better suited for LKML.

-- 
Regards,
Pavel Roskin