Hi Marcel, Bala, > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Marcel Holtmann > Sent: Thursday, October 07, 2010 9:42 AM > To: Shanmugamkamatchi Balashanmugam > Cc: Shanmugamkamatchi Balashanmugam; Luis Rodriguez; Johannes Berg; > linux-bluetooth; linux-kernel@xxxxxxxxxxxxxxx; linux- > wireless@xxxxxxxxxxxxxxx; Deepak Dhamdhere; Sree Durbha > Subject: Re: RFC: btusb firmware load help > > Hi Bala, > > > >> Thanks Johannes. This would be better option to change PID in > firmware > > >> as blacklisting 3002 might create problems for 3011 chipsets. > > >> Will try and let you people know. > > > The misbehaving 3002 needs to be blacklisted in btusb.c anyway. > However > > > after loading the firmware to 3002 device, it should change its PID > to > > > something else. > > > > > > I am still trying to figure out if this is one stage firmware > loading or > > > a two stage firmware loading. This is all pretty unclear and nobody > has > > > answered this clearly so far. > > > > eeprom based 3011 chips comes up with PID 3000 giving control to DFU > > driver [ath3k]. ath3k downloads the > > firmware changing PID to 3002. Now btusb gets control. > > > > In sflash based devices to reduce windows suspend/resume time we had > a > > small firmware in flash which > > enables the device to get detected as Generic Bluetooth USB device > with > > PID 3002. So control reaches btusb when device is plugged in, > leaving > > no option for us to load the actual firmware. > > > > Solution would be to blacklist 3002 in btusb, enable ath3k to get > > control for both the devices, download the firmware and change PID to > > 3003 so that control with come to btusb. > > so here is the thing that needs to be done. > > a) Get a firmware for PID 3000 devices that change the firmware to some > other PID. Since 3003 is already in use as well, using 3004 or later is > better approach. > > b) Blacklist PID 3002 in btusb.c. > > c) Handle special firmware loading case for PID 3002 sflash devices. If > firmware is loaded changed to 3005 or other. > > And as a general note, I prefer that the PID after loading firmware is > different if you don't happen to actually load the same firmware. > > So please sort out your USB PID assignment for Bluetooth in general. > This seems to be a mess that is not thought through properly. > > Regards > > Marcel > Yes, it is a good idea to let the downloadable firmware set a new PID, along with the blacklist on the 3002 PID for the first go round. I emphasize, it is the downloaded firmware that will be required to do the PID swizzling, not the sflash firmware. And I agree we should have a map of the PIDs in use and what they are used for, once we get through this immediate fixing phase. Thanks, K++ ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
