* [PATCH 02/12] ath9k: Cleanup function return types
From: Sujith @ 2009-08-07 4:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/eeprom.c | 5 +----
drivers/net/wireless/ath/ath9k/hw.c | 4 +---
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/mac.c | 17 ++++-------------
drivers/net/wireless/ath/ath9k/mac.h | 8 ++++----
5 files changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c b/drivers/net/wireless/ath/ath9k/eeprom.c
index 4cb64a0..86b13d1 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -35,7 +35,6 @@ static void ath9k_hw_analog_shift_rmw(struct ath_hw *ah,
static inline u16 ath9k_hw_fbin2freq(u8 fbin, bool is2GHz)
{
-
if (fbin == AR5416_BCHAN_UNUSED)
return fbin;
@@ -95,7 +94,7 @@ static inline bool ath9k_hw_nvram_read(struct ath_hw *ah, u32 off, u16 *data)
return sc->bus_ops->eeprom_read(ah, off, data);
}
-static inline bool ath9k_hw_fill_vpd_table(u8 pwrMin, u8 pwrMax, u8 *pPwrList,
+static inline void ath9k_hw_fill_vpd_table(u8 pwrMin, u8 pwrMax, u8 *pPwrList,
u8 *pVpdList, u16 numIntercepts,
u8 *pRetVpdList)
{
@@ -120,8 +119,6 @@ static inline bool ath9k_hw_fill_vpd_table(u8 pwrMin, u8 pwrMax, u8 *pPwrList,
pRetVpdList[i] = (u8) k;
currPwr += 2;
}
-
- return true;
}
static void ath9k_hw_get_legacy_target_powers(struct ath_hw *ah,
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 71a3bcc..6514dc7 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -4019,14 +4019,12 @@ void ath9k_hw_reset_tsf(struct ath_hw *ah)
ath9k_ps_restore(ah->ah_sc);
}
-bool ath9k_hw_set_tsfadjust(struct ath_hw *ah, u32 setting)
+void ath9k_hw_set_tsfadjust(struct ath_hw *ah, u32 setting)
{
if (setting)
ah->misc_mode |= AR_PCU_TX_ADD_TSF;
else
ah->misc_mode &= ~AR_PCU_TX_ADD_TSF;
-
- return true;
}
bool ath9k_hw_setslottime(struct ath_hw *ah, u32 us)
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index d4aaf4f..e83e900 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -601,7 +601,7 @@ void ath9k_hw_write_associd(struct ath_softc *sc);
u64 ath9k_hw_gettsf64(struct ath_hw *ah);
void ath9k_hw_settsf64(struct ath_hw *ah, u64 tsf64);
void ath9k_hw_reset_tsf(struct ath_hw *ah);
-bool ath9k_hw_set_tsfadjust(struct ath_hw *ah, u32 setting);
+void ath9k_hw_set_tsfadjust(struct ath_hw *ah, u32 setting);
bool ath9k_hw_setslottime(struct ath_hw *ah, u32 us);
void ath9k_hw_set11nmac2040(struct ath_hw *ah, enum ath9k_ht_macmode mode);
void ath9k_hw_beaconinit(struct ath_hw *ah, u32 next_beacon, u32 beacon_period);
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 6f923e3..800bfab 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -40,20 +40,15 @@ u32 ath9k_hw_gettxbuf(struct ath_hw *ah, u32 q)
return REG_READ(ah, AR_QTXDP(q));
}
-bool ath9k_hw_puttxbuf(struct ath_hw *ah, u32 q, u32 txdp)
+void ath9k_hw_puttxbuf(struct ath_hw *ah, u32 q, u32 txdp)
{
REG_WRITE(ah, AR_QTXDP(q), txdp);
-
- return true;
}
-bool ath9k_hw_txstart(struct ath_hw *ah, u32 q)
+void ath9k_hw_txstart(struct ath_hw *ah, u32 q)
{
DPRINTF(ah->ah_sc, ATH_DBG_QUEUE, "Enable TXE on queue: %u\n", q);
-
REG_WRITE(ah, AR_Q_TXE, 1 << q);
-
- return true;
}
u32 ath9k_hw_numtxpending(struct ath_hw *ah, u32 q)
@@ -178,7 +173,7 @@ bool ath9k_hw_stoptxdma(struct ath_hw *ah, u32 q)
#undef ATH9K_TIME_QUANTUM
}
-bool ath9k_hw_filltxdesc(struct ath_hw *ah, struct ath_desc *ds,
+void ath9k_hw_filltxdesc(struct ath_hw *ah, struct ath_desc *ds,
u32 segLen, bool firstSeg,
bool lastSeg, const struct ath_desc *ds0)
{
@@ -202,8 +197,6 @@ bool ath9k_hw_filltxdesc(struct ath_hw *ah, struct ath_desc *ds,
ads->ds_txstatus4 = ads->ds_txstatus5 = 0;
ads->ds_txstatus6 = ads->ds_txstatus7 = 0;
ads->ds_txstatus8 = ads->ds_txstatus9 = 0;
-
- return true;
}
void ath9k_hw_cleartxdesc(struct ath_hw *ah, struct ath_desc *ds)
@@ -888,7 +881,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
return 0;
}
-bool ath9k_hw_setuprxdesc(struct ath_hw *ah, struct ath_desc *ds,
+void ath9k_hw_setuprxdesc(struct ath_hw *ah, struct ath_desc *ds,
u32 size, u32 flags)
{
struct ar5416_desc *ads = AR5416DESC(ds);
@@ -901,8 +894,6 @@ bool ath9k_hw_setuprxdesc(struct ath_hw *ah, struct ath_desc *ds,
ads->ds_rxstatus8 &= ~AR_RxDone;
if (!(pCap->hw_caps & ATH9K_HW_CAP_AUTOSLEEP))
memset(&(ads->u), 0, sizeof(ads->u));
-
- return true;
}
bool ath9k_hw_setrxabort(struct ath_hw *ah, bool set)
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 1176bce..7b39822 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -628,12 +628,12 @@ struct ath9k_channel;
struct ath_rate_table;
u32 ath9k_hw_gettxbuf(struct ath_hw *ah, u32 q);
-bool ath9k_hw_puttxbuf(struct ath_hw *ah, u32 q, u32 txdp);
-bool ath9k_hw_txstart(struct ath_hw *ah, u32 q);
+void ath9k_hw_puttxbuf(struct ath_hw *ah, u32 q, u32 txdp);
+void ath9k_hw_txstart(struct ath_hw *ah, u32 q);
u32 ath9k_hw_numtxpending(struct ath_hw *ah, u32 q);
bool ath9k_hw_updatetxtriglevel(struct ath_hw *ah, bool bIncTrigLevel);
bool ath9k_hw_stoptxdma(struct ath_hw *ah, u32 q);
-bool ath9k_hw_filltxdesc(struct ath_hw *ah, struct ath_desc *ds,
+void ath9k_hw_filltxdesc(struct ath_hw *ah, struct ath_desc *ds,
u32 segLen, bool firstSeg,
bool lastSeg, const struct ath_desc *ds0);
void ath9k_hw_cleartxdesc(struct ath_hw *ah, struct ath_desc *ds);
@@ -668,7 +668,7 @@ bool ath9k_hw_releasetxqueue(struct ath_hw *ah, u32 q);
bool ath9k_hw_resettxqueue(struct ath_hw *ah, u32 q);
int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
u32 pa, struct ath_desc *nds, u64 tsf);
-bool ath9k_hw_setuprxdesc(struct ath_hw *ah, struct ath_desc *ds,
+void ath9k_hw_setuprxdesc(struct ath_hw *ah, struct ath_desc *ds,
u32 size, u32 flags);
bool ath9k_hw_setrxabort(struct ath_hw *ah, bool set);
void ath9k_hw_putrxbuf(struct ath_hw *ah, u32 rxdp);
--
1.6.4
^ permalink raw reply related
* [PATCH 01/12] ath9k: Remove unneeded assignment of protocol field
From: Sujith @ 2009-08-07 4:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6b07ced..f6a8b1c 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -788,7 +788,6 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
DMA_FROM_DEVICE);
skb_put(skb, ds->ds_rxstat.rs_datalen);
- skb->protocol = cpu_to_be16(ETH_P_CONTROL);
/* see if any padding is done by the hw and remove it */
hdr = (struct ieee80211_hdr *)skb->data;
--
1.6.4
^ permalink raw reply related
* ath9k ath_ani_calibrate
From: Howard Chu @ 2009-08-07 3:56 UTC (permalink / raw)
To: linux-wireless
I was seeing this function showing up consistently while running powertop. It
seems that ANI is always enabled by default, and I didn't see any ioctl or
config option to disable it. It sets a timer to wakeup every 100ms and do
whatever calibration it's trying to do. I changed the ANI_POLLINTERVAL to
1000ms and recompiled, and haven't noticed any ill effect yet. Is there any
reason why this calibration needs to happen 10 times a second? Will it still
be useful if it were toned down, to 250ms, or 500ms? (Note - because the
driver takes the minimum of the active calibration intervals, and
ANI_POLLINTERVAL is the smallest, it is always the one that wins...)
With this changed to 1sec, I still see the ath9k driver waking up 10-12
times/second but I presume that's in response to random packets from the AP.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
^ permalink raw reply
* Re: [PATCH] b43: Fix hardware key index handling
From: Michael Buesch @ 2009-08-06 20:41 UTC (permalink / raw)
To: Larry Finger; +Cc: John W Linville, wireless, bcm43xx-dev, gregor kowski
In-Reply-To: <4A7AE8E6.4050301@lwfinger.net>
On Thursday 06 August 2009 16:29:58 Larry Finger wrote:
> Michael Buesch wrote:
> > This fixes the hardware encryption keys index and array size handling.
> >
> > Thanks to Gregor Kowski for reporting this issue.
> >
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
> >
> > ---
> >
> > This should probably go as a bugfix.
> > (Does this actually fix the PHY transmission errors? I don't see them anymore...
> > Note that you need to enable debugging to see them.)
>
> I still see the PHY transmission errors.
Ah ok. I also have a new AP. Maybe that's why I'm not seeing it here. I'll try
later further away from the AP. That would show them again then...
> I had two of them and a "RX:
> packet dropped" debug message within seconds of reloading b43 with
> this patch included.
Should be fine. This happens sometimes.
Connection and rekeying does work. (Rekeying might still break if there's
heavy traffic. But that bug always was there. I think it's related to mac80211's
key handling. I also saw it on intel wireless.)
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] cfg80211: fix disassociation warning due to misuse of wdev->current_bss
From: Pavel Roskin @ 2009-08-06 20:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville
In-Reply-To: <1249564158.4852.24.camel@johannes.local>
On Thu, 2009-08-06 at 15:09 +0200, Johannes Berg wrote:
> On Thu, 2009-08-06 at 08:55 -0400, Pavel Roskin wrote:
>
> > Now that the check is fixed, it turn out there is a related problem in
> > the same function. If the device is in the managed mode and disconnects
> > from an AP due to a low signal,
>
> Who decides to disconnect?
I was unscrewing the antenna from the AP, and the AP wasn't visible in
the scan results without an antenna, so I assume that the station was
deciding to disconnect on its own.
> This isn't making any sense to me. Once you're connected,
> wdev->auth_bsses[i] shouldn't be set any more.
I see that you have posted several patches for the issue. I'll test
them on the same hardware tomorrow to avoid introducing extra variables.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Why are RX packets dropped during scanning?
From: Ben Greear @ 2009-08-06 20:37 UTC (permalink / raw)
To: linux-wireless
Can anyone tell me why the ieee80211_rx_h_passive_scan method
drops non beacon packets when the hardware is scanning?
Why not let them fall through and be processed?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2.6.30] iwl3945: fix rfkill switch
From: reinette chatre @ 2009-08-06 20:15 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless@vger.kernel.org, Zhu, Yi, John W. Linville,
stable@kernel.org
In-Reply-To: <20090806071902.GA9816@dhcp-lab-161.englab.brq.redhat.com>
Hi Stanislaw,
On Thu, 2009-08-06 at 00:19 -0700, Stanislaw Gruszka wrote:
> On Wed, Aug 05, 2009 at 03:51:49PM -0700, reinette chatre wrote:
> > On Tue, 2009-08-04 at 05:35 -0700, Stanislaw Gruszka wrote:
> > > Due to rfkill and iwlwifi mishmash of SW / HW killswitch representation,
> > > we have race conditions which make unable turn wifi radio on, after enable
> > > and disable again killswitch. I can observe this problem on my laptop
> > > with iwl3945 device.
> > >
> > > In rfkill core HW switch and SW switch are separate 'states'. Device can
> > > be only in one of 3 states: RFKILL_STATE_SOFT_BLOCKED, RFKILL_STATE_UNBLOCKED,
> > > RFKILL_STATE_HARD_BLOCKED. Whereas in iwlwifi driver we have separate bits
> > > STATUS_RF_KILL_HW and STATUS_RF_KILL_SW for HW and SW switches - radio can be
> > > turned on, only if both bits are cleared.
> > >
> > > In this particular race conditions, radio can not be turned on if in driver
> > > STATUS_RF_KILL_SW bit is set, and rfkill core is in state
> > > RFKILL_STATE_HARD_BLOCKED, because rfkill core is unable to call
> > > rfkill->toggle_radio(). This situation can be entered in case:
> > >
> >
> > I am trying to understand this race condition ...
> >
> > > - killswitch is turned on
> > > - rfkill core 'see' button change first and move to RFKILL_STATE_SOFT_BLOCKED
> > > also call ->toggle_radio() and STATE_RF_KILL_SW in driver is set
> > > - iwl3945 get info about button from hardware to set STATUS_RF_KILL_HW bit and
> > > force rfkill to move to RFKILL_STATE_HARD_BLOCKED
> >
> > ok - so at this point we have rfkill == RFKILL_STATE_HARD_BLOCKED, and
> > driver == STATE_RF_KILL_SW | STATE_RF_KILL_HW
> >
> > > - killsiwtch is turend off
>
> Here rfkill core routines are called. Rfkill wants to clear STATUS_RF_KILL_SW
> but it can not as state is RFKILL_STATE_HARD_BLOCKED.
>
> > > - driver clear STATUS_RF_KILL_HW
> >
> > at this point the driver should clear STATE_RF_KILL_HW and then call
> > iwl_rfkill_set_hw_state(). From what I can tell, in
> > iwl_rfkill_set_hw_state() the test for iwl_is_rfkill_sw() will cause the
> > driver to call rfkill_force_state for RFKILL_STATE_SOFT_BLOCKED
> >
> > So, from what I understand after the above the status will be
> >
> > rfkill == RFKILL_STATE_SOFT_BLOCKED, and driver == STATE_RF_KILL_SW
>
> Thats right. But rfkill core no longer wants to manipulate state via
> ->toggle_radio() and radio stays disabled.
>
> > > - rfkill core is unable to clear STATUS_RF_KILL_SW in driver
> >
> > I do not understand why this is a problem here. Could you please
> > highlight what I am missing?
>
> In my description I miss the most important part, sorry. Race is when the
> switches are performed in that order:
>
> Radio enabled
> - rfkill SW on
> - driver HW on
> Radio disabled - ok
> - rfkill SW off <- problem not clearing STATUS_RF_KILL_SW
> - driver HW off
> Radio disabled - wrong
>
> Everything is fine when actions are in that order:
>
> Radio enabled
> - rfkill SW on
> - driver HW on
> Radio disabled - ok
> - driver HW off
> - rfkill SW off
> Radio enabled - ok
Thanks for the explanation.
>
> > >
> > > Additionally call to rfkill_epo() when STATUS_RF_KILL_HW in driver is set
> > > cause move to the same situation.
> > >
> > > In 2.6.31 this problem is fixed due to _total_ rewrite of rfkill subsystem.
> > > This is a quite small fix for 2.6.30.x in iwl3945 driver. We disable
> > > STATUS_RF_KILL_SW bit regardless of HW bit state. Also report to rfkill
> > > subsystem SW switch bit before HW switch bit to move rfkill subsystem
> > > to SOFT_BLOCK rather than HARD_BLOCK.
> > >
> > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > > ---
> > > I'm not sure if this is good candidate for stable as this is not backport
> > > of upstream commit. Also I did not test this patch with other iwlwifi devices,
> > > only with iwl3945.
> > >
> > > drivers/net/wireless/iwlwifi/iwl-rfkill.c | 24 ++++++++++++++----------
> > > 1 files changed, 14 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rfkill.c b/drivers/net/wireless/iwlwifi/iwl-rfkill.c
> > > index 2ad9faf..d6b6098 100644
> > > --- a/drivers/net/wireless/iwlwifi/iwl-rfkill.c
> > > +++ b/drivers/net/wireless/iwlwifi/iwl-rfkill.c
> > > @@ -54,21 +54,28 @@ static int iwl_rfkill_soft_rf_kill(void *data, enum rfkill_state state)
> > > case RFKILL_STATE_UNBLOCKED:
> > > if (iwl_is_rfkill_hw(priv)) {
> > > err = -EBUSY;
> > > - goto out_unlock;
> > > + /* pass error to rfkill core to make it state HARD
> > > + * BLOCKED and disable software kill switch */
> > > }
> > > iwl_radio_kill_sw_enable_radio(priv);
> > > break;
> > > case RFKILL_STATE_SOFT_BLOCKED:
> > > iwl_radio_kill_sw_disable_radio(priv);
> > > + /* rfkill->mutex lock is taken */
> > > + if (priv->rfkill->state == RFKILL_STATE_HARD_BLOCKED) {
> > > + /* force rfkill core state to be SOFT BLOCKED,
> > > + * otherwise core will be unable to disable software
> > > + * kill switch */
> > > + priv->rfkill->state = RFKILL_STATE_SOFT_BLOCKED;
> > > + }
> >
> > I understand that you are directly changing the rfkill internals because
> > the mutex is taken ... but this really does not seem right to directly
> > modify the rfkill state in this way.
>
> Agree this is dirty hack, but I did not find a better way. Eventually,
> if we add call to rfkill_uevent(), this would behave the same
> as rfkill_force_state() .
Sorry, but I really do not understand why this code is needed. From what
you say rfkill can be in one of three states: RFKILL_STATE_UNBLOCKED,
RFKILL_STATE_SOFT_BLOCKED, or RFKILL_STATE_HARD_BLOCKED. From what I
understand the above code is called when there is an rfkill state change
and the new state is provided. So, only _one_ of the three states will
be provided as parameter. This state is then tested - so in the case
that you modified here the state has already been tested to be
RFKILL_STATE_SOFT_BLOCKED. How is it thus possible that it can be
RFKILL_STATE_HARD_BLOCKED also?
Reinette
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Fabio Comolli @ 2009-08-06 20:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Linux Kernel Mailing List, netdev,
Rafael J. Wysocki, linux-wireless
In-Reply-To: <43e72e890908061232k467ba1f7iece5d0aa9bece811@mail.gmail.com>
Hi Luis.
I'm using 2.6.31-rc5 and I'm not using wireless-testing.
Regards,
Fabio
On Thu, Aug 6, 2009 at 9:32 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Aug 6, 2009 at 12:26 PM, Fabio Comolli<fabio.comolli@gmail.com> wrote:
>> Hi John. I'm using ath5k .
>>
>> The card is a:
>>
>> 01:00.0 Ethernet controller: Atheros Communications Inc. AR5001
>> Wireless Network Adapter (rev 01)
>>
>> with PCI ID:
>>
>> 01:00.0 0200: 168c:001c (rev 01)
>
> What kernel?
>
> This is probably a driver/mac80211 adding work into the mac80211
> workqueue during the susend --> resume cycle. We recently changed the
> warning to be moved onto the actual caller who does the queue_work()
> so we don't have to guess at this and do a painful debugging.
>
> I suspect you are not using the latest wireless-testing.
>
> Luis
>
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-08-06
From: David Miller @ 2009-08-06 20:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090806190200.GJ26809@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 6 Aug 2009 15:02:00 -0400
> Here is another big round of updates intended for 2.6.32...mostly the usual
> suspects, although it looks like Luis has been exceptionally busy with
> both ath9k and regulatory enforcement bits. Jussi has a number of
> rndis_wlan changes, and of course Johannes has a number of patches as
> well.
Pulled, thanks John.
Will push out to kernel.org after build tests.
^ permalink raw reply
* Re: [PATCH] Document pci_ids.h addition policy.
From: Greg KH @ 2009-08-06 19:38 UTC (permalink / raw)
To: Dave Jones, Marcel Holtmann, Luis R. Rodriguez, linville,
linux-kernel, linux-wireless, zhifeng.cai, stephen.chen,
linux-usb, jbarnes
In-Reply-To: <20090806191359.GA4345@redhat.com>
On Thu, Aug 06, 2009 at 03:13:59PM -0400, Dave Jones wrote:
> On Thu, Aug 06, 2009 at 11:33:26AM -0700, Greg Kroah-Hartman wrote:
>
> > > I agree. In fact, I'd go further, and say that the bulk of what we have
> > > in pci_ids.h is also pointlessly shared. Only a tiny fraction of the device
> > > entries in that file are used by multiple files in the kernel.
> >
> > I agree with that as well, which is why when I was PCI maintainer, I
> > didn't allow any new additions to the pci_ids.h file, unless it was
> > going to be an id that was shared by different drivers. That cut the
> > new additions down to about none :)
>
> Perhaps documenting this is a good idea to prevent things being moved there,
> as it still seems to be happening judging from the git log.
>
> Signed-off-by: Dave Jones <davej@redhat.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
^ permalink raw reply
* Re: Best (ath9k) miniPCI card for testing overall AP functionality
From: X Xiao @ 2009-08-06 19:38 UTC (permalink / raw)
To: Luis R. Rodriguez, Pavel Roskin
Cc: Philip A. Prindeville, linux-wireless, Pen Li
In-Reply-To: <1249584482.19169.10.camel@mj>
again in my case the ubnt SR71A worked as an AP just fine, using 06-25 compat-wireless that is.
xxiao
--- On Thu, 8/6/09, Pavel Roskin <proski@gnu.org> wrote:
> From: Pavel Roskin <proski@gnu.org>
> Subject: Re: Best (ath9k) miniPCI card for testing overall AP functionality
> To: "Luis R. Rodriguez" <mcgrof@gmail.com>
> Cc: "Philip A. Prindeville" <philipp_subx@redfish-solutions.com>, linux-wireless@vger.kernel.org, "Pen Li" <Pen.Li@atheros.com>
> Date: Thursday, August 6, 2009, 1:48 PM
> On Thu, 2009-08-06 at 10:08 -0700,
> Luis R. Rodriguez wrote:
>
> > > By the way, AR9160 is supported by MadWifi,
> unlike AR9280. MadWifi is
> > > not actively developed, but if you need another
> reference point, you'll
> > > have it.
> >
> > Does MadWifi support 11n? :)
>
> Of could it doesn't, but neither does ath5k, and the
> subject mentions
> "overall AP functionality", not 802.11n support.
>
> --
> Regards,
> Pavel Roskin
> --
> 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
* Re: [PATCH] rndis_wlan: wait association to complete
From: Jussi Kivilinna @ 2009-08-06 19:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linville, Jouni Malinen
In-Reply-To: <1249584385.28278.124.camel@johannes.local>
Quoting "Johannes Berg" <johannes@sipsolutions.net>:
> On Thu, 2009-08-06 at 21:17 +0300, Jussi Kivilinna wrote:
>> Fix WPA authentication problems by waiting to association to complete.
>> Otherwise userspace (wpa_supplicant) receives authentication packets before
>> association events from driver.
>
>> + /* If we return now, userspace would get association events too late
>> + * (after receiving first packets from access point). This causes
>> + * WPA authentication to fail.
>
> This is a bit weird, shouldn't you just send the event later then?
>
rndis_wlan bases on rndis_host/usbnet. Problem is that rndis_host uses
polling for rndis_command() results to avoid more complex interrupt
based solution. Because rndis_host and therefore rndis_wlan doesn't
handle interrupts on command channel, rndis_wlan knows about completed
association too late. 'Too late' means here that device starts
receiving packets from AP, which end up ignored because userspace
thinks device isn't assosiated yet (I think).
So this patch adds waiting in set_essid() and active polling for
association completion in worker.
Real fix would probably be to hold on data channel until association
is complete, but that would mean touching usbnet/rndis_host little bit
too much than I'd like to.
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Luis R. Rodriguez @ 2009-08-06 19:32 UTC (permalink / raw)
To: Fabio Comolli
Cc: John W. Linville, Linux Kernel Mailing List, netdev,
Rafael J. Wysocki, linux-wireless
In-Reply-To: <b637ec0b0908061226m33203bco7ac38cecb939b382@mail.gmail.com>
On Thu, Aug 6, 2009 at 12:26 PM, Fabio Comolli<fabio.comolli@gmail.com> wrote:
> Hi John. I'm using ath5k .
>
> The card is a:
>
> 01:00.0 Ethernet controller: Atheros Communications Inc. AR5001
> Wireless Network Adapter (rev 01)
>
> with PCI ID:
>
> 01:00.0 0200: 168c:001c (rev 01)
What kernel?
This is probably a driver/mac80211 adding work into the mac80211
workqueue during the susend --> resume cycle. We recently changed the
warning to be moved onto the actual caller who does the queue_work()
so we don't have to guess at this and do a painful debugging.
I suspect you are not using the latest wireless-testing.
Luis
^ permalink raw reply
* Re: [PATCH] Document pci_ids.h addition policy.
From: John W. Linville @ 2009-08-06 19:16 UTC (permalink / raw)
To: Dave Jones, Greg KH, Marcel Holtmann, Luis R. Rodriguez,
linux-kernel, linux-wireless, zhifeng.cai, stephen.chen,
linux-usb, jbarnes
In-Reply-To: <20090806191359.GA4345@redhat.com>
On Thu, Aug 06, 2009 at 03:13:59PM -0400, Dave Jones wrote:
> On Thu, Aug 06, 2009 at 11:33:26AM -0700, Greg Kroah-Hartman wrote:
>
> > > I agree. In fact, I'd go further, and say that the bulk of what we have
> > > in pci_ids.h is also pointlessly shared. Only a tiny fraction of the device
> > > entries in that file are used by multiple files in the kernel.
> >
> > I agree with that as well, which is why when I was PCI maintainer, I
> > didn't allow any new additions to the pci_ids.h file, unless it was
> > going to be an id that was shared by different drivers. That cut the
> > new additions down to about none :)
>
> Perhaps documenting this is a good idea to prevent things being moved there,
> as it still seems to be happening judging from the git log.
>
> Signed-off-by: Dave Jones <davej@redhat.com>
>
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 73b46b6..f9156fd 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2,6 +2,9 @@
> * PCI Class, Vendor and Device IDs
> *
> * Please keep sorted.
> + *
> + * Do not add new entries to this file unless the definitions
> + * are shared between multiple drivers.
> */
>
> /* Device classes and subclasses */
>
ACK
--
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: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Fabio Comolli @ 2009-08-06 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Linux Kernel Mailing List, netdev, Rafael J. Wysocki,
linux-wireless
In-Reply-To: <20090806183247.GI26809@tuxdriver.com>
Hi John. I'm using ath5k .
The card is a:
01:00.0 Ethernet controller: Atheros Communications Inc. AR5001
Wireless Network Adapter (rev 01)
with PCI ID:
01:00.0 0200: 168c:001c (rev 01)
Regards,
Fabio
On Thu, Aug 6, 2009 at 8:32 PM, John W. Linville<linville@tuxdriver.com> wrote:
> What driver are you using?
>
> On Thu, Aug 06, 2009 at 08:30:23PM +0200, Fabio Comolli wrote:
>> Just got this after a resume from suspend-to-ram. Wifi needed to be
>> disabled and reenabled (with hardware Fn+F2 key - this is an eeePC900)
>> to function again.
>>
>>
>> [ 919.858759] ------------[ cut here ]------------
>> [ 919.858787] WARNING: at net/mac80211/mlme.c:2292
>> ieee80211_sta_work+0x97/0xd2d [mac80211]()
>> [ 919.858791] Hardware name: 900
>> [ 919.858793] Modules linked in: uvcvideo videodev v4l1_compat arc4
>> ecb ath5k mac80211 ath cfg80211
>> [ 919.860022] Pid: 793, comm: phy0 Tainted: G M 2.6.31-rc5 #11
>> [ 919.860025] Call Trace:
>> [ 919.860035] [<c10209cf>] warn_slowpath_common+0x65/0x7c
>> [ 919.860058] [<f83d621e>] ? ieee80211_sta_work+0x97/0xd2d [mac80211]
>> [ 919.860064] [<c10209f3>] warn_slowpath_null+0xd/0x10
>> [ 919.860086] [<f83d621e>] ieee80211_sta_work+0x97/0xd2d [mac80211]
>> [ 919.860092] [<c101bb2b>] ? __wake_up+0x2f/0x56
>> [ 919.860097] [<c101bb39>] ? __wake_up+0x3d/0x56
>> [ 919.860103] [<c102eb04>] ? insert_work+0x96/0x9f
>> [ 919.860108] [<c102ed63>] ? __queue_work+0x32/0x49
>> [ 919.860113] [<c102eda1>] ? queue_work_on+0x27/0x2f
>> [ 919.860119] [<c102f52f>] ? queue_work+0x2d/0x45
>> [ 919.860140] [<f83d3324>] ?
>> ieee80211_ibss_notify_scan_completed+0x63/0x68 [mac80211]
>> [ 919.860162] [<f83d1059>] ? ieee80211_scan_completed+0x320/0x328 [mac80211]
>> [ 919.860184] [<f83d1160>] ? ieee80211_scan_work+0xb5/0x171 [mac80211]
>> [ 919.860190] [<c102f075>] worker_thread+0x15d/0x204
>> [ 919.860211] [<f83d6187>] ? ieee80211_sta_work+0x0/0xd2d [mac80211]
>> [ 919.860218] [<c1032217>] ? autoremove_wake_function+0x0/0x2f
>> [ 919.860223] [<c102ef18>] ? worker_thread+0x0/0x204
>> [ 919.860229] [<c1031fab>] kthread+0x63/0x68
>> [ 919.860234] [<c1031f48>] ? kthread+0x0/0x68
>> [ 919.860240] [<c1002f93>] kernel_thread_helper+0x7/0x10
>> [ 919.860244] ---[ end trace 7a3a8d08c5a7bedf ]---
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> 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: CRDA and cross-compilation
From: Luis R. Rodriguez @ 2009-08-06 19:23 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless
In-Reply-To: <1249585684.19169.12.camel@mj>
On Thu, Aug 6, 2009 at 12:08 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Thu, 2009-08-06 at 11:42 -0700, Luis R. Rodriguez wrote:
>
>> > -all: $(REG_BIN) crda intersect verify
>> > +all: all_noverify verify
>> > +
>> > +all_noverify: crda intersect regdbdump
>>
>> You removed REG_BIN from here, was that intentional?
>
> Yes. It's not needed for the build. As for the "verify" target, it
> already depends on $(REG_BIN)
Oh nice, thanks applied!
Luis
^ permalink raw reply
* Re: CRDA and cross-compilation
From: Jon Loeliger @ 2009-08-06 19:21 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Pavel Roskin, Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A7B2B7A.5030802@redfish-solutions.com>
On Thu, 2009-08-06 at 12:14 -0700, Philip A. Prindeville wrote:
>
> Can someone roll *all* the patches together? For instance, "pkg-config" shouldn't be used on a cross-compile...
>
> -Philip
Philip,
These are the sorts of issues that made my patch seem
more complicated than first blush might suggest was needed.
jdl
^ permalink raw reply
* pull request: wireless-next-2.6 2009-08-06
From: John W. Linville @ 2009-08-06 19:02 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is another big round of updates intended for 2.6.32...mostly the usual
suspects, although it looks like Luis has been exceptionally busy with
both ath9k and regulatory enforcement bits. Jussi has a number of
rndis_wlan changes, and of course Johannes has a number of patches as
well.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit e4c4e448cf557921ffbbbd6d6ddac81fdceacb4f:
Eric Dumazet (1):
neigh: Convert garbage collection from softirq to workqueue
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Andrey Yurovsky (1):
libertas: check valid bits in SPI bus mode reg
Bob Copeland (3):
mac80211: disable beacons before removing the associated interface
ath5k: update PCU opmode whenever a new interface is added
ath5k: fix CAB queue operation
Daniel C Halperin (1):
iwlwifi: clear iwl_cmd_meta structure before use
Gábor Stefanik (1):
b43: implement baseband init for LP-PHY <= rev1
Holger Schurig (1):
orinoco: enable cfg80211 "set_channel" operation
Igor Perminov (1):
mac80211: FIF_PSPOLL filter flag
Ivo van Doorn (1):
rt2x00: Fix build error when crypto support is disabled
Jay Sternberg (1):
iwlwifi: remove duplicated version info from sysfs
Johannes Berg (8):
mac80211: disable software retry for now
cfg80211: keep track of current_bss for userspace SME
mac80211: fix sparse warnings/errors
iwlwifi: don't export symbols not needed in other modules
cfg80211: fix NETDEV_UNREGISTER notifier
mac80211: fix powersave
cfg80211: lower dynamic PS timeout to 100ms
cfg80211: clear SSID on disconnect/no connection
Julia Lawall (1):
drivers/net/wireless: Use DIV_ROUND_CLOSEST
Jussi Kivilinna (10):
usbnet: allow "minidriver" to prevent urb unlinking on usbnet_stop
rndis_wlan: stop workers on rndis_wlan_stop() and restore on rndis_wlan_reset()
rndis_wlan: clear cfg80211 scan on rndis_wlan_stop()
rndis_wlan: reset device and restore multicast list on rndis_wlan_reset()
rndis_wlan: set current packet filter to zero on stop
rndis_wlan: add rndis_set/query_oid debugging
rndis_host: allow rndis_wlan to see all indications
rndis_wlan: handle 802.11 indications from device
rndis_wlan: add missing padding to struct rndis_80211_remove_key
rndis_wlan: rework key handling
Larry Finger (2):
b43: Work around mac80211 race condition
b43legacy: Work around mac80211 race condition
Luis R. Rodriguez (51):
ath9k: re-order cancelling of work on mac80211 workqueue
ath9k: move cancel_delayed_work_sync() out of ath_deinit_leds()
ath9k: move workqueue cancels to stop callback
ar76c50x-usb: cancel promisc work during mac80211 stop
at76c50x-usb: cancel scan work at stop callback
ar9170: remove unneeded flush_workqueue()
wext: remove extra return on wireless_nlevent_init()
ath: depend on cfg80211
ath: simplify kconfig dependency and add documentation
ath: use menuconfig to put ath stuff in its own page
ath5k: remove EXPERIMENTAL marker
wireless: use menuconfig for WLAN_PRE80211 and WLAN_80211
rt2x00: move experimental on kconfig only to rt2800usb
ar9170: remove EXPERIMENTAL marker
at76c50x-usb: remove unneeded flush_workqueue() at usb disconnect
mac80211: redefine usage of the mac80211 workqueue
cfg80211: use goto out on country IE reg hint failure
cfg80211: do not iterate over rdev list on country IE hint
cfg80211: decouple regulatory variables from cfg80211_mutex
cfg80211: enable country IE support to all cfg80211 drivers
iwlwifi: remove usage of orig_flags
ath9k: remove usage of AR_SREV_*() wrapper to detect supported hw
ath9k: use a switch for revising supported hw mac revisions
ath9k: propagate hw initialization errors
ath9k: move memory allocation of ath_hw to ath_init()
ath9k: move devid cache setting to ath_init()
ath9k: move cache setting of softc ah prior to attach
ath9k: call hw initializer directly
ath9k: pass only one argument to hw attach
ath9k: move hw macrevision checker to helper
ath9k: rename ath9k_hw_newstate() to ath9k_hw_init_defaults()
ath9k: rename ath9k_hw_set_defaults() to ath9k_hw_init_config()
ath9k: remove debug message for no memoery on ath_init()
ath9k: break up hw initialization into a few more helpers
ath9k: describe hw initialization better
ath9k: distinguish between device initialization and ath_softc init
ath9k: remove !NULL check before kfree()
ath9k: use helper macro to kfree and nullify on ath9k_hw_rfdetach()
ath9k: rename ath9k_hw_rfdetach() to ath9k_hw_rf_free()
ath9k: rename ath9k_hw_ani_detach() to ath9k_hw_ani_disable()
ath9k: set ah to null after freeing
ath9k: set sc->sc_ah to NULL after freeing it
ath9k: call ath9k_hw_detach() once upon hw init failure
ath9k: remove dangling error check on keycache reset on hw init
ath9k: remove spurious check for channel on keycache reset
ath9k: Remove _t postfix for ar9287_eeprom structure
ath9k: add ar9271 revision and subrevision ID helpers
ath9k: add initvals and registry definitions for AR9271
ath9k: add initial hardware support for ar9271
ath9k: cancel xmit poll work at stop() callback
ath9k: fix compile warning on ath9k_hw_AR9287_check_eeprom()
Maithili Hinge (1):
libertas: Fix WEP association failure with open source wpa_supplicant 0.5.10
Maxim Levitsky (2):
mac80211: Retry probe request few times
mac80211: Increase timeouts for station polling
Michael Buesch (1):
b43: Fix unaligned 32bit SHM-shared access
Pavel Roskin (2):
rt61pci: fix module reloading
rt2x00: cancel all work on disconnect
Tomas Winkler (1):
rfkill: add the GPS radio type
Vasanthakumar Thiagarajan (3):
ath9k: Update rate control for 11NA HT40 mode
ath9k: Maintain monotonicity of PER while going across different phy
ath9k: Remove unused ath9k_hw_intrget()
Wey-Yi Guy (2):
iwlwifi: Distinguish power amplifier for 6000 series
iwlwifi: remove deprecated 6000 series adapters
Zhu Yi (3):
iwmc3200wifi: fix set_wpa_version and set_auth_type order
iwmc3200wifi: set WEP key static flag correctly
iwmc3200wifi: avoid setting default key for 802.1X and RSNA
gregor kowski (1):
b43: remove wrong probe_resp_plcp write
drivers/net/usb/rndis_host.c | 48 ++-
drivers/net/usb/usbnet.c | 32 +-
drivers/net/wireless/Kconfig | 4 +-
drivers/net/wireless/at76c50x-usb.c | 18 +-
drivers/net/wireless/ath/Kconfig | 21 +-
drivers/net/wireless/ath/ar9170/Kconfig | 4 +-
drivers/net/wireless/ath/ar9170/led.c | 11 +-
drivers/net/wireless/ath/ar9170/main.c | 29 +-
drivers/net/wireless/ath/ath5k/Kconfig | 3 +-
drivers/net/wireless/ath/ath5k/base.c | 8 +-
drivers/net/wireless/ath/ath9k/Kconfig | 1 -
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/ani.h | 4 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/calib.c | 106 ++++-
drivers/net/wireless/ath/ath9k/eeprom.c | 175 +++++--
drivers/net/wireless/ath/ath9k/eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/hw.c | 368 +++++++++------
drivers/net/wireless/ath/ath9k/hw.h | 11 +-
drivers/net/wireless/ath/ath9k/initvals.h | 666 ++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/main.c | 89 +++--
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
drivers/net/wireless/ath/ath9k/phy.c | 53 +--
drivers/net/wireless/ath/ath9k/phy.h | 3 +
drivers/net/wireless/ath/ath9k/rc.c | 7 +-
drivers/net/wireless/ath/ath9k/reg.h | 37 ++
drivers/net/wireless/ath/ath9k/virtual.c | 17 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/net/wireless/b43/b43.h | 11 +
drivers/net/wireless/b43/dma.c | 21 +-
drivers/net/wireless/b43/main.c | 42 ++-
drivers/net/wireless/b43/phy_common.c | 9 +-
drivers/net/wireless/b43/phy_common.h | 5 +
drivers/net/wireless/b43/phy_lp.c | 94 ++++-
drivers/net/wireless/b43/phy_lp.h | 11 +-
drivers/net/wireless/b43/phy_n.c | 3 +-
drivers/net/wireless/b43/pio.c | 2 +-
drivers/net/wireless/b43legacy/dma.c | 22 +-
drivers/net/wireless/b43legacy/main.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 14 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 48 ++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 51 +--
drivers/net/wireless/iwlwifi/iwl-core.c | 6 -
drivers/net/wireless/iwlwifi/iwl-core.h | 3 +
drivers/net/wireless/iwlwifi/iwl-csr.h | 10 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 17 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
drivers/net/wireless/iwlwifi/iwl-rx.c | 1 -
drivers/net/wireless/iwlwifi/iwl-sta.c | 1 -
drivers/net/wireless/iwlwifi/iwl-tx.c | 1 +
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 9 +-
drivers/net/wireless/iwmc3200wifi/commands.c | 49 ++-
drivers/net/wireless/libertas/if_spi.c | 2 +-
drivers/net/wireless/libertas/wext.c | 2 +
drivers/net/wireless/orinoco/cfg.c | 41 ++
drivers/net/wireless/p54/led.c | 5 +-
drivers/net/wireless/p54/main.c | 2 +-
drivers/net/wireless/p54/p54spi.c | 4 +-
drivers/net/wireless/p54/txrx.c | 2 +-
drivers/net/wireless/rndis_wlan.c | 617 +++++++++++++++++++++---
drivers/net/wireless/rt2x00/Kconfig | 8 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 22 +-
drivers/net/wireless/rt2x00/rt61pci.c | 5 +
drivers/net/wireless/rtl818x/rtl8187_dev.c | 2 +-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 10 +-
drivers/net/wireless/strip.c | 9 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 2 +-
include/linux/rfkill.h | 1 +
include/linux/usb/rndis_host.h | 13 +-
include/linux/usb/usbnet.h | 6 +-
include/net/cfg80211.h | 14 -
include/net/mac80211.h | 58 ++-
net/mac80211/driver-trace.c | 3 +
net/mac80211/ibss.c | 6 +-
net/mac80211/ieee80211_i.h | 9 +-
net/mac80211/iface.c | 36 ++-
net/mac80211/main.c | 40 ++-
net/mac80211/mesh.c | 10 +-
net/mac80211/mesh_hwmp.c | 4 +-
net/mac80211/mlme.c | 113 +++--
net/mac80211/pm.c | 8 +-
net/mac80211/scan.c | 8 +-
net/mac80211/tx.c | 2 +-
net/mac80211/util.c | 41 ++
net/rfkill/core.c | 4 +-
net/wireless/core.c | 24 +-
net/wireless/core.h | 8 +-
net/wireless/mlme.c | 38 +-
net/wireless/reg.c | 107 ++---
net/wireless/reg.h | 15 +
net/wireless/sme.c | 55 ++-
net/wireless/wext.c | 1 -
96 files changed, 2757 insertions(+), 796 deletions(-)
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-08-06.patch.bz2
--
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: CRDA and cross-compilation
From: Philip A. Prindeville @ 2009-08-06 19:14 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Luis R. Rodriguez, Jon Loeliger, linux-wireless
In-Reply-To: <1249580707.14919.29.camel@mj>
Pavel Roskin wrote:
> On Thu, 2009-08-06 at 09:56 -0700, Luis R. Rodriguez wrote:
>
>> ACK, is it possible to make it simpler?
>
> OK, here's my take.
>
> We only need a native compiler to verify regulatory.bin. I believe it's
> orthogonal to building CRDA.
>
> For someone doing a cross-compilation, it makes no sense to verify the
> installed regulatory.bin. Thus, the verification should be optional.
>
> But the compilation of regdbdump shouldn't be. Firstly, it's installed
> by "make install". Secondly, somebody may want to verify regulatory.bin
> on the target system.
>
> Here's the patch:
>
>
> crda: make it possible to disable verification
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
> Makefile | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b93b735..3cc61c2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -24,7 +24,9 @@ PUBKEY_DIR?=pubkeys
>
> CFLAGS += -Wall -g
>
> -all: $(REG_BIN) crda intersect verify
> +all: all_noverify verify
> +
> +all_noverify: crda intersect regdbdump
>
> ifeq ($(USE_OPENSSL),1)
> CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
> @@ -74,11 +76,12 @@ $(REG_BIN):
> $(NQ) ' EXIST ' $(REG_BIN)
> $(NQ)
> $(NQ) ERROR: The file: $(REG_BIN) is missing. You need this in place in order
> - $(NQ) to build CRDA. You can get it from:
> + $(NQ) to verify CRDA. You can get it from:
> $(NQ)
> $(NQ) $(REG_GIT)
> $(NQ)
> $(NQ) "Once cloned (no need to build) cp regulatory.bin to $(REG_BIN)"
> + $(NQ) "Use \"make noverify\" to disable verification"
> $(NQ)
> $(Q) exit 1
>
>
Can someone roll *all* the patches together? For instance, "pkg-config" shouldn't be used on a cross-compile...
-Philip
^ permalink raw reply
* [PATCH] Document pci_ids.h addition policy.
From: Dave Jones @ 2009-08-06 19:13 UTC (permalink / raw)
To: Greg KH
Cc: Marcel Holtmann, Luis R. Rodriguez, linville, linux-kernel,
linux-wireless, zhifeng.cai, stephen.chen, linux-usb, jbarnes
In-Reply-To: <20090806183326.GA28433@kroah.com>
On Thu, Aug 06, 2009 at 11:33:26AM -0700, Greg Kroah-Hartman wrote:
> > I agree. In fact, I'd go further, and say that the bulk of what we have
> > in pci_ids.h is also pointlessly shared. Only a tiny fraction of the device
> > entries in that file are used by multiple files in the kernel.
>
> I agree with that as well, which is why when I was PCI maintainer, I
> didn't allow any new additions to the pci_ids.h file, unless it was
> going to be an id that was shared by different drivers. That cut the
> new additions down to about none :)
Perhaps documenting this is a good idea to prevent things being moved there,
as it still seems to be happening judging from the git log.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 73b46b6..f9156fd 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2,6 +2,9 @@
* PCI Class, Vendor and Device IDs
*
* Please keep sorted.
+ *
+ * Do not add new entries to this file unless the definitions
+ * are shared between multiple drivers.
*/
/* Device classes and subclasses */
^ permalink raw reply related
* Re: CRDA and cross-compilation
From: Pavel Roskin @ 2009-08-06 19:08 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jon Loeliger, Philip A. Prindeville, linux-wireless
In-Reply-To: <43e72e890908061142w41d3c0e8x1dc81ffd3ac5b8ae@mail.gmail.com>
On Thu, 2009-08-06 at 11:42 -0700, Luis R. Rodriguez wrote:
> > -all: $(REG_BIN) crda intersect verify
> > +all: all_noverify verify
> > +
> > +all_noverify: crda intersect regdbdump
>
> You removed REG_BIN from here, was that intentional?
Yes. It's not needed for the build. As for the "verify" target, it
already depends on $(REG_BIN)
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] cfg80211: Set WEP ciphers
From: Samuel Ortiz @ 2009-08-06 19:04 UTC (permalink / raw)
To: John W. Linville; +Cc: Zhu, Yi, Johannes Berg, linux-wireless
With iwconfig there is no way to properly set the ciphers when trying to
connect to a WEP SSID. Although mac80211 based drivers dont need it, several
fullmac drivers do.
This patch basically sets the WEP ciphers whenever they're not set at all.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
---
net/wireless/sme.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 8a7dcbf..b78a111 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -638,14 +638,28 @@ int __cfg80211_connect(struct cfg80211_registered_device *rdev,
if (connkeys && connkeys->def >= 0) {
int idx;
+ u32 cipher;
idx = connkeys->def;
+ cipher = connkeys->params[idx].cipher;
/* If given a WEP key we may need it for shared key auth */
- if (connkeys->params[idx].cipher == WLAN_CIPHER_SUITE_WEP40 ||
- connkeys->params[idx].cipher == WLAN_CIPHER_SUITE_WEP104) {
+ if (cipher == WLAN_CIPHER_SUITE_WEP40 ||
+ cipher == WLAN_CIPHER_SUITE_WEP104) {
connect->key_idx = idx;
connect->key = connkeys->params[idx].key;
connect->key_len = connkeys->params[idx].key_len;
+
+ /*
+ * If ciphers are not set (e.g. when going through
+ * iwconfig), we have to set them appropriately here.
+ */
+ if (connect->crypto.cipher_group == 0)
+ connect->crypto.cipher_group = cipher;
+
+ if (connect->crypto.n_ciphers_pairwise == 0) {
+ connect->crypto.n_ciphers_pairwise = 1;
+ connect->crypto.ciphers_pairwise[0] = cipher;
+ }
}
}
--
1.6.3.1
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply related
* Re: [PATCH] pci_ids.h: add new Atheros USB vendor ID
From: Greg KH @ 2009-08-06 18:33 UTC (permalink / raw)
To: Dave Jones, Marcel Holtmann, Luis R. Rodriguez, linville,
linux-kernel, linux-wireless, zhifeng.cai, stephen.chen,
linux-usb
In-Reply-To: <20090806181546.GA11589@redhat.com>
On Thu, Aug 06, 2009 at 02:15:46PM -0400, Dave Jones wrote:
> On Wed, Aug 05, 2009 at 10:09:32PM -0700, Greg Kroah-Hartman wrote:
> > > the closest we have is drivers/hid/hid-ids.h and we might just should
> > > have Greg create a usb-ids.h file.
> >
> > Ick, no, there's no such file for a good reason. Put your device ids in
> > the driver files, no need to share it across the whole kernel.
>
> I agree. In fact, I'd go further, and say that the bulk of what we have
> in pci_ids.h is also pointlessly shared. Only a tiny fraction of the device
> entries in that file are used by multiple files in the kernel.
I agree with that as well, which is why when I was PCI maintainer, I
didn't allow any new additions to the pci_ids.h file, unless it was
going to be an id that was shared by different drivers. That cut the
new additions down to about none :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] pci_ids.h: add new Atheros USB vendor ID
From: Joe Perches @ 2009-08-06 18:50 UTC (permalink / raw)
To: Dave Jones
Cc: Greg KH, Marcel Holtmann, Luis R. Rodriguez, linville,
linux-kernel, linux-wireless, zhifeng.cai, stephen.chen,
linux-usb
In-Reply-To: <20090806181546.GA11589@redhat.com>
On Thu, 2009-08-06 at 14:15 -0400, Dave Jones wrote:
> On Wed, Aug 05, 2009 at 10:09:32PM -0700, Greg Kroah-Hartman wrote:
> > > the closest we have is drivers/hid/hid-ids.h and we might just should
> > > have Greg create a usb-ids.h file.
> > Ick, no, there's no such file for a good reason. Put your device ids in
> > the driver files, no need to share it across the whole kernel.
> I agree. In fact, I'd go further, and say that the bulk of what we have
> in pci_ids.h is also pointlessly shared. Only a tiny fraction of the device
> entries in that file are used by multiple files in the kernel.
I created some scripts a while ago to go through the
kernel to convert struct pci_device definitions to use
PCI_VDEVICE and PCI_DEVICE.
I could move definitions out of the pci_ids.h file at
the same time and closer to their actual use if those
definitions were not globally used. Maybe move them
by module or by specific file.
Perhaps like this example unsigned, not to be applied,
patch below:
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index d2ba04d..e978eb8 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -264,30 +264,12 @@ static void amd_iso_dev_put(void)
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
- {
- PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x740c),
- .driver_data = (unsigned long)ohci_quirk_amd756,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_OPTI, 0xc861),
- .driver_data = (unsigned long)ohci_quirk_opti,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_ANY_ID),
- .driver_data = (unsigned long)ohci_quirk_ns,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xa0f8),
- .driver_data = (unsigned long)ohci_quirk_zfmicro,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA_2, 0x01b6),
- .driver_data = (unsigned long)ohci_quirk_toshiba_scc,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB),
- .driver_data = (unsigned long)ohci_quirk_nec,
- },
+ { PCI_UNNAMED_DEVICE(AMD, 0x740c), .driver_data = (unsigned long)ohci_quirk_amd756 },
+ { PCI_UNNAMED_DEVICE(OPTI, 0xc861), .driver_data = (unsigned long)ohci_quirk_opti },
+ { PCI_UNNAMED_DEVICE(NS, PCI_ANY_ID), .driver_data = (unsigned long)ohci_quirk_ns },
+ { PCI_UNNAMED_DEVICE(COMPAQ, 0xa0f8), .driver_data = (unsigned long)ohci_quirk_zfmicro },
+ { PCI_UNNAMED_DEVICE(TOSHIBA_2, 0x01b6), .driver_data = (unsigned long)ohci_quirk_toshiba_scc },
+ { PCI_NAMED_DEVICE(NEC, NEC_USB), .driver_data = (unsigned long)ohci_quirk_nec },
{
/* Toshiba portege 4000 */
.vendor = PCI_VENDOR_ID_AL,
@@ -296,22 +278,10 @@ static const struct pci_device_id ohci_pci_quirks[] = {
.subdevice = 0x0004,
.driver_data = (unsigned long) broken_suspend,
},
- {
- PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152),
- .driver_data = (unsigned long) broken_suspend,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4397),
- .driver_data = (unsigned long)ohci_quirk_amd700,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4398),
- .driver_data = (unsigned long)ohci_quirk_amd700,
- },
- {
- PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
- .driver_data = (unsigned long)ohci_quirk_amd700,
- },
+ { PCI_UNNAMED_DEVICE(ITE, 0x8152), .driver_data = (kernel_ulong_t)broken_suspend },
+ { PCI_UNNAMED_DEVICE(ATI, 0x4397), .driver_data = (kernel_ulong_t)ohci_quirk_amd700 },
+ { PCI_UNNAMED_DEVICE(ATI, 0x4398), .driver_data = (kernel_ulong_t)ohci_quirk_amd700 },
+ { PCI_UNNAMED_DEVICE(ATI, 0x4399), .driver_data = (kernel_ulong_t)ohci_quirk_amd700 },
/* FIXME for some of the early AMD 760 southbridges, OHCI
* won't work at all. blacklist them.
diff --git a/drivers/usb/host/whci/hcd.c b/drivers/usb/host/whci/hcd.c
index e019a50..91e6563 100644
--- a/drivers/usb/host/whci/hcd.c
+++ b/drivers/usb/host/whci/hcd.c
@@ -351,7 +351,7 @@ static void __exit whci_hc_driver_exit(void)
module_exit(whci_hc_driver_exit);
/* PCI device ID's that we handle (so it gets loaded) */
-static struct pci_device_id whci_hcd_id_table[] = {
+static const struct pci_device_id whci_hcd_id_table[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_WIRELESS_WHCI, ~0) },
{ /* empty last entry */ }
};
^ permalink raw reply related
* Re: [PATCH] rndis_wlan: wait association to complete
From: Johannes Berg @ 2009-08-06 18:46 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, linville, Jouni Malinen
In-Reply-To: <20090806181746.31308.15687.stgit@fate.lan>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
On Thu, 2009-08-06 at 21:17 +0300, Jussi Kivilinna wrote:
> Fix WPA authentication problems by waiting to association to complete.
> Otherwise userspace (wpa_supplicant) receives authentication packets before
> association events from driver.
> + /* If we return now, userspace would get association events too late
> + * (after receiving first packets from access point). This causes
> + * WPA authentication to fail.
This is a bit weird, shouldn't you just send the event later then?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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