RE: RFC: btusb firmware load help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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‰¨þ)ßø

[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux