Here are the antenna related fixes for the sprom.
--
Greetings Michael.
Index: wireless-2.6/drivers/ssb/pci.c
===
--- wireless-2.6.orig/drivers/ssb/pci.c 2007-12-09 21:35:20.0 +0100
+++ wireless-2.6/drivers/ssb/pci.c
Ivo and Dmitry,
I have finally figured out why the b43 rfkill LED handling routine works on
some systems, and not on
others. It works as long as rfkill-input is built-in, or if the module is
loaded, but this module is
not automatically loaded even though rfkill.ko has been loaded, and
On Monday 10 December 2007 18:08:12 Larry Finger wrote:
Ivo and Dmitry,
I have finally figured out why the b43 rfkill LED handling routine works on
some systems, and not on
others. It works as long as rfkill-input is built-in, or if the module is
loaded, but this module is
not
On Monday 10 December 2007 18:17:38 Michael Buesch wrote:
On Monday 10 December 2007 18:08:12 Larry Finger wrote:
Ivo and Dmitry,
I have finally figured out why the b43 rfkill LED handling routine works on
some systems, and not on
others. It works as long as rfkill-input is built-in,
On Monday 10 December 2007 18:23:21 Larry Finger wrote:
This version of the rfkill switch patch is pretty straight forward. Please
comment on the dropping of wl-mutex before rfkill initialization. This is
the only way I could avoid the circular locking without a much earlier
rfkill
Michael Buesch wrote:
I think that's not acceptable, as it introduces a nasty (although unlikely)
race condition with the band switch. I will think about it and will fix
it myself then. If there's no way to properly fix it, I think it may also
be OK to live with this damn unlikely race.
On Dec 10, 2007 2:36 AM, Michael Buesch [EMAIL PROTECTED] wrote:
I have identified another regression introduced by
commit f04b3787bbce4567e28069a9ec97dcd804626ac7.
On my device it shows up as broken transmission after
a suspend/resume cycle. The workaround for it is to boot
a known good
