* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Luis R. Rodriguez @ 2010-07-14 20:32 UTC (permalink / raw)
To: Philip A. Prindeville
Cc: Luis Rodriguez, Hauke Mehrtens, linux-wireless@vger.kernel.org,
mcgrof@infradead.org
In-Reply-To: <4C3E1315.5050607@redfish-solutions.com>
On Wed, Jul 14, 2010 at 12:42:13PM -0700, Philip A. Prindeville wrote:
> On 07/14/2010 12:33 PM, Luis R. Rodriguez wrote:
> > On Wed, Jul 14, 2010 at 11:11 AM, Philip A. Prindeville
> > <philipp_subx@redfish-solutions.com> wrote:
> >> On 07/13/2010 04:44 PM, Luis R. Rodriguez wrote:
> >>> On Tue, Jul 13, 2010 at 2:54 PM, Luis R. Rodriguez
> >>> <lrodriguez@atheros.com> wrote:
> >>>> On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
> >>>> <philipp_subx@redfish-solutions.com> wrote:
> >>>>> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
> >>>>>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> >>>>>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
> >>>>>>> not if just CONFIG_PM is set.
> >>>>>>>
> >>>>>>> This should fix the problems reported by Philip Prindeville.
> >>>>>>>
> >>>>>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> >>>>>>
> >>>>>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
> >>>>>>
> >>>>>> Luis
> >>>>>
> >>>>> And...
> >>>>>
> >>>>>
> >>>>> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
> >>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
> >>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
> >>>>> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
> >>>>> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
> >>>>> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
> >>>>> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
> >>>>> make[1]: *** [modules] Error 2
> >>>>> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
> >>>>> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
> >>>>
> >>>> Thanks for reporting this, I am working on it now.
> >>>
> >>> This is now fixed, I'll push out a new tarball shortly.
> >>>
> >>> Luis
> >>
> >> That tarball never made it out... can you please retry?
> >
> > The cronjob kicks off at noon PST time.
> >
> > Luis
>
> Just picked up the tarball:
>
> /home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.c: In function 'rt2x00pci_initialize':
> /home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.c:156: error: implicit declaration of function 'request_threaded_irq'
> make[5]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.o] Error 1
> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00] Error 2
> make[4]: *** Waiting for unfinished jobs....
>
>
> I'm thinking that it might be good to have a variety of nightly builds to detect damage. Do you all have infrastructure for that?
Yeah, feel free to send patches against this to enable that:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-user.git
Otherwise I'll get to it when I can.
> This is building against 2.6.27.48
Hauke pointed out threaded ISR stuff needs to be done as was done with b43.
Luis
^ permalink raw reply
* [PATCH] compat-wireless: backport threaded-irq for rt2x00
From: Hauke Mehrtens @ 2010-07-14 20:49 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, philipp_subx, Hauke Mehrtens
This backport was done like for the b43 driver. This was just build tested.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/09-threaded-irq.patch | 55 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/patches/09-threaded-irq.patch b/patches/09-threaded-irq.patch
index c1a33e1..cdc506d 100644
--- a/patches/09-threaded-irq.patch
+++ b/patches/09-threaded-irq.patch
@@ -61,3 +61,58 @@ thread in process context as well.
};
/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
+--- a/drivers/net/wireless/rt2x00/rt2x00.h
++++ b/drivers/net/wireless/rt2x00/rt2x00.h
+@@ -882,6 +882,9 @@ struct rt2x00_dev {
+ * and interrupt thread routine.
+ */
+ u32 irqvalue[2];
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ struct compat_threaded_irq irq_compat;
++#endif
+ };
+
+ /*
+--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
++++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
+@@ -153,10 +153,18 @@ int rt2x00pci_initialize(struct rt2x00_d
+ /*
+ * Register interrupt handler.
+ */
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ status = compat_request_threaded_irq(&rt2x00dev->irq_compat,
++ rt2x00dev->irq,
++ rt2x00dev->ops->lib->irq_handler,
++ rt2x00dev->ops->lib->irq_handler_thread,
++ IRQF_SHARED, rt2x00dev->name, rt2x00dev);
++#else
+ status = request_threaded_irq(rt2x00dev->irq,
+ rt2x00dev->ops->lib->irq_handler,
+ rt2x00dev->ops->lib->irq_handler_thread,
+ IRQF_SHARED, rt2x00dev->name, rt2x00dev);
++#endif
+ if (status) {
+ ERROR(rt2x00dev, "IRQ %d allocation failed (error %d).\n",
+ rt2x00dev->irq, status);
+@@ -180,7 +188,11 @@ void rt2x00pci_uninitialize(struct rt2x0
+ /*
+ * Free irq line.
+ */
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ compat_free_threaded_irq(&rt2x00dev->irq_compat);
++#else
+ free_irq(rt2x00dev->irq, rt2x00dev);
++#endif
+
+ /*
+ * Free DMA
+@@ -195,6 +207,9 @@ EXPORT_SYMBOL_GPL(rt2x00pci_uninitialize
+ */
+ static void rt2x00pci_free_reg(struct rt2x00_dev *rt2x00dev)
+ {
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ compat_destroy_threaded_irq(&rt2x00dev->irq_compat);
++#endif
+ kfree(rt2x00dev->rf);
+ rt2x00dev->rf = NULL;
+
--
1.7.0.4
^ permalink raw reply related
* Re: Rate control & USB
From: Ivo Van Doorn @ 2010-07-14 21:36 UTC (permalink / raw)
To: Julian Calaby; +Cc: Helmut Schaa, linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <AANLkTilWtwXuJ8ZA_QHDGURnbTOwlJXivBewSvAr4ncj@mail.gmail.com>
On Wed, Jul 14, 2010 at 3:53 AM, Julian Calaby <julian.calaby@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 05:51, Ivo Van Doorn <ivdoorn@gmail.com> wrote:
>> On Tue, Jul 13, 2010 at 9:15 PM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>>> Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn:
>>>> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa
>>>> <helmut.schaa@googlemail.com> wrote:
>>>> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn:
>>>> >> I am currently looking into the old problem of the mac80211 rate
>>>> >> control algorithms
>>>> >> and USB devices. The Ralink USB devices (and as far as I know, the
>>>> >> other USB devices
>>>> >> as well), do not work well with the PID and Minstrel algorithms. This
>>>> >> is caused by the
>>>> >> fact that USB devices do not report the TX status to mac80211.
>>>> >
>>>> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO
>>>> > register like the PCI variants? Does it contain useful data or just crap?
>>>>
>>>> Well I guess he has the registers (we don't have rt2870 specific specsheets,
>>>> but the register definitions from the original Ralink driver to
>>>> suggest the register
>>>> is there). However, even if it contains valid data, how do you want to match
>>>> the contents of that register with the sent frames in the queue?
>>>
>>> We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should
>>> contain the same ID alongside the TX status after the frame was processed
>>> by the hw.
>>
>> True, but we would have the same problem in rt2800pci, that the number
>> of bits is too limited to completely identify a queue + queue index correctly.
>
> We could have a table that matches queue and queue index to the
> packet's ID. So if we're sending packet #47 from queue #1, and it gets
> assigned id #9, then we drop that information into the table - so when
> the hardware tells us the status of packet id #9 we can look up which
> queue it is and send it to the right place.
True, but the overhead of having that lookup table is not really worth
it I believe.
This solution depends on the number of bits available, thus it works
only for rt2800usb,
while with a different RC method I am looking for a more generic solution.
> Of course, this means storing a stack of extra data in system memory,
> as well as having the complexity of looking up the queue data when we
> get the status back, but if we've only got limited bits, then that'll
> set a hard limit on the amount of data and time to retrieve, and we
> may not even need all of it unless the hardware's running at full
> capacity. We could reduce it further if we don't need a status of
> *every* packet - we could potentially get away with only storing data
> for, let's say, every fourth packet or something.
Well it should be up to the RC algorithm to indicate for which frames
it at least demands a TX status and for which frames it is less important.
> As we're likely to see similarly crippled devices elsewhere, maybe we
> could incorporate this type of accounting into mac80211 somewhere.
That really depends on which devices actually have the TX status reporting
registers without any mapping to a real packet. I think there are more devices
without TX status reporting and without TX status registers, than those with the
TX status registers.
Ivo
^ permalink raw reply
* Re: [PATCH] compat-wireless: backport threaded-irq for rt2x00
From: Luis R. Rodriguez @ 2010-07-14 21:41 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof, philipp_subx
In-Reply-To: <1279140598-6509-1-git-send-email-hauke@hauke-m.de>
On Wed, Jul 14, 2010 at 1:49 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> This backport was done like for the b43 driver. This was just build tested.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Thanks!!! Applied
Luis
^ permalink raw reply
* [PATCH] minstrel_ht: fix freeze with legacy hardware
From: Christian Lamparter @ 2010-07-14 21:43 UTC (permalink / raw)
To: linux-wireless; +Cc: John W Linville, Felix Fietkau
Ever since minstrel_ht was prompted to be the default RC,
I had an this odd freeze in ieee80211_tx_status,
whenever I tried to connect my p54*(legacy 11abg) to
a 802.11n network.
Apparently, minstrel_ht was not interested if the hardware
supported 802.11n or not?
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Note: There's another possible way to fix this.
We can simply AND sta's ht_supported bool with
the setting in sband's ht_supported.
The advantage is that we won't need this patch
and the procedure would "match" to what we did
with the ht_cap flags.
This is up for debate... But in the meantime,
here's a fix.
P.S.: is there a valid operation situation
where sta is be NULL, but priv_sta isn't?
---
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index b5ace24..8ad3630 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -635,8 +635,12 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
int stbc;
int i;
- /* fall back to the old minstrel for legacy stations */
- if (sta && !sta->ht_cap.ht_supported) {
+ /*
+ * fall back to the old minstrel for legacy stations,
+ * or on legacy hardware.
+ */
+ if ((sta && !sta->ht_cap.ht_supported) ||
+ !sband->ht_cap.ht_supported) {
msp->is_ht = false;
memset(&msp->legacy, 0, sizeof(msp->legacy));
msp->legacy.r = msp->ratelist;
^ permalink raw reply related
* Re: [PATCH] minstrel_ht: fix freeze with legacy hardware
From: Felix Fietkau @ 2010-07-14 21:50 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John W Linville
In-Reply-To: <201007142343.33937.chunkeey@googlemail.com>
On 2010-07-14 11:43 PM, Christian Lamparter wrote:
> Ever since minstrel_ht was prompted to be the default RC,
> I had an this odd freeze in ieee80211_tx_status,
> whenever I tried to connect my p54*(legacy 11abg) to
> a 802.11n network.
>
> Apparently, minstrel_ht was not interested if the hardware
> supported 802.11n or not?
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> Note: There's another possible way to fix this.
> We can simply AND sta's ht_supported bool with
> the setting in sband's ht_supported.
>
> The advantage is that we won't need this patch
> and the procedure would "match" to what we did
> with the ht_cap flags.
>
> This is up for debate... But in the meantime,
> here's a fix.
>
> P.S.: is there a valid operation situation
> where sta is be NULL, but priv_sta isn't?
Either of those two options is OK with me. I would prefer masking it in
mac80211 though, since the sta ht setting are already partially masked
by hw capabilities.
- Felix
^ permalink raw reply
* [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Luis R. Rodriguez @ 2010-07-15 0:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Tushit Jain, Kyungwan Nam
An A-MPDU may contain several subframes each containing its own
CRC for the data. Each subframe also has a respective CRC for the
MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
ACK frames that have a valid data CRC but have failed to pass the
CRC for the MPDU length, if and only if the subframe is not the
last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
been caught. Discarding those subframes results in packet loss under
heavy stress conditions, an example being UDP video. Since the
frames are ACK'd by hardware we need to let these frames through
and process them as valid frames.
Cc: Tushit Jain <tushit.jain@atheros.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31 +++++++++++++++++++++++++-
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 06ef710..5b995be 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -579,12 +579,39 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_flags |= ATH9K_RX_DECRYPT_BUSY;
if ((rxsp->status11 & AR_RxFrameOK) == 0) {
+ /*
+ * AR_CRCErr will bet set to true if we're on the last
+ * subframe and the AR_PostDelimCRCErr is caught.
+ * In a way this also gives us a guarantee that when
+ * (!(AR_CRCErr) && (AR_PostDelimCRCErr)) we cannot
+ * possibly be reviewing the last subframe. AR_CRCErr
+ * is the CRC of the actual data.
+ */
if (rxsp->status11 & AR_CRCErr) {
rxs->rs_status |= ATH9K_RXERR_CRC;
} else if (rxsp->status11 & AR_PHYErr) {
- rxs->rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(rxsp->status11, AR_PHYErrCode);
- rxs->rs_phyerr = phyerr;
+ /*
+ * If we reach a point here where AR_PostDelimCRCErr is
+ * true it implies we're *not* on the last subframe. In
+ * in that case that we know already that the CRC of
+ * the frame was OK, and MAC would send an ACK for that
+ * subframe, even if we did get a phy error of type
+ * ATH9K_PHYERR_OFDM_RESTART. This is only applicable
+ * to frame that are prior to the last subframe.
+ * The AR_PostDelimCRCErr is the CRC for the MPDU
+ * delimiter, which contains the 4 reserved bits,
+ * the MPDU length (12 bits), and follows the MPDU
+ * delimiter for an A-MPDU subframe (0x4E = 'N' ASCII).
+ */
+ if ((phyerr == ATH9K_PHYERR_OFDM_RESTART) &&
+ (rxsp->status11 & AR_PostDelimCRCErr)) {
+ rxs->rs_phyerr = 0;
+ } else {
+ rxs->rs_status |= ATH9K_RXERR_PHY;
+ rxs->rs_phyerr = phyerr;
+ }
+
} else if (rxsp->status11 & AR_DecryptCRCErr) {
rxs->rs_status |= ATH9K_RXERR_DECRYPT;
} else if (rxsp->status11 & AR_MichaelErr) {
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Satya @ 2010-07-15 3:24 UTC (permalink / raw)
To: Luis R. Rodriguez, linville
Cc: linux-wireless, Luis R. Rodriguez, Tushit Jain, Kyungwan Nam
In-Reply-To: <1279152521-10805-1-git-send-email-lrodriguez@atheros.com>
I just wonder if the delimiter length CRC is wrong, where from we
get the length of the data packet to get to a state where we say
we have received the data packet with correct CRC ?
I am not sure about this. I appreciate if someone could clarify this.
Thanks.
Regards,
Satya.
----- Original Message -----
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: <linville@tuxdriver.com>
Cc: <linux-wireless@vger.kernel.org>; "Luis R. Rodriguez"
<lrodriguez@atheros.com>; "Tushit Jain" <tushit.jain@atheros.com>; "Kyungwan
Nam" <kyungwan.nam@atheros.com>
Sent: Thursday, July 15, 2010 5:38 AM
Subject: [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle
subframes
> An A-MPDU may contain several subframes each containing its own
> CRC for the data. Each subframe also has a respective CRC for the
> MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
> ACK frames that have a valid data CRC but have failed to pass the
> CRC for the MPDU length, if and only if the subframe is not the
> last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
> been caught. Discarding those subframes results in packet loss under
> heavy stress conditions, an example being UDP video. Since the
> frames are ACK'd by hardware we need to let these frames through
> and process them as valid frames.
>
> Cc: Tushit Jain <tushit.jain@atheros.com>
> Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31
> +++++++++++++++++++++++++-
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> index 06ef710..5b995be 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> @@ -579,12 +579,39 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah,
> struct ath_rx_status *rxs,
> rxs->rs_flags |= ATH9K_RX_DECRYPT_BUSY;
>
> if ((rxsp->status11 & AR_RxFrameOK) == 0) {
> + /*
> + * AR_CRCErr will bet set to true if we're on the last
> + * subframe and the AR_PostDelimCRCErr is caught.
> + * In a way this also gives us a guarantee that when
> + * (!(AR_CRCErr) && (AR_PostDelimCRCErr)) we cannot
> + * possibly be reviewing the last subframe. AR_CRCErr
> + * is the CRC of the actual data.
> + */
> if (rxsp->status11 & AR_CRCErr) {
> rxs->rs_status |= ATH9K_RXERR_CRC;
> } else if (rxsp->status11 & AR_PHYErr) {
> - rxs->rs_status |= ATH9K_RXERR_PHY;
> phyerr = MS(rxsp->status11, AR_PHYErrCode);
> - rxs->rs_phyerr = phyerr;
> + /*
> + * If we reach a point here where AR_PostDelimCRCErr is
> + * true it implies we're *not* on the last subframe. In
> + * in that case that we know already that the CRC of
> + * the frame was OK, and MAC would send an ACK for that
> + * subframe, even if we did get a phy error of type
> + * ATH9K_PHYERR_OFDM_RESTART. This is only applicable
> + * to frame that are prior to the last subframe.
> + * The AR_PostDelimCRCErr is the CRC for the MPDU
> + * delimiter, which contains the 4 reserved bits,
> + * the MPDU length (12 bits), and follows the MPDU
> + * delimiter for an A-MPDU subframe (0x4E = 'N' ASCII).
> + */
> + if ((phyerr == ATH9K_PHYERR_OFDM_RESTART) &&
> + (rxsp->status11 & AR_PostDelimCRCErr)) {
> + rxs->rs_phyerr = 0;
> + } else {
> + rxs->rs_status |= ATH9K_RXERR_PHY;
> + rxs->rs_phyerr = phyerr;
> + }
> +
> } else if (rxsp->status11 & AR_DecryptCRCErr) {
> rxs->rs_status |= ATH9K_RXERR_DECRYPT;
> } else if (rxsp->status11 & AR_MichaelErr) {
> --
> 1.7.0.4
>
> --
> 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] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Luis R. Rodriguez @ 2010-07-15 4:21 UTC (permalink / raw)
To: Satya; +Cc: linville, linux-wireless, Tushit Jain, Kyungwan Nam
In-Reply-To: <003201cb23cd$527f3f90$aa01a8c0@satya>
On Wed, Jul 14, 2010 at 8:24 PM, Satya <satya.rao@redpinesignals.com> wrote:
>
> I just wonder if the delimiter length CRC is wrong, where from we
> get the length of the data packet to get to a state where we say
> we have received the data packet with correct CRC ?
>
> I am not sure about this. I appreciate if someone could clarify this.
> Thanks.
Great question :), Kyungwan, Kyungwan?
PS. This e-mail thread is on a public mailing list.
Luis
^ permalink raw reply
* [patch] orinoco_usb: potential null dereference
From: Dan Carpenter @ 2010-07-15 8:23 UTC (permalink / raw)
To: Pavel Roskin
Cc: David Gibson, John W. Linville, David Kilroy, linux-wireless,
orinoco-devel, kernel-janitors
Smatch complains that "upriv->read_urb" gets dereferenced before
checking for NULL. It turns out that it's possible for
"upriv->read_urb" to be NULL so I added checks around the dereferences.
Also I remove an "if (upriv->bap_buf != NULL)" check because
"kfree(NULL) is OK.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/orinoco/orinoco_usb.c b/drivers/net/wireless/orinoco/orinoco_usb.c
index 78f089b..11d5ec2 100644
--- a/drivers/net/wireless/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/orinoco/orinoco_usb.c
@@ -1504,16 +1504,16 @@ static inline void ezusb_delete(struct ezusb_priv *upriv)
ezusb_ctx_complete(list_entry(item,
struct request_context, list));
- if (upriv->read_urb->status == -EINPROGRESS)
+ if (upriv->read_urb && upriv->read_urb->status == -EINPROGRESS)
printk(KERN_ERR PFX "Some URB in progress\n");
mutex_unlock(&upriv->mtx);
- kfree(upriv->read_urb->transfer_buffer);
- if (upriv->bap_buf != NULL)
- kfree(upriv->bap_buf);
- if (upriv->read_urb != NULL)
+ if (upriv->read_urb) {
+ kfree(upriv->read_urb->transfer_buffer);
usb_free_urb(upriv->read_urb);
+ }
+ kfree(upriv->bap_buf);
if (upriv->dev) {
struct orinoco_private *priv = ndev_priv(upriv->dev);
orinoco_if_del(priv);
^ permalink raw reply related
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Bartlomiej Zolnierkiewicz @ 2010-07-15 8:41 UTC (permalink / raw)
To: Felix Fietkau
Cc: John W. Linville, Ivo Van Doorn, Christoph Egger,
Gertjan van Wingerde, Helmut Schaa, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <4C3DCD5C.1080705@openwrt.org>
On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> On 2010-07-14 3:15 PM, John W. Linville wrote:
> > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> >> so all Code depending on that can't ever be selected and, if there's
> >> >> no plan to add these options, should be cleaned up
> >> >>
> >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
> >> >
> >> > NAK,
> >> >
> >> > this is not dead code, it is needed for the Ralink System-on-Chip
> >> > Platform devices.
> >> >
> >> > While I can't fix Kconfig errors and the current KConfig file may be
> >> > wrong, this code cannot and will not be deleted.
> >>
> >> When the config option was introduced, the config options RALINK_RT288X and
> >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> >>
> >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> >> isn't dead but actually in use.
> >
> > Perhaps Helmut and Felix can send us the missing code?
> The missing code is a MIPS platform port, which is currently being
> maintained in OpenWrt, but is not ready for upstream submission yet.
> I'm not working on this code at the moment, but I think it will be
> submitted once it's ready.
People are using automatic scripts to catch unused config options nowadays
so the issue is quite likely to come back again sooner or later..
Would it be possible to improve situation somehow till the missing parts
get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
situation to Kconfig (if the config option itself really cannot be removed)
until all code is ready etc.?
I bet that Christoph would be willing to update his patch if you ask him
nicely..
Thanks,
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: Bug#588196: b43: does not join multicast groups
From: Simon Richter @ 2010-07-15 8:51 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, Ben Hutchings, Stefano Brivio, linux-wireless,
588196
In-Reply-To: <4C3DB065.70009@bu3sch.de>
Hi,
On Wed, Jul 14, 2010 at 02:41:09PM +0200, Michael Büsch wrote:
> The same applies to receiving. The RX queue is also dropped on switch
> from DMA to PIO.
Sure, but the packet is repeated every ten seconds. The problem is that
none of those packets is received, even long after the switch to PIO.
> >advertisement, sent to 33:33:00:00:00:01). I have no idea where the
> >packet is dropped; from my somewhat limited understanding of 802.11, I'd
> >expect the frames to be treated like broadcast frames by the AP, so it'd
> >be the receiver dropping them in the MAC filter.
> The actual switch from DMA to PIO mode completely reinitializes
> the hardware and drops all queues.
Would it be possible to reinitialize the multicast filter at this point?
Simon
^ permalink raw reply
* [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: yogeshp @ 2010-07-15 13:18 UTC (permalink / raw)
To: linville; +Cc: Nishant Sarmukadam, Pradeep Nemavat, linux-wireless
BA window size for a successful BA setup is not made available to the driver by
mac80211. The patch below gets the BA window size from addba response and
indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
Signed-off-by: yogeshp@marvell.com
Signed-off-by: nishants@marvell.com
---
include/net/mac80211.h | 3 ++-
net/mac80211/agg-rx.c | 4 ++--
net/mac80211/agg-tx.c | 17 ++++++++++-------
net/mac80211/driver-ops.h | 6 +++---
net/mac80211/driver-trace.h | 2 +-
net/mac80211/sta_info.h | 1 +
6 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7f256e2..29ff874 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1734,7 +1734,8 @@ struct ieee80211_ops {
int (*ampdu_action)(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn);
+ struct ieee80211_sta *sta, u16 tid,
+ u16 buf_size, u16 *ssn);
int (*get_survey)(struct ieee80211_hw *hw, int idx,
struct survey_info *survey);
void (*rfkill_poll)(struct ieee80211_hw *hw);
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 965b272..8a2522f 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -76,7 +76,7 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
#endif /* CONFIG_MAC80211_HT_DEBUG */
if (drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_STOP,
- &sta->sta, tid, NULL))
+ &sta->sta, tid, 0, NULL))
printk(KERN_DEBUG "HW problem - can not stop rx "
"aggregation for tid %d\n", tid);
@@ -274,7 +274,7 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
}
ret = drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_START,
- &sta->sta, tid, &start_seq_num);
+ &sta->sta, tid, 0, &start_seq_num);
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "Rx A-MPDU request on tid %d result %d\n", tid, ret);
#endif /* CONFIG_MAC80211_HT_DEBUG */
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index c893f23..4332ca8 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -186,7 +186,7 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
ret = drv_ampdu_action(local, sta->sdata,
IEEE80211_AMPDU_TX_STOP,
- &sta->sta, tid, NULL);
+ &sta->sta, tid, 0, NULL);
/* HW shall not deny going back to legacy */
if (WARN_ON(ret)) {
@@ -307,7 +307,7 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
start_seq_num = sta->tid_seq[tid] >> 4;
ret = drv_ampdu_action(local, sdata, IEEE80211_AMPDU_TX_START,
- &sta->sta, tid, &start_seq_num);
+ &sta->sta, tid, 0, &start_seq_num);
if (ret) {
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "BA request denied - HW unavailable for"
@@ -470,7 +470,7 @@ ieee80211_agg_splice_finish(struct ieee80211_local *local, u16 tid)
}
static void ieee80211_agg_tx_operational(struct ieee80211_local *local,
- struct sta_info *sta, u16 tid)
+ struct sta_info *sta, u16 tid, u16 buf_size)
{
lockdep_assert_held(&sta->ampdu_mlme.mtx);
@@ -480,7 +480,7 @@ static void ieee80211_agg_tx_operational(struct ieee80211_local *local,
drv_ampdu_action(local, sta->sdata,
IEEE80211_AMPDU_TX_OPERATIONAL,
- &sta->sta, tid, NULL);
+ &sta->sta, tid, buf_size, NULL);
/*
* synchronize with TX path, while splicing the TX path
@@ -541,7 +541,7 @@ void ieee80211_start_tx_ba_cb(struct ieee80211_vif *vif, u8 *ra, u16 tid)
goto unlock;
if (test_bit(HT_AGG_STATE_RESPONSE_RECEIVED, &tid_tx->state))
- ieee80211_agg_tx_operational(local, sta, tid);
+ ieee80211_agg_tx_operational(local, sta, tid, tid_tx->buf_size);
unlock:
mutex_unlock(&sta->ampdu_mlme.mtx);
@@ -733,10 +733,11 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
size_t len)
{
struct tid_ampdu_tx *tid_tx;
- u16 capab, tid;
+ u16 capab, tid, buf_size;
capab = le16_to_cpu(mgmt->u.action.u.addba_resp.capab);
tid = (capab & IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
+ buf_size = (capab & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK) >> 6;
mutex_lock(&sta->ampdu_mlme.mtx);
@@ -753,6 +754,8 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
del_timer(&tid_tx->addba_resp_timer);
+ tid_tx->buf_size = buf_size;
+
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "switched off addBA timer for tid %d\n", tid);
#endif
@@ -766,7 +769,7 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
}
if (test_bit(HT_AGG_STATE_DRV_READY, &tid_tx->state))
- ieee80211_agg_tx_operational(local, sta, tid);
+ ieee80211_agg_tx_operational(local, sta, tid, buf_size);
sta->ampdu_mlme.addba_req_num[tid] = 0;
} else {
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 14123dc..383eee7 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -354,17 +354,17 @@ static inline int drv_ampdu_action(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta, u16 tid,
- u16 *ssn)
+ u16 buf_size, u16 *ssn)
{
int ret = -EOPNOTSUPP;
might_sleep();
- trace_drv_ampdu_action(local, sdata, action, sta, tid, ssn);
+ trace_drv_ampdu_action(local, sdata, action, sta, tid, buf_size, ssn);
if (local->ops->ampdu_action)
ret = local->ops->ampdu_action(&local->hw, &sdata->vif, action,
- sta, tid, ssn);
+ sta, tid, buf_size, ssn);
trace_drv_return_int(local, ret);
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 5d5d2a9..c98bce0 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -733,7 +733,7 @@ TRACE_EVENT(drv_ampdu_action,
struct ieee80211_sub_if_data *sdata,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta, u16 tid,
- u16 *ssn),
+ u16 buf_size, u16 *ssn),
TP_ARGS(local, sdata, action, sta, tid, ssn),
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 54262e7..6685d4d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -95,6 +95,7 @@ struct tid_ampdu_tx {
unsigned long state;
u8 dialog_token;
u8 stop_initiator;
+ u16 buf_size;
};
/**
--
1.5.4.1
^ permalink raw reply related
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: John W. Linville @ 2010-07-15 13:28 UTC (permalink / raw)
To: yogeshp; +Cc: Nishant Sarmukadam, Pradeep Nemavat, linux-wireless
In-Reply-To: <4C3F0AA3.4050706@marvell.com>
On Thu, Jul 15, 2010 at 06:48:27PM +0530, yogeshp wrote:
> BA window size for a successful BA setup is not made available to the driver by
> mac80211. The patch below gets the BA window size from addba response and
> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
>
> Signed-off-by: yogeshp@marvell.com
> Signed-off-by: nishants@marvell.com
This patch seems to have a lot of whitespace damage. Please
follow the normal practices, etc. Also, the Signed-off-by: line
typically includes the full name (e.g. "Signed-off-by: Full Name
<namef@marvell.com>").
I didn't look too closely at the code itself, so I'll leave it to
others to comment on that...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Bug#588196: b43: does not join multicast groups
From: Michael Büsch @ 2010-07-15 13:45 UTC (permalink / raw)
To: Simon Richter
Cc: Larry Finger, Ben Hutchings, Stefano Brivio, linux-wireless,
588196
In-Reply-To: <20100715085149.GA9922@richter>
On 07/15/2010 10:51 AM, Simon Richter wrote:
>> The same applies to receiving. The RX queue is also dropped on switch
>> from DMA to PIO.
>
> Sure, but the packet is repeated every ten seconds. The problem is that
> none of those packets is received, even long after the switch to PIO.
The filter flags are not updated because (as I already said) the reinit
happens without mac80211's knowledge.
>> The actual switch from DMA to PIO mode completely reinitializes
>> the hardware and drops all queues.
>
> Would it be possible to reinitialize the multicast filter at this point?
Yeah everything is possible.
I'd rather like to see the actual _problem_ fixed instead of
continuing to waste hours and hours on the hackish workaround.
So in the end the workaround (aka PIO fallback) can be removed.
If this problem is fixed, the next one will show up. (For example
the fact that the PIO fallback won't work on an AP, too, for these
reasons).
Please work on fixing up the PCI core code, which most likely
causes the problem, instead of extending the workaround hack.
--
Greetings Michael.
^ permalink raw reply
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: Luis R. Rodriguez @ 2010-07-15 16:59 UTC (permalink / raw)
To: yogeshp; +Cc: linville, Nishant Sarmukadam, Pradeep Nemavat, linux-wireless
In-Reply-To: <4C3F0AA3.4050706@marvell.com>
On Thu, Jul 15, 2010 at 6:18 AM, yogeshp <yogeshp@marvell.com> wrote:
> BA window size for a successful BA setup is not made available to the driver by
> mac80211. The patch below gets the BA window size from addba response and
> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
But why do you want that? Your patch and commit log do not mention why
you need this. Also your patch does not address changing all of the
other drivers, and breaks compilation so NACK, WTF!
When I compile mac80211 with your patch it fails compilation:
CHECK net/mac80211/main.c
net/mac80211/main.c:617:9: error: invalid bitfield width, -1.
CC [M] net/mac80211/main.o
In file included from net/mac80211/driver-ops.h:7,
from net/mac80211/main.c:29:
net/mac80211/driver-trace.h: In function ‘trace_drv_ampdu_action’:
net/mac80211/driver-trace.h:731: warning: passing argument 7 of ‘(void
(*)(void *, struct ieee80211_local *, struct ieee80211_sub_if_data *,
enum ieee80211_ampdu_mlme_action, struct ieee80211_sta *, u16, u16,
u16 *))it_func’ makes integer from pointer without a cast
net/mac80211/driver-trace.h:731: note: expected ‘u16’ but argument is
of type ‘u16 *’
net/mac80211/driver-trace.h:731: error: too few arguments to function
‘(void (*)(void *, struct ieee80211_local *, struct
ieee80211_sub_if_data *, enum ieee80211_ampdu_mlme_action, struct
ieee80211_sta *, u16, u16, u16 *))it_func’
make[1]: *** [net/mac80211/main.o] Error 1
make: *** [_module_net/mac80211] Error 2
When I compile ath9k and ath9k_htc with this patch I also get:
CHECK drivers/net/wireless/ath/ath9k/main.c
drivers/net/wireless/ath/ath9k/main.c:2068:31: warning: incorrect type
in initializer (incompatible argument 6 (different base types))
drivers/net/wireless/ath/ath9k/main.c:2068:31: expected int (
*ampdu_action )( ... )
drivers/net/wireless/ath/ath9k/main.c:2068:31: got int ( static
[toplevel] *<noident> )( ... )
CC [M] drivers/net/wireless/ath/ath9k/main.o
drivers/net/wireless/ath/ath9k/main.c:2068: warning: initialization
from incompatible pointer type
CC [M] drivers/net/wireless/ath/ath9k/htc_drv_txrx.o
CHECK drivers/net/wireless/ath/ath9k/htc_drv_main.c
drivers/net/wireless/ath/ath9k/htc_drv_main.c:1846:31: warning:
incorrect type in initializer (incompatible argument 6 (different base
types))
drivers/net/wireless/ath/ath9k/htc_drv_main.c:1846:31: expected int
( *ampdu_action )( ... )
drivers/net/wireless/ath/ath9k/htc_drv_main.c:1846:31: got int (
static [toplevel] *<noident> )( ... )
CC [M] drivers/net/wireless/ath/ath9k/htc_drv_main.o
drivers/net/wireless/ath/ath9k/htc_drv_main.c:1846: warning:
initialization from incompatible pointer type
In fact I'm surprised this even compiles with your patch. If you want
to submit this make sure you use both checkpatch.pl to test your patch
and also use sparse to compile test. You can get sparse from:
git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git
I recommend to use use the v0.4.2 tag:
git checkout -b rel42 v0.4.2
make
make install
Then when compiling to test your patch use C=1 to use sparse.
make C=1 M=drivers/net/wireless/ath/ath9k/
> Signed-off-by: yogeshp@marvell.com
> Signed-off-by: nishants@marvell.com
Please read the Developer's Certificate of Origin 1.1, on
Documentation/SubmittingPatches.
Also please read:
http://wireless.kernel.org/en/developers/Documentation
Luis
^ permalink raw reply
* Re: [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Luis R. Rodriguez @ 2010-07-15 18:27 UTC (permalink / raw)
To: Satya; +Cc: linville, linux-wireless, Tushit Jain, Kyungwan Nam
In-Reply-To: <AANLkTimc0k8SmNnyRpa05luw6nKR-qy0rLBe09TBi4qS@mail.gmail.com>
On Wed, Jul 14, 2010 at 9:21 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Jul 14, 2010 at 8:24 PM, Satya <satya.rao@redpinesignals.com> wrote:
>>
>> I just wonder if the delimiter length CRC is wrong, where from we
>> get the length of the data packet to get to a state where we say
>> we have received the data packet with correct CRC ?
>>
>> I am not sure about this. I appreciate if someone could clarify this.
>> Thanks.
>
> Great question :), Kyungwan?
---- Kyungwan wrote:
Actually, the scenario we are addressing here is, delimiter "after" good
crc subframe has crc error such that AR9003 keeps searching next
delimiter but in a meanwhile, restart PHY error occurs and receiving stops.
In this case, by design, AR9003 reports these PHY error and delimiter crc
error by using Rx descriptor of good crc subframe and S/W used to discard
this good crc subframe because of PHY error. But after more investigation,
we found this scenario and we could save this good crc subframe with
the attached patch.
Please note that this happens only if AR9003 advanced feature
(restart PHY error) is enabled.excemption
----
So it seems that by design the delimiter CRC error status is just
borrowed for this exception by our MAC hardware folks to annotate this
specific situation.
Luis
^ permalink raw reply
* [PATCH] compat-wireless: refresh patch
From: Hauke Mehrtens @ 2010-07-15 18:50 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/03-rfkill.patch | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/patches/03-rfkill.patch b/patches/03-rfkill.patch
index 236891d..e8a9fe8 100644
--- a/patches/03-rfkill.patch
+++ b/patches/03-rfkill.patch
@@ -228,6 +228,6 @@ This would do the policing from within mac80211.
+#else
+#include <linux/rfkill_backport.h>
+#endif
+ #include <linux/workqueue.h>
#include "ath5k.h"
- #include "debug.h"
--
1.7.0.4
^ permalink raw reply related
* Compat-wireless release for 2010-07-15 is baked
From: Compat-wireless cronjob account @ 2010-07-15 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
73374eb..5f9a783 master -> origin/master
f88f925..4b87329 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
521acd5..bc3e7ea history -> origin/history
+ c9ce0c0...732f7b0 master -> origin/master (forced update)
* [new tag] next-20100715 -> next-20100715
compat-wireless code metrics
494061 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH] compat-wireless: refresh patch
From: Luis R. Rodriguez @ 2010-07-15 19:05 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1279219854-18193-1-git-send-email-hauke@hauke-m.de>
On Thu, Jul 15, 2010 at 11:50 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Nice timing, thanks, applied.
Luis
^ permalink raw reply
* Re: Compat-wireless release for 2010-07-15 is baked
From: Luis R. Rodriguez @ 2010-07-15 19:08 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20100715190302.C6699404F0@repository3.orbit-lab.org>
On Thu, Jul 15, 2010 at 12:03 PM, Compat-wireless cronjob account
<compat@orbit-lab.org> wrote:
> From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
> 73374eb..5f9a783 master -> origin/master
> f88f925..4b87329 wl -> origin/wl
> From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
> 521acd5..bc3e7ea history -> origin/history
> + c9ce0c0...732f7b0 master -> origin/master (forced update)
> * [new tag] next-20100715 -> next-20100715
>
> compat-wireless code metrics
>
> 494061 - Total upstream lines of code being pulled
This didn't get Hauke's last patch, will force a new one out shortly.
Luis
^ permalink raw reply
* [RFC] wireless: only use alpha2 regulatory information from country IE
From: John W. Linville @ 2010-07-15 19:06 UTC (permalink / raw)
To: linux-wireless; +Cc: mcgrof, kyle, John W. Linville
The meaning and/or usage of the country IE is somewhat poorly defined.
In practice, this means that regulatory rulesets in a country IE are
often incomplete and might be untrustworthy. This removes the code
associated with interpreting those rulesets while preserving respect
for country "alpha2" codes also contained in the country IE.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
This patch is compile-tested only! Please feel free to suggest that
I have left something out or missed some nuance of our regulatory
enforcement code...
include/net/regulatory.h | 1 -
net/wireless/reg.c | 625 +---------------------------------------------
2 files changed, 12 insertions(+), 614 deletions(-)
diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index f873ee3..9e103a4 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -54,7 +54,6 @@ struct regulatory_request {
enum nl80211_reg_initiator initiator;
char alpha2[2];
bool intersect;
- u32 country_ie_checksum;
enum environment_cap country_ie_env;
struct list_head list;
};
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 1ac2bdd..678d0bd 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -67,17 +67,9 @@ static struct platform_device *reg_pdev;
const struct ieee80211_regdomain *cfg80211_regdomain;
/*
- * We use this as a place for the rd structure built from the
- * last parsed country IE to rest until CRDA gets back to us with
- * what it thinks should apply for the same country
- */
-static const struct ieee80211_regdomain *country_ie_regdomain;
-
-/*
* Protects static reg.c components:
* - cfg80211_world_regdom
* - cfg80211_regdom
- * - country_ie_regdomain
* - last_request
*/
static DEFINE_MUTEX(reg_mutex);
@@ -275,25 +267,6 @@ static bool is_user_regdom_saved(void)
return true;
}
-/**
- * country_ie_integrity_changes - tells us if the country IE has changed
- * @checksum: checksum of country IE of fields we are interested in
- *
- * If the country IE has not changed you can ignore it safely. This is
- * useful to determine if two devices are seeing two different country IEs
- * even on the same alpha2. Note that this will return false if no IE has
- * been set on the wireless core yet.
- */
-static bool country_ie_integrity_changes(u32 checksum)
-{
- /* If no IE has been set then the checksum doesn't change */
- if (unlikely(!last_request->country_ie_checksum))
- return false;
- if (unlikely(last_request->country_ie_checksum != checksum))
- return true;
- return false;
-}
-
static int reg_copy_regd(const struct ieee80211_regdomain **dst_regd,
const struct ieee80211_regdomain *src_regd)
{
@@ -506,471 +479,6 @@ static bool freq_in_rule_band(const struct ieee80211_freq_range *freq_range,
}
/*
- * This is a work around for sanity checking ieee80211_channel_to_frequency()'s
- * work. ieee80211_channel_to_frequency() can for example currently provide a
- * 2 GHz channel when in fact a 5 GHz channel was desired. An example would be
- * an AP providing channel 8 on a country IE triplet when it sent this on the
- * 5 GHz band, that channel is designed to be channel 8 on 5 GHz, not a 2 GHz
- * channel.
- *
- * This can be removed once ieee80211_channel_to_frequency() takes in a band.
- */
-static bool chan_in_band(int chan, enum ieee80211_band band)
-{
- int center_freq = ieee80211_channel_to_frequency(chan);
-
- switch (band) {
- case IEEE80211_BAND_2GHZ:
- if (center_freq <= 2484)
- return true;
- return false;
- case IEEE80211_BAND_5GHZ:
- if (center_freq >= 5005)
- return true;
- return false;
- default:
- return false;
- }
-}
-
-/*
- * Some APs may send a country IE triplet for each channel they
- * support and while this is completely overkill and silly we still
- * need to support it. We avoid making a single rule for each channel
- * though and to help us with this we use this helper to find the
- * actual subband end channel. These type of country IE triplet
- * scenerios are handled then, all yielding two regulaotry rules from
- * parsing a country IE:
- *
- * [1]
- * [2]
- * [36]
- * [40]
- *
- * [1]
- * [2-4]
- * [5-12]
- * [36]
- * [40-44]
- *
- * [1-4]
- * [5-7]
- * [36-44]
- * [48-64]
- *
- * [36-36]
- * [40-40]
- * [44-44]
- * [48-48]
- * [52-52]
- * [56-56]
- * [60-60]
- * [64-64]
- * [100-100]
- * [104-104]
- * [108-108]
- * [112-112]
- * [116-116]
- * [120-120]
- * [124-124]
- * [128-128]
- * [132-132]
- * [136-136]
- * [140-140]
- *
- * Returns 0 if the IE has been found to be invalid in the middle
- * somewhere.
- */
-static int max_subband_chan(enum ieee80211_band band,
- int orig_cur_chan,
- int orig_end_channel,
- s8 orig_max_power,
- u8 **country_ie,
- u8 *country_ie_len)
-{
- u8 *triplets_start = *country_ie;
- u8 len_at_triplet = *country_ie_len;
- int end_subband_chan = orig_end_channel;
-
- /*
- * We'll deal with padding for the caller unless
- * its not immediate and we don't process any channels
- */
- if (*country_ie_len == 1) {
- *country_ie += 1;
- *country_ie_len -= 1;
- return orig_end_channel;
- }
-
- /* Move to the next triplet and then start search */
- *country_ie += 3;
- *country_ie_len -= 3;
-
- if (!chan_in_band(orig_cur_chan, band))
- return 0;
-
- while (*country_ie_len >= 3) {
- int end_channel = 0;
- struct ieee80211_country_ie_triplet *triplet =
- (struct ieee80211_country_ie_triplet *) *country_ie;
- int cur_channel = 0, next_expected_chan;
-
- /* means last triplet is completely unrelated to this one */
- if (triplet->ext.reg_extension_id >=
- IEEE80211_COUNTRY_EXTENSION_ID) {
- *country_ie -= 3;
- *country_ie_len += 3;
- break;
- }
-
- if (triplet->chans.first_channel == 0) {
- *country_ie += 1;
- *country_ie_len -= 1;
- if (*country_ie_len != 0)
- return 0;
- break;
- }
-
- if (triplet->chans.num_channels == 0)
- return 0;
-
- /* Monitonically increasing channel order */
- if (triplet->chans.first_channel <= end_subband_chan)
- return 0;
-
- if (!chan_in_band(triplet->chans.first_channel, band))
- return 0;
-
- /* 2 GHz */
- if (triplet->chans.first_channel <= 14) {
- end_channel = triplet->chans.first_channel +
- triplet->chans.num_channels - 1;
- }
- else {
- end_channel = triplet->chans.first_channel +
- (4 * (triplet->chans.num_channels - 1));
- }
-
- if (!chan_in_band(end_channel, band))
- return 0;
-
- if (orig_max_power != triplet->chans.max_power) {
- *country_ie -= 3;
- *country_ie_len += 3;
- break;
- }
-
- cur_channel = triplet->chans.first_channel;
-
- /* The key is finding the right next expected channel */
- if (band == IEEE80211_BAND_2GHZ)
- next_expected_chan = end_subband_chan + 1;
- else
- next_expected_chan = end_subband_chan + 4;
-
- if (cur_channel != next_expected_chan) {
- *country_ie -= 3;
- *country_ie_len += 3;
- break;
- }
-
- end_subband_chan = end_channel;
-
- /* Move to the next one */
- *country_ie += 3;
- *country_ie_len -= 3;
-
- /*
- * Padding needs to be dealt with if we processed
- * some channels.
- */
- if (*country_ie_len == 1) {
- *country_ie += 1;
- *country_ie_len -= 1;
- break;
- }
-
- /* If seen, the IE is invalid */
- if (*country_ie_len == 2)
- return 0;
- }
-
- if (end_subband_chan == orig_end_channel) {
- *country_ie = triplets_start;
- *country_ie_len = len_at_triplet;
- return orig_end_channel;
- }
-
- return end_subband_chan;
-}
-
-/*
- * Converts a country IE to a regulatory domain. A regulatory domain
- * structure has a lot of information which the IE doesn't yet have,
- * so for the other values we use upper max values as we will intersect
- * with our userspace regulatory agent to get lower bounds.
- */
-static struct ieee80211_regdomain *country_ie_2_rd(
- enum ieee80211_band band,
- u8 *country_ie,
- u8 country_ie_len,
- u32 *checksum)
-{
- struct ieee80211_regdomain *rd = NULL;
- unsigned int i = 0;
- char alpha2[2];
- u32 flags = 0;
- u32 num_rules = 0, size_of_regd = 0;
- u8 *triplets_start = NULL;
- u8 len_at_triplet = 0;
- /* the last channel we have registered in a subband (triplet) */
- int last_sub_max_channel = 0;
-
- *checksum = 0xDEADBEEF;
-
- /* Country IE requirements */
- BUG_ON(country_ie_len < IEEE80211_COUNTRY_IE_MIN_LEN ||
- country_ie_len & 0x01);
-
- alpha2[0] = country_ie[0];
- alpha2[1] = country_ie[1];
-
- /*
- * Third octet can be:
- * 'I' - Indoor
- * 'O' - Outdoor
- *
- * anything else we assume is no restrictions
- */
- if (country_ie[2] == 'I')
- flags = NL80211_RRF_NO_OUTDOOR;
- else if (country_ie[2] == 'O')
- flags = NL80211_RRF_NO_INDOOR;
-
- country_ie += 3;
- country_ie_len -= 3;
-
- triplets_start = country_ie;
- len_at_triplet = country_ie_len;
-
- *checksum ^= ((flags ^ alpha2[0] ^ alpha2[1]) << 8);
-
- /*
- * We need to build a reg rule for each triplet, but first we must
- * calculate the number of reg rules we will need. We will need one
- * for each channel subband
- */
- while (country_ie_len >= 3) {
- int end_channel = 0;
- struct ieee80211_country_ie_triplet *triplet =
- (struct ieee80211_country_ie_triplet *) country_ie;
- int cur_sub_max_channel = 0, cur_channel = 0;
-
- if (triplet->ext.reg_extension_id >=
- IEEE80211_COUNTRY_EXTENSION_ID) {
- country_ie += 3;
- country_ie_len -= 3;
- continue;
- }
-
- /*
- * APs can add padding to make length divisible
- * by two, required by the spec.
- */
- if (triplet->chans.first_channel == 0) {
- country_ie++;
- country_ie_len--;
- /* This is expected to be at the very end only */
- if (country_ie_len != 0)
- return NULL;
- break;
- }
-
- if (triplet->chans.num_channels == 0)
- return NULL;
-
- if (!chan_in_band(triplet->chans.first_channel, band))
- return NULL;
-
- /* 2 GHz */
- if (band == IEEE80211_BAND_2GHZ)
- end_channel = triplet->chans.first_channel +
- triplet->chans.num_channels - 1;
- else
- /*
- * 5 GHz -- For example in country IEs if the first
- * channel given is 36 and the number of channels is 4
- * then the individual channel numbers defined for the
- * 5 GHz PHY by these parameters are: 36, 40, 44, and 48
- * and not 36, 37, 38, 39.
- *
- * See: http://tinyurl.com/11d-clarification
- */
- end_channel = triplet->chans.first_channel +
- (4 * (triplet->chans.num_channels - 1));
-
- cur_channel = triplet->chans.first_channel;
-
- /*
- * Enhancement for APs that send a triplet for every channel
- * or for whatever reason sends triplets with multiple channels
- * separated when in fact they should be together.
- */
- end_channel = max_subband_chan(band,
- cur_channel,
- end_channel,
- triplet->chans.max_power,
- &country_ie,
- &country_ie_len);
- if (!end_channel)
- return NULL;
-
- if (!chan_in_band(end_channel, band))
- return NULL;
-
- cur_sub_max_channel = end_channel;
-
- /* Basic sanity check */
- if (cur_sub_max_channel < cur_channel)
- return NULL;
-
- /*
- * Do not allow overlapping channels. Also channels
- * passed in each subband must be monotonically
- * increasing
- */
- if (last_sub_max_channel) {
- if (cur_channel <= last_sub_max_channel)
- return NULL;
- if (cur_sub_max_channel <= last_sub_max_channel)
- return NULL;
- }
-
- /*
- * When dot11RegulatoryClassesRequired is supported
- * we can throw ext triplets as part of this soup,
- * for now we don't care when those change as we
- * don't support them
- */
- *checksum ^= ((cur_channel ^ cur_sub_max_channel) << 8) |
- ((cur_sub_max_channel ^ cur_sub_max_channel) << 16) |
- ((triplet->chans.max_power ^ cur_sub_max_channel) << 24);
-
- last_sub_max_channel = cur_sub_max_channel;
-
- num_rules++;
-
- if (country_ie_len >= 3) {
- country_ie += 3;
- country_ie_len -= 3;
- }
-
- /*
- * Note: this is not a IEEE requirement but
- * simply a memory requirement
- */
- if (num_rules > NL80211_MAX_SUPP_REG_RULES)
- return NULL;
- }
-
- country_ie = triplets_start;
- country_ie_len = len_at_triplet;
-
- size_of_regd = sizeof(struct ieee80211_regdomain) +
- (num_rules * sizeof(struct ieee80211_reg_rule));
-
- rd = kzalloc(size_of_regd, GFP_KERNEL);
- if (!rd)
- return NULL;
-
- rd->n_reg_rules = num_rules;
- rd->alpha2[0] = alpha2[0];
- rd->alpha2[1] = alpha2[1];
-
- /* This time around we fill in the rd */
- while (country_ie_len >= 3) {
- int end_channel = 0;
- struct ieee80211_country_ie_triplet *triplet =
- (struct ieee80211_country_ie_triplet *) country_ie;
- struct ieee80211_reg_rule *reg_rule = NULL;
- struct ieee80211_freq_range *freq_range = NULL;
- struct ieee80211_power_rule *power_rule = NULL;
-
- /*
- * Must parse if dot11RegulatoryClassesRequired is true,
- * we don't support this yet
- */
- if (triplet->ext.reg_extension_id >=
- IEEE80211_COUNTRY_EXTENSION_ID) {
- country_ie += 3;
- country_ie_len -= 3;
- continue;
- }
-
- if (triplet->chans.first_channel == 0) {
- country_ie++;
- country_ie_len--;
- break;
- }
-
- reg_rule = &rd->reg_rules[i];
- freq_range = ®_rule->freq_range;
- power_rule = ®_rule->power_rule;
-
- reg_rule->flags = flags;
-
- /* 2 GHz */
- if (band == IEEE80211_BAND_2GHZ)
- end_channel = triplet->chans.first_channel +
- triplet->chans.num_channels -1;
- else
- end_channel = triplet->chans.first_channel +
- (4 * (triplet->chans.num_channels - 1));
-
- end_channel = max_subband_chan(band,
- triplet->chans.first_channel,
- end_channel,
- triplet->chans.max_power,
- &country_ie,
- &country_ie_len);
-
- /*
- * The +10 is since the regulatory domain expects
- * the actual band edge, not the center of freq for
- * its start and end freqs, assuming 20 MHz bandwidth on
- * the channels passed
- */
- freq_range->start_freq_khz =
- MHZ_TO_KHZ(ieee80211_channel_to_frequency(
- triplet->chans.first_channel) - 10);
- freq_range->end_freq_khz =
- MHZ_TO_KHZ(ieee80211_channel_to_frequency(
- end_channel) + 10);
-
- /*
- * These are large arbitrary values we use to intersect later.
- * Increment this if we ever support >= 40 MHz channels
- * in IEEE 802.11
- */
- freq_range->max_bandwidth_khz = MHZ_TO_KHZ(40);
- power_rule->max_antenna_gain = DBI_TO_MBI(100);
- power_rule->max_eirp = DBM_TO_MBM(triplet->chans.max_power);
-
- i++;
-
- if (country_ie_len >= 3) {
- country_ie += 3;
- country_ie_len -= 3;
- }
-
- BUG_ON(i > NL80211_MAX_SUPP_REG_RULES);
- }
-
- return rd;
-}
-
-
-/*
* Helper for regdom_intersect(), this does the real
* mathematical intersection fun
*/
@@ -1191,7 +699,6 @@ static int freq_reg_info_regd(struct wiphy *wiphy,
return -EINVAL;
}
-EXPORT_SYMBOL(freq_reg_info);
int freq_reg_info(struct wiphy *wiphy,
u32 center_freq,
@@ -1205,6 +712,7 @@ int freq_reg_info(struct wiphy *wiphy,
reg_rule,
NULL);
}
+EXPORT_SYMBOL(freq_reg_info);
/*
* Note that right now we assume the desired channel bandwidth
@@ -1243,41 +751,8 @@ static void handle_channel(struct wiphy *wiphy, enum ieee80211_band band,
desired_bw_khz,
®_rule);
- if (r) {
- /*
- * This means no regulatory rule was found in the country IE
- * with a frequency range on the center_freq's band, since
- * IEEE-802.11 allows for a country IE to have a subset of the
- * regulatory information provided in a country we ignore
- * disabling the channel unless at least one reg rule was
- * found on the center_freq's band. For details see this
- * clarification:
- *
- * http://tinyurl.com/11d-clarification
- */
- if (r == -ERANGE &&
- last_request->initiator ==
- NL80211_REGDOM_SET_BY_COUNTRY_IE) {
- REG_DBG_PRINT("cfg80211: Leaving channel %d MHz "
- "intact on %s - no rule found in band on "
- "Country IE\n",
- chan->center_freq, wiphy_name(wiphy));
- } else {
- /*
- * In this case we know the country IE has at least one reg rule
- * for the band so we respect its band definitions
- */
- if (last_request->initiator ==
- NL80211_REGDOM_SET_BY_COUNTRY_IE)
- REG_DBG_PRINT("cfg80211: Disabling "
- "channel %d MHz on %s due to "
- "Country IE\n",
- chan->center_freq, wiphy_name(wiphy));
- flags |= IEEE80211_CHAN_DISABLED;
- chan->flags = flags;
- }
+ if (r)
return;
- }
power_rule = ®_rule->power_rule;
freq_range = ®_rule->freq_range;
@@ -2010,7 +1485,7 @@ EXPORT_SYMBOL(regulatory_hint);
/* Caller must hold reg_mutex */
static bool reg_same_country_ie_hint(struct wiphy *wiphy,
- u32 country_ie_checksum)
+ char *alpha2, enum environment_cap env)
{
struct wiphy *request_wiphy;
@@ -2026,13 +1501,17 @@ static bool reg_same_country_ie_hint(struct wiphy *wiphy,
return false;
if (likely(request_wiphy != wiphy))
- return !country_ie_integrity_changes(country_ie_checksum);
+ return (last_request->alpha2[0] == alpha2[0] &&
+ last_request->alpha2[1] == alpha2[1] &&
+ last_request->country_ie_env == env);
/*
* We should not have let these through at this point, they
* should have been picked up earlier by the first alpha2 check
* on the device
*/
- if (WARN_ON(!country_ie_integrity_changes(country_ie_checksum)))
+ if (WARN_ON((last_request->alpha2[0] == alpha2[0] &&
+ last_request->alpha2[1] == alpha2[1] &&
+ last_request->country_ie_env == env )))
return true;
return false;
}
@@ -2048,7 +1527,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
{
struct ieee80211_regdomain *rd = NULL;
char alpha2[2];
- u32 checksum = 0;
enum environment_cap env = ENVIRON_ANY;
struct regulatory_request *request;
@@ -2064,14 +1542,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
if (country_ie_len < IEEE80211_COUNTRY_IE_MIN_LEN)
goto out;
- /*
- * Pending country IE processing, this can happen after we
- * call CRDA and wait for a response if a beacon was received before
- * we were able to process the last regulatory_hint_11d() call
- */
- if (country_ie_regdomain)
- goto out;
-
alpha2[0] = country_ie[0];
alpha2[1] = country_ie[1];
@@ -2090,12 +1560,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
wiphy_idx_valid(last_request->wiphy_idx)))
goto out;
- rd = country_ie_2_rd(band, country_ie, country_ie_len, &checksum);
- if (!rd) {
- REG_DBG_PRINT("cfg80211: Ignoring bogus country IE\n");
- goto out;
- }
-
/*
* This will not happen right now but we leave it here for the
* the future when we want to add suspend/resume support and having
@@ -2105,24 +1569,17 @@ void regulatory_hint_11d(struct wiphy *wiphy,
* If we hit this before we add this support we want to be informed of
* it as it would indicate a mistake in the current design
*/
- if (WARN_ON(reg_same_country_ie_hint(wiphy, checksum)))
+ if (WARN_ON(reg_same_country_ie_hint(wiphy, alpha2, env)))
goto free_rd_out;
request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
if (!request)
goto free_rd_out;
- /*
- * We keep this around for when CRDA comes back with a response so
- * we can intersect with that
- */
- country_ie_regdomain = rd;
-
request->wiphy_idx = get_wiphy_idx(wiphy);
- request->alpha2[0] = rd->alpha2[0];
- request->alpha2[1] = rd->alpha2[1];
+ request->alpha2[0] = alpha2[0];
+ request->alpha2[1] = alpha2[1];
request->initiator = NL80211_REGDOM_SET_BY_COUNTRY_IE;
- request->country_ie_checksum = checksum;
request->country_ie_env = env;
mutex_unlock(®_mutex);
@@ -2383,33 +1840,6 @@ static void print_regdomain_info(const struct ieee80211_regdomain *rd)
print_rd_rules(rd);
}
-#ifdef CONFIG_CFG80211_REG_DEBUG
-static void reg_country_ie_process_debug(
- const struct ieee80211_regdomain *rd,
- const struct ieee80211_regdomain *country_ie_regdomain,
- const struct ieee80211_regdomain *intersected_rd)
-{
- printk(KERN_DEBUG "cfg80211: Received country IE:\n");
- print_regdomain_info(country_ie_regdomain);
- printk(KERN_DEBUG "cfg80211: CRDA thinks this should applied:\n");
- print_regdomain_info(rd);
- if (intersected_rd) {
- printk(KERN_DEBUG "cfg80211: We intersect both of these "
- "and get:\n");
- print_regdomain_info(intersected_rd);
- return;
- }
- printk(KERN_DEBUG "cfg80211: Intersection between both failed\n");
-}
-#else
-static inline void reg_country_ie_process_debug(
- const struct ieee80211_regdomain *rd,
- const struct ieee80211_regdomain *country_ie_regdomain,
- const struct ieee80211_regdomain *intersected_rd)
-{
-}
-#endif
-
/* Takes ownership of rd only if it doesn't fail */
static int __set_regdom(const struct ieee80211_regdomain *rd)
{
@@ -2521,34 +1951,6 @@ static int __set_regdom(const struct ieee80211_regdomain *rd)
return 0;
}
- /*
- * Country IE requests are handled a bit differently, we intersect
- * the country IE rd with what CRDA believes that country should have
- */
-
- /*
- * Userspace could have sent two replies with only
- * one kernel request. By the second reply we would have
- * already processed and consumed the country_ie_regdomain.
- */
- if (!country_ie_regdomain)
- return -EALREADY;
- BUG_ON(rd == country_ie_regdomain);
-
- /*
- * Intersect what CRDA returned and our what we
- * had built from the Country IE received
- */
-
- intersected_rd = regdom_intersect(rd, country_ie_regdomain);
-
- reg_country_ie_process_debug(rd,
- country_ie_regdomain,
- intersected_rd);
-
- kfree(country_ie_regdomain);
- country_ie_regdomain = NULL;
-
if (!intersected_rd)
return -EINVAL;
@@ -2688,9 +2090,6 @@ void /* __init_or_exit */ regulatory_exit(void)
reset_regdomains();
- kfree(country_ie_regdomain);
- country_ie_regdomain = NULL;
-
kfree(last_request);
platform_device_unregister(reg_pdev);
--
1.7.1.1
^ permalink raw reply related
* [PATCH] mac80211: improve error checking if WEP fails to init
From: John W. Linville @ 2010-07-15 20:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Stanislaw Gruszka, John W. Linville
Do this by poisoning the values of wep_tx_tfm and wep_rx_tfm if either
crypto allocation fails.
Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/wep.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index 6d133b6..9ebc8d8 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -32,13 +32,16 @@ int ieee80211_wep_init(struct ieee80211_local *local)
local->wep_tx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0,
CRYPTO_ALG_ASYNC);
- if (IS_ERR(local->wep_tx_tfm))
+ if (IS_ERR(local->wep_tx_tfm)) {
+ local->wep_rx_tfm = ERR_PTR(-EINVAL);
return PTR_ERR(local->wep_tx_tfm);
+ }
local->wep_rx_tfm = crypto_alloc_blkcipher("ecb(arc4)", 0,
CRYPTO_ALG_ASYNC);
if (IS_ERR(local->wep_rx_tfm)) {
crypto_free_blkcipher(local->wep_tx_tfm);
+ local->wep_tx_tfm = ERR_PTR(-EINVAL);
return PTR_ERR(local->wep_rx_tfm);
}
--
1.7.1.1
^ permalink raw reply related
* Re: [RFC] wireless: only use alpha2 regulatory information from country IE
From: Kyle McMartin @ 2010-07-16 0:46 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, mcgrof, kyle
In-Reply-To: <1279220807-18245-1-git-send-email-linville@tuxdriver.com>
On Thu, Jul 15, 2010 at 03:06:47PM -0400, John W. Linville wrote:
> The meaning and/or usage of the country IE is somewhat poorly defined.
> In practice, this means that regulatory rulesets in a country IE are
> often incomplete and might be untrustworthy. This removes the code
> associated with interpreting those rulesets while preserving respect
> for country "alpha2" codes also contained in the country IE.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> This patch is compile-tested only! Please feel free to suggest that
> I have left something out or missed some nuance of our regulatory
> enforcement code...
>
Building it now...
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Gertjan van Wingerde @ 2010-07-16 7:18 UTC (permalink / raw)
To: Helmut Schaa
Cc: Bartlomiej Zolnierkiewicz, Felix Fietkau, John W. Linville,
Ivo Van Doorn, Christoph Egger, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <AANLkTilqoYMMKYJT-YYbEzdnytUSYa0EylEiJ4x5xXXH@mail.gmail.com>
On 07/16/10 08:57, Helmut Schaa wrote:
> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com <mailto:bzolnier@gmail.com>> wrote:
>
> On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> > On 2010-07-14 3:15 PM, John W. Linville wrote:
> > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com <mailto:luis.f.correia@gmail.com>> wrote:
> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>> wrote:
> > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> > >> >> so all Code depending on that can't ever be selected and, if there's
> > >> >> no plan to add these options, should be cleaned up
> > >> >>
> > >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>>
> > >> >
> > >> > NAK,
> > >> >
> > >> > this is not dead code, it is needed for the Ralink System-on-Chip
> > >> > Platform devices.
> > >> >
> > >> > While I can't fix Kconfig errors and the current KConfig file may be
> > >> > wrong, this code cannot and will not be deleted.
> > >>
> > >> When the config option was introduced, the config options RALINK_RT288X and
> > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> > >>
> > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> > >> isn't dead but actually in use.
> > >
> > > Perhaps Helmut and Felix can send us the missing code?
> > The missing code is a MIPS platform port, which is currently being
> > maintained in OpenWrt, but is not ready for upstream submission yet.
> > I'm not working on this code at the moment, but I think it will be
> > submitted once it's ready.
>
> People are using automatic scripts to catch unused config options nowadays
> so the issue is quite likely to come back again sooner or later..
>
> Would it be possible to improve situation somehow till the missing parts
> get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
> situation to Kconfig (if the config option itself really cannot be removed)
> until all code is ready etc.?
>
>
> Or we could just remove RT2800PCI_SOC completely and build the soc specific
> parts always as part of rt2800pci. I mean it's not much code, just the platform
> driver stuff and the eeprom access.
>
I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by
unconditionally compiling in the generic SOC code, but we should not unconditionally
register the SOC platform device, which is currently also under the scope of this
Kconfig variable.
---
Gertjan.
^ 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