* perm_addr get
@ 2012-12-21 13:01 Jiri Pirko
2012-12-21 13:09 ` Ben Hutchings
0 siblings, 1 reply; 4+ messages in thread
From: Jiri Pirko @ 2012-12-21 13:01 UTC (permalink / raw)
To: netdev; +Cc: bhutchings
Hi all.
>From what I understand dev->perm_addr is set only in case the hw has
permanent hw address somewhere written (for example EPROM).
So when I query device which does not have perm_addr set I get:
testt1:~$ ethtool -P team0
Permanent address: 00:00:00:00:00:00
Is this the correct behaviour? Wouldn't it be more correct if
ethtool_get_perm_addr() fails with -ENOENT for something like that?
Thanks.
Jiri
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: perm_addr get 2012-12-21 13:01 perm_addr get Jiri Pirko @ 2012-12-21 13:09 ` Ben Hutchings 2012-12-21 13:25 ` Jiri Pirko 0 siblings, 1 reply; 4+ messages in thread From: Ben Hutchings @ 2012-12-21 13:09 UTC (permalink / raw) To: Jiri Pirko; +Cc: netdev On Fri, 2012-12-21 at 14:01 +0100, Jiri Pirko wrote: > Hi all. > > From what I understand dev->perm_addr is set only in case the hw has > permanent hw address somewhere written (for example EPROM). > > So when I query device which does not have perm_addr set I get: > > testt1:~$ ethtool -P team0 > Permanent address: 00:00:00:00:00:00 > > Is this the correct behaviour? Wouldn't it be more correct if > ethtool_get_perm_addr() fails with -ENOENT for something like that? I don't think we should change the implementation now, as someone might depend on it. It's trivial to distinguish this not-a-permanent-address case. However the ethtool command output could be improved. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: perm_addr get 2012-12-21 13:09 ` Ben Hutchings @ 2012-12-21 13:25 ` Jiri Pirko 2012-12-21 14:40 ` Ben Hutchings 0 siblings, 1 reply; 4+ messages in thread From: Jiri Pirko @ 2012-12-21 13:25 UTC (permalink / raw) To: Ben Hutchings; +Cc: netdev Fri, Dec 21, 2012 at 02:09:55PM CET, bhutchings@solarflare.com wrote: >On Fri, 2012-12-21 at 14:01 +0100, Jiri Pirko wrote: >> Hi all. >> >> From what I understand dev->perm_addr is set only in case the hw has >> permanent hw address somewhere written (for example EPROM). >> >> So when I query device which does not have perm_addr set I get: >> >> testt1:~$ ethtool -P team0 >> Permanent address: 00:00:00:00:00:00 >> >> Is this the correct behaviour? Wouldn't it be more correct if >> ethtool_get_perm_addr() fails with -ENOENT for something like that? > >I don't think we should change the implementation now, as someone might >depend on it. It's trivial to distinguish this not-a-permanent-address >case. However the ethtool command output could be improved. Well, not change it even if it is not correct? And by "trivial to distinguish" you mean 00:00:00:00:00:00 ~ device has no permanent address? But in some cases (like vxge, mac80211) it's possible to see 00:00:00:00:00:00 by ethtool -P even though the device has permanent address (set later on, after register_netdev call). I think that ethtool_get_perm_addr should return: -ENOENT if dev has no perm addr -EAGAIN if dev perm addr hasn't been obtained yet 0 (and addr) in other cases And how exactly should be the ethtool output improved? Thanks Jiri > >Ben. > >-- >Ben Hutchings, Staff Engineer, Solarflare >Not speaking for my employer; that's the marketing department's job. >They asked us to note that Solarflare product names are trademarked. > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: perm_addr get 2012-12-21 13:25 ` Jiri Pirko @ 2012-12-21 14:40 ` Ben Hutchings 0 siblings, 0 replies; 4+ messages in thread From: Ben Hutchings @ 2012-12-21 14:40 UTC (permalink / raw) To: Jiri Pirko; +Cc: netdev On Fri, 2012-12-21 at 14:25 +0100, Jiri Pirko wrote: > Fri, Dec 21, 2012 at 02:09:55PM CET, bhutchings@solarflare.com wrote: > >On Fri, 2012-12-21 at 14:01 +0100, Jiri Pirko wrote: > >> Hi all. > >> > >> From what I understand dev->perm_addr is set only in case the hw has > >> permanent hw address somewhere written (for example EPROM). > >> > >> So when I query device which does not have perm_addr set I get: > >> > >> testt1:~$ ethtool -P team0 > >> Permanent address: 00:00:00:00:00:00 > >> > >> Is this the correct behaviour? Wouldn't it be more correct if > >> ethtool_get_perm_addr() fails with -ENOENT for something like that? > > > >I don't think we should change the implementation now, as someone might > >depend on it. It's trivial to distinguish this not-a-permanent-address > >case. However the ethtool command output could be improved. > > Well, not change it even if it is not correct? And by "trivial to distinguish" > you mean 00:00:00:00:00:00 ~ device has no permanent address? > But in some cases (like vxge, mac80211) it's possible to see 00:00:00:00:00:00 > by ethtool -P even though the device has permanent address (set later on, after > register_netdev call). Oh well, those are just driver bugs that should be fixed. > I think that ethtool_get_perm_addr should return: > -ENOENT if dev has no perm addr > -EAGAIN if dev perm addr hasn't been obtained yet > 0 (and addr) in other cases > > And how exactly should be the ethtool output improved? Print something like 'No permanent address assigned' when the address is all-zeroes. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-12-21 14:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-21 13:01 perm_addr get Jiri Pirko 2012-12-21 13:09 ` Ben Hutchings 2012-12-21 13:25 ` Jiri Pirko 2012-12-21 14:40 ` Ben Hutchings
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.