* [PATCH] ath9k_hw: fix invalid extension channel noisefloor readings in HT20
From: Felix Fietkau @ 2010-07-23 2:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
When the hardware is configured in HT20 mode, noise floor readings for
the extension channel often return invalid values, which keep the
values in the NF history buffer at the hardware-specific maximum limit.
Fix this by discarding the extension channel values when in HT20 mode.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -1508,6 +1508,9 @@ static void ar5008_hw_do_getnf(struct at
nf = MS(REG_READ(ah, AR_PHY_CH2_CCA), AR_PHY_CH2_MINCCA_PWR);
nfarray[2] = sign_extend(nf, 9);
+ if (!IS_CHAN_HT40(ah->curchan))
+ return;
+
nf = MS(REG_READ(ah, AR_PHY_EXT_CCA), AR_PHY_EXT_MINCCA_PWR);
nfarray[3] = sign_extend(nf, 9);
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -477,7 +477,8 @@ static void ar9002_hw_do_getnf(struct at
nfarray[0] = sign_extend(nf, 9);
nf = MS(REG_READ(ah, AR_PHY_EXT_CCA), AR9280_PHY_EXT_MINCCA_PWR);
- nfarray[3] = sign_extend(nf, 9);
+ if (IS_CHAN_HT40(ah->curchan))
+ nfarray[3] = sign_extend(nf, 9);
if (AR_SREV_9285(ah) || AR_SREV_9271(ah))
return;
@@ -486,7 +487,8 @@ static void ar9002_hw_do_getnf(struct at
nfarray[1] = sign_extend(nf, 9);
nf = MS(REG_READ(ah, AR_PHY_CH1_EXT_CCA), AR9280_PHY_CH1_EXT_MINCCA_PWR);
- nfarray[4] = sign_extend(nf, 9);
+ if (IS_CHAN_HT40(ah->curchan))
+ nfarray[4] = sign_extend(nf, 9);
}
static void ar9002_hw_set_nf_limits(struct ath_hw *ah)
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1029,6 +1029,9 @@ static void ar9003_hw_do_getnf(struct at
nf = MS(REG_READ(ah, AR_PHY_CCA_2), AR_PHY_CH2_MINCCA_PWR);
nfarray[2] = sign_extend(nf, 9);
+ if (!IS_CHAN_HT40(ah->curchan))
+ return;
+
nf = MS(REG_READ(ah, AR_PHY_EXT_CCA), AR_PHY_EXT_MINCCA_PWR);
nfarray[3] = sign_extend(nf, 9);
^ permalink raw reply
* Re: [RFC] refactor ath9k_platform to sound sane for use in both ath9k and ath5k
From: Daniel Golle @ 2010-07-23 2:02 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTim7zJFbV0N0yoV--F3-8_fuv3jWFilozC9wmuP-@mail.gmail.com>
Hi!
In order to support the Senao EAP7660D board, I now added
ath5k_platform.h and patched ath5k (and madwifi).
In this way, the infrastructure for ath9k and ath5k remains separate, as
discussed in
https://lists.openwrt.org/pipermail/openwrt-devel/2010-July/007506.html
Is there any chance to have the patches added in
https://dev.openwrt.org/changeset/22188
included to linux-wireless?
Thank you!
Daniel
On 06/21/2010 08:02 PM, Luis R. Rodriguez wrote:
> On Mon, Jun 21, 2010 at 4:48 AM, Daniel Golle<daniel.golle@gmail.com> wrote:
>
>> I'm developing on OpenWrt to work with EEPROM-less ath5k mini-pci devices.
>> This is needed to support the ar71xx-based Senao EAP7660D board which got
>> two AR5413 modules soldered into its mini-pci slots. In the original
>> Firmware, MAC addresses as well as calibration-data seems to be part of the
>> firmware blob stored on the board flash.
>> See https://lists.openwrt.org/pipermail/openwrt-devel/2010-June/007366.html
>> for the corresponding discussion on OpenWrt-devel.
>>
> I don't see much "discussion" there.
>
>
>> Similarly to the way this happens for ath9k, I managed to get ath5k to use
>> the MAC address and eeprom-data supplied by ath9k_platform_data.
>> Including ath9k_platform.h in ath5k-sources looks confusing as the name
>> ath9k_platform suggests that the supplied ath9k_platform_info struct is
>> specific to ath9k devices.
>> Consequently, I believe ath9k_platform.h should be renamed into
>> ath_platform.h, the macro ATH9K_PLAT_EEP_MAX_WORDS into
>> ATH_PLAT_EEP_MAX_WORDS and struct ath9k_platform_data should be refactored
>> to be struct ath_platform_data.
>> Please let me know if you agree with this in theory; if yes, I'll start
>> posting the patches to OpenWrt.
>>
> You can stuff any general stuff into the ath module which is shared by both.
>
> Luis
>
^ permalink raw reply
* [PATCH] ath9k: fix yet another buffer leak in the tx aggregation code
From: Felix Fietkau @ 2010-07-23 1:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.
Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -518,6 +518,14 @@ static void ath_tx_complete_aggr(struct
bf = bf_next;
}
+ /* prepend un-acked frames to the beginning of the pending frame queue */
+ if (!list_empty(&bf_pending)) {
+ spin_lock_bh(&txq->axq_lock);
+ list_splice(&bf_pending, &tid->buf_q);
+ ath_tx_queue_tid(txq, tid);
+ spin_unlock_bh(&txq->axq_lock);
+ }
+
if (tid->state & AGGR_CLEANUP) {
if (tid->baw_head == tid->baw_tail) {
tid->state &= ~AGGR_ADDBA_COMPLETE;
@@ -530,14 +538,6 @@ static void ath_tx_complete_aggr(struct
return;
}
- /* prepend un-acked frames to the beginning of the pending frame queue */
- if (!list_empty(&bf_pending)) {
- spin_lock_bh(&txq->axq_lock);
- list_splice(&bf_pending, &tid->buf_q);
- ath_tx_queue_tid(txq, tid);
- spin_unlock_bh(&txq->axq_lock);
- }
-
rcu_read_unlock();
if (needreset)
^ permalink raw reply
* Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
From: Ohad Ben-Cohen @ 2010-07-22 23:56 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Roger Quadros, Tony Lindgren, Pandita Vikram,
Kalle Valo
In-Reply-To: <alpine.LFD.2.00.1007230052320.12562@xanadu.home>
On Fri, Jul 23, 2010 at 1:56 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 21 Jul 2010, Ohad Ben-Cohen wrote:
>
>> This patch series adds native support for wl1271 on ZOOM.
>>
>> Changes since v1:
>>
>> - introduce a fixed regulator device to control the power of wl1271
>> - allow to propagate private board-specific data to SDIO function drivers
>> - allow SDIO function driver to control the card's power via new API
>> - make it possible to keep the card's power down (without depending
>> on an explicit SDIO function driver power-down request)
>>
>> Thanks to these changes, we no longer need a separate platform
>> device (carrying e.g. the external irq information of the device),
>> and no longer need to emulate virtual card detect events.
>>
>> The two "board muxing" pathces were already taken by Tony, and
>> are resent here just to make it easier for people to use/test these pathces.
>>
>> The changes to the MMC core really needs careful review; there still
>> might be some pitfalls that haven't been covered. E.g., one thing
>> we plan to look at next is their bahvior together with SDIO Suspend/Resume.
>>
>> Special thanks to Roger Quadros and Nicolas Pitre for their extensive
>> review and helpful suggestions.
>
> FYI, I do intend to review those patches, but I'll be flying home in a
> couple hours, and once there I'll be gone on vacation for 2 weeks. So
> this review won't happen right away.
Thanks, Nicolas.
>
>
> Nicolas
>
^ permalink raw reply
* Re: [PATCH v2 01/20] sdio: add TI + wl1271 ids
From: Ohad Ben-Cohen @ 2010-07-22 23:38 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Roger Quadros, Tony Lindgren, Nicolas Pitre,
Pandita Vikram, Kalle Valo
In-Reply-To: <1279735134.3035.9.camel@localhost.localdomain>
Hi Marcel,
On Wed, Jul 21, 2010 at 8:58 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Add SDIO IDs for TI and for TI's wl1271 wlan device.
>>
>> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> ---
>> include/linux/mmc/sdio_ids.h | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
>> index 33b2ea0..0d313c6 100644
>> --- a/include/linux/mmc/sdio_ids.h
>> +++ b/include/linux/mmc/sdio_ids.h
>> @@ -43,4 +43,7 @@
>> #define SDIO_DEVICE_ID_SIANO_NOVA_A0 0x1100
>> #define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347
>>
>> +#define SDIO_VENDOR_ID_TI 0x0097
>> +#define SDIO_DEVICE_ID_TI_WL1271 0x4076
>> +
>
> are we still doing this non-sense for no real reason. What is so wrong
> with keeping the IDs inside the driver code?
Either way we can't go so wrong here (having global VENDOR_IDs can
potentially prevent redefinitions of the same ID in different drivers,
but that's probably not that big of an
issue too).
But if we prefer people to stop adding IDs to this global pool, let's
at least make it clear. We can probably seal it with some "please
don't add new IDs if you don't have to" footnote (care to send such
patch ? :)
Thanks,
Ohad.
> Personally I don't even see a point for these ID defines at all. Just
> use the bare numbers in SDIO_DEVICE and put a comment above what kind of
> device this is.
>
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
From: Ohad Ben-Cohen @ 2010-07-22 23:18 UTC (permalink / raw)
To: Gabay, Benzy
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar, Madhusudhan,
Luciano Coelho, akpm@linux-foundation.org, San Mehat,
Roger Quadros, Tony Lindgren, Nicolas Pitre, Pandita, Vikram,
Kalle Valo
In-Reply-To: <676FD6AA0F002F49B89E70F0C5EFD22C1311192A47@dlee04.ent.ti.com>
Hi Gever,
On Wed, Jul 21, 2010 at 9:55 PM, Gabay, Benzy <benzyg@ti.com> wrote:
> From: Ohad Ben-Cohen [mailto:ohad@wizery.com]
> Sent: Wednesday, July 21, 2010 12:34 PM
> To: linux-wireless@vger.kernel.org; linux-mmc@vger.kernel.org; linux-omap@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org; linux@arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm@linux-foundation.org; San Mehat; Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle Valo; Ohad Ben-Cohen
> Subject: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off
>
> Keep the MMC3 wl1271 WLAN device powered off until its
> SDIO function driver requests otherwise.
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> arch/arm/mach-omap2/board-zoom-peripherals.c | 1 +
> arch/arm/mach-omap2/hsmmc.c | 3 +++
> arch/arm/mach-omap2/hsmmc.h | 1 +
> arch/arm/plat-omap/include/plat/mmc.h | 3 +++
> drivers/mmc/host/omap_hsmmc.c | 3 +++
> 5 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
> index 3230801..3ab9125 100644
> --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
> +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
> @@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
> .gpio_wp = -EINVAL,
> .gpio_cd = -EINVAL,
> .ocr_mask = MMC_VDD_165_195,
> + .dont_power_card = true,
> .priv_data = &omap_zoom_wlan_data,
> },
> {} /* Terminator */
...
> --
> 1.7.0.4
>
> [Benzy Gabay] small comment: Please make sure that all 127x related changes are not bounded only to MMC3.
> On OMAP4 WLAN is used on MMC5.
The only place MMC3 is bound is in the board files (see code snippet
above), so that should be ok.
I can probably split this patch to make this more obvious just by
reading the diffstat if you prefer.
Thanks,
Ohad.
>
^ permalink raw reply
* Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
From: Ohad Ben-Cohen @ 2010-07-22 23:13 UTC (permalink / raw)
To: Roger Quadros, Mark Brown
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, Kalle Valo, Pandita Vikram,
linux@arm.linux.org.uk, Nicolas Pitre, Tony Lindgren, San Mehat,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4C48287D.1000603@nokia.com>
On Thu, Jul 22, 2010 at 2:16 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> On 07/21/2010 08:59 PM, ext Mark Brown wrote:
>>
>> On Wed, Jul 21, 2010 at 08:33:44PM +0300, Ohad Ben-Cohen wrote:
>>
>>> +static struct regulator_consumer_supply zoom_vmmc3_supply = {
>>> + .supply = "vmmc",
>>> +};
>>
>> This looks like a misconfiguration on the consumer - I'd strongly expect
>> the consumer to have a dev_name specified also with the name being in
>> terms of the consumer device.
>
> you need to add something like
>
> .dev_name = "mmci-omap-hs.2"
I already set the .dev member of the consumer in a similar manner to
how all other regulators are configured in this board - please check
out patch 13:
https://patchwork.kernel.org/patch/113418/
Does this look reasonable to you ?
Thanks,
Ohad.
>
> regards,
> -roger
>
^ permalink raw reply
* Re: [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
From: Björn Smedman @ 2010-07-22 22:56 UTC (permalink / raw)
To: Felix Fietkau; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <4C4791AF.8040909@openwrt.org>
2010/7/22 Felix Fietkau <nbd@openwrt.org>:
> On 2010-07-22 12:17 AM, Björn Smedman wrote:
>> Hi all,
>>
>> I just tried out compat-wireless-2010-07-16 on AR913x (with
>> openwrt/trunk@r22321) and saw some weird performance problems.
>>
> Could you please try if the earlier version that was in OpenWrt
> (2010-07-06) has the same issues?
>
Quickly flashing the builds I have on hand I came up with this small
table comparing MacBook 11g and 11n clients for various openwrt/trunk
versions:
r21960P (compat-wireless-2010-06-15): 11g = 12Mbps, 11n = 7.2Mbps
r22286 (compat-wireless-2010-07-06): 11g = 7.2Mbps*, 11n = 4.2Mbps*
r22321 (compat-wireless-2010-07-16): 11g = 12Mbps*, 11n = 2.9Mbps*
(*) Bursty / unstable performance.
(P) Some patches of my own on top of openwrt.
I realize it doesn't say very much unfortunately...
/Björn
^ permalink raw reply
* Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
From: Nicolas Pitre @ 2010-07-22 22:56 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Roger Quadros, Tony Lindgren, Pandita Vikram,
Kalle Valo
In-Reply-To: <1279733634-21974-1-git-send-email-ohad@wizery.com>
On Wed, 21 Jul 2010, Ohad Ben-Cohen wrote:
> This patch series adds native support for wl1271 on ZOOM.
>
> Changes since v1:
>
> - introduce a fixed regulator device to control the power of wl1271
> - allow to propagate private board-specific data to SDIO function drivers
> - allow SDIO function driver to control the card's power via new API
> - make it possible to keep the card's power down (without depending
> on an explicit SDIO function driver power-down request)
>
> Thanks to these changes, we no longer need a separate platform
> device (carrying e.g. the external irq information of the device),
> and no longer need to emulate virtual card detect events.
>
> The two "board muxing" pathces were already taken by Tony, and
> are resent here just to make it easier for people to use/test these pathces.
>
> The changes to the MMC core really needs careful review; there still
> might be some pitfalls that haven't been covered. E.g., one thing
> we plan to look at next is their bahvior together with SDIO Suspend/Resume.
>
> Special thanks to Roger Quadros and Nicolas Pitre for their extensive
> review and helpful suggestions.
FYI, I do intend to review those patches, but I'll be flying home in a
couple hours, and once there I'll be gone on vacation for 2 weeks. So
this review won't happen right away.
Nicolas
^ permalink raw reply
* [PATCH] lib80211: remove unused host_build_iv option
From: John W. Linville @ 2010-07-22 20:33 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ipw2x00/libipw.h | 1 -
drivers/net/wireless/ipw2x00/libipw_tx.c | 16 +++-------------
drivers/net/wireless/ipw2x00/libipw_wx.c | 2 +-
include/net/lib80211.h | 3 ---
net/wireless/lib80211_crypt_ccmp.c | 1 -
net/wireless/lib80211_crypt_tkip.c | 1 -
net/wireless/lib80211_crypt_wep.c | 1 -
7 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/libipw.h b/drivers/net/wireless/ipw2x00/libipw.h
index 284b0e4..7b9539a 100644
--- a/drivers/net/wireless/ipw2x00/libipw.h
+++ b/drivers/net/wireless/ipw2x00/libipw.h
@@ -828,7 +828,6 @@ struct libipw_device {
int host_strip_iv_icv;
int host_open_frag;
- int host_build_iv;
int ieee802_1x; /* is IEEE 802.1X used */
/* WPA data */
diff --git a/drivers/net/wireless/ipw2x00/libipw_tx.c b/drivers/net/wireless/ipw2x00/libipw_tx.c
index da8beac..01c88a7 100644
--- a/drivers/net/wireless/ipw2x00/libipw_tx.c
+++ b/drivers/net/wireless/ipw2x00/libipw_tx.c
@@ -260,7 +260,7 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
int i, bytes_per_frag, nr_frags, bytes_last_frag, frag_size,
rts_required;
unsigned long flags;
- int encrypt, host_encrypt, host_encrypt_msdu, host_build_iv;
+ int encrypt, host_encrypt, host_encrypt_msdu;
__be16 ether_type;
int bytes, fc, hdr_len;
struct sk_buff *skb_frag;
@@ -301,7 +301,6 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
host_encrypt = ieee->host_encrypt && encrypt && crypt;
host_encrypt_msdu = ieee->host_encrypt_msdu && encrypt && crypt;
- host_build_iv = ieee->host_build_iv && encrypt && crypt;
if (!encrypt && ieee->ieee802_1x &&
ieee->drop_unencrypted && ether_type != htons(ETH_P_PAE)) {
@@ -313,7 +312,7 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
skb_copy_from_linear_data(skb, dest, ETH_ALEN);
skb_copy_from_linear_data_offset(skb, ETH_ALEN, src, ETH_ALEN);
- if (host_encrypt || host_build_iv)
+ if (host_encrypt)
fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA |
IEEE80211_FCTL_PROTECTED;
else
@@ -467,7 +466,7 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
for (; i < nr_frags; i++) {
skb_frag = txb->fragments[i];
- if (host_encrypt || host_build_iv)
+ if (host_encrypt)
skb_reserve(skb_frag,
crypt->ops->extra_mpdu_prefix_len);
@@ -502,15 +501,6 @@ netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
* to insert the IV between the header and the payload */
if (host_encrypt)
libipw_encrypt_fragment(ieee, skb_frag, hdr_len);
- else if (host_build_iv) {
- atomic_inc(&crypt->refcnt);
- if (crypt->ops->build_iv)
- crypt->ops->build_iv(skb_frag, hdr_len,
- ieee->sec.keys[ieee->sec.active_key],
- ieee->sec.key_sizes[ieee->sec.active_key],
- crypt->priv);
- atomic_dec(&crypt->refcnt);
- }
if (ieee->config &
(CFG_LIBIPW_COMPUTE_FCS | CFG_LIBIPW_RESERVE_FCS))
diff --git a/drivers/net/wireless/ipw2x00/libipw_wx.c b/drivers/net/wireless/ipw2x00/libipw_wx.c
index 8a4bae4..d7bd6cf 100644
--- a/drivers/net/wireless/ipw2x00/libipw_wx.c
+++ b/drivers/net/wireless/ipw2x00/libipw_wx.c
@@ -320,7 +320,7 @@ int libipw_wx_set_encode(struct libipw_device *ieee,
};
int i, key, key_provided, len;
struct lib80211_crypt_data **crypt;
- int host_crypto = ieee->host_encrypt || ieee->host_decrypt || ieee->host_build_iv;
+ int host_crypto = ieee->host_encrypt || ieee->host_decrypt;
DECLARE_SSID_BUF(ssid);
LIBIPW_DEBUG_WX("SET_ENCODE\n");
diff --git a/include/net/lib80211.h b/include/net/lib80211.h
index fb4e278..848cce1 100644
--- a/include/net/lib80211.h
+++ b/include/net/lib80211.h
@@ -54,9 +54,6 @@ struct lib80211_crypto_ops {
/* deinitialize crypto context and free allocated private data */
void (*deinit) (void *priv);
- int (*build_iv) (struct sk_buff * skb, int hdr_len,
- u8 *key, int keylen, void *priv);
-
/* encrypt/decrypt return < 0 on error or >= 0 on success. The return
* value from decrypt_mpdu is passed as the keyidx value for
* decrypt_msdu. skb must have enough head and tail room for the
diff --git a/net/wireless/lib80211_crypt_ccmp.c b/net/wireless/lib80211_crypt_ccmp.c
index b7fa31d..dacb3b4 100644
--- a/net/wireless/lib80211_crypt_ccmp.c
+++ b/net/wireless/lib80211_crypt_ccmp.c
@@ -467,7 +467,6 @@ static struct lib80211_crypto_ops lib80211_crypt_ccmp = {
.name = "CCMP",
.init = lib80211_ccmp_init,
.deinit = lib80211_ccmp_deinit,
- .build_iv = lib80211_ccmp_hdr,
.encrypt_mpdu = lib80211_ccmp_encrypt,
.decrypt_mpdu = lib80211_ccmp_decrypt,
.encrypt_msdu = NULL,
diff --git a/net/wireless/lib80211_crypt_tkip.c b/net/wireless/lib80211_crypt_tkip.c
index a7f9956..0fe4051 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -757,7 +757,6 @@ static struct lib80211_crypto_ops lib80211_crypt_tkip = {
.name = "TKIP",
.init = lib80211_tkip_init,
.deinit = lib80211_tkip_deinit,
- .build_iv = lib80211_tkip_hdr,
.encrypt_mpdu = lib80211_tkip_encrypt,
.decrypt_mpdu = lib80211_tkip_decrypt,
.encrypt_msdu = lib80211_michael_mic_add,
diff --git a/net/wireless/lib80211_crypt_wep.c b/net/wireless/lib80211_crypt_wep.c
index 6d41e05..e2e8887 100644
--- a/net/wireless/lib80211_crypt_wep.c
+++ b/net/wireless/lib80211_crypt_wep.c
@@ -269,7 +269,6 @@ static struct lib80211_crypto_ops lib80211_crypt_wep = {
.name = "WEP",
.init = lib80211_wep_init,
.deinit = lib80211_wep_deinit,
- .build_iv = lib80211_wep_build_iv,
.encrypt_mpdu = lib80211_wep_encrypt,
.decrypt_mpdu = lib80211_wep_decrypt,
.encrypt_msdu = NULL,
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix race between sysfs and cfg80211
From: Luis R. Rodriguez @ 2010-07-22 20:37 UTC (permalink / raw)
To: mbizon; +Cc: linux-wireless
In-Reply-To: <1279725698.10426.4.camel@sakura.staff.proxad.net>
On Wed, Jul 21, 2010 at 8:21 AM, Maxime Bizon <mbizon@freebox.fr> wrote:
> From: Maxime Bizon <mbizon@freebox.fr>
>
> device_add() is called before adding the phy to the cfg80211 device
> list.
>
> So if a userspace program uses sysfs uevents to detect new phy
> devices, and queries nl80211 to get phy info, it can get ENODEV even
> though the phy exists in sysfs.
>
> An easy workaround is to hold the cfg80211 mutex until the phy is
> present in sysfs/cfg80211/debugfs.
>
> Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
> ---
You should resubmit as a new e-mail with a subject of [PATCH v2].
Luis
^ permalink raw reply
* Re: [PATCH] atmel: silence sparse warnings
From: Dan Williams @ 2010-07-22 22:36 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279823041-21156-1-git-send-email-linville@tuxdriver.com>
On Thu, 2010-07-22 at 14:24 -0400, John W. Linville wrote:
> CHECK drivers/net/wireless/atmel.c
> drivers/net/wireless/atmel.c:3694:30: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3695:31: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3696:30: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3697:32: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3698:30: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3699:31: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3700:30: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3701:32: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3702:32: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3703:30: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3704:32: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3705:32: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3706:28: warning: cast to restricted __le16
> drivers/net/wireless/atmel.c:3707:29: warning: cast to restricted __le16
Eww. All the atmel code predates sparse, but it certainly looks like we
need to le16_to_cpu() everything that comes from the device here. Is
the sparse problem coming from the fact that the code copies LE data
into a non-tagged struct?
I think what we should do here is to (a) make host_info_struct __packed,
and (b) annotate its members as __le16 where appropriate. But since
that structure's members are used fairly often, I think we may want to
do the endian conversion just once like the code already does, but
certainly without trying to do the conversion in-place on the struct
that's making sparse complain.
Dan
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> Is this any better than what we have now??
>
> drivers/net/wireless/atmel.c | 73 ++++++++++++++++++++++++++++++++----------
> 1 files changed, 56 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
> index c8f7090..008d712 100644
> --- a/drivers/net/wireless/atmel.c
> +++ b/drivers/net/wireless/atmel.c
> @@ -3617,6 +3617,7 @@ static void atmel_command_irq(struct atmel_private *priv)
> static int atmel_wakeup_firmware(struct atmel_private *priv)
> {
> struct host_info_struct *iface = &priv->host_info;
> + u8 buf[sizeof(struct host_info_struct)];
> u16 mr1, mr3;
> int i;
>
> @@ -3688,23 +3689,61 @@ static int atmel_wakeup_firmware(struct atmel_private *priv)
> return -EIO;
> }
>
> - atmel_copy_to_host(priv->dev, (unsigned char *)iface,
> - priv->host_info_base, sizeof(*iface));
> -
> - iface->tx_buff_pos = le16_to_cpu(iface->tx_buff_pos);
> - iface->tx_buff_size = le16_to_cpu(iface->tx_buff_size);
> - iface->tx_desc_pos = le16_to_cpu(iface->tx_desc_pos);
> - iface->tx_desc_count = le16_to_cpu(iface->tx_desc_count);
> - iface->rx_buff_pos = le16_to_cpu(iface->rx_buff_pos);
> - iface->rx_buff_size = le16_to_cpu(iface->rx_buff_size);
> - iface->rx_desc_pos = le16_to_cpu(iface->rx_desc_pos);
> - iface->rx_desc_count = le16_to_cpu(iface->rx_desc_count);
> - iface->build_version = le16_to_cpu(iface->build_version);
> - iface->command_pos = le16_to_cpu(iface->command_pos);
> - iface->major_version = le16_to_cpu(iface->major_version);
> - iface->minor_version = le16_to_cpu(iface->minor_version);
> - iface->func_ctrl = le16_to_cpu(iface->func_ctrl);
> - iface->mac_status = le16_to_cpu(iface->mac_status);
> + atmel_copy_to_host(priv->dev, (unsigned char *)&buf,
> + priv->host_info_base, sizeof(buf));
> +
> + iface->int_status = buf[offsetof(struct host_info_struct,
> + int_status)];
> + iface->int_mask = buf[offsetof(struct host_info_struct, int_mask)];
> + iface->lockout_host = buf[offsetof(struct host_info_struct,
> + lockout_host)];
> + iface->lockout_mac = buf[offsetof(struct host_info_struct,
> + lockout_mac)];
> + iface->tx_buff_pos =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + tx_buff_pos)]);
> + iface->tx_buff_size =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + tx_buff_size)]);
> + iface->tx_desc_pos =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + tx_desc_pos)]);
> + iface->tx_desc_count =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + tx_desc_count)]);
> + iface->rx_buff_pos =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + rx_buff_pos)]);
> + iface->rx_buff_size =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + rx_buff_size)]);
> + iface->rx_desc_pos =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + rx_desc_pos)]);
> + iface->rx_desc_count =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + rx_desc_count)]);
> + iface->build_version =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + build_version)]);
> + iface->command_pos =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + command_pos)]);
> + iface->major_version =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + major_version)]);
> + iface->minor_version =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + minor_version)]);
> + iface->func_ctrl =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + func_ctrl)]);
> + iface->mac_status =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + mac_status)]);
> + iface->generic_IRQ_type =
> + le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
> + generic_IRQ_type)]);
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: orphan the atmel wireless driver
From: Dan Williams @ 2010-07-22 22:28 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Simon Kelley
In-Reply-To: <1279823468-21366-1-git-send-email-linville@tuxdriver.com>
On Thu, 2010-07-22 at 14:31 -0400, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Aww, how sad :(. I'll take it since I still have some of this
hardware. Not that I'll do much with it, but if the patches are simple
I'm happy to test+ack them.
Dan
> MAINTAINERS | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3148b71..2911648 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1170,11 +1170,10 @@ S: Supported
> F: drivers/usb/gadget/atmel_usba_udc.*
>
> ATMEL WIRELESS DRIVER
> -M: Simon Kelley <simon@thekelleys.org.uk>
> L: linux-wireless@vger.kernel.org
> W: http://www.thekelleys.org.uk/atmel
> W: http://atmelwlandriver.sourceforge.net/
> -S: Maintained
> +S: Orphan
> F: drivers/net/wireless/atmel*
>
> AUDIT SUBSYSTEM
^ permalink raw reply
* Re: [patch -next] libertas: precedence bug
From: Dan Williams @ 2010-07-22 22:24 UTC (permalink / raw)
To: Dan Carpenter
Cc: John W. Linville, Holger Schurig, David S. Miller,
Amitkumar Karwar, Stephen Hemminger, libertas-dev, linux-wireless,
kernel-janitors
In-Reply-To: <20100722122102.GH17585@bicker>
On Thu, 2010-07-22 at 14:21 +0200, Dan Carpenter wrote:
> Negate has precedence over comparison so the original test was always
> false. (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR).
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> diff --git a/drivers/net/wireless/libertas/tx.c b/drivers/net/wireless/libertas/tx.c
> index 411a3bb..8000ca6 100644
> --- a/drivers/net/wireless/libertas/tx.c
> +++ b/drivers/net/wireless/libertas/tx.c
> @@ -180,7 +180,7 @@ void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count)
> {
> struct tx_radiotap_hdr *radiotap_hdr;
>
> - if (!priv->wdev->iftype == NL80211_IFTYPE_MONITOR ||
> + if (priv->wdev->iftype != NL80211_IFTYPE_MONITOR ||
> priv->currenttxskb == NULL)
> return;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] minstrel: don't complain about feedback for unrequested rates
From: John W. Linville @ 2010-07-22 19:46 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Sven Geggus, netdev, John W. Linville
In-Reply-To: <4C4896D5.8010802@openwrt.org>
"It's not problematic if minstrel gets feedback for rates that it
doesn't have in its list, it should just ignore it. - Felix"
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rc80211_minstrel.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index f65ce6d..778c604 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -67,7 +67,6 @@ rix_to_ndx(struct minstrel_sta_info *mi, int rix)
for (i = rix; i >= 0; i--)
if (mi->r[i].rix == rix)
break;
- WARN_ON(i < 0);
return i;
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH] minstrel_ht: remove unnecessary NULL check in minstrel_ht_update_caps
From: John W. Linville @ 2010-07-22 19:39 UTC (permalink / raw)
To: linux-wireless
Cc: Dan Carpenter, Felix Fietkau, Johannes Berg, John W. Linville
In-Reply-To: <20100722110933.GA17585@bicker>
If sta is NULL, we will have problems long before we get here...
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index b5ace24..a16694b 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -636,7 +636,7 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
int i;
/* fall back to the old minstrel for legacy stations */
- if (sta && !sta->ht_cap.ht_supported) {
+ if (!sta->ht_cap.ht_supported) {
msp->is_ht = false;
memset(&msp->legacy, 0, sizeof(msp->legacy));
msp->legacy.r = msp->ratelist;
--
1.7.1.1
^ permalink raw reply related
* Re: potential null deref in minstrel_ht_update_caps()?
From: John W. Linville @ 2010-07-22 19:35 UTC (permalink / raw)
To: Dan Carpenter; +Cc: nbd, linux-wireless, johannes
In-Reply-To: <20100722110933.GA17585@bicker>
On Thu, Jul 22, 2010 at 01:09:33PM +0200, Dan Carpenter wrote:
> This is a smatch thing.
>
> net/mac80211/rc80211_minstrel_ht.c +639 minstrel_ht_update_caps(15)
> warn: variable dereferenced before check 'sta'
> 631 struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
> 632 struct ieee80211_local *local = hw_to_local(mp->hw);
> 633 u16 sta_cap = sta->ht_cap.cap;
> ^^^^^^^^^^^^^^^
> Dereferenced here.
>
> 634 int ack_dur;
> 635 int stbc;
> 636 int i;
> 637
> 638 /* fall back to the old minstrel for legacy stations */
> 639 if (sta && !sta->ht_cap.ht_supported) {
> ^^^
> Checked here.
>
> 640 msp->is_ht = false;
> 641 memset(&msp->legacy, 0, sizeof(msp->legacy));
>
> It seems like a bug, but I'm not sure how to deal with it.
I think that sta NULL check is unnecessary there.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] iwlwifi: assume vif is NULL for internal scans and non-NULL otherwise
From: Guy, Wey-Yi @ 2010-07-22 19:36 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, Dan Carpenter
In-Reply-To: <1279826937-24581-1-git-send-email-linville@tuxdriver.com>
Hi John,
On Thu, 2010-07-22 at 12:28 -0700, John W. Linville wrote:
> The current practice of checking vif for NULL in one place but not
> another seems to confuse some static checkers, smatch in particular.
> Since vif will only be NULL in the case of internal scans, adjust the
> checks accordingly.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 ++++-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 5 ++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index 74623e0..0ca0df4 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -1234,7 +1234,10 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
>
> IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
> spin_lock_irqsave(&priv->lock, flags);
> - interval = vif ? vif->bss_conf.beacon_int : 0;
> + if (priv->is_internal_short_scan)
> + interval = 0;
> + else
> + interval = vif->bss_conf.beacon_int;
> spin_unlock_irqrestore(&priv->lock, flags);
>
> scan->suspend_time = 0;
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 8eb3471..b102bab 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -2883,7 +2883,10 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
> IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
>
> spin_lock_irqsave(&priv->lock, flags);
> - interval = vif ? vif->bss_conf.beacon_int : 0;
> + if (priv->is_internal_short_scan)
> + interval = 0;
> + else
> + interval = vif->bss_conf.beacon_int;
> spin_unlock_irqrestore(&priv->lock, flags);
>
> scan->suspend_time = 0;
Make sense, Thanks.
Wey
^ permalink raw reply
* [PATCH] iwlwifi: assume vif is NULL for internal scans and non-NULL otherwise
From: John W. Linville @ 2010-07-22 19:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Dan Carpenter, John W. Linville
In-Reply-To: <20100721221616.GT17585@bicker>
The current practice of checking vif for NULL in one place but not
another seems to confuse some static checkers, smatch in particular.
Since vif will only be NULL in the case of internal scans, adjust the
checks accordingly.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 ++++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 74623e0..0ca0df4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -1234,7 +1234,10 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
spin_lock_irqsave(&priv->lock, flags);
- interval = vif ? vif->bss_conf.beacon_int : 0;
+ if (priv->is_internal_short_scan)
+ interval = 0;
+ else
+ interval = vif->bss_conf.beacon_int;
spin_unlock_irqrestore(&priv->lock, flags);
scan->suspend_time = 0;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 8eb3471..b102bab 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -2883,7 +2883,10 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
spin_lock_irqsave(&priv->lock, flags);
- interval = vif ? vif->bss_conf.beacon_int : 0;
+ if (priv->is_internal_short_scan)
+ interval = 0;
+ else
+ interval = vif->bss_conf.beacon_int;
spin_unlock_irqrestore(&priv->lock, flags);
scan->suspend_time = 0;
--
1.7.1.1
^ permalink raw reply related
* Re: potential null deref in iwlagn_request_scan()?
From: John W. Linville @ 2010-07-22 19:28 UTC (permalink / raw)
To: Dan Carpenter; +Cc: johannes.berg, linux-wireless
In-Reply-To: <20100721221616.GT17585@bicker>
On Thu, Jul 22, 2010 at 12:16:16AM +0200, Dan Carpenter wrote:
> Smatch complains about iwlagn_request_scan().
>
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c +1354 iwlagn_request_scan(204)
> error: we previously assumed 'vif' could be null.
>
> 1351 if (!priv->is_internal_short_scan) {
> 1352 cmd_len = iwl_fill_probe_req(priv,
> 1353 (struct ieee80211_mgmt *)scan->data,
> 1354 vif->addr,
> ^^^^^^^^^
>
> 1355 priv->scan_request->ie,
> 1356 priv->scan_request->ie_len,
> 1357 IWL_MAX_SCAN_SIZE - sizeof(*scan));
> 1358 } else {
> 1359 /* use bcast addr, will not be transmitted but must be valid */
>
> This was added in 3a0b9aad0a8166e9f "iwlwifi: use virtual interface
> address for scan". Prior to that commit the function assumed that vif
> could be NULL throughout.
>
> I don't know the code well enough to know what to do about this.
>
> Also the same thing for:
> drivers/net/wireless/iwlwifi/iwl3945-base.c +2963 iwl3945_request_scan(158)
> error: we previously assumed 'vif' could be null.
I think both of these are more-or-less OK. It looks like the only
time vif would be NULL is in the "priv->is_internal_short_scan ==
true" case. I'll send a patch, but I don't know if it really matters.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] zd1211rw: make CR_INTERRUPT cast explicit
From: John W. Linville @ 2010-07-22 19:03 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <1279730218.9003.7.camel@mj>
On Wed, Jul 21, 2010 at 12:36:58PM -0400, Pavel Roskin wrote:
> On Wed, 2010-07-21 at 11:08 -0400, John W. Linville wrote:
> > CHECK drivers/net/wireless/zd1211rw/zd_usb.c
> > drivers/net/wireless/zd1211rw/zd_usb.c:376:24: warning: implicit cast from nocast type
> >
> > The value comparison is intentional, so forcing the cast seems warranted
> > in order to silence the sparse warning.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
> > index 818e148..acbf4d9 100644
> > --- a/drivers/net/wireless/zd1211rw/zd_usb.c
> > +++ b/drivers/net/wireless/zd1211rw/zd_usb.c
> > @@ -373,7 +373,7 @@ static inline void handle_regs_int(struct urb *urb)
> > spin_lock(&intr->lock);
> >
> > int_num = le16_to_cpu(*(__le16 *)(urb->transfer_buffer+2));
> > - if (int_num == CR_INTERRUPT) {
> > + if (int_num == (u16 __force) CR_INTERRUPT) {
>
> I think __force should be used sparingly, especially outside headers. I
> tried other ways to prevent the warning. I tried declaring int_num as
> zd_addr_t, but sparse keeps complaining about the same comparison.
Actually, it looks like it works w/o the "__force" as well.
Any objection to a version like that?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: minstrel_tx_status mac80211 WARNINGs in vanilla 2.6.34.1
From: Felix Fietkau @ 2010-07-22 19:07 UTC (permalink / raw)
To: John W. Linville; +Cc: Sven Geggus, netdev, linux-wireless
In-Reply-To: <20100722144723.GA2616@tuxdriver.com>
On 2010-07-22 4:47 PM, John W. Linville wrote:
> On Thu, Jul 22, 2010 at 02:30:01PM +0200, Sven Geggus wrote:
>> Hello,
>>
>> running vanilla 2.6.34.1 I get the following warnings in kernel log:
>>
>> WARNING: at net/mac80211/rc80211_minstrel.c:70 minstrel_tx_status+0x67/0xd1 [mac80211]()
>> Hardware name: SCENIC E300/E600
>> Modules linked in: i915 drm_kms_helper drm video backlight output lp loop
>> snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
>> snd_seq_dummy zd1211rw snd_seq_oss usbhid mac80211 option cfg80211
>> snd_seq_midi usbserial snd_rawmidi snd_seq_midi_event snd_seq snd_timer
>> snd_seq_device snd parport_pc ehci_hcd uhci_hcd soundcore intel_agp parport
>> usbcore nls_base snd_page_alloc agpgart rng_core floppy sg
>> Pid: 0, comm: swapper Tainted: G W 2.6.34.1 #3
>> Call Trace:
>> [<c102af25>] warn_slowpath_common+0x60/0x90
>> [<c102af62>] warn_slowpath_null+0xd/0x10
>> [<f83cbd48>] minstrel_tx_status+0x67/0xd1 [mac80211]
>> [<f83b6eb1>] ieee80211_tx_status+0x1f6/0x5ac [mac80211]
>> [<c1261533>] ? skb_dequeue+0x45/0x4c
>> [<f83b6896>] ieee80211_tasklet_handler+0x61/0xd6 [mac80211]
>> [<c102ed7d>] tasklet_action+0x62/0x9f
>> [<c102f331>] __do_softirq+0x77/0xe5
>> [<c102f3c5>] do_softirq+0x26/0x2b
>> [<c102f52f>] irq_exit+0x29/0x66
>> [<c1003e90>] do_IRQ+0x85/0x9b
>> [<c1002d29>] common_interrupt+0x29/0x30
>> [<c10083ac>] ? default_idle+0x2d/0x42
>> [<c1001a9b>] cpu_idle+0x44/0x71
>> [<c12e00de>] rest_init+0x96/0x98
>> [<c1498862>] start_kernel+0x2a5/0x2aa
>> [<c14980b7>] i386_start_kernel+0xb7/0xbf
>> ---[ end trace f22ceacef336878f ]---
>>
>> Wireless driver is zd1211rw.
>>
>> Did not test with older kernel because this device has not been in user on
>> this machine before.
>>
>> WLAN does however seem to work anyway.
>
> Well, I just took a quick look -- so, I'm not 100% sure...
>
> But, it looks to me like zd1211rw is reporting tx status on a rate
> that minstrel didn't expect it to use. It seems like the hardware
> is pre-wired to do retries on sequentially lower rates, which seems
> a bit incompatible with minstrel's worldview.
>
> Felix, can we accomodate this? The "WLAN does however seem to work
> anyway" seems to suggest things work, so can we at least not yell
> about it?
I think we should just drop that WARN_ON(). It's not problematic if
minstrel gets feedback for rates that it doesn't have in its list, it
should just ignore it.
- Felix
^ permalink raw reply
* Compat-wireless release for 2010-07-22 is baked
From: Compat-wireless cronjob account @ 2010-07-22 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
1a05138..04898a5 master -> origin/master
0442f68..c7ecb8a wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
5f11688..afdbfed history -> origin/history
+ fecd01b...dd5c869 master -> origin/master (forced update)
e095937..cd5b8f8 stable -> origin/stable
* [new tag] next-20100722 -> next-20100722
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
493727 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4605 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2467 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100722
compat-wireless release: compat-wireless-2010-07-13-4-g04898a5
^ permalink raw reply
* [PATCH] MAINTAINERS: remove entry for wavelan
From: John W. Linville @ 2010-07-22 18:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Jean Tourrilhes, John W. Linville
The driver is already removed from drivers/staging. The wireless
extensions part is not really valid anymore either, since wext got moved
and refactored, etc.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 220a4ba..f160c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6177,14 +6177,6 @@ F: Documentation/watchdog/
F: drivers/watchdog/
F: include/linux/watchdog.h
-WAVELAN NETWORK DRIVER & WIRELESS EXTENSIONS
-M: Jean Tourrilhes <jt@hpl.hp.com>
-L: linux-wireless@vger.kernel.org
-W: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/
-S: Maintained
-F: Documentation/networking/wavelan.txt
-F: drivers/staging/wavelan/
-
WD7000 SCSI DRIVER
M: Miroslav Zagorac <zaga@fly.cc.fer.hr>
L: linux-scsi@vger.kernel.org
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] wireless: remove prism54
From: John W. Linville @ 2010-07-22 18:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <AANLkTikWo6tjyYCDMgoA9WXvbNaWIe_oSp180jcdtWgy@mail.gmail.com>
On Wed, Jul 21, 2010 at 01:58:40PM -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 21, 2010 at 11:05 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > This driver is no longer necessary due to p54pci. It has seen very
> > little maintenance for some time, and at least Fedora has had it
> > disabled without any user complaints.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> Hm, we had a few users report back that only with prism54 and not
> p54pci could they get their device functional. IIRC Christian noted
> some issues with the EEPROM, and it seems the fault was on the
> manufacturer. My memory may be foggy but indeed I do remember a few
> users did complain about the feature removal plan. I can dig these
> e-mails up if needed.
I think I found some of that in the archive. Do we have any sort of
plan for resolving these EEPROM-related (i.e. missing and/or damaged
EEPROM) issue?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
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