* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Johannes Berg @ 2011-01-25 10:42 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295950241.3650.3.camel@jlt3.sipsolutions.net>
On Tue, 2011-01-25 at 11:10 +0100, Johannes Berg wrote:
> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>
> > Well a wiphy flag won't do here. Probe requests may be filtered in
> > some modes (AP-mode) but needed in others (p2p?).
> > I think flexibility is a nice added bonus here. A FW can decide to
> > handle most standard probe-requests and simply not pass them up.
> > Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
> >
> > The current patches leave this policy in the hands of the driver/fw.
>
> That is _very_ dangerous. If the user has older firmware that doesn't
> know about WSC2, how would the user know not to configure WSC2 in
> hostapd? That needs to be known to hostapd so it can verify this
> situation. For P2P, we already know whether or not P2P is supported, but
> that's rather vague in case there will ever be a revision of the P2P
> spec with say different IEs.
>
> Additionally, a "regular AP" (not P2P, not WSC) would still want to
> reply to probe requests from WSC/P2P devices with the normal template.
>
> IMHO it would be smarter to rework the firmware to only reply to probe
> requests if the probe response is configured. Then, if WSC, P2P, or
> similar technologies are in use on the interface, hostapd can simply
> decide to not configure the probe response and have host-based
> processing. Would that be a change you could still make?
Of course, firmware can reply to non-p2p/non-wsc2 probe requests with a
static probe response template.
The question is how much knowledge you want to put into the firmware
about those protocols. If you want to put all knowledge in there, then
at least you need to indicate to hostapd which protocols the firmware
knows not to reply to.
Also, a way to turn off this behaviour would still be good for future
protocol changes. If P2P changes in 3 years, I'm sure this firmware
won't be updated to match since you'll be a few hardware generations
ahead. Then, being able to turn off the offload completely would allow
users to take advantage of new protocols without changing hardware. Of
course, you may want to force users to buy new hardware that way -- but
in that case we *still* need the advertisement of what's possible so
users know right away that they need to buy new hardware and don't try
to configure something that just fails in strange ways.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
From: Juuso Oikarinen @ 2011-01-25 10:38 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1295951310.3650.9.camel@jlt3.sipsolutions.net>
On Tue, 2011-01-25 at 11:28 +0100, ext Johannes Berg wrote:
> On Tue, 2011-01-25 at 12:21 +0200, juuso.oikarinen@nokia.com wrote:
> > From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> >
> > Some vendor specific cipher suites require non-zero key indexes for pairwise
> > keys, but as of currently, the cfg80211 does not allow it.
>
> Hmm, also -- does this mean that WAPI might use multiple pairwise keys?
> That's most definitely not supported at all in mac80211.
Hi, AFAIK no, it does not use multiple pairwise keys. At least the
wl12xx hardware does not appear to support that - it just uses the
latest set key.
Still, in WAPI, the key index is toggled between 0 and 1 for each key
re-negotiation. I don't know the exact encryption details, but the key
index is present in the encrypted data, so it needs to be set correctly
for successful encryption/decryption.
-Juuso
> johannes
>
^ permalink raw reply
* Re: [PATCH 2/2] ath5k: correct endianness of frame duration
From: Bob Copeland @ 2011-01-25 10:38 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, linux-wireless, mickflemm, jirislaby, lrodriguez
In-Reply-To: <201101251423.32008.br1@einfach.org>
On Tue, Jan 25, 2011 at 02:23:31PM +0900, Bruno Randolf wrote:
> > The ath5k version of ieee80211_generic_frame_duration() returns
> > an __le16 for standard modes but a cpu-endian int for turbo/half/
> > quarter rates. Make it always return cpu-endian values.
>
> I wonder what effect this has in ath5k_hw_set_ifs_intervals() where
> ack_tx_time was little endian before...
Good point, I didn't think about that. My guess is EIFS would have
been much too large on big endian arches before the patch. But then
EIFS resets after successful rx so maybe our many BE users (heh)
wouldn't have noticed except on very idle channels...
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
From: Johannes Berg @ 2011-01-25 10:28 UTC (permalink / raw)
To: juuso.oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <1295950882-16785-1-git-send-email-juuso.oikarinen@nokia.com>
On Tue, 2011-01-25 at 12:21 +0200, juuso.oikarinen@nokia.com wrote:
> From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>
> Some vendor specific cipher suites require non-zero key indexes for pairwise
> keys, but as of currently, the cfg80211 does not allow it.
Hmm, also -- does this mean that WAPI might use multiple pairwise keys?
That's most definitely not supported at all in mac80211.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
From: Johannes Berg @ 2011-01-25 10:27 UTC (permalink / raw)
To: juuso.oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <1295950882-16785-1-git-send-email-juuso.oikarinen@nokia.com>
On Tue, 2011-01-25 at 12:21 +0200, juuso.oikarinen@nokia.com wrote:
> From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>
> Some vendor specific cipher suites require non-zero key indexes for pairwise
> keys, but as of currently, the cfg80211 does not allow it.
Well, technically, that is incorrect -- just adding a vendor-specific
cipher to 802.11-2007 (11i) will uphold that requirement. Using
different mechanisms like WAPI might run afoul of this check... But
technically WAPI could also use CCMP etc. and then you might have to use
non-zero even for CCMP, so this code would again be wrong.
OTOH, I don't really see a good way to capture this in code...
johannes
^ permalink raw reply
* [PATCH] cfg80211: Allow non-zero indexes for device specific pair-wise ciphers
From: juuso.oikarinen @ 2011-01-25 10:21 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Some vendor specific cipher suites require non-zero key indexes for pairwise
keys, but as of currently, the cfg80211 does not allow it.
As validating they cipher parameters for vendor specific cipher suites is the
job of the driver or hardware/firmware, change the cfg80211 to allow also
non-zero pairwise key indexes for vendor specific ciphers.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/wireless/util.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4ed065d..6a750bc 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -167,12 +167,15 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
/*
* Disallow pairwise keys with non-zero index unless it's WEP
- * (because current deployments use pairwise WEP keys with
- * non-zero indizes but 802.11i clearly specifies to use zero)
+ * or a vendor specific cipher (because current deployments use
+ * pairwise WEP keys with non-zero indices and for vendor specific
+ * ciphers this should be validated in the driver or hardware level
+ * - but 802.11i clearly specifies to use zero)
*/
if (pairwise && key_idx &&
- params->cipher != WLAN_CIPHER_SUITE_WEP40 &&
- params->cipher != WLAN_CIPHER_SUITE_WEP104)
+ ((params->cipher == WLAN_CIPHER_SUITE_TKIP) ||
+ (params->cipher == WLAN_CIPHER_SUITE_CCMP) ||
+ (params->cipher == WLAN_CIPHER_SUITE_AES_CMAC)))
return -EINVAL;
switch (params->cipher) {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 2/6] nl80211: Pass probe response data to drivers
From: Johannes Berg @ 2011-01-25 10:12 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <AANLkTinJo7EV7zr=Z6oN3M2X3=gcv1W8G7cpbHPPNs=0@mail.gmail.com>
On Mon, 2011-01-24 at 22:47 +0200, Arik Nemtsov wrote:
> On Mon, Jan 24, 2011 at 13:35, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> >> Allow usermode to pass probe-response data. This data can be used as a
> >> template probe-response offloading.
> >
> > Why use a separate command for this, and not do it like the SSID? I also
>
> Its only relevant to AP-mode (at least for now) so bss_conf didn't
> seem appropriate.
> Also since its a dynamically allocated buffer it should be protected by RCU.
But all that is unrelated to the nl80211 API, no? Also the SSID already
uses bss_conf too, and it's AP mode too...
> About compatibility - good point there. Currently the probe response
> template is set according to the beacon for compatibility. As for SSID
> - with the current wl12xx we'll set an empty SSID when a
> non-supporting hostapd is encountered. I'll fix that (in a v3). Other
> than that, we should be able to operate with either one configured.
Does that mean if you set an empty SSID it won't reply but pass them up?
Then you could implement the behaviour I just asked for ...
johannes
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Johannes Berg @ 2011-01-25 10:10 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <AANLkTi=cSdi_i=RBtcp_aLG92S3xdMvJEMSfVdqX=qAK@mail.gmail.com>
On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
> Well a wiphy flag won't do here. Probe requests may be filtered in
> some modes (AP-mode) but needed in others (p2p?).
> I think flexibility is a nice added bonus here. A FW can decide to
> handle most standard probe-requests and simply not pass them up.
> Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>
> The current patches leave this policy in the hands of the driver/fw.
That is _very_ dangerous. If the user has older firmware that doesn't
know about WSC2, how would the user know not to configure WSC2 in
hostapd? That needs to be known to hostapd so it can verify this
situation. For P2P, we already know whether or not P2P is supported, but
that's rather vague in case there will ever be a revision of the P2P
spec with say different IEs.
Additionally, a "regular AP" (not P2P, not WSC) would still want to
reply to probe requests from WSC/P2P devices with the normal template.
IMHO it would be smarter to rework the firmware to only reply to probe
requests if the probe response is configured. Then, if WSC, P2P, or
similar technologies are in use on the interface, hostapd can simply
decide to not configure the probe response and have host-based
processing. Would that be a change you could still make?
johannes
^ permalink raw reply
* [PATCH] rt2x00: add device id for windy31 usb device
From: Greg KH @ 2011-01-25 9:42 UTC (permalink / raw)
To: Ivo van Doorn, Gertjan van Wingerde, John W. Linville
Cc: linux-wireless, users, rf
From: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds the device id for the windy31 USB device to the rt73usb
driver.
Thanks to Ralf Flaxa for reporting this and providing testing and a
sample device.
Reported-by: Ralf Flaxa <rf@suse.de>
Tested-by: Ralf Flaxa <rf@suse.de>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2446,6 +2446,7 @@ static struct usb_device_id rt73usb_device_table[] = {
{ USB_DEVICE(0x04bb, 0x093d), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x148f, 0x2671), USB_DEVICE_DATA(&rt73usb_ops) },
+ { USB_DEVICE(0x0812, 0x3101), USB_DEVICE_DATA(&rt73usb_ops) },
/* Qcom */
{ USB_DEVICE(0x18e8, 0x6196), USB_DEVICE_DATA(&rt73usb_ops) },
{ USB_DEVICE(0x18e8, 0x6229), USB_DEVICE_DATA(&rt73usb_ops) },
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Jouni Malinen @ 2011-01-25 9:41 UTC (permalink / raw)
To: Arik Nemtsov
Cc: linux-wireless, Luciano Coelho, Johannes Berg, John W. Linville
In-Reply-To: <AANLkTimYZN5438DOGNOE9Ltny5M-qg-K1ShFKToRMyuw@mail.gmail.com>
On Mon, Jan 24, 2011 at 11:16:43PM +0200, Arik Nemtsov wrote:
> The SSID-as-attr not used for the probe-resp template. It is used by
> FW to filter out which probe-reqs should be responded to when
> operating with a hidden SSID.
OK, that would be useful to mention in nl80211.h comments and
cfg80211.h, too, I'd guess.
> The wl12xx FW updates the timestamp and DA. I mentioned in the
> documentation of ieee80211_proberesp_get (and various other parts)
> that the DA should be set manually and that this should be used as a
> template (which also implies timestamp should be set). If some part is
> unclear can you point out a specific patch?
DA should be pretty obvious. Timestamp is something that I hope is clear
for whoever is implementing a driver, but it could be mentioned
somewhere.
> For WPS (without p2p), it appears the probe-resp doesn't depend on the
> probe-req (in hostapd code).
This is the case for WPS 1.0, but the protocol update in WSC 2.0 does
introduce a dependency.
> Perhaps we can start with these AP-mode only patches and expand the
> functionality when it is needed for p2p?
I'm fine with them if there is a capability flag that allows user space
to know that the driver does not use user space -based Probe Request
processing. With that, hostapd/wpa_supplicant can disable functionality
like multi-SSID support, WPS 2.0, P2P until we get more complete
capability information on what devices that process Probe Request frames
internally can do.
> Note that the current patch doesn't remove existing functionality - a
> driver/FW operating in p2p mode can simply choose not to use the
> template and just pass probe-requests up.
Until now, I've been assuming that nl80211-based interface means that
Probe Request frames are handled in user space. Since this set of
patches makes it very obvious that that will not be the case, I do want
to be able to figure that out in user space easily. All it really takes
is to add a capability flag indicating whether user space -based Probe
Request processing is used or not.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [RFC] iwl3945: remove check_plcp_health
From: Stanislaw Gruszka @ 2011-01-25 9:35 UTC (permalink / raw)
To: Wey-Yi Guy, Abhijeet Kolekar; +Cc: linux-wireless, Intel Linux Wireless
This patch helps some users currently complaining about iwl3945
performance.
https://bugzilla.redhat.com/show_bug.cgi?id=654599
https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/+index?comments=all
Patch does not helps all users, but they seems to be affected
by different bug or bugs.
Patch effectively reverts commit a29576a7844326c5223f4d4adbfd3f4d64173d4c
"iwl3945: add plcp error checking". It is minimal fix intended to
-stable posting. I will post cleaning up patch, if fix will be accepted.
---
drivers/net/wireless/iwlwifi/iwl-3945.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index 8cacb4e..eb916d7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -2832,7 +2832,6 @@ static struct iwl_lib_ops iwl3945_lib = {
.config_ap = iwl3945_config_ap,
.manage_ibss_station = iwl3945_manage_ibss_station,
.recover_from_tx_stall = iwl_bg_monitor_recover,
- .check_plcp_health = iwl3945_good_plcp_health,
.debugfs_ops = {
.rx_stats_read = iwl3945_ucode_rx_stats_read,
--
1.7.1
^ permalink raw reply related
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Arend van Spriel @ 2011-01-25 9:07 UTC (permalink / raw)
To: Jamie Kitson; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=YpOhbqCNZsLiY=24+HJiupe4zL0KW8ZOmFzjU@mail.gmail.com>
Hi Jamie,
On Mon, 24 Jan 2011 22:40:35 +0100, Jamie Kitson <jamie@kitten-x.com>
wrote:
>> Could you also provide the panic trace?
>
> How/where do I find that?
>
> Thanks, Jamie
>
I actually found some screenshots you posted on ArchLinux forum so if
those are valid I am all set.
Gr. AvS
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
^ permalink raw reply
* Re: Realtek rtl8188 support?
From: Brian Prodoehl @ 2011-01-25 7:57 UTC (permalink / raw)
To: Larry Finger
Cc: Walter Goldens, Gábor Stefanik, John W. Linville,
Stefan Lippers-Hollmann, wireless
In-Reply-To: <4D0A1DD6.8050500@lwfinger.net>
On Thu, Dec 16, 2010 at 9:10 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 12/16/2010 07:25 AM, Walter Goldens wrote:
>> Realtek has not yet sent me the code for the USB
>>> devices, but as the chip
>>> and core code is common, it should not be far behind.
>
>> Hey Larry,
>>
>> Whats the status quo for the USB driver?
>
> Realtek is still testing/finishing. They sent me the firmware, which I pushed to
> linux-firmware, thus that part is ready.
>
> As we just got the code for the PCIe version into wireless-testing yesterday, I
> hope that the good news on it will help the USB effort.
>
> Larry
Any word on a mac80211-based driver for the RTL8191SE? PCIe,
vendor/device is 10ec:8172 (comes standard in a lot of new Toshiba
laptops). The RTL8191SE and RTL8192SE use the same driver and
firmware from Realtek. That driver from Realtek is sort of similar to
Realtek's RTL8192CE driver, but, functionally, they look different
enough that I really doubt it would just work if I added the
vendor/device pair and got the rtl8192ce driver to load the right
firmware for the RTL8192SE.
-Brian
^ permalink raw reply
* Re: [PATCH 2/2] ath5k: remove debug_dump_skb() functions
From: Bruno Randolf @ 2011-01-25 5:24 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, linux-wireless, mickflemm, jirislaby, lrodriguez
In-Reply-To: <1295929976-11858-2-git-send-email-me@bobcopeland.com>
On Tue January 25 2011 13:32:56 Bob Copeland wrote:
> Now that rx and tx dumps go through the tracing infrastructure,
> we no longer need to keep these routines around.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/debug.c | 20 --------------------
> drivers/net/wireless/ath/ath5k/debug.h | 10 ----------
> 2 files changed, 0 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index d2f84d7..0230f30 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -308,8 +308,6 @@ static const struct {
> { ATH5K_DEBUG_CALIBRATE, "calib", "periodic calibration" },
> { ATH5K_DEBUG_TXPOWER, "txpower", "transmit power setting" },
> { ATH5K_DEBUG_LED, "led", "LED management" },
> - { ATH5K_DEBUG_DUMP_RX, "dumprx", "print received skb content" },
> - { ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
> { ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
> { ATH5K_DEBUG_DMA, "dma", "dma start/stop" },
> { ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
> @@ -1036,24 +1034,6 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc,
> struct ath5k_hw *ah) }
>
> void
> -ath5k_debug_dump_skb(struct ath5k_softc *sc,
> - struct sk_buff *skb, const char *prefix, int tx)
> -{
> - char buf[16];
> -
> - if (likely(!((tx && (sc->debug.level & ATH5K_DEBUG_DUMP_TX)) ||
> - (!tx && (sc->debug.level & ATH5K_DEBUG_DUMP_RX)))))
> - return;
> -
> - snprintf(buf, sizeof(buf), "%s %s", wiphy_name(sc->hw->wiphy), prefix);
> -
> - print_hex_dump_bytes(buf, DUMP_PREFIX_NONE, skb->data,
> - min(200U, skb->len));
> -
> - printk(KERN_DEBUG "\n");
> -}
> -
> -void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
> {
> struct ath5k_desc *ds = bf->desc;
> diff --git a/drivers/net/wireless/ath/ath5k/debug.h
> b/drivers/net/wireless/ath/ath5k/debug.h index 3e34428..b0355ae 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.h
> +++ b/drivers/net/wireless/ath/ath5k/debug.h
> @@ -116,8 +116,6 @@ enum ath5k_debug_level {
> ATH5K_DEBUG_CALIBRATE = 0x00000020,
> ATH5K_DEBUG_TXPOWER = 0x00000040,
> ATH5K_DEBUG_LED = 0x00000080,
> - ATH5K_DEBUG_DUMP_RX = 0x00000100,
> - ATH5K_DEBUG_DUMP_TX = 0x00000200,
> ATH5K_DEBUG_DUMPBANDS = 0x00000400,
> ATH5K_DEBUG_DMA = 0x00000800,
> ATH5K_DEBUG_ANI = 0x00002000,
> @@ -152,10 +150,6 @@ void
> ath5k_debug_dump_bands(struct ath5k_softc *sc);
>
> void
> -ath5k_debug_dump_skb(struct ath5k_softc *sc,
> - struct sk_buff *skb, const char *prefix, int tx);
> -
> -void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf);
>
> #else /* no debugging */
> @@ -182,10 +176,6 @@ static inline void
> ath5k_debug_dump_bands(struct ath5k_softc *sc) {}
>
> static inline void
> -ath5k_debug_dump_skb(struct ath5k_softc *sc,
> - struct sk_buff *skb, const char *prefix, int tx) {}
> -
> -static inline void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf) {}
>
> #endif /* ifdef CONFIG_ATH5K_DEBUG */
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: use tracing for packet tx/rx dump
From: Bruno Randolf @ 2011-01-25 5:24 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, linux-wireless, mickflemm, jirislaby, lrodriguez
In-Reply-To: <1295929976-11858-1-git-send-email-me@bobcopeland.com>
On Tue January 25 2011 13:32:55 Bob Copeland wrote:
> This adds a few tracepoints to ath5k driver transmit and
> receive callbacks in order to record packet traffic.
> We record the entire packet in the trace buffer so that
> the data can be extracted with trace-cmd and external
> plugins.
>
> Compared to the previous debugging calls, this approach
> removes an out-of-line function call from the tx and rx
> paths in the compiled-in-but-disabled case, while
> improving the ability to process the logged data.
>
> A new option, CONFIG_ATH5K_TRACER, is added so that one
> may disable the tracepoints completely.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>
> drivers/net/wireless/ath/ath5k/Kconfig | 11 +++
> drivers/net/wireless/ath/ath5k/base.c | 16 +++--
> drivers/net/wireless/ath/ath5k/trace.h | 107
> ++++++++++++++++++++++++++++++++ 3 files changed, 128 insertions(+), 6
> deletions(-)
> create mode 100644 drivers/net/wireless/ath/ath5k/trace.h
>
> diff --git a/drivers/net/wireless/ath/ath5k/Kconfig
> b/drivers/net/wireless/ath/ath5k/Kconfig index e079331..e18a9aa 100644
> --- a/drivers/net/wireless/ath/ath5k/Kconfig
> +++ b/drivers/net/wireless/ath/ath5k/Kconfig
> @@ -40,6 +40,17 @@ config ATH5K_DEBUG
>
> modprobe ath5k debug=0x00000400
>
> +config ATH5K_TRACER
> + bool "Atheros 5xxx tracer"
> + depends on ATH5K
> + depends on EVENT_TRACING
> + ---help---
> + Say Y here to enable tracepoints for the ath5k driver
> + using the kernel tracing infrastructure. Select this
> + option if you are interested in debugging the driver.
> +
> + If unsure, say N.
> +
> config ATH5K_AHB
> bool "Atheros 5xxx AHB bus support"
> depends on (ATHEROS_AR231X && !PCI)
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 14377ac..9c59cb6 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -61,6 +61,9 @@
> #include "debug.h"
> #include "ani.h"
>
> +#define CREATE_TRACE_POINTS
> +#include "trace.h"
> +
> int ath5k_modparam_nohwcrypt;
> module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
> @@ -1384,7 +1387,7 @@ ath5k_receive_frame(struct ath5k_softc *sc, struct
> sk_buff *skb,
> sc->sbands[sc->curchan->band].bitrates[rxs->rate_idx].hw_value_short)
> rxs->flag |= RX_FLAG_SHORTPRE;
>
> - ath5k_debug_dump_skb(sc, skb, "RX ", 0);
> + trace_ath5k_rx(sc, skb);
>
> ath5k_update_beacon_rssi(sc, skb, rs->rs_rssi);
>
> @@ -1529,7 +1532,7 @@ ath5k_tx_queue(struct ieee80211_hw *hw, struct
> sk_buff *skb, unsigned long flags;
> int padsize;
>
> - ath5k_debug_dump_skb(sc, skb, "TX ", 1);
> + trace_ath5k_tx(sc, skb, txq);
>
> /*
> * The hardware expects the header padded to 4 byte boundaries.
> @@ -1578,7 +1581,7 @@ drop_packet:
>
> static void
> ath5k_tx_frame_completed(struct ath5k_softc *sc, struct sk_buff *skb,
> - struct ath5k_tx_status *ts)
> + struct ath5k_txq *txq, struct ath5k_tx_status *ts)
> {
> struct ieee80211_tx_info *info;
> int i;
> @@ -1630,6 +1633,7 @@ ath5k_tx_frame_completed(struct ath5k_softc *sc,
> struct sk_buff *skb, else
> sc->stats.antenna_tx[0]++; /* invalid */
>
> + trace_ath5k_tx_complete(sc, skb, txq, ts);
> ieee80211_tx_status(sc->hw, skb);
> }
>
> @@ -1666,7 +1670,7 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct
> ath5k_txq *txq)
>
> dma_unmap_single(sc->dev, bf->skbaddr, skb->len,
> DMA_TO_DEVICE);
> - ath5k_tx_frame_completed(sc, skb, &ts);
> + ath5k_tx_frame_completed(sc, skb, txq, &ts);
> }
>
> /*
> @@ -1808,8 +1812,6 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct
> ieee80211_vif *vif) goto out;
> }
>
> - ath5k_debug_dump_skb(sc, skb, "BC ", 1);
> -
> ath5k_txbuf_free_skb(sc, avf->bbuf);
> avf->bbuf->skb = skb;
> ret = ath5k_beacon_setup(sc, avf->bbuf);
> @@ -1904,6 +1906,8 @@ ath5k_beacon_send(struct ath5k_softc *sc)
> sc->opmode == NL80211_IFTYPE_MESH_POINT)
> ath5k_beacon_update(sc->hw, vif);
>
> + trace_ath5k_tx(sc, bf->skb, &sc->txqs[sc->bhalq]);
> +
> ath5k_hw_set_txdp(ah, sc->bhalq, bf->daddr);
> ath5k_hw_start_tx_dma(ah, sc->bhalq);
> ATH5K_DBG(sc, ATH5K_DEBUG_BEACON, "TXDP[%u] = %llx (%p)\n",
> diff --git a/drivers/net/wireless/ath/ath5k/trace.h
> b/drivers/net/wireless/ath/ath5k/trace.h new file mode 100644
> index 0000000..2de68ad
> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath5k/trace.h
> @@ -0,0 +1,107 @@
> +#if !defined(__TRACE_ATH5K_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define __TRACE_ATH5K_H
> +
> +#include <linux/tracepoint.h>
> +#include "base.h"
> +
> +#ifndef CONFIG_ATH5K_TRACER
> +#undef TRACE_EVENT
> +#define TRACE_EVENT(name, proto, ...) \
> +static inline void trace_ ## name(proto) {}
> +#endif
> +
> +struct sk_buff;
> +
> +#define PRIV_ENTRY __field(struct ath5k_softc *, priv)
> +#define PRIV_ASSIGN __entry->priv = priv
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM ath5k
> +
> +TRACE_EVENT(ath5k_rx,
> + TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
> + TP_ARGS(priv, skb),
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(unsigned long, skbaddr)
> + __dynamic_array(u8, frame, skb->len)
> + ),
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->skbaddr = (unsigned long) skb;
> + memcpy(__get_dynamic_array(frame), skb->data, skb->len);
> + ),
> + TP_printk(
> + "[%p] RX skb=%lx", __entry->priv, __entry->skbaddr
> + )
> +);
> +
> +TRACE_EVENT(ath5k_tx,
> + TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
> + struct ath5k_txq *q),
> +
> + TP_ARGS(priv, skb, q),
> +
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(unsigned long, skbaddr)
> + __field(u8, qnum)
> + __dynamic_array(u8, frame, skb->len)
> + ),
> +
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->skbaddr = (unsigned long) skb;
> + __entry->qnum = (u8) q->qnum;
> + memcpy(__get_dynamic_array(frame), skb->data, skb->len);
> + ),
> +
> + TP_printk(
> + "[%p] TX skb=%lx q=%d", __entry->priv, __entry->skbaddr,
> + __entry->qnum
> + )
> +);
> +
> +TRACE_EVENT(ath5k_tx_complete,
> + TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
> + struct ath5k_txq *q, struct ath5k_tx_status *ts),
> +
> + TP_ARGS(priv, skb, q, ts),
> +
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(unsigned long, skbaddr)
> + __field(u8, qnum)
> + __field(u8, ts_status)
> + __field(s8, ts_rssi)
> + __field(u8, ts_antenna)
> + ),
> +
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->skbaddr = (unsigned long) skb;
> + __entry->qnum = (u8) q->qnum;
> + __entry->ts_status = ts->ts_status;
> + __entry->ts_rssi = ts->ts_rssi;
> + __entry->ts_antenna = ts->ts_antenna;
> + ),
> +
> + TP_printk(
> + "[%p] TX end skb=%lx q=%d stat=%x rssi=%d ant=%x",
> + __entry->priv, __entry->skbaddr, __entry->qnum,
> + __entry->ts_status, __entry->ts_rssi, __entry->ts_antenna
> + )
> +);
> +
> +#endif /* __TRACE_ATH5K_H */
> +
> +#ifdef CONFIG_ATH5K_TRACER
> +
> +#undef TRACE_INCLUDE_PATH
> +#define TRACE_INCLUDE_PATH ../../drivers/net/wireless/ath/ath5k
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_FILE trace
> +
> +#include <trace/define_trace.h>
> +
> +#endif
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 2/2] ath5k: correct endianness of frame duration
From: Bruno Randolf @ 2011-01-25 5:23 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, linux-wireless, mickflemm, jirislaby, lrodriguez
In-Reply-To: <1295929904-11806-2-git-send-email-me@bobcopeland.com>
On Tue January 25 2011 13:31:44 Bob Copeland wrote:
> The ath5k version of ieee80211_generic_frame_duration() returns
> an __le16 for standard modes but a cpu-endian int for turbo/half/
> quarter rates. Make it always return cpu-endian values.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/pcu.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/pcu.c
> b/drivers/net/wireless/ath/ath5k/pcu.c index e5f2b96..a702817 100644
> --- a/drivers/net/wireless/ath/ath5k/pcu.c
> +++ b/drivers/net/wireless/ath/ath5k/pcu.c
> @@ -86,7 +86,7 @@ int ath5k_hw_get_frame_duration(struct ath5k_hw *ah,
> if (!ah->ah_bwmode) {
> dur = ieee80211_generic_frame_duration(sc->hw,
> NULL, len, rate);
> - return dur;
> + return le16_to_cpu(dur);
> }
>
> bitrate = rate->bitrate;
> @@ -265,8 +265,6 @@ static inline void ath5k_hw_write_rate_duration(struct
> ath5k_hw *ah) * what rate we should choose to TX ACKs. */
> tx_time = ath5k_hw_get_frame_duration(ah, 10, rate);
>
> - tx_time = le16_to_cpu(tx_time);
> -
> ath5k_hw_reg_write(ah, tx_time, reg);
>
> if (!(rate->flags & IEEE80211_RATE_SHORT_PREAMBLE))
I wonder what effect this has in ath5k_hw_set_ifs_intervals() where
ack_tx_time was little endian before...
But the change makes sense.
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Bruno Randolf @ 2011-01-25 5:12 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, linux-wireless, mickflemm, jirislaby, lrodriguez
In-Reply-To: <1295929904-11806-1-git-send-email-me@bobcopeland.com>
On Tue January 25 2011 13:31:43 Bob Copeland wrote:
> Review spotted a problem with the error handling in ath5k_hw_dma_stop:
> a successful return from ath5k_hw_stop_tx_dma will be treated as
> an error, so we always bail out of the loop after processing a single
> active queue. As a result, we may not actually stop some queues during
> reset.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> These two patches fix some buglets I found when reviewing some old code.
>
> drivers/net/wireless/ath/ath5k/dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/dma.c
> b/drivers/net/wireless/ath/ath5k/dma.c index 0064be7..e828b98 100644
> --- a/drivers/net/wireless/ath/ath5k/dma.c
> +++ b/drivers/net/wireless/ath/ath5k/dma.c
> @@ -838,7 +838,7 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
> for (i = 0; i < qmax; i++) {
> err = ath5k_hw_stop_tx_dma(ah, i);
> /* -EINVAL -> queue inactive */
> - if (err != -EINVAL)
> + if (err && err != -EINVAL)
> return err;
> }
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: Fix power save usage count imbalance on deinit
From: Rajkumar Manoharan @ 2011-01-25 5:10 UTC (permalink / raw)
To: Paul Stewart
Cc: Rajkumar Manoharan, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimJB1QJ63f_=RPRuMXGnt95+y9LQzpAMmcEcLx2@mail.gmail.com>
On Tue, Jan 25, 2011 at 05:33:31AM +0530, Paul Stewart wrote:
> This change doesn't regress the issue with scan-during-suspend. The
> other regression you should test for is that the system really does
> continue to honor powersave after a suspend-resume cycle (verify
> null-functions and drop in power consumption). You should be able to
> do that yourself, and I'd suggest testing for this case as well before
> committing any changes to powersave.
>
Thanks a lot Paul for validating the patch. Sure I will do more testing
with this patch.
--
Rajkumar
^ permalink raw reply
* [PATCH] fix_rtlwifi_rfkill_state_not_synchronous_with_true_rfstate_issue
From: 李朝明 @ 2011-01-25 5:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <301B5E6D9B3042F6ABB4C6479ACB875E@realsil.com.cn>
Sorry for last patch have no description.
1. when driver init, rfkill_state was setted, but because the flag valid may
not be true, this will cause rfkill_state
not synchronous with the true rf state, and will cause some issues when we
do rfkill.
and now in driver init we will set rfkill_state to rf_on, and at the same
time
we tell rfkill to set rf_on also.
2. for rtl8192ce you can check GPIO any time, not only after up_first_time
== true. so we delete rtlpci->up_first_time
in rtl92ce_gpio_radio_on_off_checking.
Signed-off-by: chaoming_li <chaoming_li@realsil.com.cn>
---
drivers/net/wireless/rtlwifi/base.c | 13 ++++++++-----
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 2 +-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c
b/drivers/net/wireless/rtlwifi/base.c
index cf0b73e..33323b4 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -251,15 +251,18 @@ void rtl_init_rfkill(struct ieee80211_hw *hw)
bool blocked;
u8 valid = 0;
- radio_state = rtlpriv->cfg->ops->radio_onoff_checking(hw, &valid);
+ /*1. set init state to on */
+ rtlpriv->rfkill.rfkill_state = 1;
+ wiphy_rfkill_set_hw_state(hw->wiphy, 0);
- /*set init state to that of switch */
- rtlpriv->rfkill.rfkill_state = radio_state;
- printk(KERN_INFO "rtlwifi: wireless switch is %s\n",
- rtlpriv->rfkill.rfkill_state ? "on" : "off");
+ /*2. check gpio for rf state */
+ radio_state = rtlpriv->cfg->ops->radio_onoff_checking(hw, &valid);
+ /*3. if valid, change state based on gpio */
if (valid) {
rtlpriv->rfkill.rfkill_state = radio_state;
+ printk(KERN_INFO "rtlwifi: wireless switch is %s\n",
+ rtlpriv->rfkill.rfkill_state ? "on" :
"off");
blocked = (rtlpriv->rfkill.rfkill_state == 1) ? 0 : 1;
wiphy_rfkill_set_hw_state(hw->wiphy, blocked);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 1c41a0c..cb2e01a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1943,7 +1943,7 @@ bool rtl92ce_gpio_radio_on_off_checking(struct
ieee80211_hw *hw, u8 * valid)
bool b_actuallyset = false;
unsigned long flag;
- if ((rtlpci->up_first_time == 1) || (rtlpci->being_init_adapter))
+ if (rtlpci->being_init_adapter)
return false;
if (ppsc->b_swrf_processing)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ath5k: remove debug_dump_skb() functions
From: Bob Copeland @ 2011-01-25 4:32 UTC (permalink / raw)
To: linville
Cc: linux-wireless, mickflemm, Bruno Randolf, jirislaby, lrodriguez,
Bob Copeland
In-Reply-To: <1295929976-11858-1-git-send-email-me@bobcopeland.com>
Now that rx and tx dumps go through the tracing infrastructure,
we no longer need to keep these routines around.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/debug.c | 20 --------------------
drivers/net/wireless/ath/ath5k/debug.h | 10 ----------
2 files changed, 0 insertions(+), 30 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index d2f84d7..0230f30 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -308,8 +308,6 @@ static const struct {
{ ATH5K_DEBUG_CALIBRATE, "calib", "periodic calibration" },
{ ATH5K_DEBUG_TXPOWER, "txpower", "transmit power setting" },
{ ATH5K_DEBUG_LED, "led", "LED management" },
- { ATH5K_DEBUG_DUMP_RX, "dumprx", "print received skb content" },
- { ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
{ ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
{ ATH5K_DEBUG_DMA, "dma", "dma start/stop" },
{ ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
@@ -1036,24 +1034,6 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
}
void
-ath5k_debug_dump_skb(struct ath5k_softc *sc,
- struct sk_buff *skb, const char *prefix, int tx)
-{
- char buf[16];
-
- if (likely(!((tx && (sc->debug.level & ATH5K_DEBUG_DUMP_TX)) ||
- (!tx && (sc->debug.level & ATH5K_DEBUG_DUMP_RX)))))
- return;
-
- snprintf(buf, sizeof(buf), "%s %s", wiphy_name(sc->hw->wiphy), prefix);
-
- print_hex_dump_bytes(buf, DUMP_PREFIX_NONE, skb->data,
- min(200U, skb->len));
-
- printk(KERN_DEBUG "\n");
-}
-
-void
ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
{
struct ath5k_desc *ds = bf->desc;
diff --git a/drivers/net/wireless/ath/ath5k/debug.h b/drivers/net/wireless/ath/ath5k/debug.h
index 3e34428..b0355ae 100644
--- a/drivers/net/wireless/ath/ath5k/debug.h
+++ b/drivers/net/wireless/ath/ath5k/debug.h
@@ -116,8 +116,6 @@ enum ath5k_debug_level {
ATH5K_DEBUG_CALIBRATE = 0x00000020,
ATH5K_DEBUG_TXPOWER = 0x00000040,
ATH5K_DEBUG_LED = 0x00000080,
- ATH5K_DEBUG_DUMP_RX = 0x00000100,
- ATH5K_DEBUG_DUMP_TX = 0x00000200,
ATH5K_DEBUG_DUMPBANDS = 0x00000400,
ATH5K_DEBUG_DMA = 0x00000800,
ATH5K_DEBUG_ANI = 0x00002000,
@@ -152,10 +150,6 @@ void
ath5k_debug_dump_bands(struct ath5k_softc *sc);
void
-ath5k_debug_dump_skb(struct ath5k_softc *sc,
- struct sk_buff *skb, const char *prefix, int tx);
-
-void
ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf);
#else /* no debugging */
@@ -182,10 +176,6 @@ static inline void
ath5k_debug_dump_bands(struct ath5k_softc *sc) {}
static inline void
-ath5k_debug_dump_skb(struct ath5k_softc *sc,
- struct sk_buff *skb, const char *prefix, int tx) {}
-
-static inline void
ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf) {}
#endif /* ifdef CONFIG_ATH5K_DEBUG */
--
1.7.1.1
^ permalink raw reply related
* [PATCH 1/2] ath5k: use tracing for packet tx/rx dump
From: Bob Copeland @ 2011-01-25 4:32 UTC (permalink / raw)
To: linville
Cc: linux-wireless, mickflemm, Bruno Randolf, jirislaby, lrodriguez,
Bob Copeland
This adds a few tracepoints to ath5k driver transmit and
receive callbacks in order to record packet traffic.
We record the entire packet in the trace buffer so that
the data can be extracted with trace-cmd and external
plugins.
Compared to the previous debugging calls, this approach
removes an out-of-line function call from the tx and rx
paths in the compiled-in-but-disabled case, while
improving the ability to process the logged data.
A new option, CONFIG_ATH5K_TRACER, is added so that one
may disable the tracepoints completely.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/Kconfig | 11 +++
drivers/net/wireless/ath/ath5k/base.c | 16 +++--
drivers/net/wireless/ath/ath5k/trace.h | 107 ++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+), 6 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/trace.h
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index e079331..e18a9aa 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -40,6 +40,17 @@ config ATH5K_DEBUG
modprobe ath5k debug=0x00000400
+config ATH5K_TRACER
+ bool "Atheros 5xxx tracer"
+ depends on ATH5K
+ depends on EVENT_TRACING
+ ---help---
+ Say Y here to enable tracepoints for the ath5k driver
+ using the kernel tracing infrastructure. Select this
+ option if you are interested in debugging the driver.
+
+ If unsure, say N.
+
config ATH5K_AHB
bool "Atheros 5xxx AHB bus support"
depends on (ATHEROS_AR231X && !PCI)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 14377ac..9c59cb6 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -61,6 +61,9 @@
#include "debug.h"
#include "ani.h"
+#define CREATE_TRACE_POINTS
+#include "trace.h"
+
int ath5k_modparam_nohwcrypt;
module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
@@ -1384,7 +1387,7 @@ ath5k_receive_frame(struct ath5k_softc *sc, struct sk_buff *skb,
sc->sbands[sc->curchan->band].bitrates[rxs->rate_idx].hw_value_short)
rxs->flag |= RX_FLAG_SHORTPRE;
- ath5k_debug_dump_skb(sc, skb, "RX ", 0);
+ trace_ath5k_rx(sc, skb);
ath5k_update_beacon_rssi(sc, skb, rs->rs_rssi);
@@ -1529,7 +1532,7 @@ ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
unsigned long flags;
int padsize;
- ath5k_debug_dump_skb(sc, skb, "TX ", 1);
+ trace_ath5k_tx(sc, skb, txq);
/*
* The hardware expects the header padded to 4 byte boundaries.
@@ -1578,7 +1581,7 @@ drop_packet:
static void
ath5k_tx_frame_completed(struct ath5k_softc *sc, struct sk_buff *skb,
- struct ath5k_tx_status *ts)
+ struct ath5k_txq *txq, struct ath5k_tx_status *ts)
{
struct ieee80211_tx_info *info;
int i;
@@ -1630,6 +1633,7 @@ ath5k_tx_frame_completed(struct ath5k_softc *sc, struct sk_buff *skb,
else
sc->stats.antenna_tx[0]++; /* invalid */
+ trace_ath5k_tx_complete(sc, skb, txq, ts);
ieee80211_tx_status(sc->hw, skb);
}
@@ -1666,7 +1670,7 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
dma_unmap_single(sc->dev, bf->skbaddr, skb->len,
DMA_TO_DEVICE);
- ath5k_tx_frame_completed(sc, skb, &ts);
+ ath5k_tx_frame_completed(sc, skb, txq, &ts);
}
/*
@@ -1808,8 +1812,6 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
goto out;
}
- ath5k_debug_dump_skb(sc, skb, "BC ", 1);
-
ath5k_txbuf_free_skb(sc, avf->bbuf);
avf->bbuf->skb = skb;
ret = ath5k_beacon_setup(sc, avf->bbuf);
@@ -1904,6 +1906,8 @@ ath5k_beacon_send(struct ath5k_softc *sc)
sc->opmode == NL80211_IFTYPE_MESH_POINT)
ath5k_beacon_update(sc->hw, vif);
+ trace_ath5k_tx(sc, bf->skb, &sc->txqs[sc->bhalq]);
+
ath5k_hw_set_txdp(ah, sc->bhalq, bf->daddr);
ath5k_hw_start_tx_dma(ah, sc->bhalq);
ATH5K_DBG(sc, ATH5K_DEBUG_BEACON, "TXDP[%u] = %llx (%p)\n",
diff --git a/drivers/net/wireless/ath/ath5k/trace.h b/drivers/net/wireless/ath/ath5k/trace.h
new file mode 100644
index 0000000..2de68ad
--- /dev/null
+++ b/drivers/net/wireless/ath/ath5k/trace.h
@@ -0,0 +1,107 @@
+#if !defined(__TRACE_ATH5K_H) || defined(TRACE_HEADER_MULTI_READ)
+#define __TRACE_ATH5K_H
+
+#include <linux/tracepoint.h>
+#include "base.h"
+
+#ifndef CONFIG_ATH5K_TRACER
+#undef TRACE_EVENT
+#define TRACE_EVENT(name, proto, ...) \
+static inline void trace_ ## name(proto) {}
+#endif
+
+struct sk_buff;
+
+#define PRIV_ENTRY __field(struct ath5k_softc *, priv)
+#define PRIV_ASSIGN __entry->priv = priv
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM ath5k
+
+TRACE_EVENT(ath5k_rx,
+ TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
+ TP_ARGS(priv, skb),
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(unsigned long, skbaddr)
+ __dynamic_array(u8, frame, skb->len)
+ ),
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->skbaddr = (unsigned long) skb;
+ memcpy(__get_dynamic_array(frame), skb->data, skb->len);
+ ),
+ TP_printk(
+ "[%p] RX skb=%lx", __entry->priv, __entry->skbaddr
+ )
+);
+
+TRACE_EVENT(ath5k_tx,
+ TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
+ struct ath5k_txq *q),
+
+ TP_ARGS(priv, skb, q),
+
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(unsigned long, skbaddr)
+ __field(u8, qnum)
+ __dynamic_array(u8, frame, skb->len)
+ ),
+
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->skbaddr = (unsigned long) skb;
+ __entry->qnum = (u8) q->qnum;
+ memcpy(__get_dynamic_array(frame), skb->data, skb->len);
+ ),
+
+ TP_printk(
+ "[%p] TX skb=%lx q=%d", __entry->priv, __entry->skbaddr,
+ __entry->qnum
+ )
+);
+
+TRACE_EVENT(ath5k_tx_complete,
+ TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb,
+ struct ath5k_txq *q, struct ath5k_tx_status *ts),
+
+ TP_ARGS(priv, skb, q, ts),
+
+ TP_STRUCT__entry(
+ PRIV_ENTRY
+ __field(unsigned long, skbaddr)
+ __field(u8, qnum)
+ __field(u8, ts_status)
+ __field(s8, ts_rssi)
+ __field(u8, ts_antenna)
+ ),
+
+ TP_fast_assign(
+ PRIV_ASSIGN;
+ __entry->skbaddr = (unsigned long) skb;
+ __entry->qnum = (u8) q->qnum;
+ __entry->ts_status = ts->ts_status;
+ __entry->ts_rssi = ts->ts_rssi;
+ __entry->ts_antenna = ts->ts_antenna;
+ ),
+
+ TP_printk(
+ "[%p] TX end skb=%lx q=%d stat=%x rssi=%d ant=%x",
+ __entry->priv, __entry->skbaddr, __entry->qnum,
+ __entry->ts_status, __entry->ts_rssi, __entry->ts_antenna
+ )
+);
+
+#endif /* __TRACE_ATH5K_H */
+
+#ifdef CONFIG_ATH5K_TRACER
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH ../../drivers/net/wireless/ath/ath5k
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE trace
+
+#include <trace/define_trace.h>
+
+#endif
--
1.7.1.1
^ permalink raw reply related
* [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Bob Copeland @ 2011-01-25 4:31 UTC (permalink / raw)
To: linville
Cc: linux-wireless, mickflemm, Bruno Randolf, jirislaby, lrodriguez,
Bob Copeland
Review spotted a problem with the error handling in ath5k_hw_dma_stop:
a successful return from ath5k_hw_stop_tx_dma will be treated as
an error, so we always bail out of the loop after processing a single
active queue. As a result, we may not actually stop some queues during
reset.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
These two patches fix some buglets I found when reviewing some old code.
drivers/net/wireless/ath/ath5k/dma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
index 0064be7..e828b98 100644
--- a/drivers/net/wireless/ath/ath5k/dma.c
+++ b/drivers/net/wireless/ath/ath5k/dma.c
@@ -838,7 +838,7 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
for (i = 0; i < qmax; i++) {
err = ath5k_hw_stop_tx_dma(ah, i);
/* -EINVAL -> queue inactive */
- if (err != -EINVAL)
+ if (err && err != -EINVAL)
return err;
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH 2/2] ath5k: correct endianness of frame duration
From: Bob Copeland @ 2011-01-25 4:31 UTC (permalink / raw)
To: linville
Cc: linux-wireless, mickflemm, Bruno Randolf, jirislaby, lrodriguez,
Bob Copeland
In-Reply-To: <1295929904-11806-1-git-send-email-me@bobcopeland.com>
The ath5k version of ieee80211_generic_frame_duration() returns
an __le16 for standard modes but a cpu-endian int for turbo/half/
quarter rates. Make it always return cpu-endian values.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/pcu.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index e5f2b96..a702817 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -86,7 +86,7 @@ int ath5k_hw_get_frame_duration(struct ath5k_hw *ah,
if (!ah->ah_bwmode) {
dur = ieee80211_generic_frame_duration(sc->hw,
NULL, len, rate);
- return dur;
+ return le16_to_cpu(dur);
}
bitrate = rate->bitrate;
@@ -265,8 +265,6 @@ static inline void ath5k_hw_write_rate_duration(struct ath5k_hw *ah)
* what rate we should choose to TX ACKs. */
tx_time = ath5k_hw_get_frame_duration(ah, 10, rate);
- tx_time = le16_to_cpu(tx_time);
-
ath5k_hw_reg_write(ah, tx_time, reg);
if (!(rate->flags & IEEE80211_RATE_SHORT_PREAMBLE))
--
1.7.1.1
^ permalink raw reply related
* [PATCH] fix_rtlwifi_rfkill_state_not_synchronous_with_true_rfstate_issue
From: 李朝明 @ 2011-01-25 4:10 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1291828372-25159-5-git-send-email-Larry.Finger@lwfinger.net>
>From 0bd7f0e28e5b6f4fe2a98aad7392c72d55420880 Mon Sep 17 00:00:00 2001
From: zhaoming_li <chaoming_li@realsil.com.cn>
Date: Tue, 25 Jan 2011 11:59:53 +0800
Subject: [PATCH]
fix_rtlwifi_rfkill_state_not_synchronous_with_true_rfstate_issue
---
drivers/net/wireless/rtlwifi/base.c | 13 ++++++++-----
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 2 +-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c
b/drivers/net/wireless/rtlwifi/base.c
index cf0b73e..33323b4 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -251,15 +251,18 @@ void rtl_init_rfkill(struct ieee80211_hw *hw)
bool blocked;
u8 valid = 0;
- radio_state = rtlpriv->cfg->ops->radio_onoff_checking(hw, &valid);
+ /*1. set init state to on */
+ rtlpriv->rfkill.rfkill_state = 1;
+ wiphy_rfkill_set_hw_state(hw->wiphy, 0);
- /*set init state to that of switch */
- rtlpriv->rfkill.rfkill_state = radio_state;
- printk(KERN_INFO "rtlwifi: wireless switch is %s\n",
- rtlpriv->rfkill.rfkill_state ? "on" : "off");
+ /*2. check gpio for rf state */
+ radio_state = rtlpriv->cfg->ops->radio_onoff_checking(hw, &valid);
+ /*3. if valid, change state based on gpio */
if (valid) {
rtlpriv->rfkill.rfkill_state = radio_state;
+ printk(KERN_INFO "rtlwifi: wireless switch is %s\n",
+ rtlpriv->rfkill.rfkill_state ? "on" :
"off");
blocked = (rtlpriv->rfkill.rfkill_state == 1) ? 0 : 1;
wiphy_rfkill_set_hw_state(hw->wiphy, blocked);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index 1c41a0c..cb2e01a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1943,7 +1943,7 @@ bool rtl92ce_gpio_radio_on_off_checking(struct
ieee80211_hw *hw, u8 * valid)
bool b_actuallyset = false;
unsigned long flag;
- if ((rtlpci->up_first_time == 1) || (rtlpci->being_init_adapter))
+ if (rtlpci->being_init_adapter)
return false;
if (ppsc->b_swrf_processing)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/6] ath: Fix WEP hardware encryption
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20110125041522.6944.22566.stgit@localhost6.localdomain6>
In AP mode hardware encryption for WEP was not used on the RX side because
there was a mismatch in the key indices. The key index in the WLAN header is
0-3 while the hardware key cache was configured for key indices >= 4. This is
ok for transmit but received packets were not decrypted in HW and therefore
mac80211 had to decrypt them in SW - this can be easily seen by adding some
debug prints in mac80211/wep.c (around line 296). I have noticed it by watching
the system CPU load under high traffic.
This patch configures WEP keys into the "standard" key indices 0-4 which were
reserved for that.
Tested with ath5k on a 600MHz mips board the difference is ~15% CPU load (with
this patch) vs. ~45% CPU load (before) when the AP receives 28Mbps of WEP
encrypted data.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/key.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/key.c b/drivers/net/wireless/ath/key.c
index 5d465e5..5748dae 100644
--- a/drivers/net/wireless/ath/key.c
+++ b/drivers/net/wireless/ath/key.c
@@ -465,6 +465,16 @@ int ath_key_config(struct ath_common *common,
hk.kv_len = key->keylen;
memcpy(hk.kv_val, key->key, key->keylen);
+ /* set WEP keys directly to index */
+ if ((key->cipher == WLAN_CIPHER_SUITE_WEP40 ||
+ key->cipher == WLAN_CIPHER_SUITE_WEP104) && key->keyidx < 4) {
+ ret = ath_hw_set_keycache_entry(common, key->keyidx, &hk, NULL);
+ if (!ret)
+ return -EIO;
+ set_bit(key->keyidx, common->keymap);
+ return key->keyidx;
+ }
+
if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE)) {
switch (vif->type) {
case NL80211_IFTYPE_AP:
@@ -541,10 +551,8 @@ EXPORT_SYMBOL(ath_key_config);
void ath_key_delete(struct ath_common *common, struct ieee80211_key_conf *key)
{
ath_hw_keyreset(common, key->hw_key_idx);
- if (key->hw_key_idx < IEEE80211_WEP_NKID)
- return;
-
clear_bit(key->hw_key_idx, common->keymap);
+
if (key->cipher != WLAN_CIPHER_SUITE_TKIP)
return;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox