B43_BFL_BTCOEXIST

Michael Buesch mb at bu3sch.de
Wed Aug 20 17:21:18 UTC 2008


On Wednesday 20 August 2008 19:18:54 Michael Buesch wrote:
> 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.

Oh, I forgot to say:
So this obviously does only work with combined WLAN-Bluetooth chips, as the
GPIO lines must be physically connected. It has no effect on USB BT sticks.

-- 
Greetings Michael.




More information about the kernel-team mailing list