[PATCH v2 1/2] backports: Include drivers/net/wireless/cw1200

[PATCH v2 1/2] backports: Include drivers/net/wireless/cw1200

[Solomon Peachy]

The cw1200 WLAN driver was added in 3.11-rc; include it in backports.

Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
 copy-list | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/copy-list b/copy-list
index aaf5ae9..a227f30 100644
--- a/copy-list
+++ b/copy-list
@@ -28,7 +28,7 @@ include/linux/usb/usbnet.h
 include/linux/usb/rndis_host.h
 include/linux/spi/libertas_spi.h
 include/linux/platform_data/brcmfmac-sdio.h
-
+include/linux/platform_data/net-cw1200.h
 include/uapi/linux/nl80211.h
 
 include/net/cfg80211.h
@@ -51,6 +51,7 @@ include/linux/bcma/
 drivers/net/wireless/b43/
 drivers/net/wireless/b43legacy/
 drivers/net/wireless/brcm80211/
+drivers/net/wireless/cw1200/
 drivers/net/wireless/iwlegacy/
 drivers/net/wireless/iwlwifi/
 drivers/net/wireless/rt2x00/
-- 
1.8.3.1

[PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Solomon Peachy]

Without this patch, the hardware *will* hang on <3.2 kernels when a
512-byte SDIO transfer occurs.

3.2-rc added an SDIO quirk to work around this, so this code was
stripped from the driver when committed to the mainline.

Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
 .../network/75-cw1200-sdio-quirk/cw1200.patch             | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 patches/collateral-evolutions/network/75-cw1200-sdio-quirk/cw1200.patch

diff --git a/patches/collateral-evolutions/network/75-cw1200-sdio-quirk/cw1200.patch b/patches/collateral-evolutions/network/75-cw1200-sdio-quirk/cw1200.patch
new file mode 100644
index 0000000..2533051
--- /dev/null
+++ b/patches/collateral-evolutions/network/75-cw1200-sdio-quirk/cw1200.patch
@@ -0,0 +1,15 @@
+--- a/drivers/net/wireless/cw1200/cw1200_sdio.c
++++ b/drivers/net/wireless/cw1200/cw1200_sdio.c
+@@ -253,6 +253,12 @@ static size_t cw1200_sdio_align_size(struct hwbus_priv *self, size_t size)
+ 	else
+ 		size = sdio_align_size(self->func, size);
+ 
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(3, 2, 0))
++	/* A quirk to handle this was committed in 3.2-rc */
++	if (size == SDIO_BLOCK_SIZE)
++		size += SDIO_BLOCK_SIZE;  /* HW bug; force use of block mode */
++#endif
++
+ 	return size;
+ }
+ 
-- 
1.8.3.1

Re: [PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Luis R. Rodriguez]

On Thu, Aug 15, 2013 at 08:55:57AM -0400, Solomon Peachy wrote:
> Without this patch, the hardware *will* hang on <3.2 kernels when a
> 512-byte SDIO transfer occurs.
> 
> 3.2-rc added an SDIO quirk to work around this, so this code was
> stripped from the driver when committed to the mainline.
> 
> Signed-off-by: Solomon Peachy <pizza@shaftnet.org>

Thanks, applied both and pushed!

  Luis

Re: [PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Hauke Mehrtens]

On 08/16/2013 05:07 AM, Luis R. Rodriguez wrote:
> On Thu, Aug 15, 2013 at 08:55:57AM -0400, Solomon Peachy wrote:
>> Without this patch, the hardware *will* hang on <3.2 kernels when a
>> 512-byte SDIO transfer occurs.
>>
>> 3.2-rc added an SDIO quirk to work around this, so this code was
>> stripped from the driver when committed to the mainline.
>>
>> Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
> 
> Thanks, applied both and pushed!
> 
>   Luis

Hi Solomon,

I just compile tested cw1200 against many kernel versions and I always
get an error of a missing symbol for kernel <= 3.9:

WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/2.6.39/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.0.89/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.1.10/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.2.50/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.3.8/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.4.56/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.5.7/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.6.11/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.7.10/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.8.13/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!
WARNING: "get_random_int"
[/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.9.11/drivers/net/wireless/cw1200/cw1200_core.ko]
undefined!

I deactivate compiling against older kernels than 3.6.39 because that
caused some other problems like starting with 3.6.37 and missing
hw_features in 2.6.38:

    drivers/net/wireless/cw1200/bh.c: In function ‘cw1200_register_bh’:
    drivers/net/wireless/cw1200/bh.c:62:72: error: ‘WQ_CPU_INTENSIVE’
undeclared (first use in this function)
    drivers/net/wireless/cw1200/bh.c:62:72: note: each undeclared
identifier is reported only once for each function it appears in
    make[7]: *** [/drivers/net/wireless/cw1200/bh.o] Error 1

Hauke

Re: [PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

On Fri, Aug 16, 2013 at 12:38:39PM +0200, Hauke Mehrtens wrote:
> I just compile tested cw1200 against many kernel versions and I always
> get an error of a missing symbol for kernel <= 3.9:
> 
> WARNING: "get_random_int"
> [/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.4.56/drivers/net/wireless/cw1200/cw1200_core.ko]
> undefined!

Argh, it wasn't an exported symbol in older kernels.  (How did 
this ever work for me on my 3.4 testbed?)

Hmm.  Rather than patching cw1200 to use get_random_bytes(), 
would it make more sense to add a backported version of this to 
compat-3.8 instead?

> I deactivate compiling against older kernels than 3.6.39 because that
> caused some other problems like starting with 3.6.37 and missing
> hw_features in 2.6.38:
> 
>     drivers/net/wireless/cw1200/bh.c: In function ‘cw1200_register_bh’:
>     drivers/net/wireless/cw1200/bh.c:62:72: error: ‘WQ_CPU_INTENSIVE’
> undeclared (first use in this function)
>     drivers/net/wireless/cw1200/bh.c:62:72: note: each undeclared
> identifier is reported only once for each function it appears in
>     make[7]: *** [/drivers/net/wireless/cw1200/bh.o] Error 1

IIRC this was actually defined in 2.6.36. I have another patch (stripped 
via the mainlining effort) that implements this functionality via 
kthreads for <=2.6.35 kernels.  (Given that the new workqueue semantics 
were backported, I'd hoped to retire this patch...)

I'll go through the 'ckmake' process, and post any necessary patches to 
get cw1200 to cleanly build at least as far back as 2.6.35.

Cheers,

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Hauke Mehrtens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/16/2013 01:47 PM, Solomon Peachy wrote:
> On Fri, Aug 16, 2013 at 12:38:39PM +0200, Hauke Mehrtens wrote:
>> I just compile tested cw1200 against many kernel versions and I
>> always get an error of a missing symbol for kernel <= 3.9:
>> 
>> WARNING: "get_random_int" 
>> [/pub/mem/hauke/devel/tmp/.tmp.ckmake/3.4.56/drivers/net/wireless/cw1200/cw1200_core.ko]
>>
>> 
undefined!
> 
> Argh, it wasn't an exported symbol in older kernels.  (How did this
> ever work for me on my 3.4 testbed?)

I tested this on an amd64 system, it could be that it works on some
other archs.

> Hmm.  Rather than patching cw1200 to use get_random_bytes(), would
> it make more sense to add a backported version of this to 
> compat-3.8 instead?

Yes you should put it into backport/compat/backport-3.10.c.
I am still wondering if get_random_int() is needed for such an
algorithm at all.

>> I deactivate compiling against older kernels than 3.6.39 because
>> that caused some other problems like starting with 3.6.37 and
>> missing hw_features in 2.6.38:
>> 
>> drivers/net/wireless/cw1200/bh.c: In function
>> ‘cw1200_register_bh’: drivers/net/wireless/cw1200/bh.c:62:72:
>> error: ‘WQ_CPU_INTENSIVE’ undeclared (first use in this
>> function) drivers/net/wireless/cw1200/bh.c:62:72: note: each
>> undeclared identifier is reported only once for each function it
>> appears in make[7]: *** [/drivers/net/wireless/cw1200/bh.o] Error
>> 1
> 
> IIRC this was actually defined in 2.6.36. I have another patch
> (stripped via the mainlining effort) that implements this
> functionality via kthreads for <=2.6.35 kernels.  (Given that the
> new workqueue semantics were backported, I'd hoped to retire this
> patch...)
> 
> I'll go through the 'ckmake' process, and post any necessary
> patches to get cw1200 to cleanly build at least as far back as
> 2.6.35.

I uploaded a logfile with some error messages:
http://hauke-m.de/files/compat-wireless/ckmake.log

Hauke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJSDiYbAAoJEIZ0px9YPRMyM7UP/AtPam8sVOqlnXaNUzRtr4fi
1JXy4Ec89o7yt8t3yhnn034yd7gnSw6bt1AlQwRNRtcasvtS9hDge9JZ2XBFSQP0
zDHzz38K3v149dG0CIuV+o+C+804KLVhbFHMfYoIur8XgS17T4hQgurZDENb8Iv2
EfI1asWNtjWfw9tSURkGHoZoJj9A17e4fEIBY8JuURCfewMAxIjcbV2VrrmNF2ZE
kzuFk6xW/dQVeWBFRMTOHj0lVkAR5DtVcFJR0cM9ZnxCZdAMpLAvAtOspm1Hf111
DdLlCtLJYRpaW6RIPtKOx1XJfltyVYP41DetVmAWnTnBhexFybHk8DVDmhKjTED2
sTPWUK8B6RT3VYHf8tzJISJxJWmH5N7F7Cv4dA+Bqqb8gs93UlggHu0GdFiT7XGF
1ao1vWpUq/eN+ya9cunE7BCG4hgawJL8xYnzwQEV0mhSLJCQb6518WXB6FlKqWZM
c96S8SdNSbKgdr0ls3OFYFSqNct0TN5o5qMYZEUCIiNmsMi5neRt2fHsE97YuPpY
QcJcQZglYNrO0bnIZTGSK+Gc0ZXMjADOokgY4swGSg0C4RiqGhSa0TJ87BExeDAn
18YldR3j7yuc9oC5oAwPWnL3oW3+8uEyR2qoQKTmJdXTSYFHU05iyHL3wxccH4Bv
bT/MufoA/VYj9tPe9SWn
=aRf8
-----END PGP SIGNATURE-----

Re: [PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

On Fri, Aug 16, 2013 at 03:16:11PM +0200, Hauke Mehrtens wrote:
> I tested this on an amd64 system, it could be that it works on some
> other archs.

Yeah, I was building this on arm.

> Yes you should put it into backport/compat/backport-3.10.c.
> I am still wondering if get_random_int() is needed for such an
> algorithm at all.

I'm not sure what you mean by this.  This is get_random_int() in current 
kernels: (copied from 3.11-rc)

/*
 * Get a random word for internal kernel use only. Similar to urandom but
 * with the goal of minimal entropy pool depletion. As a result, the random
 * value is not cryptographically secure but for several uses the cost of
 * depleting entropy is too high
 */
static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash);
unsigned int get_random_int(void)
{
        __u32 *hash;
        unsigned int ret;

        if (arch_get_random_int(&ret))
                return ret;

        hash = get_cpu_var(get_random_int_hash);

        hash[0] += current->pid + jiffies + get_cycles();
        md5_transform(hash, random_int_secret);
        ret = hash[0];
        put_cpu_var(get_random_int_hash);

        return ret;
}

The cw1200 driver calls get_random_int() on every tx paket when there is 
QoS/queue contention to determine random backoff intervals.  The numbers 
don't need to be cryptographically secure, just "different" -- and 
there's really no point in sucking the kernel entropy pool dry to do 
this when it could happen on nearly every frame we transmit.  IOW, this 
is the perfect situation for get_random_int() vs get_random_bytes().

I wonder if it's worth backporting this whole thing (possibly minus 
arch_get_random_int()) or just re-implementing it using 
get_random_bytes() instead:

unsigned int get_random_int(void)
{
	int r;
	get_random_bytes(&r, sizeof(r));

	return r;
}

After all, this logic is what any modules would have had would have had 
to use prior to 3.10.

Any thoughts on this?

> I uploaded a logfile with some error messages:
> http://hauke-m.de/files/compat-wireless/ckmake.log

Thanks, I will look into this tonight.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH v2 2/2] backports: Add patch for cw1200_sdio with kernels < 3.2

[Hauke Mehrtens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/16/2013 04:23 PM, Solomon Peachy wrote:
> On Fri, Aug 16, 2013 at 03:16:11PM +0200, Hauke Mehrtens wrote:
>> I tested this on an amd64 system, it could be that it works on
>> some other archs.
> 
> Yeah, I was building this on arm.
> 
>> Yes you should put it into backport/compat/backport-3.10.c. I am
>> still wondering if get_random_int() is needed for such an 
>> algorithm at all.
> 
> I'm not sure what you mean by this.  This is get_random_int() in
> current kernels: (copied from 3.11-rc)
> 
> /* * Get a random word for internal kernel use only. Similar to
> urandom but * with the goal of minimal entropy pool depletion. As a
> result, the random * value is not cryptographically secure but for
> several uses the cost of * depleting entropy is too high */ static
> DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash); 
> unsigned int get_random_int(void) { __u32 *hash; unsigned int ret;
> 
> if (arch_get_random_int(&ret)) return ret;
> 
> hash = get_cpu_var(get_random_int_hash);
> 
> hash[0] += current->pid + jiffies + get_cycles(); 
> md5_transform(hash, random_int_secret); ret = hash[0]; 
> put_cpu_var(get_random_int_hash);
> 
> return ret; }
> 
> The cw1200 driver calls get_random_int() on every tx paket when
> there is QoS/queue contention to determine random backoff
> intervals.  The numbers don't need to be cryptographically secure,
> just "different" -- and there's really no point in sucking the
> kernel entropy pool dry to do this when it could happen on nearly
> every frame we transmit.  IOW, this is the perfect situation for
> get_random_int() vs get_random_bytes().
> 
> I wonder if it's worth backporting this whole thing (possibly minus
>  arch_get_random_int()) or just re-implementing it using 
> get_random_bytes() instead:
> 
> unsigned int get_random_int(void) { int r; get_random_bytes(&r,
> sizeof(r));
> 
> return r; }
> 
> After all, this logic is what any modules would have had would have
> had to use prior to 3.10.
> 
> Any thoughts on this?

Yes using get_random_bytes() sound good to me, so you would add this
functions somewhere to backports.

I was thinking about if using get_random_int() in cw1200 already has a
too big overhead, but I do not know how long it takes to generate this
random data, but this is unrelated to backports.

>> I uploaded a logfile with some error messages: 
>> http://hauke-m.de/files/compat-wireless/ckmake.log
> 
> Thanks, I will look into this tonight.
> 
> - Solomon
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJSDo5AAAoJEIZ0px9YPRMyJuAQAKcHsDg6sptiQKuLWx6JWRZy
T2q0hdiNR38hl6tHmYjhWl+BY5GWrFTAQGw48nFSu6kNCk0UQPIcffDNTKoGZe0r
Ls+bzmfsD9ZcstndnK26gRKvsW5vOxUPvgtl8Jqf3YvX16ApZqr9XSWFWXSEYKSX
8LYvewR/6su66y5OUcL4VmQv/6CgLmslQDRJQanKfMkh/1B32JXvNMWbFQt/rviR
iwOpvrSYTfAeG0WUUdsSDXM56Rm2JeE57PNwYT9RIiyjKY50V+Zv3kVXqWrtsmeo
+Ql2pTGMrCW9ImJFUEgaCSYlpb0omOGOa6nRmkkV8o8MbibgWYhSEnlRLvMDl5z4
UJjKKGN4FNJyWDcxeVvayU1oLo0dLlkBEw0BVxrScgaOBochi3l5cJOB2FB8VM5l
petaOTuVAE+ctNEqiKNezfINvaGawvv3EBzmetKlm/oPdbUvhoCKRea4ZtASQzz+
thGSNFLBYk4kH3wGArmDZG3jVoQ/65PtsondVZy3JtV3/q4EY5FJPldMe5ONviyR
CKoCHxK/UbeyE8J/emCxMekj7OJfglpDdaAEApqku2EC1icEjI8fi6ny2n2JsFjx
nyYIGLJmLVeYxts0eAeYcM9MzxlaagQEvDl+j8FgcJpvGKgf7tUwxwzM6ZF/kokV
VH6XKReprJeXS1TKmIzy
=ICEb
-----END PGP SIGNATURE-----