From: "John W. Linville" <linville@tuxdriver.com>
To: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ethtool: fix ethtool_get_regs() to work with zero length registers
Date: Wed, 20 Jul 2011 10:36:12 -0400 [thread overview]
Message-ID: <20110720143611.GA18231@tuxdriver.com> (raw)
In-Reply-To: <4E26C2DC.8090208@qca.qualcomm.com>
On Wed, Jul 20, 2011 at 02:58:20PM +0300, Kalle Valo wrote:
> On 07/20/2011 02:38 PM, Ben Hutchings wrote:
> > On Wed, 2011-07-20 at 12:18 +0300, Kalle Valo wrote:
> >> cfg80211 exports zero length register size as it currently only uses
> >> struct ethtool_regs.version to export struct wiphy.hw_version.
> > [...]
> >
> > The ethtool_regs::version field represents the version of the register
> > dump format. This may or may not relate to a hardware version.
This seems like a strange claim to make...?
struct ethtool_regs {
__u32 cmd;
__u32 version; /* driver-specific, indicates different chips/revs */
__u32 len; /* bytes */
__u8 data[0];
};
That "indicates different chips/revs" comment has been there at least
as long as the kernel has been in git (back to the 2.6.12 era).
> > If you don't actually provide a register dump then don't implement this
> > operation.
>
> Then we have a problem as cfg80211 exports the hw version without any
> register dumps:
>
> static int cfg80211_get_regs_len(struct net_device *dev)
> {
> /* For now, return 0... */
> return 0;
> }
>
> static void cfg80211_get_regs(struct net_device *dev, struct
> ethtool_regs *regs,
> void *data)
> {
> struct wireless_dev *wdev = dev->ieee80211_ptr;
>
> regs->version = wdev->wiphy->hw_version;
> regs->len = 0;
> }
>
> And this has been there a long time already. How cfg80211 should export
> hw version if this is not a proper way?
The ethool binary already has support for the at76c50x_usb driver,
which uses this very mechanism in exactly this way. I know this
worked previously, although I don't know what might have changed to
break it...?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
WARNING: multiple messages have this Message-ID (diff)
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
To: Kalle Valo <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
Cc: Ben Hutchings
<bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] ethtool: fix ethtool_get_regs() to work with zero length registers
Date: Wed, 20 Jul 2011 10:36:12 -0400 [thread overview]
Message-ID: <20110720143611.GA18231@tuxdriver.com> (raw)
In-Reply-To: <4E26C2DC.8090208-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
On Wed, Jul 20, 2011 at 02:58:20PM +0300, Kalle Valo wrote:
> On 07/20/2011 02:38 PM, Ben Hutchings wrote:
> > On Wed, 2011-07-20 at 12:18 +0300, Kalle Valo wrote:
> >> cfg80211 exports zero length register size as it currently only uses
> >> struct ethtool_regs.version to export struct wiphy.hw_version.
> > [...]
> >
> > The ethtool_regs::version field represents the version of the register
> > dump format. This may or may not relate to a hardware version.
This seems like a strange claim to make...?
struct ethtool_regs {
__u32 cmd;
__u32 version; /* driver-specific, indicates different chips/revs */
__u32 len; /* bytes */
__u8 data[0];
};
That "indicates different chips/revs" comment has been there at least
as long as the kernel has been in git (back to the 2.6.12 era).
> > If you don't actually provide a register dump then don't implement this
> > operation.
>
> Then we have a problem as cfg80211 exports the hw version without any
> register dumps:
>
> static int cfg80211_get_regs_len(struct net_device *dev)
> {
> /* For now, return 0... */
> return 0;
> }
>
> static void cfg80211_get_regs(struct net_device *dev, struct
> ethtool_regs *regs,
> void *data)
> {
> struct wireless_dev *wdev = dev->ieee80211_ptr;
>
> regs->version = wdev->wiphy->hw_version;
> regs->len = 0;
> }
>
> And this has been there a long time already. How cfg80211 should export
> hw version if this is not a proper way?
The ethool binary already has support for the at76c50x_usb driver,
which uses this very mechanism in exactly this way. I know this
worked previously, although I don't know what might have changed to
break it...?
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-07-20 14:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-20 9:18 [PATCH] ethtool: fix ethtool_get_regs() to work with zero length registers Kalle Valo
2011-07-20 9:18 ` Kalle Valo
2011-07-20 11:38 ` Ben Hutchings
2011-07-20 11:58 ` Kalle Valo
2011-07-20 11:58 ` Kalle Valo
2011-07-20 14:36 ` John W. Linville [this message]
2011-07-20 14:36 ` John W. Linville
2011-07-21 17:46 ` Ben Hutchings
2011-07-21 17:54 ` [PATCH net-2.6] ethtool: Allow zero-length register dumps again Ben Hutchings
2011-07-21 17:54 ` Ben Hutchings
2011-07-21 22:25 ` David Miller
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=20110720143611.GA18231@tuxdriver.com \
--to=linville@tuxdriver.com \
--cc=bhutchings@solarflare.com \
--cc=kvalo@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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.