@@ -304,6 +304,8 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,structieee80211_tx_info*info;structsk_buff*skb;intid=result->id;+intrate=-1;+u8retries=0;/* check for id legality */if(unlikely(id>=ACX_TX_DESCRIPTORS||wl->tx_frames[id]==NULL)){
@@ -314,19 +316,22 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,skb=wl->tx_frames[id];info=IEEE80211_SKB_CB(skb);-/* update packet status */-if(!(info->flags&IEEE80211_TX_CTL_NO_ACK)){-if(result->status==TX_SUCCESS)+/* update the TX status info */+if(result->status==TX_SUCCESS){+if(!(info->flags&IEEE80211_TX_CTL_NO_ACK))info->flags|=IEEE80211_TX_STAT_ACK;-if(result->status&TX_RETRY_EXCEEDED){-/* FIXME */-/* info->status.excessive_retries = 1; */-wl->stats.excessive_retries++;-}+rate=wl1271_rate_to_idx(wl,result->rate_class_index);+retries=result->ack_failures;+}elseif(result->status==TX_RETRY_EXCEEDED){+wl->stats.excessive_retries++;+retries=result->ack_failures;}-/* FIXME */-/* info->status.retry_count = result->ack_failures; */+info->status.rates[0].idx=rate;+info->status.rates[0].count=retries;+info->status.rates[0].flags=0;+info->status.ack_signal=-1;+wl->stats.retry_count+=result->ack_failures;/* update security sequence number */
@@ -350,8 +355,6 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,result->id,skb,result->ack_failures,result->rate_class_index,result->status);-/* FIXME: do we need to tell the stack about the used rate? */-/* return the packet to the stack */ieee80211_tx_status(wl->hw,skb);wl->tx_frames[result->id]=NULL;
From: Juuso Oikarinen <redacted>
After the busy-words, if the firmware did not complete by the end of the
first (fixed) busy-word, a flip of the CS line is required to enable clocking
out the actual read data.
This patch changes the mechanism such that the CS line is flipped after each
busyword.
Also, the busy-word mechanism is finally enabled, and the number of fixed
busywords reduced to the minimum.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Teemu Paasikivi <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271.h | 9 +----
drivers/net/wireless/wl12xx/wl1271_spi.c | 67 ++++++++++-------------------
2 files changed, 24 insertions(+), 52 deletions(-)
The noise element in the ieee80211_rx_status struct has been deprecated in
commit "mac80211: deprecate RX status noise". Remove the usage of this
element from wl1271_rx.c to avoid warnings.
Signed-off-by: Luciano Coelho <redacted>
Reviewed-by: Teemu Paasikivi <redacted>
---
drivers/net/wireless/wl12xx/wl1271_rx.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
From: Juuso Oikarinen <redacted>
The wl1271 does not support disabling the connection monitor feature.
Perform the next best thing by increasing the beacon-loss threshold and
BSS_LOSE event timeout to the maximum values.
This is needed, because we really don't want any random probe-requests during
scanning or especially while in ad-hoc mode and not beaconing.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Teemu Paasikivi <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_acx.c | 18 ++++++++++++++----
drivers/net/wireless/wl12xx/wl1271_acx.h | 2 +-
drivers/net/wireless/wl12xx/wl1271_init.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_main.c | 12 +++++++++++-
4 files changed, 27 insertions(+), 7 deletions(-)
@@ -1651,6 +1651,11 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,if(ret<0)gotoout_sleep;+/* enable the connection monitoring feature */+ret=wl1271_acx_conn_monit_params(wl,true);+if(ret<0)+gotoout_sleep;+/* If we want to go in PSM but we're not there yet */if(test_bit(WL1271_FLAG_PSM_REQUESTED,&wl->flags)&&!test_bit(WL1271_FLAG_PSM,&wl->flags)){
@@ -1663,6 +1668,11 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,/* use defaults when not associated */clear_bit(WL1271_FLAG_STA_ASSOCIATED,&wl->flags);wl->aid=0;++/* disable connection monitor features */+ret=wl1271_acx_conn_monit_params(wl,false);+if(ret<0)+gotoout_sleep;}}
When forward porting some patches to upstream, there was a mistake and the
wl1271_spi driver name remained, erroneously, as "wl1271". This patch fixes
that.
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_spi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Juuso Oikarinen <redacted>
Clean up the code to convert a firmware rate class index into an index
for the rate configuration table.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Kalle Valo <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_conf.h | 26 +++++++++
drivers/net/wireless/wl12xx/wl1271_main.c | 85 +++++++++++++++++++++++++++++
drivers/net/wireless/wl12xx/wl1271_rx.c | 76 +-------------------------
drivers/net/wireless/wl12xx/wl1271_rx.h | 2 +-
4 files changed, 114 insertions(+), 75 deletions(-)
From: Juuso Oikarinen <redacted>
The driver tx-queue flush operation leaks broadcast-frames. This leak occurs
if the driver is shut down while there are frames in TX buffers (such as in
a firmware crash scenario.) Fix the leak.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Teemu Paasikivi <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_tx.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
Poll for join command completion instead of waiting blindly for 10 msecs.
There is a timeout of 100 msecs, if the command doesn't complete by then, we
return an error code.
Signed-off-by: Luciano Coelho <redacted>
Reviewed-by: Juuso Oikarinen <redacted>
---
drivers/net/wireless/wl12xx/wl1271_boot.c | 3 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 38 +++++++++++++++++++++++++----
drivers/net/wireless/wl12xx/wl1271_cmd.h | 1 +
3 files changed, 36 insertions(+), 6 deletions(-)
@@ -248,6 +249,35 @@ int wl1271_cmd_radio_parms(struct wl1271 *wl)returnret;}+/*+*Pollthemailboxeventfielduntilanyofthebitsinthemaskissetora+*timeoutoccurs(WL1271_EVENT_TIMEOUTinmsecs)+*/+staticintwl1271_cmd_wait_for_event(structwl1271*wl,u32mask)+{+u32events_vector,event;+unsignedlongtimeout;++timeout=jiffies+msecs_to_jiffies(WL1271_EVENT_TIMEOUT);++do{+if(time_after(jiffies,timeout))+return-ETIMEDOUT;++msleep(1);++/* read from both event fields */+wl1271_read(wl,wl->mbox_ptr[0],&events_vector,+sizeof(events_vector),false);+event=events_vector&mask;+wl1271_read(wl,wl->mbox_ptr[1],&events_vector,+sizeof(events_vector),false);+event|=events_vector&mask;+}while(!event);++return0;+}+intwl1271_cmd_join(structwl1271*wl,u8bss_type){staticbooldo_cal=true;
@@ -1137,10 +1140,7 @@ static int wl1271_join_channel(struct wl1271 *wl, int channel)/* pass through frames from all BSS */wl1271_configure_filters(wl,FIF_OTHER_BSS);-/* the dummy join is performed always with STATION BSS type to allow-alsoad-hocmodetolistentothesurroundingswithoutsendingany-beaconsyet.*/-ret=wl1271_cmd_join(wl,BSS_TYPE_STA_BSS);+ret=wl1271_cmd_join(wl,wl->set_bss_type);if(ret<0)gotoout;
@@ -1211,7 +1211,7 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)test_bit(WL1271_FLAG_JOINED,&wl->flags)){wl->channel=channel;/* FIXME: maybe use CMD_CHANNEL_SWITCH for this? */-ret=wl1271_cmd_join(wl,wl->bss_type);+ret=wl1271_cmd_join(wl,wl->set_bss_type);if(ret<0)wl1271_warning("cmd join to update channel failed %d",ret);
@@ -1575,13 +1575,12 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,if(ret<0)gotoout;-if(wl->bss_type==BSS_TYPE_IBSS){-/* FIXME: This implements rudimentary ad-hoc support --propertemplatesareonthewishlistandnotification-onwhentheychange.Thispatchwillupdatethetemplates-oneverycalltothisfunction.*/+if((changed&&BSS_CHANGED_BEACON)&&+(wl->bss_type==BSS_TYPE_IBSS)){structsk_buff*beacon=ieee80211_beacon_get(hw,vif);+wl1271_debug(DEBUG_ADHOC,"ad-hoc beacon updated");+if(beacon){structieee80211_hdr*hdr;
From: Juuso Oikarinen <redacted>
Configure a probe-request template to the wl1271 when associated - the
wl1271 will use this to attempt to recover a connection when beacon loss
is detected.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Luciano Coelho <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_event.c | 12 ------------
drivers/net/wireless/wl12xx/wl1271_main.c | 9 +++++++++
2 files changed, 9 insertions(+), 12 deletions(-)
From: Juuso Oikarinen <redacted>
This patch removes the MAC address randomization from the driver. This removes
a nasty Nokia-OUI dependency from the driver.
With this patch, unless an address is explicitly configured to the driver
by the user, only a zero address will be configured, and the driver will be
unable to start.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Teemu Paasikivi <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
From: Saravanan Dhanabal <redacted>
After last transmission, the device goes to sleep earlier
than the configured dynamic power save timeout. If timeout
is set to 400ms, device enters into sleep mode at around
330ms since from last TX.
This patch removes the msleep(1), which causes the delay
after ELP wakeup. Replaced with udelay(10), the variation
is around 7-10ms.
Signed-off-by: Saravanan Dhanabal <redacted>
Reviewed-by: Juuso Oikarinen <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_cmd.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
From: Juuso Oikarinen <redacted>
This patch configures the mac80211 to not perform connection monitoring
(periodic probe-requests) and instead rely on the hardware to do it.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Luciano Coelho <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
@@ -451,11 +451,15 @@ int wl1271_boot(struct wl1271 *wl)if(REF_CLOCK!=0){u16val;-/* Set clock type */+/* Set clock type (open drain) */val=wl1271_top_reg_read(wl,OCP_REG_CLK_TYPE);val&=FREF_CLK_TYPE_BITS;-val|=CLK_REQ_PRCM;wl1271_top_reg_write(wl,OCP_REG_CLK_TYPE,val);++/* Set clock pull mode (no pull) */+val=wl1271_top_reg_read(wl,OCP_REG_CLK_PULL);+val|=NO_PULL;+wl1271_top_reg_write(wl,OCP_REG_CLK_PULL,val);}else{u16val;/* Set clock polarity */
From: Teemu Paasikivi <redacted>
Change the driver to call ieee80211_beacon_loss function always when
BSS_LOST_EVENT is received. Reason for the change is that entering PSM
might fail before driver receives BSS_LOST_EVENT. In such case the
driver would disable PSM and the stack would not be notified about beacon
loss and connection loss detection would be delayed by tens of seconds.
Signed-off-by: Teemu Paasikivi <redacted>
Reviewed-by: Juuso Oikarinen <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_event.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
@@ -173,9 +173,12 @@ static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)*TheBSS_LOSE_EVENT_IDisonlyneededwhilepsm(andhencebeacon*filtering)isenabled.WithoutPSM,thestackwillreceiveall*beaconsandcandetectbeaconlossbyitself.+*+*Asthere'spossibilitythatthedriverdisablesPSMbeforereceiving+*BSS_LOSE_EVENT,beaconlosshastobereportedtothestack.+**/-if(vector&BSS_LOSE_EVENT_ID&&-test_bit(WL1271_FLAG_PSM,&wl->flags)){+if(vector&BSS_LOSE_EVENT_ID){wl1271_debug(DEBUG_EVENT,"BSS_LOSE_EVENT");/* indicate to the stack, that beacons have been lost */
From: Juuso Oikarinen <redacted>
If PSM entry fails despite of retries, assume that the AP has been lost,
and indicate connection loss to the mac80211. This is much safer than
remaining in active mode.
Signed-off-by: Juuso Oikarinen <redacted>
Reviewed-by: Luciano Coelho <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_event.c | 21 +++------------------
1 files changed, 3 insertions(+), 18 deletions(-)
@@ -82,15 +82,8 @@ static int wl1271_event_ps_report(struct wl1271 *wl,true);}else{wl1271_error("PSM entry failed, giving up.\n");-/* FIXME: this may need to be reconsidered. for now it-isnotpossibletoindicatetothemac80211-afterwardsthatPSMentryfailed.Tomaximize-functionality(receivingdataandremaining-associated)makesurethatweareinsyncwiththe-APinregardofPSMmode.*/-ret=wl1271_ps_set_mode(wl,STATION_ACTIVE_MODE,-false);wl->psm_entry_retry=0;+*beacon_loss=true;}break;caseEVENT_ENTER_POWER_SAVE_SUCCESS:
@@ -180,16 +173,8 @@ static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)returnret;}-if(wl->vif&&beacon_loss){-/* Obviously, it's dangerous to release the mutex while-weareholdingmanyofthevariablesinthewlstruct.-That'swhyit'sdonelastinthefunction,andcaremust-betakenthatnothingmoreisdoneafterthisfunction-returns.*/-mutex_unlock(&wl->mutex);-ieee80211_beacon_loss(wl->vif);-mutex_lock(&wl->mutex);-}+if(wl->vif&&beacon_loss)+ieee80211_connection_loss(wl->vif);return0;}
From: Teemu Paasikivi <redacted>
There were wrong format specifiers in wl1271_sdio.c in some debug
outputs. This has been causing warnings on some platforms.
Signed-off-by: Teemu Paasikivi <redacted>
Reviewed-by: Luciano Coelho <redacted>
Signed-off-by: Luciano Coelho <redacted>
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
From: John W. Linville <hidden> Date: 2010-03-26 13:04:22
On Fri, Mar 26, 2010 at 12:53:09PM +0200, Luciano Coelho wrote:
Here are 25 more patches for wl1271 which are still pending in our internal
tree. Please apply. :)
Are we catching-up? Or will these dumps continue indefinitely?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
On Fri, 2010-03-26 at 14:02 +0100, ext John W. Linville wrote:
On Fri, Mar 26, 2010 at 12:53:09PM +0200, Luciano Coelho wrote:
quoted
Here are 25 more patches for wl1271 which are still pending in our internal
tree. Please apply. :)
Are we catching-up? Or will these dumps continue indefinitely?
Now we have finally caught up! Sorry for the mess, but we haven't been
sending patches for a while and they really got delayed.
The idea from now on is to send them weekly (still in patch-sets), but
not so many at once. We review and test our patches internally before
sending upstream, that's why we have to send them in batches.
I'm currently reconsidering this process and trying to figure out how we
can do things in a simpler way. We are already doing all our mac80211
work upstream, but for the driver we haven't found a good solution yet.
Would you prefer to pull stuff from a git tree instead of applying the
patches?
--
Cheers,
Luca.
From: John W. Linville <hidden> Date: 2010-03-26 13:28:37
On Fri, Mar 26, 2010 at 03:13:15PM +0200, Luciano Coelho wrote:
On Fri, 2010-03-26 at 14:02 +0100, ext John W. Linville wrote:
quoted
On Fri, Mar 26, 2010 at 12:53:09PM +0200, Luciano Coelho wrote:
quoted
Here are 25 more patches for wl1271 which are still pending in our internal
tree. Please apply. :)
Are we catching-up? Or will these dumps continue indefinitely?
Now we have finally caught up! Sorry for the mess, but we haven't been
sending patches for a while and they really got delayed.
The idea from now on is to send them weekly (still in patch-sets), but
not so many at once. We review and test our patches internally before
sending upstream, that's why we have to send them in batches.
Apparently Nokia, Intel, and maybe Atheros need to form some sort of
support group -- Patch-hoarder's Anonymous... :-)
I'm currently reconsidering this process and trying to figure out how we
can do things in a simpler way. We are already doing all our mac80211
work upstream, but for the driver we haven't found a good solution yet.
Would you prefer to pull stuff from a git tree instead of applying the
patches?
It doesn't make a great deal of difference to me. I have been pulling
from Intel for a little while now, and that has worked-out fairly
well from my perspective. But, applying patchbombs is usually easy
so long as there hasn't been lots of other activity in the driver.
So, whatever is convenient for you is probably acceptable to me.
Hth!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
On Fri, 2010-03-26 at 14:26 +0100, ext John W. Linville wrote:
On Fri, Mar 26, 2010 at 03:13:15PM +0200, Luciano Coelho wrote:
quoted
On Fri, 2010-03-26 at 14:02 +0100, ext John W. Linville wrote:
quoted
On Fri, Mar 26, 2010 at 12:53:09PM +0200, Luciano Coelho wrote:
quoted
Here are 25 more patches for wl1271 which are still pending in our internal
tree. Please apply. :)
Are we catching-up? Or will these dumps continue indefinitely?
Now we have finally caught up! Sorry for the mess, but we haven't been
sending patches for a while and they really got delayed.
The idea from now on is to send them weekly (still in patch-sets), but
not so many at once. We review and test our patches internally before
sending upstream, that's why we have to send them in batches.
Apparently Nokia, Intel, and maybe Atheros need to form some sort of
support group -- Patch-hoarder's Anonymous... :-)
LOL!
quoted
I'm currently reconsidering this process and trying to figure out how we
can do things in a simpler way. We are already doing all our mac80211
work upstream, but for the driver we haven't found a good solution yet.
Would you prefer to pull stuff from a git tree instead of applying the
patches?
It doesn't make a great deal of difference to me. I have been pulling
from Intel for a little while now, and that has worked-out fairly
well from my perspective. But, applying patchbombs is usually easy
so long as there hasn't been lots of other activity in the driver.
So, whatever is convenient for you is probably acceptable to me.
Good that this hasn't been causing too much extra work for you. If you
have any trouble applying the patches I send, just let me know and I'll
fix it.
I think the main drawback of sending patchbombs is that we don't get
good reviews from the community. Nobody wants to dig into a so many
patches at once, so it would probably be much better to have the patches
sent one-by-one (or in relevant sets). Unfortunately, we still have
many internal rounds before we're satisfied with the patches. But I'll
see if we can change that.
Tfyh! :)
--
Cheers,
Luca.