There's been about 3 months since the last time this patch was sent,
so I assume it was lost in the
queue or something.
Please consider applying. It is only a one-liner, It fixes a real WTF-type bug
(modprobe -r b44 && modprobe b44 and boom! no internet!)
and I 've been testing, using and carrying it along for the last 3 months
(not to mention having to spend the time to debug it in the first place :-)
It is a regression from 2.6.24 IIRC (when b44 was ported to the ssb
stack) and the patch is
authored by the guy who wrote this port.
Currently this and the other b44 patch I 'm going to resend next are
the only things that make
me maintain a custom kernel.
Thanks in advance,
---------- Forwarded message ----------
From: Michael Buesch <email@example.com>
Date: Sun, Nov 16, 2008 at 4:39 PM
Subject: [PATCH] b44: Disable device on shutdown
To: Jeff Garzik <firstname.lastname@example.org>
Cc: email@example.com, Pantelis Koukousoulas <firstname.lastname@example.org>,
Gary Zambrano <email@example.com>, firstname.lastname@example.org
Disable the SSB core on device shutdown.
This has two advantages:
1) A clean device shutdown is always desired here, because we disable
the device's global crystal in the next statement.
2) This fixes a bug where the device will come up with the enable-bit
set on the next initialization (without a reboot inbetween).
This causes breakage on the second initialization due to code that
checks this bit (ssb_device_is_enabled() checks).
Reported-by: Pantelis Koukousoulas <email@example.com>
Signed-off-by: Michael Buesch <firstname.lastname@example.org>
I think this should go in for 2.6.28, as it fixes a
device-doesn't-work-anymore bug after a insmod-rmmod-insmod cycle.
--- wireless-testing.orig/drivers/net/b44.c 2008-11-16
+++ wireless-testing/drivers/net/b44.c 2008-11-16 14:47:06.000000000 +0100
Also applied, and again it was very whitespace mangled by your
That's why these patches sit for so long. It's because you post them
in a format that makes integrating them require a lot of work by the
It seems there is no way to prevent the gmail web client from horribly
mangling a patch :(
From now on I guess I 'll just put up a tree in gitorious and send pull
The first time these 2 patches were sent by Michael and they were
Thanks for applying and sorry for the trouble (it is the last time I
get it wrong, I promise :)