* Compat-wireless release for 2011-10-09 is baked
From: Compat-wireless cronjob account @ 2011-10-09 19:03 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
811845 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3573 - % of code consists of backport work
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-09 14:47 UTC (permalink / raw)
To: v4mp; +Cc: linux-wireless
In-Reply-To: <loom.20111009T161348-133@post.gmane.org>
On 10/09/2011 09:21 AM, v4mp wrote:
>
> Sorry, but i can't get this Alfa product to work with the latest bleeding edge
> compat-wireless-2011-10-08 on ubuntu 11.04, tryed with kernels 2.6.38-11,
> 2.6.39 rc4 and 3.0
>
> i tryed also the 2.6.39-1 version of compat-wireless
>
> Don't show anything in managed and monitor mode..
I do not know about monitor mode, but the Alfa device works in managed mode with
kernel 3.1-rc9 from both wireless-testing and mainline. I use NetworkManager.
All of this current code should be in the latest bleeding edge compat-wireless
version.
Have you installed the firmware?
Larry
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Larry Finger @ 2011-10-09 14:35 UTC (permalink / raw)
To: John W Linville
Cc: Rafał Miłecki, Michael Büsch, Michael Buesch,
b43-dev, linux-wireless
In-Reply-To: <CACna6rz-0TZrwctTZR-YLDHG=xdt4Oc5ShbjCZiad7Cvmh0+hQ@mail.gmail.com>
On 10/09/2011 03:48 AM, Rafał Miłecki wrote:
> 2011/10/9 Michael Büsch<m@bues.ch>:
>> On Sat, 08 Oct 2011 17:28:42 -0500
>> Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>
>>> The kernel now contains library routines to establish crc8 tables and
>>> to calculate the appropriate sums. Use them for ssb.
>>
>>> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
>>> +
>>> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
>>> +#define SROM_CRC8_POLY 0xAB
>>> +
>>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>>> {
>>> + size /= 2;
>>> + while (size--)
>>> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
>>> +}
>>>
>>> - return crc;
>>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>>> +{
>>> + size /= 2;
>>> + while (size--)
>>> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
>>> }
>>
>>> return -ENOMEM;
>>> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
>>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
>>> sprom_do_read(bus, buf);
>>> + /* convert to le */
>>> + htol16_buf(buf, 2 * bus->sprom_size);
>>
>>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
>>> sprom_do_read(bus, buf);
>>> + htol16_buf(buf, 2 * bus->sprom_size);
>>> err = sprom_check_crc(buf, bus->sprom_size);
>>
>>> + /* restore endianess */
>>> + ltoh16_buf(buf, 2 * bus->sprom_size);
>>> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
>>
>> This endianness stuff is _really_ ugly.
>> Does this patch decrease the code size, at least? I'll almost doubt it.
>> If it doesn't, why are we actually doing this?
>> It doesn't even decrease the .data size. Worse, it converts a .const
>> table to a .data table.
>>
>> Just my 2 cents.
>
> Agree. I already tried converting bcma to use crc8:
> [RFC][WORTH IT?][PATCH] bcma: make use of crc8 lib
> http://lists.infradead.org/pipermail/b43-dev/2011-June/001466.html
>
> But resigned, it was introducing some hacks or not optimal ops, I
> decided it's not worth it.
>
> Even Arend said their brcm80211 is hacky about crc8 usage:
>
> W dniu 15 czerwca 2011 21:26 użytkownik Arend van Spriel
> <arend@broadcom.com> napisał:
>> Agree. In brcm80211 we convert the entire sprom, calculate, and convert it
>> back. Also not perfect I think as it loops over de sprom data twice.
John,
Please drop this patch. The amount of code churning is not worth the 100 byte
saving in the size of the generated code.
Larry
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-09 14:21 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CA+XFjio+on2rUymoSZNxOWKMX9xOn5hutA6q01r0yBeOXz0ivw@mail.gmail.com>
Sorry, but i can't get this Alfa product to work with the latest bleeding edge
compat-wireless-2011-10-08 on ubuntu 11.04, tryed with kernels 2.6.38-11,
2.6.39 rc4 and 3.0
i tryed also the 2.6.39-1 version of compat-wireless
Don't show anything in managed and monitor mode..
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Arend van Spriel @ 2011-10-09 10:33 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Michael Büsch, Larry Finger, John W Linville, Michael Buesch,
b43-dev@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rz-0TZrwctTZR-YLDHG=xdt4Oc5ShbjCZiad7Cvmh0+hQ@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/09/2011 10:48 AM, Rafał Miłecki wrote:
> Agree. I already tried converting bcma to use crc8:
> [RFC][WORTH IT?][PATCH] bcma: make use of crc8 lib
> http://lists.infradead.org/pipermail/b43-dev/2011-June/001466.html
>
> But resigned, it was introducing some hacks or not optimal ops, I
> decided it's not worth it.
>
> Even Arend said their brcm80211 is hacky about crc8 usage:
>
> W dniu 15 czerwca 2011 21:26 użytkownik Arend van Spriel
> <arend@broadcom.com> napisał:
>> Agree. In brcm80211 we convert the entire sprom, calculate, and convert it
>> back. Also not perfect I think as it loops over de sprom data twice.
>
Hi Rafał,
"not perfect" == "hacky" ;-)
I also just replied with a less hacky approach. Reading the sprom as
bytes will read the sprom content as is (little-endian) and you can do
the crc8 check without any conversions. After the check there is only
one conversion needed to move to a word array.
Gr. AvS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOkXheAAoJELcEx/G14aEWnHwP+wZRWLladazO/zZnuMrnEuRk
xhMzbZcIy8gJwkGs/GwuWqnHBZu+Qx/k/BC3S1CNNmLPOf7qLNbS4hgKRZn+2Tze
FHYzXb6IPXkCE6MS5BFRi2qxnzrxam7gL00SB5NuGceS4b3LQL+wNHzPx5yPlPEW
KsJnecyFTabclun2zxucZPB19w2xrS84Xcl2Db+2nV3wSn700REr5mr3+pmVXmvd
ptLuWsc5ZoAnvuTQq/PUjKvQb/tA7CpDFs9+uvCeKa93Rb3JIRwTk5tAVadLEWn7
6IWyN0VMK+pdL2LT14qc1LWJa192tn8qbmOg21lKsQFepP4egJyRGWaU7aKo9bdG
PVSXfqme0azRl6vd+G28Q/SVdt//w5HBoPgdWlORhNdo/sov07QVl8gf80QkTn/A
Ij3M1+LMlUFu7weuIwgKBIA+Bi6CxTR/3ozK+S3ItpVqt6gCnMlDYtEUM6pk2vVj
8ppl0LtGHyrogFgwOrcYbxMKJGbk8Po82T+Um7wchcHuRxGLD3NuErndMiRwemMk
zALNLYNCLLftCSypCgkM5kyfDkDf7uZMxJZbPXyIIFCP4BXm5xrgx39sYQAVx4if
bIjW0W3OmIbBcQScZ4+KRZ5YN1g45VFRQ3+4BPyusApYqzwSmjxUj8aomfD2QhEJ
Fh/5uq3JIrpQazyEsILz
=JjZ0
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Arend van Spriel @ 2011-10-09 9:50 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, John W Linville, Michael Buesch, zajec5@gmail.com,
b43-dev@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <20111009005107.43a49372@milhouse>
On 10/09/2011 12:51 AM, Michael Büsch wrote:
> On Sat, 08 Oct 2011 17:28:42 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> The kernel now contains library routines to establish crc8 tables and
>> to calculate the appropriate sums. Use them for ssb.
>
>> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
>> +
>> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
>> +#define SROM_CRC8_POLY 0xAB
>> +
>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>> {
>> + size /= 2;
>> + while (size--)
>> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
>> +}
>>
>> - return crc;
>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>> +{
>> + size /= 2;
>> + while (size--)
>> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
>> }
>
>> return -ENOMEM;
>> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
>> sprom_do_read(bus, buf);
>> + /* convert to le */
>> + htol16_buf(buf, 2 * bus->sprom_size);
>
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
>> sprom_do_read(bus, buf);
>> + htol16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_check_crc(buf, bus->sprom_size);
>
>> + /* restore endianess */
>> + ltoh16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
>
> This endianness stuff is _really_ ugly.
It may seem ugly, but is not new. Choosing a 8-bit crc to check a 16-bit
array is not very efficient considering host endianess. The endianess
was also dealt with in the old version:
- for (word = 0; word < size - 1; word++) {
- crc = ssb_crc8(crc, sprom[word] & 0x00FF);
- crc = ssb_crc8(crc, (sprom[word] & 0xFF00) >> 8);
- }
It is a bit easier on the eye. I guess the ugliness comes from the fact
that there are two calls to htol16_buf.
A better approach would be to read sprom as bytes and run the crc8 over
the byte array. When ok do ltoh16_buf once.
> Does this patch decrease the code size, at least? I'll almost doubt it.
> If it doesn't, why are we actually doing this?
Probably for the same reason why struct list_head and related functions
are used. Trying to use what is commonly available in the kernel.
> It doesn't even decrease the .data size. Worse, it converts a .const
> table to a .data table.
True. .code size became .data size, because of the flexibility that the
table is generated for a given polynomial. Every 'bility' comes with a
price and this seems not too pricy.
> Just my 2 cents.
>
Gr. AvS
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Rafał Miłecki @ 2011-10-09 8:48 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, John W Linville, Michael Buesch, b43-dev,
linux-wireless
In-Reply-To: <20111009005107.43a49372@milhouse>
2011/10/9 Michael Büsch <m@bues.ch>:
> On Sat, 08 Oct 2011 17:28:42 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> The kernel now contains library routines to establish crc8 tables and
>> to calculate the appropriate sums. Use them for ssb.
>
>> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
>> +
>> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
>> +#define SROM_CRC8_POLY 0xAB
>> +
>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>> {
>> + size /= 2;
>> + while (size--)
>> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
>> +}
>>
>> - return crc;
>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>> +{
>> + size /= 2;
>> + while (size--)
>> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
>> }
>
>> return -ENOMEM;
>> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
>> sprom_do_read(bus, buf);
>> + /* convert to le */
>> + htol16_buf(buf, 2 * bus->sprom_size);
>
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
>> sprom_do_read(bus, buf);
>> + htol16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_check_crc(buf, bus->sprom_size);
>
>> + /* restore endianess */
>> + ltoh16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
>
> This endianness stuff is _really_ ugly.
> Does this patch decrease the code size, at least? I'll almost doubt it.
> If it doesn't, why are we actually doing this?
> It doesn't even decrease the .data size. Worse, it converts a .const
> table to a .data table.
>
> Just my 2 cents.
Agree. I already tried converting bcma to use crc8:
[RFC][WORTH IT?][PATCH] bcma: make use of crc8 lib
http://lists.infradead.org/pipermail/b43-dev/2011-June/001466.html
But resigned, it was introducing some hacks or not optimal ops, I
decided it's not worth it.
Even Arend said their brcm80211 is hacky about crc8 usage:
W dniu 15 czerwca 2011 21:26 użytkownik Arend van Spriel
<arend@broadcom.com> napisał:
> Agree. In brcm80211 we convert the entire sprom, calculate, and convert it
> back. Also not perfect I think as it loops over de sprom data twice.
--
Rafał
^ permalink raw reply
* Re: [PATCH 1/2] wl12xx: sdio: use dev_dbg instead of wl1271_debug
From: Luciano Coelho @ 2011-10-09 6:09 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <CAB3XZEeiyAxzE6tiqe2D71jKuusa-hPz-2fw5bqHocaw+d1xWg@mail.gmail.com>
On Sun, 2011-10-09 at 02:08 +0200, Eliad Peller wrote:
> On Fri, Oct 7, 2011 at 1:34 PM, Luciano Coelho <coelho@ti.com> wrote:
> > To prevent a useless dependency between the sdio module and the wl12xx
> > module, we need to replace the wl1271_debug macros (and friends) for
> > dev_dbg and other equivalents.
> >
> > At the same time, remove the SDIO data hexdump, since this produces
> > way too much data and is not particularly useful. There's not
> > print_hex_dump() equivalent for dynamic debug, so it's hard to control
> > when the dumps are printed out.
> >
> > Signed-off-by: Luciano Coelho <coelho@ti.com>
> > ---
> [...]
> > if (!(sdio_flags & MMC_PM_KEEP_POWER)) {
> > - wl1271_error("can't keep power while host "
> > + dev_err(dev, "can't keep power while host \n"
> > "is suspended");
>
> you missed the concatenation here :)
Ouch! Et tu Brutus?! :)
My regex didn't spread across lines. I'll fix it, thanks for checking.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 1/2] wl12xx: sdio: use dev_dbg instead of wl1271_debug
From: Eliad Peller @ 2011-10-09 0:08 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1317987297-18172-1-git-send-email-coelho@ti.com>
On Fri, Oct 7, 2011 at 1:34 PM, Luciano Coelho <coelho@ti.com> wrote:
> To prevent a useless dependency between the sdio module and the wl12xx
> module, we need to replace the wl1271_debug macros (and friends) for
> dev_dbg and other equivalents.
>
> At the same time, remove the SDIO data hexdump, since this produces
> way too much data and is not particularly useful. There's not
> print_hex_dump() equivalent for dynamic debug, so it's hard to control
> when the dumps are printed out.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
[...]
> if (!(sdio_flags & MMC_PM_KEEP_POWER)) {
> - wl1271_error("can't keep power while host "
> + dev_err(dev, "can't keep power while host \n"
> "is suspended");
you missed the concatenation here :)
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Gábor Stefanik @ 2011-10-08 23:29 UTC (permalink / raw)
To: Larry Finger; +Cc: Toddy, linux-wireless
In-Reply-To: <4E907FB8.1040101@lwfinger.net>
On Sat, Oct 8, 2011 at 6:52 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 10/08/2011 11:24 AM, Toddy wrote:
>>
>> Hello Larry,
>>
>> thanks for the quick reply! Yes I know this version is a bit older, but
>> when I
>> use the newest compat-wireless (eg.
>>
>> http://www.orbit-lab.org/kernel/compat-wireless-2.6/compat-wireless-2011-10-07.tar.bz2)
>> the driver loads but some features like monitor-mode and packet injection
>> doesn't work. The listing of available networks (with airodump) doesn't
>> work
>> too. Usually I have 13 channels because I live in Germany but if I use the
>> newest driver I have only 11 channels. But if I use the older
>> compat-wireless
>> package all works fine.
>
> The difference between 11 and 13 channels depends on your CRDA settings. Do
> you have that package installed? Check the output of dmesg to see what
> domain is being set. If you have CRDA installed, then you can force the use
> of Germany in the domain by creating a file named
> /etc/modprobe.d/50-cfg80211.conf containing a single line with "options
> cfg80211 ieee80211_regdom=DE" (without the quote marks).
>
> You can get a list of available networks using iwconfig or iw. I know those
> work.
>
> As I do not test, support, nor condone packet injection, I cannot speak to
> it working on any driver.
Well, packet injection is required for Hostapd to work.
>
> Larry
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Joe Perches @ 2011-10-08 23:11 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <4E90D5F7.6020005@lwfinger.net>
On Sat, 2011-10-08 at 18:00 -0500, Larry Finger wrote:
> On 10/08/2011 05:38 PM, Joe Perches wrote:
> > On Sat, 2011-10-08 at 17:28 -0500, Larry Finger wrote:
> >> The kernel now contains library routines to establish crc8 tables and
> >> to calculate the appropriate sums. Use them for ssb.
> > []
> >> --- wireless-testing-new.orig/drivers/ssb/pci.c
> > []
> >> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
> >
> > Perhaps a rename and use le16_to_cpup?
> >
> >> +static inline void htol16_buf(u16 *buf, unsigned int size)
> >
> > and cpu_to_le16p?
>
> I'm sorry, but I don't see any advantage to using a pointer version here. Please
> enlighten me.
It's just a naming consistency thing,
you already are using a pointer version,
and maybe this should go into byteorder.h
inline void array_cpu_to_le16p(u16 *p, size_t size)
{
while (size) {
cpu_to_le16p(p++);
size--;
}
}
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Larry Finger @ 2011-10-08 23:00 UTC (permalink / raw)
To: Joe Perches
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <1318113514.1844.34.camel@Joe-Laptop>
On 10/08/2011 05:38 PM, Joe Perches wrote:
> On Sat, 2011-10-08 at 17:28 -0500, Larry Finger wrote:
>> The kernel now contains library routines to establish crc8 tables and
>> to calculate the appropriate sums. Use them for ssb.
> []
>> --- wireless-testing-new.orig/drivers/ssb/pci.c
> []
>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>
> Perhaps a rename and use le16_to_cpup?
>
>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>
> and cpu_to_le16p?
I'm sorry, but I don't see any advantage to using a pointer version here. Please
enlighten me.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Michael Büsch @ 2011-10-08 22:51 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <4e90ce9a.89uGF659NNpbpyA3%Larry.Finger@lwfinger.net>
On Sat, 08 Oct 2011 17:28:42 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The kernel now contains library routines to establish crc8 tables and
> to calculate the appropriate sums. Use them for ssb.
> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
> +
> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
> +#define SROM_CRC8_POLY 0xAB
> +
> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
> {
> + size /= 2;
> + while (size--)
> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
> +}
>
> - return crc;
> +static inline void htol16_buf(u16 *buf, unsigned int size)
> +{
> + size /= 2;
> + while (size--)
> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
> }
> return -ENOMEM;
> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
> sprom_do_read(bus, buf);
> + /* convert to le */
> + htol16_buf(buf, 2 * bus->sprom_size);
> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
> sprom_do_read(bus, buf);
> + htol16_buf(buf, 2 * bus->sprom_size);
> err = sprom_check_crc(buf, bus->sprom_size);
> + /* restore endianess */
> + ltoh16_buf(buf, 2 * bus->sprom_size);
> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
This endianness stuff is _really_ ugly.
Does this patch decrease the code size, at least? I'll almost doubt it.
If it doesn't, why are we actually doing this?
It doesn't even decrease the .data size. Worse, it converts a .const
table to a .data table.
Just my 2 cents.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Joe Perches @ 2011-10-08 22:38 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <4e90ce9a.89uGF659NNpbpyA3%Larry.Finger@lwfinger.net>
On Sat, 2011-10-08 at 17:28 -0500, Larry Finger wrote:
> The kernel now contains library routines to establish crc8 tables and
> to calculate the appropriate sums. Use them for ssb.
[]
> --- wireless-testing-new.orig/drivers/ssb/pci.c
[]
> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
Perhaps a rename and use le16_to_cpup?
> +static inline void htol16_buf(u16 *buf, unsigned int size)
and cpu_to_le16p?
^ permalink raw reply
* [PATCH] ssb: Convert to use crc8 code in kernel library
From: Larry Finger @ 2011-10-08 22:28 UTC (permalink / raw)
To: John W Linville; +Cc: Michael Buesch, zajec5, b43-dev, linux-wireless
The kernel now contains library routines to establish crc8 tables and
to calculate the appropriate sums. Use them for ssb.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
This is -next material.
This has been tested on both and little- and big-endian platforms.
Larry
---
Kconfig | 1
pci.c | 85 ++++++++++++++++++----------------------------------------------
2 files changed, 26 insertions(+), 60 deletions(-)
Index: wireless-testing-new/drivers/ssb/pci.c
===================================================================
--- wireless-testing-new.orig/drivers/ssb/pci.c
+++ wireless-testing-new/drivers/ssb/pci.c
@@ -20,6 +20,7 @@
#include <linux/slab.h>
#include <linux/pci.h>
#include <linux/delay.h>
+#include <linux/crc8.h>
#include "ssb_private.h"
@@ -179,71 +180,29 @@ err_pci:
SPEX16(_outvar, _offset, _mask, _shift)
-static inline u8 ssb_crc8(u8 crc, u8 data)
+static u8 srom_crc8_table[CRC8_TABLE_SIZE];
+
+/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
+#define SROM_CRC8_POLY 0xAB
+
+static inline void ltoh16_buf(u16 *buf, unsigned int size)
{
- /* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
- static const u8 t[] = {
- 0x00, 0xF7, 0xB9, 0x4E, 0x25, 0xD2, 0x9C, 0x6B,
- 0x4A, 0xBD, 0xF3, 0x04, 0x6F, 0x98, 0xD6, 0x21,
- 0x94, 0x63, 0x2D, 0xDA, 0xB1, 0x46, 0x08, 0xFF,
- 0xDE, 0x29, 0x67, 0x90, 0xFB, 0x0C, 0x42, 0xB5,
- 0x7F, 0x88, 0xC6, 0x31, 0x5A, 0xAD, 0xE3, 0x14,
- 0x35, 0xC2, 0x8C, 0x7B, 0x10, 0xE7, 0xA9, 0x5E,
- 0xEB, 0x1C, 0x52, 0xA5, 0xCE, 0x39, 0x77, 0x80,
- 0xA1, 0x56, 0x18, 0xEF, 0x84, 0x73, 0x3D, 0xCA,
- 0xFE, 0x09, 0x47, 0xB0, 0xDB, 0x2C, 0x62, 0x95,
- 0xB4, 0x43, 0x0D, 0xFA, 0x91, 0x66, 0x28, 0xDF,
- 0x6A, 0x9D, 0xD3, 0x24, 0x4F, 0xB8, 0xF6, 0x01,
- 0x20, 0xD7, 0x99, 0x6E, 0x05, 0xF2, 0xBC, 0x4B,
- 0x81, 0x76, 0x38, 0xCF, 0xA4, 0x53, 0x1D, 0xEA,
- 0xCB, 0x3C, 0x72, 0x85, 0xEE, 0x19, 0x57, 0xA0,
- 0x15, 0xE2, 0xAC, 0x5B, 0x30, 0xC7, 0x89, 0x7E,
- 0x5F, 0xA8, 0xE6, 0x11, 0x7A, 0x8D, 0xC3, 0x34,
- 0xAB, 0x5C, 0x12, 0xE5, 0x8E, 0x79, 0x37, 0xC0,
- 0xE1, 0x16, 0x58, 0xAF, 0xC4, 0x33, 0x7D, 0x8A,
- 0x3F, 0xC8, 0x86, 0x71, 0x1A, 0xED, 0xA3, 0x54,
- 0x75, 0x82, 0xCC, 0x3B, 0x50, 0xA7, 0xE9, 0x1E,
- 0xD4, 0x23, 0x6D, 0x9A, 0xF1, 0x06, 0x48, 0xBF,
- 0x9E, 0x69, 0x27, 0xD0, 0xBB, 0x4C, 0x02, 0xF5,
- 0x40, 0xB7, 0xF9, 0x0E, 0x65, 0x92, 0xDC, 0x2B,
- 0x0A, 0xFD, 0xB3, 0x44, 0x2F, 0xD8, 0x96, 0x61,
- 0x55, 0xA2, 0xEC, 0x1B, 0x70, 0x87, 0xC9, 0x3E,
- 0x1F, 0xE8, 0xA6, 0x51, 0x3A, 0xCD, 0x83, 0x74,
- 0xC1, 0x36, 0x78, 0x8F, 0xE4, 0x13, 0x5D, 0xAA,
- 0x8B, 0x7C, 0x32, 0xC5, 0xAE, 0x59, 0x17, 0xE0,
- 0x2A, 0xDD, 0x93, 0x64, 0x0F, 0xF8, 0xB6, 0x41,
- 0x60, 0x97, 0xD9, 0x2E, 0x45, 0xB2, 0xFC, 0x0B,
- 0xBE, 0x49, 0x07, 0xF0, 0x9B, 0x6C, 0x22, 0xD5,
- 0xF4, 0x03, 0x4D, 0xBA, 0xD1, 0x26, 0x68, 0x9F,
- };
- return t[crc ^ data];
-}
-
-static u8 ssb_sprom_crc(const u16 *sprom, u16 size)
-{
- int word;
- u8 crc = 0xFF;
-
- for (word = 0; word < size - 1; word++) {
- crc = ssb_crc8(crc, sprom[word] & 0x00FF);
- crc = ssb_crc8(crc, (sprom[word] & 0xFF00) >> 8);
- }
- crc = ssb_crc8(crc, sprom[size - 1] & 0x00FF);
- crc ^= 0xFF;
+ size /= 2;
+ while (size--)
+ *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
+}
- return crc;
+static inline void htol16_buf(u16 *buf, unsigned int size)
+{
+ size /= 2;
+ while (size--)
+ *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
}
static int sprom_check_crc(const u16 *sprom, size_t size)
{
- u8 crc;
- u8 expected_crc;
- u16 tmp;
-
- crc = ssb_sprom_crc(sprom, size);
- tmp = sprom[size - 1] & SSB_SPROM_REVISION_CRC;
- expected_crc = tmp >> SSB_SPROM_REVISION_CRC_SHIFT;
- if (crc != expected_crc)
+ if (crc8(srom_crc8_table, (u8 *)sprom, 2 * size, CRC8_INIT_VALUE) !=
+ CRC8_GOOD_VALUE(srom_crc8_table))
return -EPROTO;
return 0;
@@ -690,8 +649,11 @@ static int ssb_pci_sprom_get(struct ssb_
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
return -ENOMEM;
+ crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
sprom_do_read(bus, buf);
+ /* convert to le */
+ htol16_buf(buf, 2 * bus->sprom_size);
err = sprom_check_crc(buf, bus->sprom_size);
if (err) {
/* try for a 440 byte SPROM - revision 4 and higher */
@@ -702,6 +664,7 @@ static int ssb_pci_sprom_get(struct ssb_
return -ENOMEM;
bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
sprom_do_read(bus, buf);
+ htol16_buf(buf, 2 * bus->sprom_size);
err = sprom_check_crc(buf, bus->sprom_size);
if (err) {
/* All CRC attempts failed.
@@ -721,9 +684,11 @@ static int ssb_pci_sprom_get(struct ssb_
goto out_free;
}
ssb_printk(KERN_WARNING PFX "WARNING: Invalid"
- " SPROM CRC (corrupt SPROM)\n");
+ " SPROM CRC (corrupt SPROM)\n");
}
}
+ /* restore endianess */
+ ltoh16_buf(buf, 2 * bus->sprom_size);
err = sprom_extract(bus, sprom, buf, bus->sprom_size);
out_free:
Index: wireless-testing-new/drivers/ssb/Kconfig
===================================================================
--- wireless-testing-new.orig/drivers/ssb/Kconfig
+++ wireless-testing-new/drivers/ssb/Kconfig
@@ -24,6 +24,7 @@ config SSB
# Common SPROM support routines
config SSB_SPROM
bool
+ select CRC8
# Support for Block-I/O. SELECT this from the driver that needs it.
config SSB_BLOCKIO
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Shahar Lev @ 2011-10-08 20:30 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, Johannes Berg, linux-wireless
In-Reply-To: <1318104160.9690.49.camel@cumari>
Part of a plot to increase the chances of my submissions getting
through by posing as Mr. Levi.
Thanks,
The Other Shahar
On Sat, Oct 8, 2011 at 10:02 PM, Luciano Coelho <coelho@ti.com> wrote:
> On Sat, 2011-10-08 at 21:55 +0200, Arik Nemtsov wrote:
>> On Sat, Oct 8, 2011 at 21:45, Luciano Coelho <coelho@ti.com> wrote:
>> >
>> > But what I meant with "the bug" was that, if this can be avoided in
>> > mac80211, why not do it there? Is it a a big effort to do it in
>> > mac80211?
>>
>> Not sure it's a big effort, but it requires testing etc. I'm afraid
>> we're all pretty busy with other stuff right now :)
>
> Not a very good excuse when it comes to upstreaming, but okay, I'll take
> this in anyway. :)
>
> Thanks, Shahar, and welcome! :)
>
> (BTW, Shahar Lev is not to be confused with Shahar Levi, as they are two
> different persons :)
>
> --
> Cheers,
> Luca.
>
>
^ permalink raw reply
* [PATCH 2/2] ath9k: only send FCS-fail packets to mac80211 if requested
From: Felix Fietkau @ 2011-10-08 20:02 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
In-Reply-To: <1318104179-90126-1-git-send-email-nbd@openwrt.org>
Prevents lots of broken frames from showing up on monitor interfaces
by default.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/recv.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index c7306dc..bc71c0e 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -811,6 +811,7 @@ static bool ath9k_rx_accept(struct ath_common *common,
struct ath_rx_status *rx_stats,
bool *decrypt_error)
{
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
bool is_mc, is_valid_tkip, strip_mic, mic_error;
struct ath_hw *ah = common->ah;
__le16 fc;
@@ -875,7 +876,7 @@ static bool ath9k_rx_accept(struct ath_common *common,
status_mask = ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
ATH9K_RXERR_KEYMISS;
- if (ah->is_monitoring)
+ if (ah->is_monitoring && (sc->rx.rxfilter & FIF_FCSFAIL))
status_mask |= ATH9K_RXERR_CRC;
if (rx_stats->rs_status & ~status_mask)
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/2] ath9k_hw: fix a regression in key miss handling
From: Felix Fietkau @ 2011-10-08 20:02 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
The commit "ath9k_hw: Fix incorrect key_miss handling" changed the code
to only report key miss errors if a MIC error wasn't reported.
When checking the flags in that order in the MAC code, it might miss some
real events, because the value of the MIC error flag is undefined under
some conditions.
The primary issue addressed by the previous commit is making sure that
MIC errors are properly reported on the STA side. This can be fixed in
a better way by adding a separate rx status flag for key miss and
ignoring it for multicast frames.
This fix slightly improves stability in AP mode on some older hardware,
like AR9132.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++--
drivers/net/wireless/ath/ath9k/mac.c | 4 ++--
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/recv.c | 27 ++++++++++++++-------------
4 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 6cabc85..b363cc0 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -525,8 +525,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (rxsp->status11 & AR_MichaelErr)
rxs->rs_status |= ATH9K_RXERR_MIC;
- else if (rxsp->status11 & AR_KeyMiss)
- rxs->rs_status |= ATH9K_RXERR_DECRYPT;
+ if (rxsp->status11 & AR_KeyMiss)
+ rxs->rs_status |= ATH9K_RXERR_KEYMISS;
}
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 22f23ea..43f53d6 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -620,8 +620,8 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
- else if (ads.ds_rxstatus8 & AR_KeyMiss)
- rs->rs_status |= ATH9K_RXERR_DECRYPT;
+ if (ads.ds_rxstatus8 & AR_KeyMiss)
+ rs->rs_status |= ATH9K_RXERR_KEYMISS;
}
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 91c9654..934caa7 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -181,6 +181,7 @@ struct ath_htc_rx_status {
#define ATH9K_RXERR_FIFO 0x04
#define ATH9K_RXERR_DECRYPT 0x08
#define ATH9K_RXERR_MIC 0x10
+#define ATH9K_RXERR_KEYMISS 0x20
#define ATH9K_RX_MORE 0x01
#define ATH9K_RX_MORE_AGGR 0x02
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index f658ec6..c7306dc 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -823,7 +823,8 @@ static bool ath9k_rx_accept(struct ath_common *common,
test_bit(rx_stats->rs_keyix, common->tkip_keymap);
strip_mic = is_valid_tkip && ieee80211_is_data(fc) &&
!(rx_stats->rs_status &
- (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC));
+ (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
+ ATH9K_RXERR_KEYMISS));
if (!rx_stats->rs_datalen)
return false;
@@ -851,6 +852,8 @@ static bool ath9k_rx_accept(struct ath_common *common,
* descriptors.
*/
if (rx_stats->rs_status != 0) {
+ u8 status_mask;
+
if (rx_stats->rs_status & ATH9K_RXERR_CRC) {
rxs->flag |= RX_FLAG_FAILED_FCS_CRC;
mic_error = false;
@@ -858,7 +861,8 @@ static bool ath9k_rx_accept(struct ath_common *common,
if (rx_stats->rs_status & ATH9K_RXERR_PHY)
return false;
- if (rx_stats->rs_status & ATH9K_RXERR_DECRYPT) {
+ if ((rx_stats->rs_status & ATH9K_RXERR_DECRYPT) ||
+ (!is_mc && (rx_stats->rs_status & ATH9K_RXERR_KEYMISS))) {
*decrypt_error = true;
mic_error = false;
}
@@ -868,17 +872,14 @@ static bool ath9k_rx_accept(struct ath_common *common,
* decryption and MIC failures. For monitor mode,
* we also ignore the CRC error.
*/
- if (ah->is_monitoring) {
- if (rx_stats->rs_status &
- ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
- ATH9K_RXERR_CRC))
- return false;
- } else {
- if (rx_stats->rs_status &
- ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC)) {
- return false;
- }
- }
+ status_mask = ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
+ ATH9K_RXERR_KEYMISS;
+
+ if (ah->is_monitoring)
+ status_mask |= ATH9K_RXERR_CRC;
+
+ if (rx_stats->rs_status & ~status_mask)
+ return false;
}
/*
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Luciano Coelho @ 2011-10-08 20:02 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <CA+XVXff_5isgfReUYXh8K1nNTtAqnFp5tb36EKLL7MBaTka+UQ@mail.gmail.com>
On Sat, 2011-10-08 at 21:55 +0200, Arik Nemtsov wrote:
> On Sat, Oct 8, 2011 at 21:45, Luciano Coelho <coelho@ti.com> wrote:
> >
> > But what I meant with "the bug" was that, if this can be avoided in
> > mac80211, why not do it there? Is it a a big effort to do it in
> > mac80211?
>
> Not sure it's a big effort, but it requires testing etc. I'm afraid
> we're all pretty busy with other stuff right now :)
Not a very good excuse when it comes to upstreaming, but okay, I'll take
this in anyway. :)
Thanks, Shahar, and welcome! :)
(BTW, Shahar Lev is not to be confused with Shahar Levi, as they are two
different persons :)
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Arik Nemtsov @ 2011-10-08 19:55 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <1318103127.9690.46.camel@cumari>
On Sat, Oct 8, 2011 at 21:45, Luciano Coelho <coelho@ti.com> wrote:
>
> But what I meant with "the bug" was that, if this can be avoided in
> mac80211, why not do it there? Is it a a big effort to do it in
> mac80211?
Not sure it's a big effort, but it requires testing etc. I'm afraid
we're all pretty busy with other stuff right now :)
Arik
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Luciano Coelho @ 2011-10-08 19:45 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <CA+XVXfd+vN7b=oYrysPCuynAgy5=4SgRHuznJRW0h+6ez7YqsQ@mail.gmail.com>
On Sat, 2011-10-08 at 21:19 +0200, Arik Nemtsov wrote:
> On Fri, Oct 7, 2011 at 23:17, Luciano Coelho <coelho@ti.com> wrote:
> > On Fri, 2011-10-07 at 23:03 +0200, Shahar Lev wrote:
> >> On Fri, Oct 7, 2011 at 6:20 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >> > Maybe you should also change that? :-)
> >>
> >> Consider it added to our collective TODO.
> >
> > Well, the fix is probably supposed to be done in mac80211, instead of
> > hiding the bug by removing the warning, isn't it?
>
> Sometimes data is sent when the IBSS interface is not connected.
> wl12xx handles this correctly by throwing the packets. In this sense
> there's no "bug".
> All this patch does is remove warning messages that confuse the users
> (and developers).
>
> I agree fixing mac80211 is the better thing to do, and we'll get to it
> when time permits.
Okay, not a big problem to do this in the driver.
But what I meant with "the bug" was that, if this can be avoided in
mac80211, why not do it there? Is it a a big effort to do it in
mac80211?
--
Cheers,
Luca.
^ permalink raw reply
* problem in b43_nrssi_hw_update()?
From: Dan Carpenter @ 2011-10-08 19:29 UTC (permalink / raw)
To: mb; +Cc: linux-wireless
My latest testing version of Smatch complains about the wrapping in
b43_nrssi_hw_update() when val is 0xffff. The function is defined
like this:
/* http://bcm-specs.sipsolutions.net/NRSSILookupTable */
static void b43_nrssi_hw_update(struct b43_wldev *dev, u16 val)
{
u16 i;
s16 tmp;
for (i = 0; i < 64; i++) {
tmp = b43_nrssi_hw_read(dev, i);
tmp -= val;
tmp = clamp_val(tmp, -32, 31);
b43_nrssi_hw_write(dev, i, tmp);
}
}
It's only called from one place like this:
/* The specs state to update the NRSSI LT with
* the value 0x7FFFFFFF here. I think that is some weird
* compiler optimization in the original driver.
* Essentially, what we do here is resetting all NRSSI LT
* entries to -32 (see the clamp_val() in nrssi_hw_update())
*/
b43_nrssi_hw_update(dev, 0xFFFF); //FIXME?
Since tmp in b43_nrssi_hw_update() is s16 and val is always
(u16)0xFFFF, that means that:
tmp -= val;
is always the same just tmp += 1;
This code has a fixme, and it seems like an overly complicated way
of adding 1 to a variable, plus it doesn't seem to match the
documentation very well. :P
I know you've looked at this before and that's why it has the FIXME
comment... I'm not sure what to do...
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Arik Nemtsov @ 2011-10-08 19:19 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <1318022253.3549.108.camel@cumari>
On Fri, Oct 7, 2011 at 23:17, Luciano Coelho <coelho@ti.com> wrote:
> On Fri, 2011-10-07 at 23:03 +0200, Shahar Lev wrote:
>> On Fri, Oct 7, 2011 at 6:20 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > Maybe you should also change that? :-)
>>
>> Consider it added to our collective TODO.
>
> Well, the fix is probably supposed to be done in mac80211, instead of
> hiding the bug by removing the warning, isn't it?
Sometimes data is sent when the IBSS interface is not connected.
wl12xx handles this correctly by throwing the packets. In this sense
there's no "bug".
All this patch does is remove warning messages that confuse the users
(and developers).
I agree fixing mac80211 is the better thing to do, and we'll get to it
when time permits.
Arik
^ permalink raw reply
* Compat-wireless release for 2011-10-08 is baked
From: Compat-wireless cronjob account @ 2011-10-08 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
811845 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3573 - % of code consists of backport work
^ permalink raw reply
* Re: [PATCH 0/8] wireless: add DFS master support
From: Luis R. Rodriguez @ 2011-10-08 18:26 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, linville, Johannes Berg
In-Reply-To: <4E908C6D.7040703@neratec.com>
On Sat, Oct 8, 2011 at 10:46 AM, Zefir Kurtisi
<zefir.kurtisi@neratec.com> wrote:
> On 08.10.2011 00:32, Luis R. Rodriguez wrote:
>>
>> On Fri, Oct 7, 2011 at 3:29 PM, Luis R. Rodriguez
>> <mcgrof@qca.qualcomm.com> wrote:
>>>
>>> On Fri, Oct 7, 2011 at 2:11 PM, Luis R. Rodriguez
>>> <mcgrof@qca.qualcomm.com> wrote:
>>>>
>>>> On Tue, Oct 4, 2011 at 5:14 PM, Luis R. Rodriguez
>>>> <mcgrof@qca.qualcomm.com> wrote:
>>>>>
>>>>> On Tue, Oct 4, 2011 at 4:47 PM, Luis R. Rodriguez
>>>>> <mcgrof@qca.qualcomm.com> wrote:
>>>>>>
>>>>>> This set of 8 patches adds DFS master support to the Linux wireless
>>>>>> subsystem.
>>>>>> I've reviewed future possible changes to DFS master regions and it
>>>>>> seems that
>>>>>> we are not going to be having multiple DFS regions for one country,
>>>>>> instead
>>>>>> we'll always have one DFS region for one country.
>>>>>>
>>>>>> The changes here are spread out throughout wireless-regdb, crda the
>>>>>> kernel and
>>>>>> lastly iw. The changes made allow for older verions of CRDA to work
>>>>>> with new
>>>>>> wireless-regdb files with DFS region support. If you want DFS master
>>>>>> region
>>>>>> support you'll need to upgrade your CRDA, your kernel and then hope
>>>>>> someone
>>>>>> implements DFS master support for your respective driver.
>>>>>>
>>>>>> This patch series does not have specific driver changes, although some
>>>>>> seem to
>>>>>> be backing in the oven right now.
>>>>>
>>>>> Here's a puzzle though... If we change this series to use the other
>>>>> pad byte that was available, the first pad byte, instead of the last
>>>>> one, we loose backward compatibility support and I cannot figure out
>>>>> why. What I ended up seeing was that crda sends the message, and for
>>>>> some reason (return code is 222 from nl_wait_for_ack(), whatever that
>>>>> is) the kernel rejects it. I suspect it may have to do with some sort
>>>>> of offset to the *other* data that makes some of the rules output
>>>>> invalid data for the attribute policy, but at least when I hexdump the
>>>>> wireless-regdb the only changes I see are in the signature and the pad
>>>>> shift.
>>>>>
>>>>> I got tired of trying though and after seeing flipping the pad bytes
>>>>> things worked decided to stay with it. In my original RFC in December
>>>>> I had used u16 instead, but since the data was in the last pad byte
>>>>> things still worked. So something is fishy about only using the first
>>>>> pad byte. The change below, as far as I can tell, should not have any
>>>>> issues but it does with the older version of CRDA and even a new one.
>>>>
>>>> Johannes spotted the issue, I'll send the fix, thanks to Johannes.
>>>> John, Johannes the patches still apply my fix goes on top of these
>>>> changes, the fix is not addressing a regression introduced by this
>>>> patchset, instead it fixes a long standing issue which would prevent
>>>> us from using the next available pad byte.
>>>
>>> I'm going to respin this to make use of 2 bits:
>>>
>>> 00 unset
>>> 01 FCC
>>> 10 ETSI
>>> 11 JP
>>>
>>> We may need some more DFS values later but
>>
>> Sorry I did not finish this e-mail I meant that we may later have a
>> requirement for more DFS values but at this time we don't, we should
>> consider whether or not we will want to leave more bits for usage of
>> more DFS values and if so how many? Using two bits will give us
>> support for what we know today but nothing for the future.
>>
> For the future things we do not know of today we should add another bit and
> define
>
> 111 unknown / other
>
> to be able to mark special countrycodes that do not fully belong to the
> three known domains.
I thought about this a bit more, so we'd have to define this as a U8
attribute either way, so I would instead of calling NL80211_DFS_REGION
call it something like NL80211_CTRY_REQS and for now only use 2 bits
for the known DFS regions. We'd mask out the rest of the values. If we
ever decide we need a new DFS region we could just extend the values
on NL80211_CTRY_REQS after the last region. If we want to add a new
requirement that is country specific other than DFS we could start at
the end of the u8 instead of after the last DFS region. We could do
this without making any explicit reservations.
> We could use some invalid coding for those CCs (like no
> DFS domain set in CC
Sure, I should point out today every single regulatory domain will
have this set except US, only because I added a patch to match US to
DFS-FCC DFS region.
> but flag set for frequency band) to identify those
> special domains,
So you're saying in case later we find out we need band specific DFS data later?
> but using an additional bit would make things easier to
> handle.
We can extend this as we go, and just ensure upon review of new code
that we accommodate non -DFS crap at the end of the u8. Whatdya think?
Luis
^ 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