* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Luis R. Rodriguez @ 2009-08-27 23:14 UTC (permalink / raw)
To: Bob Copeland
Cc: mickflemm, proski, ath5k-devel, linux-wireless, John W. Linville,
ic.felix
In-Reply-To: <20090827213921.GB30419@hash.localnet>
On Thu, Aug 27, 2009 at 2:39 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Thu, Aug 27, 2009 at 11:25:03AM -0700, Luis R. Rodriguez wrote:
>> > Well, we also don't use the turbo modes at all and that's where the
>> > error is (IIRC) so it shouldn't have any impact. :)
>>
>> Again, why don't we just remove all that fucking turbo cruft?
>
> OK with me since no one seems to care enough to implement mac80211
> support. I left some of the #defines in place as they are useful
> documentation. Approx. 80 of the lines removed are comments.
>
> text data bss dec hex filename
> 136746 480 56 137282 21842 ath5k_old.ko
> 134913 480 56 135449 21119 ath5k_new.ko
>
> Disclaimer: only barely tested.
Sexy, thanks!
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> { AR5K_PHY(14),
> - { 0x00000007, 0x00000007, 0x0000000b, 0x0000000b } },
> + { 0x00000007, 0x0000000b, 0x0000000b } },
Apart from this one initval all other ar5211_ini_mode[] values between
802.11a and 802.11g are the same! Which means we could potentially
save (35 lines here * 4 bytes) + (3 entries for AR5K_PHY(14) * 4) =
152 bytes here if we just converge 11a and 11g as just OFDM data for
this ini array and remove AR5K_PHY(14) entry and deal with it as a
final write. I wonder if AR5K_PHY(14) (0x9838) was a typo for 11a or
11g. I'll try to dig to see what this is, perhaps its not a good idea
to move this out and set this later, not sure if this is inline for
the rf buffer trigger stuff, I'll poke.
All other ini arrays differ in more than 1 line so probably not worth mucking.
Luis
^ permalink raw reply
* [PATCH 2/2] mac80211: initialize rate control after station inserted
From: Reinette Chatre @ 2009-08-27 23:34 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless, Reinette Chatre
In-Reply-To: <1251416094-10420-1-git-send-email-reinette.chatre@intel.com>
From: Reinette Chatre <reinette.chatre@intel.com>
Station information may be needed by rate control algorithms, so call rate
scaling initialization after adding the station.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
net/mac80211/ibss.c | 3 ++-
net/mac80211/mlme.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 920ec87..040d184 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -413,11 +413,12 @@ struct sta_info *ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
sta->sta.supp_rates[band] = supp_rates |
ieee80211_mandatory_rates(local, band);
- rate_control_rate_init(sta);
if (sta_info_insert(sta))
return NULL;
+ rate_control_rate_init(sta);
+
return sta;
}
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 97a278a..307b33c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1554,8 +1554,6 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
ap_ht_cap_flags = sta->sta.ht_cap.cap;
- rate_control_rate_init(sta);
-
if (ifmgd->flags & IEEE80211_STA_MFP_ENABLED)
set_sta_flags(sta, WLAN_STA_MFP);
@@ -1572,6 +1570,8 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
}
}
+ rate_control_rate_init(sta);
+
rcu_read_unlock();
if (elems.wmm_param)
--
1.5.6.3
^ permalink raw reply related
* [PATCH 1/2] cfg80211: initialize rate control after station inserted
From: Reinette Chatre @ 2009-08-27 23:34 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless, Reinette Chatre
From: Reinette Chatre <reinette.chatre@intel.com>
Station information may be needed by rate control algorithms, so call rate
scaling initialization after adding the station.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
net/mac80211/cfg.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5608f6c..598db11 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -729,8 +729,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
sta_apply_parameters(local, sta, params);
- rate_control_rate_init(sta);
-
layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
sdata->vif.type == NL80211_IFTYPE_AP;
@@ -742,13 +740,17 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (err == -EEXIST && layer2_update) {
/* Need to update layer 2 devices on reassociation */
sta = sta_info_get(local, mac);
- if (sta)
+ if (sta) {
+ rate_control_rate_init(sta);
ieee80211_send_layer2_update(sta);
+ }
}
rcu_read_unlock();
return err;
}
+ rate_control_rate_init(sta);
+
if (layer2_update)
ieee80211_send_layer2_update(sta);
--
1.5.6.3
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Luis R. Rodriguez @ 2009-08-28 0:09 UTC (permalink / raw)
To: Bob Copeland
Cc: mickflemm, proski, ath5k-devel, linux-wireless, John W. Linville,
ic.felix
In-Reply-To: <43e72e890908271614p58feb9bn2130e1c963685a55@mail.gmail.com>
On Thu, Aug 27, 2009 at 4:14 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 2:39 PM, Bob Copeland<me@bobcopeland.com> wrote:
>> On Thu, Aug 27, 2009 at 11:25:03AM -0700, Luis R. Rodriguez wrote:
>>> > Well, we also don't use the turbo modes at all and that's where the
>>> > error is (IIRC) so it shouldn't have any impact. :)
>>>
>>> Again, why don't we just remove all that fucking turbo cruft?
>>
>> OK with me since no one seems to care enough to implement mac80211
>> support. I left some of the #defines in place as they are useful
>> documentation. Approx. 80 of the lines removed are comments.
>>
>> text data bss dec hex filename
>> 136746 480 56 137282 21842 ath5k_old.ko
>> 134913 480 56 135449 21119 ath5k_new.ko
>>
>> Disclaimer: only barely tested.
>
> Sexy, thanks!
>
> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
>> { AR5K_PHY(14),
>> - { 0x00000007, 0x00000007, 0x0000000b, 0x0000000b } },
>> + { 0x00000007, 0x0000000b, 0x0000000b } },
>
> Apart from this one initval all other ar5211_ini_mode[] values between
> 802.11a and 802.11g are the same! Which means we could potentially
> save (35 lines here * 4 bytes) + (3 entries for AR5K_PHY(14) * 4) =
> 152 bytes here if we just converge 11a and 11g as just OFDM data for
> this ini array and remove AR5K_PHY(14) entry and deal with it as a
> final write. I wonder if AR5K_PHY(14) (0x9838) was a typo for 11a or
> 11g. I'll try to dig to see what this is, perhaps its not a good idea
> to move this out and set this later, not sure if this is inline for
> the rf buffer trigger stuff, I'll poke.
>
> All other ini arrays differ in more than 1 line so probably not worth mucking.
OK so upon review here is what I can determine from the above:
AR5211 supports 802.11a and 802.11b, so I suspect the 11g stuff was
kept there for testing purposes, all of that is actually unused. I say
we remove 11g stuff for AR5211 as well and save ourselves those bytes.
And for the record -- reordering the mode stuff seems fine except care
must be taken to ensure all those writes are done prior to
AR5K_PHY_ACT aka 0x981c aka AR5K_PHY(7).
The rf buffer stuff I mentioned earlier would not apply here as that
is related to other stuff.
Luis
^ permalink raw reply
* ar9271 mailing list and driver project page
From: Luis R. Rodriguez @ 2009-08-28 2:43 UTC (permalink / raw)
To: devel; +Cc: linux-wireless, linux-kernel, Greg KH, John W. Linville
I'd like to announce the ar9271 development project will make use of
the Linux driver project mailing list as it is not upstream yet.
ar9271 development now also has a home page:
http://wireless.kernel.org/en/users/Drivers/ar9271
You can subscribe to this page for updates. I've tried to do a big
brain dump on documentation from what I understand of ar9271
HTC/HIF/WMI stuff so far. If you'd like to get followups on ar9271 I
suggest you either subscribe to the wiki page or subscribe to the
Linux driver development mailing list as no patches or information
will be posted to linux-wireless until it is ready for upstream
inclusion.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Nick Kossifidis @ 2009-08-28 3:01 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bob Copeland, Pavel Roskin, ath5k-devel, linux-wireless,
John W. Linville
In-Reply-To: <43e72e890908271125x378da3abw41e7f73dd8fbfe81@mail.gmail.com>
2009/8/27 Luis R. Rodriguez <mcgrof@gmail.com>:
> On Thu, Aug 27, 2009 at 11:17 AM, Bob Copeland<bcopeland@gmail.com> wrote:
>> On Thu, Aug 27, 2009 at 8:58 AM, Nick Kossifidis<mickflemm@gmail.com> wrote:
>>> 2009/8/27 Pavel Roskin <proski@gnu.org>:
>>
>>> Current code works fine (i 've checked it against various cards),
>>> there is nothing wrong
>>> with having another function for reading turbo modes, i find it's
>>> cleaner that way.
>>
>> Well, we also don't use the turbo modes at all and that's where the
>> error is (IIRC) so it shouldn't have any impact. :)
>
> Again, why don't we just remove all that fucking turbo cruft?
>
> Luis
>
Why should we remove it, we are discussing on implementing channel
width setting for 5 and 10 MHz channels already so where is the
problem supporting turbo mode (40MHz) ?
Also EEPROM code should read the eeprom and fill the structs, since
these infos are there we should read them, i don't see any reason to
skip them, i thought our goal was to support this hw as much as
possible, if we want to get rid of MadWiFi we 'll have to at least
support 5, 10 and 40MHz (turbo) channels. I understand that there is
no support yet on mac80211/cfg80211 but i don't think removing all
this stuff and bring it back is the right thing to do.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Nick Kossifidis @ 2009-08-28 3:06 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bob Copeland, proski, ath5k-devel, linux-wireless,
John W. Linville, ic.felix
In-Reply-To: <43e72e890908271709u288eaef9g23bcf077038a310f@mail.gmail.com>
2009/8/28 Luis R. Rodriguez <mcgrof@gmail.com>:
> On Thu, Aug 27, 2009 at 4:14 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Thu, Aug 27, 2009 at 2:39 PM, Bob Copeland<me@bobcopeland.com> wrote:
>>> On Thu, Aug 27, 2009 at 11:25:03AM -0700, Luis R. Rodriguez wrote:
>>>> > Well, we also don't use the turbo modes at all and that's where the
>>>> > error is (IIRC) so it shouldn't have any impact. :)
>>>>
>>>> Again, why don't we just remove all that fucking turbo cruft?
>>>
>>> OK with me since no one seems to care enough to implement mac80211
>>> support. I left some of the #defines in place as they are useful
>>> documentation. Approx. 80 of the lines removed are comments.
>>>
>>> text data bss dec hex filename
>>> 136746 480 56 137282 21842 ath5k_old.ko
>>> 134913 480 56 135449 21119 ath5k_new.ko
>>>
>>> Disclaimer: only barely tested.
>>
>> Sexy, thanks!
>>
>> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>>
>>> { AR5K_PHY(14),
>>> - { 0x00000007, 0x00000007, 0x0000000b, 0x0000000b } },
>>> + { 0x00000007, 0x0000000b, 0x0000000b } },
>>
>> Apart from this one initval all other ar5211_ini_mode[] values between
>> 802.11a and 802.11g are the same! Which means we could potentially
>> save (35 lines here * 4 bytes) + (3 entries for AR5K_PHY(14) * 4) =
>> 152 bytes here if we just converge 11a and 11g as just OFDM data for
>> this ini array and remove AR5K_PHY(14) entry and deal with it as a
>> final write. I wonder if AR5K_PHY(14) (0x9838) was a typo for 11a or
>> 11g. I'll try to dig to see what this is, perhaps its not a good idea
>> to move this out and set this later, not sure if this is inline for
>> the rf buffer trigger stuff, I'll poke.
>>
>> All other ini arrays differ in more than 1 line so probably not worth mucking.
>
> OK so upon review here is what I can determine from the above:
>
> AR5211 supports 802.11a and 802.11b, so I suspect the 11g stuff was
> kept there for testing purposes, all of that is actually unused. I say
> we remove 11g stuff for AR5211 as well and save ourselves those bytes.
AR5211 supports draft g (ofdm only) so these values are correct, we
currently don't support draft g on mac80211 but again i don't see why
we should remove all this data, Atheros hasn't removed any of this
from their HAL neither Sam (and MadWiFi/ath both support draft g
-pureg- operation).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Nick Kossifidis @ 2009-08-28 3:17 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <40f31dec0908270558y2a3a565bvcc7e470b7f2644c6@mail.gmail.com>
2009/8/27 Nick Kossifidis <mickflemm@gmail.com>:
> 2009/8/27 Pavel Roskin <proski@gnu.org>:
>> The `val' variable in ath5k_eeprom_read_turbo_modes() is used
>> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
>> it:
>>
>> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
>> eeprom.c:441: warning: 'val' may be used uninitialized in this function
>>
>> Comparing the code to the Atheros HAL, it's clear that the split between
>> ath5k_eeprom_read_modes() and ath5k_eeprom_read_turbo_modes() was
>> incorrect.
>>
>> The Atheros HAL reads both turbo and non-turbo data from EEPROM in one
>> function. Some turbo mode parameters are derived from the same EEPROM
>> values as non-turbo parameters, just from different bits.
>>
>> Merge ath5k_eeprom_read_turbo_modes() into ath5k_eeprom_read_modes() to
>> fix the warning. The actual values and offsets have been cross-checked
>> against Atheros HAL.
>>
>> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> Current code works fine (i 've checked it against various cards),
> there is nothing wrong
> with having another function for reading turbo modes, i find it's
> cleaner that way.
>
> Just change
>
> u16 val;
>
> to
>
> u16 val = 0;
>
> and it should be fine.
>
Ouch seems my local tree and current wireless-testing are out of sync
or something, yup compiler is right
you' ll need to put a
AR5K_EEPROM_READ(o, val);
before the switch.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* ipw2200: firmware DMA loading rework
From: Zhu Yi @ 2009-08-28 3:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, netdev@vger.kernel.org,
linux-mm@kvack.org, James Ketrenos, Chatre, Reinette,
linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090826074409.606b5124.akpm@linux-foundation.org>
Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
likely to fail and should always be avoided.
The patch fixes this problem by replacing the original order-6
pci_alloc_consistent() with an array of order-1 pages from a pci pool.
This utilized the ipw2200 DMA command blocks (up to 64 slots). The
maximum firmware size support remains the same (64*8K).
This patch fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14016
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/ipw2x00/ipw2200.c | 120 ++++++++++++++++++--------------
1 files changed, 67 insertions(+), 53 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 6dcac73..f593fbb 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -2874,45 +2874,27 @@ static int ipw_fw_dma_add_command_block(struct ipw_priv *priv,
return 0;
}
-static int ipw_fw_dma_add_buffer(struct ipw_priv *priv,
- u32 src_phys, u32 dest_address, u32 length)
+static int ipw_fw_dma_add_buffer(struct ipw_priv *priv, dma_addr_t *src_address,
+ int nr, u32 dest_address, u32 len)
{
- u32 bytes_left = length;
- u32 src_offset = 0;
- u32 dest_offset = 0;
- int status = 0;
+ int ret, i;
+ u32 size;
+
IPW_DEBUG_FW(">> \n");
- IPW_DEBUG_FW_INFO("src_phys=0x%x dest_address=0x%x length=0x%x\n",
- src_phys, dest_address, length);
- while (bytes_left > CB_MAX_LENGTH) {
- status = ipw_fw_dma_add_command_block(priv,
- src_phys + src_offset,
- dest_address +
- dest_offset,
- CB_MAX_LENGTH, 0, 0);
- if (status) {
+ IPW_DEBUG_FW_INFO("nr=%d dest_address=0x%x len=0x%x\n",
+ nr, dest_address, len);
+
+ for (i = 0; i < nr; i++) {
+ size = min_t(u32, len - i * CB_MAX_LENGTH, CB_MAX_LENGTH);
+ ret = ipw_fw_dma_add_command_block(priv, src_address[i],
+ dest_address +
+ i * CB_MAX_LENGTH, size,
+ 0, 0);
+ if (ret) {
IPW_DEBUG_FW_INFO(": Failed\n");
return -1;
} else
IPW_DEBUG_FW_INFO(": Added new cb\n");
-
- src_offset += CB_MAX_LENGTH;
- dest_offset += CB_MAX_LENGTH;
- bytes_left -= CB_MAX_LENGTH;
- }
-
- /* add the buffer tail */
- if (bytes_left > 0) {
- status =
- ipw_fw_dma_add_command_block(priv, src_phys + src_offset,
- dest_address + dest_offset,
- bytes_left, 0, 0);
- if (status) {
- IPW_DEBUG_FW_INFO(": Failed on the buffer tail\n");
- return -1;
- } else
- IPW_DEBUG_FW_INFO
- (": Adding new cb - the buffer tail\n");
}
IPW_DEBUG_FW("<< \n");
@@ -3160,59 +3142,91 @@ static int ipw_load_ucode(struct ipw_priv *priv, u8 * data, size_t len)
static int ipw_load_firmware(struct ipw_priv *priv, u8 * data, size_t len)
{
- int rc = -1;
+ int ret = -1;
int offset = 0;
struct fw_chunk *chunk;
- dma_addr_t shared_phys;
- u8 *shared_virt;
+ int total_nr = 0;
+ int i;
+ struct pci_pool *pool;
+ u32 *virts[CB_NUMBER_OF_ELEMENTS_SMALL];
+ dma_addr_t phys[CB_NUMBER_OF_ELEMENTS_SMALL];
IPW_DEBUG_TRACE("<< : \n");
- shared_virt = pci_alloc_consistent(priv->pci_dev, len, &shared_phys);
- if (!shared_virt)
+ pool = pci_pool_create("ipw2200", priv->pci_dev, CB_MAX_LENGTH, 0, 0);
+ if (!pool) {
+ IPW_ERROR("pci_pool_create failed\n");
return -ENOMEM;
-
- memmove(shared_virt, data, len);
+ }
/* Start the Dma */
- rc = ipw_fw_dma_enable(priv);
+ ret = ipw_fw_dma_enable(priv);
/* the DMA is already ready this would be a bug. */
BUG_ON(priv->sram_desc.last_cb_index > 0);
do {
+ u32 chunk_len;
+ u8 *start;
+ int size;
+ int nr = 0;
+
chunk = (struct fw_chunk *)(data + offset);
offset += sizeof(struct fw_chunk);
+ chunk_len = le32_to_cpu(chunk->length);
+ start = data + offset;
+
+ nr = (chunk_len + CB_MAX_LENGTH - 1) / CB_MAX_LENGTH;
+ for (i = 0; i < nr; i++) {
+ virts[total_nr] = pci_pool_alloc(pool, GFP_KERNEL,
+ &phys[total_nr]);
+ if (!virts[total_nr]) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ size = min_t(u32, chunk_len - i * CB_MAX_LENGTH,
+ CB_MAX_LENGTH);
+ memcpy(virts[total_nr], start, size);
+ start += size;
+ total_nr++;
+ /* We don't support fw chunk larger than 64*8K */
+ BUG_ON(total_nr > CB_NUMBER_OF_ELEMENTS_SMALL);
+ }
+
/* build DMA packet and queue up for sending */
/* dma to chunk->address, the chunk->length bytes from data +
* offeset*/
/* Dma loading */
- rc = ipw_fw_dma_add_buffer(priv, shared_phys + offset,
- le32_to_cpu(chunk->address),
- le32_to_cpu(chunk->length));
- if (rc) {
+ ret = ipw_fw_dma_add_buffer(priv, &phys[total_nr - nr],
+ nr, le32_to_cpu(chunk->address),
+ chunk_len);
+ if (ret) {
IPW_DEBUG_INFO("dmaAddBuffer Failed\n");
goto out;
}
- offset += le32_to_cpu(chunk->length);
+ offset += chunk_len;
} while (offset < len);
/* Run the DMA and wait for the answer */
- rc = ipw_fw_dma_kick(priv);
- if (rc) {
+ ret = ipw_fw_dma_kick(priv);
+ if (ret) {
IPW_ERROR("dmaKick Failed\n");
goto out;
}
- rc = ipw_fw_dma_wait(priv);
- if (rc) {
+ ret = ipw_fw_dma_wait(priv);
+ if (ret) {
IPW_ERROR("dmaWaitSync Failed\n");
goto out;
}
- out:
- pci_free_consistent(priv->pci_dev, len, shared_virt, shared_phys);
- return rc;
+ out:
+ for (i = 0; i < total_nr; i++)
+ pci_pool_free(pool, virts[i], phys[i]);
+
+ pci_pool_destroy(pool);
+
+ return ret;
}
/* stop nic */
--
1.5.3.6
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Luis R. Rodriguez @ 2009-08-28 3:57 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Bob Copeland, Pavel Roskin, ath5k-devel, linux-wireless,
John W. Linville
In-Reply-To: <40f31dec0908272001u1a67cbf3ycc5d9588dd48915d@mail.gmail.com>
On Thu, Aug 27, 2009 at 8:01 PM, Nick Kossifidis<mickflemm@gmail.com> wrote:
> 2009/8/27 Luis R. Rodriguez <mcgrof@gmail.com>:
>> On Thu, Aug 27, 2009 at 11:17 AM, Bob Copeland<bcopeland@gmail.com> wrote:
>>> On Thu, Aug 27, 2009 at 8:58 AM, Nick Kossifidis<mickflemm@gmail.com> wrote:
>>>> 2009/8/27 Pavel Roskin <proski@gnu.org>:
>>>
>>>> Current code works fine (i 've checked it against various cards),
>>>> there is nothing wrong
>>>> with having another function for reading turbo modes, i find it's
>>>> cleaner that way.
>>>
>>> Well, we also don't use the turbo modes at all and that's where the
>>> error is (IIRC) so it shouldn't have any impact. :)
>>
>> Again, why don't we just remove all that fucking turbo cruft?
>>
>> Luis
>>
>
> Why should we remove it, we are discussing on implementing channel
> width setting for 5 and 10 MHz channels already so where is the
> problem supporting turbo mode (40MHz) ?
Supporting 5 MHz and 10 MHz channels is very different than supporting
Turbo (40 MHz). 5 MHz and 10 MHz channels seems to be something you
can use as per 802.11, 40 MHz "Turbo" stuff is just a vendor extension
and at least by my part I don't want to move a finger to either
support it nor do I think its a good idea to support it. Other people
have objected to vendor extensions before on mac80211 so I don't think
you'll find much support for this from a lot of people.
The way I see is if you want vendor extensions like Atheros Turbo or
XR use MadWifi.
> Also EEPROM code should read the eeprom and fill the structs, since
> these infos are there we should read them, i don't see any reason to
> skip them
I didn't see Bob's patch remove that stuff. Its pointless to use it though.
> i thought our goal was to support this hw as much as
> possible,
We should support users as best as possible, whether or not you
support vendor extensions is an entirely different story.
> if we want to get rid of MadWiFi we 'll have to at least
> support 5, 10 and 40MHz (turbo) channels.
I don't want to get rid of MadWifi, what we have now is a proper
upstream replacement. MadWifi is still a hack put together, and people
who want hacks can use that.
> I understand that there is
> no support yet on mac80211/cfg80211 but i don't think removing all
> this stuff and bring it back is the right thing to do.
I don't expect it will come back.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Nick Kossifidis @ 2009-08-28 4:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bob Copeland, Pavel Roskin, ath5k-devel, linux-wireless,
John W. Linville
In-Reply-To: <43e72e890908272057s28ee11c6x624e8a08c6bd17e9@mail.gmail.com>
2009/8/28 Luis R. Rodriguez <mcgrof@gmail.com>:
> On Thu, Aug 27, 2009 at 8:01 PM, Nick Kossifidis<mickflemm@gmail.com> wrote:
>> 2009/8/27 Luis R. Rodriguez <mcgrof@gmail.com>:
>>> On Thu, Aug 27, 2009 at 11:17 AM, Bob Copeland<bcopeland@gmail.com> wrote:
>>>> On Thu, Aug 27, 2009 at 8:58 AM, Nick Kossifidis<mickflemm@gmail.com> wrote:
>>>>> 2009/8/27 Pavel Roskin <proski@gnu.org>:
>>>>
>>>>> Current code works fine (i 've checked it against various cards),
>>>>> there is nothing wrong
>>>>> with having another function for reading turbo modes, i find it's
>>>>> cleaner that way.
>>>>
>>>> Well, we also don't use the turbo modes at all and that's where the
>>>> error is (IIRC) so it shouldn't have any impact. :)
>>>
>>> Again, why don't we just remove all that fucking turbo cruft?
>>>
>>> Luis
>>>
>>
>> Why should we remove it, we are discussing on implementing channel
>> width setting for 5 and 10 MHz channels already so where is the
>> problem supporting turbo mode (40MHz) ?
>
> Supporting 5 MHz and 10 MHz channels is very different than supporting
> Turbo (40 MHz). 5 MHz and 10 MHz channels seems to be something you
> can use as per 802.11, 40 MHz "Turbo" stuff is just a vendor extension
> and at least by my part I don't want to move a finger to either
> support it nor do I think its a good idea to support it. Other people
> have objected to vendor extensions before on mac80211 so I don't think
> you'll find much support for this from a lot of people.
>
Many people use turbo mode and it's not an ugly proprietary extension, static
turbo mode is close to just having 40MHz channels, we can use the same way to
switch to it as with 5 and 10MHz channels. The difficult part is
having dynamic turbo
(supporting 20MHz and 40MHz stations at the same time) but we don't deal with it
anyway (and it's only useful on ap mode).
Most code is there, we are ready to support 5/10/40MHz channels on the
driver part
as soon as we are done with cfg80211/mac80211 compatibility so why drop it ?
> The way I see is if you want vendor extensions like Atheros Turbo or
> XR use MadWifi.
>
XR is not supported on MadWiFi, i remember only some parts were supported +
we don't have much to work with anyway (XR code is missing from Legacy and
Sam's HAL) + not many people use it anyway so i agree we can drop it but it's
nothing like turbo mode, as i said many people use that.
>> Also EEPROM code should read the eeprom and fill the structs, since
>> these infos are there we should read them, i don't see any reason to
>> skip them
>
> I didn't see Bob's patch remove that stuff. Its pointless to use it though.
>
It can be confusing (offsets missing etc) + we might want to put eeprom infos
on debugfs (i had an ugly patch just for that) for debuging.
>> i thought our goal was to support this hw as much as
>> possible,
>
> We should support users as best as possible, whether or not you
> support vendor extensions is an entirely different story.
>
>> if we want to get rid of MadWiFi we 'll have to at least
>> support 5, 10 and 40MHz (turbo) channels.
>
> I don't want to get rid of MadWifi, what we have now is a proper
> upstream replacement. MadWifi is still a hack put together, and people
> who want hacks can use that.
>
Having multiple drivers won't help users, i thought that MadWiFi was "dead"
and we were working on a complete alternative.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Luis R. Rodriguez @ 2009-08-28 5:21 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Bob Copeland, Pavel Roskin, ath5k-devel, linux-wireless,
John W. Linville
In-Reply-To: <40f31dec0908272117s27b3a59ep5f18c85aa179793d@mail.gmail.com>
On Thu, Aug 27, 2009 at 9:17 PM, Nick Kossifidis<mickflemm@gmail.com> wrote:
> Many people use turbo mode and it's not an ugly proprietary extension, static
> turbo mode is close to just having 40MHz channels,
Its not following any spec and I suspect it will create pretty noise
on existing wireless networks. 11n has at least some precautions to
try to be friendly, such as trying using primary and extension
channels to match nearby APs. I don't believe Atheros Turbo has such
things.
> we can use the same way to
> switch to it as with 5 and 10MHz channels.
5 and 10 MHz seem to be defined and used as per 802.11 and those seem
reasonable to support.
> Most code is there, we are ready to support 5/10/40MHz channels on the
> driver part
Great.
> as soon as we are done with cfg80211/mac80211 compatibility so why drop it ?
We can drop Turbo, but it seems reasonable to keep 5 MHz and 10 MHz support.
> Having multiple drivers won't help users, i thought that MadWiFi was "dead"
> and we were working on a complete alternative.
MadWifi is dead.
Luis
^ permalink raw reply
* Re: ar9271 mailing list and driver project page
From: Holger Schurig @ 2009-08-28 7:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: devel, linux-wireless, linux-kernel, Greg KH
In-Reply-To: <43e72e890908271943s6dca1257g1f1e56d0347cc21d@mail.gmail.com>
> ar9271 and ar9170 seem to share a few things, one of which is
> firmware upload. ar9271's firmware upload routine was modified
> to make it match ar9170's as much as possible to share it on
> ath.ko
Is it true that most devices which will use ath.ko won't ever use
firmware uploading? It's only a few Ath-USB devices, so maybe
you could do an ath_fw.ko for this.
(Somebody who's always working with embedded devices and likes to
keeps small :-)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: initialize rate control after station inserted
From: Johannes Berg @ 2009-08-28 7:45 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linville, linux-wireless
In-Reply-To: <1251416094-10420-1-git-send-email-reinette.chatre@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
Hi,
Thanks. I'll comment on both patches together. Can you please also tell
us what the problem is this is solving? I'm a bit lost.
I think both of these patches should just rolled into one since this is
also a mac80211 patch -- even if it's for the bit that interacts with
cfg80211.
However, I don't think I actually understand the changes.
> sta_apply_parameters(local, sta, params);
>
> - rate_control_rate_init(sta);
> -
> layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
> sdata->vif.type == NL80211_IFTYPE_AP;
>
> @@ -742,13 +740,17 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
> if (err == -EEXIST && layer2_update) {
> /* Need to update layer 2 devices on reassociation */
> sta = sta_info_get(local, mac);
> - if (sta)
> + if (sta) {
> + rate_control_rate_init(sta);
> ieee80211_send_layer2_update(sta);
> + }
> }
Why is this necessary? It should already have been called for this
station earlier?
> rcu_read_unlock();
> return err;
> }
>
> + rate_control_rate_init(sta);
> +
Also, I don't see anything between the old place that it was called and
the new place you're moving it to that could possibly change the station
parameters?
Same in ibss.c (not quoting it here) where you're only moving it to
after sta_info_insert() -- all that seems to do is add race conditions,
allowing other code to find not-yet-initialised stations.
So the only place I could see a change being necessary would be mlme.c,
but then only moving rate_control_rate_init() to after the flags
settings, not to after the insert.
Am I missing something?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 13/13] wl1271: added Juuso Oikarinen as module author
From: Luciano Coelho @ 2009-08-28 9:01 UTC (permalink / raw)
To: ext Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D-MSW/Tampere),
Valo Kalle (Nokia-D/Tampere)
In-Reply-To: <1251408741.22482.14.camel@johannes.local>
ext Johannes Berg wrote:
> On Fri, 2009-08-28 at 00:00 +0300, Luciano Coelho wrote:
>
>> Add Juuso as one of the module authors, since he's working heavily on this
>> module as well.
>>
>> Cc: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
>> ---
>> drivers/net/wireless/wl12xx/wl1271_main.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
>> index a97d434..4163eac 100644
>> --- a/drivers/net/wireless/wl12xx/wl1271_main.c
>> +++ b/drivers/net/wireless/wl12xx/wl1271_main.c
>> @@ -1449,4 +1449,5 @@ module_init(wl1271_init);
>> module_exit(wl1271_exit);
>>
>> MODULE_LICENSE("GPL");
>> -MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
>> +MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>, "
>> + "Juuso Oikarinen <juuso.oikarinen@nokia.com>");
>>
>
> Use multiple MODULE_AUTHORs instead.
>
Is that the right way to do it? At least in include/linux/module.h it
says this:
/* Author, ideally of form NAME[, NAME]*[ and NAME] */
#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
As I interpret it, it means that there should be one MODULE_AUTHOR with
a string that contains all the names. So actually the right way to do
it would be this:
MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com> and "
"Juuso Oikarinen <juuso.oikarinen@nokia.com>");
Or am I missing/misinterpreting something?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 13/13] wl1271: added Juuso Oikarinen as module author
From: Johannes Berg @ 2009-08-28 9:10 UTC (permalink / raw)
To: Luciano Coelho
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D-MSW/Tampere),
Valo Kalle (Nokia-D/Tampere)
In-Reply-To: <4A979D06.2000205@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Fri, 2009-08-28 at 12:01 +0300, Luciano Coelho wrote:
> Is that the right way to do it? At least in include/linux/module.h it
> says this:
>
> /* Author, ideally of form NAME[, NAME]*[ and NAME] */
> #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
Interesting, but I suspect that should just be changed.
If you use multiple MODULE_AUTHOR, they will be shown as such:
$ /sbin/modinfo ar9170usb | grep author
author: Christian Lamparter <chunkeey@web.de>
author: Johannes Berg <johannes@sipsolutions.net>
If you use just one, it would be one long author: line with all of them.
I think the multiple line case is much nicer.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 13/13] wl1271: added Juuso Oikarinen as module author
From: Luciano Coelho @ 2009-08-28 9:27 UTC (permalink / raw)
To: ext Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D-MSW/Tampere),
Valo Kalle (Nokia-D/Tampere)
In-Reply-To: <1251450604.3456.1.camel@johannes.local>
ext Johannes Berg wrote:
> On Fri, 2009-08-28 at 12:01 +0300, Luciano Coelho wrote:
>
>
>> Is that the right way to do it? At least in include/linux/module.h it
>> says this:
>>
>> /* Author, ideally of form NAME[, NAME]*[ and NAME] */
>> #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
>>
>
> Interesting, but I suspect that should just be changed.
>
> If you use multiple MODULE_AUTHOR, they will be shown as such:
>
> $ /sbin/modinfo ar9170usb | grep author
> author: Christian Lamparter <chunkeey@web.de>
> author: Johannes Berg <johannes@sipsolutions.net>
>
>
> If you use just one, it would be one long author: line with all of them.
> I think the multiple line case is much nicer.
>
Yes, I totally agree with you. I'll use multiple MODULE_AUTHOR()s. ;)
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 1/8] rndis_wlan: ignore OID_802_11_ADD_KEY triggered media connect indications
From: Jussi Kivilinna @ 2009-08-28 9:58 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Setting WPA keys with OID_802_11_ADD_KEY sometimes trigger
instant media connect indication. These indications are extranous and
should be ignored, as otherwise driver would send reassociation event to
userspace which in this case is not needed.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index f181b00..612c2c7 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -470,6 +470,7 @@ struct rndis_wlan_private {
int radio_on;
int infra_mode;
struct ndis_80211_ssid essid;
+ __le32 current_command_oid;
/* encryption stuff */
int encr_tx_key_index;
@@ -665,7 +666,9 @@ static int rndis_query_oid(struct usbnet *dev, __le32 oid, void *data, int *len)
u.get->msg_len = cpu_to_le32(sizeof *u.get);
u.get->oid = oid;
+ priv->current_command_oid = oid;
ret = rndis_command(dev, u.header, buflen);
+ priv->current_command_oid = 0;
if (ret < 0)
devdbg(dev, "rndis_query_oid(%s): rndis_command() failed, %d "
"(%08x)", oid_to_string(oid), ret,
@@ -725,7 +728,9 @@ static int rndis_set_oid(struct usbnet *dev, __le32 oid, void *data, int len)
u.set->handle = cpu_to_le32(0);
memcpy(u.buf + sizeof(*u.set), data, len);
+ priv->current_command_oid = oid;
ret = rndis_command(dev, u.header, buflen);
+ priv->current_command_oid = 0;
if (ret < 0)
devdbg(dev, "rndis_set_oid(%s): rndis_command() failed, %d "
"(%08x)", oid_to_string(oid), ret,
@@ -760,6 +765,7 @@ static int rndis_reset(struct usbnet *usbdev)
memset(reset, 0, sizeof(*reset));
reset->msg_type = RNDIS_MSG_RESET;
reset->msg_len = cpu_to_le32(sizeof(*reset));
+ priv->current_command_oid = 0;
ret = rndis_command(usbdev, (void *)reset, CONTROL_BUFFER_SIZE);
mutex_unlock(&priv->command_lock);
@@ -2558,6 +2564,17 @@ static void rndis_wlan_indication(struct usbnet *usbdev, void *ind, int buflen)
switch (msg->status) {
case RNDIS_STATUS_MEDIA_CONNECT:
+ if (priv->current_command_oid == OID_802_11_ADD_KEY) {
+ /* OID_802_11_ADD_KEY causes sometimes extra
+ * "media connect" indications which confuses driver
+ * and userspace to think that device is
+ * roaming/reassociating when it isn't.
+ */
+ devdbg(usbdev, "ignored OID_802_11_ADD_KEY triggered "
+ "'media connect'");
+ return;
+ }
+
usbnet_pause_rx(usbdev);
devinfo(usbdev, "media connect");
^ permalink raw reply related
* [PATCH 2/8] rndis_wlan: get bssid scan list before new scan
From: Jussi Kivilinna @ 2009-08-28 9:58 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
OID_802_11_BSSID_LIST_SCAN clears device's bssid list, so retrieve
current bssid list from device before issuing new scan.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 612c2c7..3779621 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -926,6 +926,7 @@ static int freq_to_dsconfig(struct iw_freq *freq, unsigned int *dsconfig)
* common functions
*/
static void restore_keys(struct usbnet *usbdev);
+static int rndis_check_bssid_list(struct usbnet *usbdev);
static int get_essid(struct usbnet *usbdev, struct ndis_80211_ssid *ssid)
{
@@ -1616,6 +1617,11 @@ static int rndis_scan(struct wiphy *wiphy, struct net_device *dev,
devdbg(usbdev, "cfg80211.scan");
+ /* Get current bssid list from device before new scan, as new scan
+ * clears internal bssid list.
+ */
+ rndis_check_bssid_list(usbdev);
+
if (!request)
return -EINVAL;
^ permalink raw reply related
* [PATCH 3/8] rndis_wlan: resize bssid list if too small
From: Jussi Kivilinna @ 2009-08-28 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
Buffer used for bssid list might be too small. Change rndis_query_oid()
to return required buffer length to caller and make rndis_check_bssid_list()
resize buffer when needed.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 3779621..2309ad2 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -676,7 +676,8 @@ static int rndis_query_oid(struct usbnet *dev, __le32 oid, void *data, int *len)
if (ret == 0) {
ret = le32_to_cpu(u.get_c->len);
- *len = (*len > ret) ? ret : *len;
+ if (ret > *len)
+ *len = ret;
memcpy(data, u.buf + le32_to_cpu(u.get_c->offset) + 8, *len);
ret = rndis_error_status(u.get_c->status);
@@ -1656,6 +1657,9 @@ static struct cfg80211_bss *rndis_bss_info_update(struct usbnet *usbdev,
int ie_len, bssid_len;
u8 *ie;
+ devdbg(usbdev, " found bssid: '%.32s' [%pM]", bssid->ssid.essid,
+ bssid->mac);
+
/* parse bssid structure */
bssid_len = le32_to_cpu(bssid->length);
@@ -1695,10 +1699,12 @@ static int rndis_check_bssid_list(struct usbnet *usbdev)
struct ndis_80211_bssid_list_ex *bssid_list;
struct ndis_80211_bssid_ex *bssid;
int ret = -EINVAL, len, count, bssid_len;
+ bool resized = false;
devdbg(usbdev, "check_bssid_list");
len = CONTROL_BUFFER_SIZE;
+resize_buf:
buf = kmalloc(len, GFP_KERNEL);
if (!buf) {
ret = -ENOMEM;
@@ -1709,11 +1715,18 @@ static int rndis_check_bssid_list(struct usbnet *usbdev)
if (ret != 0)
goto out;
+ if (!resized && len > CONTROL_BUFFER_SIZE) {
+ resized = true;
+ kfree(buf);
+ goto resize_buf;
+ }
+
bssid_list = buf;
bssid = bssid_list->bssid;
bssid_len = le32_to_cpu(bssid->length);
count = le32_to_cpu(bssid_list->num_items);
- devdbg(usbdev, "check_bssid_list: %d BSSIDs found", count);
+ devdbg(usbdev, "check_bssid_list: %d BSSIDs found (buflen: %d)", count,
+ len);
while (count && ((void *)bssid + bssid_len) <= (buf + len)) {
rndis_bss_info_update(usbdev, bssid);
^ permalink raw reply related
* [PATCH 4/8] rndis_wlan: increase scan timer delay
From: Jussi Kivilinna @ 2009-08-28 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
Increase scan delay from 1 sec to 6 sec. Spec says that scan by
OID_802_11_BSSID_LIST_SCAN completes in 6 seconds.
Before rfkill patch too short delay was not problem as device was
always active (radio on) and performing background scanning.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 2309ad2..cb362b0 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1607,7 +1607,7 @@ static int rndis_get_tx_power(struct wiphy *wiphy, int *dbm)
}
-#define SCAN_DELAY_JIFFIES (HZ)
+#define SCAN_DELAY_JIFFIES (6 * HZ)
static int rndis_scan(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_scan_request *request)
{
^ permalink raw reply related
* [PATCH 5/8] rndis_wlan: move link up/down work to separate functions
From: Jussi Kivilinna @ 2009-08-28 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
Move link up/down work to separate functions and use local array
for allocating memory for info structure instead of kzmalloc.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 101 ++++++++++++++++++++-----------------
1 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index cb362b0..dc3083b 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -2319,68 +2319,77 @@ static const struct iw_handler_def rndis_iw_handlers = {
};
-static void rndis_wlan_worker(struct work_struct *work)
+static void rndis_wlan_do_link_up_work(struct usbnet *usbdev)
{
- struct rndis_wlan_private *priv =
- container_of(work, struct rndis_wlan_private, work);
- struct usbnet *usbdev = priv->usbdev;
- union iwreq_data evt;
- unsigned char bssid[ETH_ALEN];
struct ndis_80211_assoc_info *info;
- int assoc_size = sizeof(*info) + IW_CUSTOM_MAX + 32;
+ union iwreq_data evt;
+ u8 assoc_buf[sizeof(*info) + IW_CUSTOM_MAX + 32];
+ u8 bssid[ETH_ALEN];
int ret, offset;
- if (test_and_clear_bit(WORK_LINK_UP, &priv->work_pending)) {
- netif_carrier_on(usbdev->net);
-
- info = kzalloc(assoc_size, GFP_KERNEL);
- if (!info)
- goto get_bssid;
-
- /* Get association info IEs from device and send them back to
- * userspace. */
- ret = get_association_info(usbdev, info, assoc_size);
- if (!ret) {
- evt.data.length = le32_to_cpu(info->req_ie_length);
- if (evt.data.length > 0) {
- offset = le32_to_cpu(info->offset_req_ies);
- wireless_send_event(usbdev->net,
- IWEVASSOCREQIE, &evt,
- (char *)info + offset);
- }
-
- evt.data.length = le32_to_cpu(info->resp_ie_length);
- if (evt.data.length > 0) {
- offset = le32_to_cpu(info->offset_resp_ies);
- wireless_send_event(usbdev->net,
- IWEVASSOCRESPIE, &evt,
- (char *)info + offset);
- }
+ memset(assoc_buf, 0, sizeof(assoc_buf));
+ info = (void *)assoc_buf;
+
+ netif_carrier_on(usbdev->net);
+
+ /* Get association info IEs from device and send them back to
+ * userspace. */
+ ret = get_association_info(usbdev, info, sizeof(assoc_buf));
+ if (!ret) {
+ evt.data.length = le32_to_cpu(info->req_ie_length);
+ if (evt.data.length > 0) {
+ offset = le32_to_cpu(info->offset_req_ies);
+ wireless_send_event(usbdev->net,
+ IWEVASSOCREQIE, &evt,
+ (char *)info + offset);
}
- kfree(info);
-
-get_bssid:
- ret = get_bssid(usbdev, bssid);
- if (!ret) {
- evt.data.flags = 0;
- evt.data.length = 0;
- memcpy(evt.ap_addr.sa_data, bssid, ETH_ALEN);
- wireless_send_event(usbdev->net, SIOCGIWAP, &evt, NULL);
+ evt.data.length = le32_to_cpu(info->resp_ie_length);
+ if (evt.data.length > 0) {
+ offset = le32_to_cpu(info->offset_resp_ies);
+ wireless_send_event(usbdev->net,
+ IWEVASSOCRESPIE, &evt,
+ (char *)info + offset);
}
usbnet_resume_rx(usbdev);
}
- if (test_and_clear_bit(WORK_LINK_DOWN, &priv->work_pending)) {
- netif_carrier_off(usbdev->net);
-
+ ret = get_bssid(usbdev, bssid);
+ if (!ret) {
evt.data.flags = 0;
evt.data.length = 0;
- memset(evt.ap_addr.sa_data, 0, ETH_ALEN);
+ memcpy(evt.ap_addr.sa_data, bssid, ETH_ALEN);
wireless_send_event(usbdev->net, SIOCGIWAP, &evt, NULL);
}
+ usbnet_resume_rx(usbdev);
+}
+
+static void rndis_wlan_do_link_down_work(struct usbnet *usbdev)
+{
+ union iwreq_data evt;
+
+ netif_carrier_off(usbdev->net);
+
+ evt.data.flags = 0;
+ evt.data.length = 0;
+ memset(evt.ap_addr.sa_data, 0, ETH_ALEN);
+ wireless_send_event(usbdev->net, SIOCGIWAP, &evt, NULL);
+}
+
+static void rndis_wlan_worker(struct work_struct *work)
+{
+ struct rndis_wlan_private *priv =
+ container_of(work, struct rndis_wlan_private, work);
+ struct usbnet *usbdev = priv->usbdev;
+
+ if (test_and_clear_bit(WORK_LINK_UP, &priv->work_pending))
+ rndis_wlan_do_link_up_work(usbdev);
+
+ if (test_and_clear_bit(WORK_LINK_DOWN, &priv->work_pending))
+ rndis_wlan_do_link_down_work(usbdev);
+
if (test_and_clear_bit(WORK_SET_MULTICAST_LIST, &priv->work_pending))
set_multicast_list(usbdev);
}
^ permalink raw reply related
* [PATCH 6/8] rndis_wlan: use is_zero_ether_addr() and is_broadcast_ether_addr()
From: Jussi Kivilinna @ 2009-08-28 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
Use is_zero_ether_addr() and is_broadcast_ether_addr() instead of
memcmp against ffff_bssid/zero_bssid.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 17 ++++++-----------
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index dc3083b..c28fde5 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -514,11 +514,6 @@ static struct cfg80211_ops rndis_config_ops = {
static void *rndis_wiphy_privid = &rndis_wiphy_privid;
-static const unsigned char zero_bssid[ETH_ALEN] = {0,};
-static const unsigned char ffff_bssid[ETH_ALEN] = { 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff };
-
-
static struct rndis_wlan_private *get_rndis_wlan_priv(struct usbnet *dev)
{
return (struct rndis_wlan_private *)dev->driver_priv;
@@ -995,7 +990,7 @@ static int is_associated(struct usbnet *usbdev)
ret = get_bssid(usbdev, bssid);
- return(ret == 0 && memcmp(bssid, zero_bssid, ETH_ALEN) != 0);
+ return (ret == 0 && !is_zero_ether_addr(bssid));
}
@@ -1293,8 +1288,8 @@ static int add_wpa_key(struct usbnet *usbdev, const u8 *key, int key_len,
devdbg(usbdev, "add_wpa_key: recv seq flag without buffer");
return -EINVAL;
}
- is_addr_ok = addr && memcmp(addr, zero_bssid, ETH_ALEN) != 0 &&
- memcmp(addr, ffff_bssid, ETH_ALEN) != 0;
+ is_addr_ok = addr && !is_zero_ether_addr(addr) &&
+ !is_broadcast_ether_addr(addr);
if ((flags & NDIS_80211_ADDKEY_PAIRWISE_KEY) && !is_addr_ok) {
devdbg(usbdev, "add_wpa_key: pairwise but bssid invalid (%pM)",
addr);
@@ -1379,8 +1374,8 @@ static int restore_key(struct usbnet *usbdev, int key_idx)
/*if (priv->encr_tx_key_index == key_idx)
flags |= NDIS_80211_ADDKEY_TRANSMIT_KEY;*/
- if (memcmp(key.bssid, zero_bssid, ETH_ALEN) != 0 &&
- memcmp(key.bssid, ffff_bssid, ETH_ALEN) != 0)
+ if (!is_zero_ether_addr(key.bssid) &&
+ !is_broadcast_ether_addr(key.bssid))
flags |= NDIS_80211_ADDKEY_PAIRWISE_KEY;
return add_wpa_key(usbdev, key.material, key.len, key_idx,
@@ -1430,7 +1425,7 @@ static int remove_key(struct usbnet *usbdev, int index, u8 bssid[ETH_ALEN])
remove_key.index = cpu_to_le32(index);
if (bssid) {
/* pairwise key */
- if (memcmp(bssid, ffff_bssid, ETH_ALEN) != 0)
+ if (!is_broadcast_ether_addr(bssid))
remove_key.index |=
NDIS_80211_ADDKEY_PAIRWISE_KEY;
memcpy(remove_key.bssid, bssid,
^ permalink raw reply related
* [PATCH 7/8] rndis_wlan: set ieee80211_ptr->iftype in rndis_change_virtual_intf
From: Jussi Kivilinna @ 2009-08-28 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index c28fde5..d117620 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -1526,7 +1526,8 @@ static int rndis_change_virtual_intf(struct wiphy *wiphy,
enum nl80211_iftype type, u32 *flags,
struct vif_params *params)
{
- struct usbnet *usbdev = netdev_priv(dev);
+ struct rndis_wlan_private *priv = wiphy_priv(wiphy);
+ struct usbnet *usbdev = priv->usbdev;
int mode;
switch (type) {
@@ -1540,6 +1541,8 @@ static int rndis_change_virtual_intf(struct wiphy *wiphy,
return -EINVAL;
}
+ priv->wdev.iftype = type;
+
return set_infra_mode(usbdev, mode);
}
^ permalink raw reply related
* [PATCH 8/8] rndis_wlan: enable infrastructure before setting random essid
From: Jussi Kivilinna @ 2009-08-28 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <20090828095849.10554.58857.stgit@fate.lan>
Random essid must be set to turn on radio when not connected. If device is
in ad-hoc mode, this results 'media connect' indications with the random
essid which should be ignored.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/rndis_wlan.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index d117620..c5a674d 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -921,6 +921,7 @@ static int freq_to_dsconfig(struct iw_freq *freq, unsigned int *dsconfig)
/*
* common functions
*/
+static int set_infra_mode(struct usbnet *usbdev, int mode);
static void restore_keys(struct usbnet *usbdev);
static int rndis_check_bssid_list(struct usbnet *usbdev);
@@ -1014,6 +1015,11 @@ static int disassociate(struct usbnet *usbdev, int reset_ssid)
/* disassociate causes radio to be turned off; if reset_ssid
* is given, set random ssid to enable radio */
if (reset_ssid) {
+ /* Set device to infrastructure mode so we don't get ad-hoc
+ * 'media connect' indications with the random ssid.
+ */
+ set_infra_mode(usbdev, NDIS_80211_INFRA_INFRA);
+
ssid.length = cpu_to_le32(sizeof(ssid.essid));
get_random_bytes(&ssid.essid[2], sizeof(ssid.essid)-2);
ssid.essid[0] = 0x1;
^ 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