B43_BFL_BTCOEXIST

[Michael Buesch]

On Wednesday 20 August 2008 18:05:19 Tim Gardner wrote:
> Larry Finger wrote:
> > Tim Gardner wrote:
> >> Larry,
> >>
> >> What does this flag do? It looks like it must change the on-the-air
> >> behavior with regard to stomping on Bluetooth. This LP comment indicates
> >> that these uncooperative adapters are causing faults in the Bluetooth
> >> driver:
> >>
> >> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/257020/comments/5
> >>
> >>
> >> While I believe the root issue is within the Bluetooth driver (nothing
> >> ought to be able to make it crash), is my hypothesis correct about the
> >> on-the-air transmit characteristics?
> > 
> > I have added Michael Buesch to the Cc list. He knows a lot more about
> > the driver than I do and will correct any misstatements of mine.
> > 
> > Yes, that flag deals with Bluetooth coexistence in the 2.4 GHz band. I
> > reread the original posting and I have no idea why the OP is blaming
> > commit c7202b637779f7e26decd6525a2f4463db918aaf. It only affects a few
> > cards and b43 is not even loaded in the dump that is shown. My belief
> > system does not allow the possibility for drivers that have never been
> > loaded to cause faults.
> > 
> > I think whatever is done for coexistence is handled by the firmware.
> > Outside of the special quirks implemented by the above commit, and the
> > ones I have submitted since, the driver does nothing special. It just
> > hands off the modified board flags to the shared memory.
> > 
> > I definitely agree that it is a problem with the Bluetooth driver.
> > 
> > Larry
> > 
> 
> It is comforting to know we share the same belief system :) If I had
> done my homework I would have _also_ noticed the b43 driver wasn't even
> loaded. In fact, the report specifically mentions i3945. Doh!

The Bluetooth-WLAN coexistence is almost completely done in firmware.
Basically, there are two GPIO pins one for WLAN-is-transmitting and one
for BT-is-transmitting. The only thing the kernel driver does is to
tell the firmware which pins on the hardware these are.
So on the chip (WLAN and BT), we have one input pin and one output pin.

How it works in detail is trivial:
The radio on either chip will not transmit, as long as the is-transmitting
line of the other radio is asserted.
While one radio transmits, it asserts the is-transmitting line of that chip.
That's all.

BT-coex can be hard to deal with. For example if the driver assigns the wrong
hardware pins for the is-transmitting input and output pins.

It's pretty hard to see, however, how this could cause a crash.
Especially if the driver is not loaded. ;)

The stack traces in the bugreport look very much like random memory
corruption. Please turn on most of the kernel-hacking debugging options.
Especially the memory/vm debugging and all the object debugging (like
spinlock and mutex debugging). Then reproduce.

-- 
Greetings Michael.