Re: RFC: btusb firmware load help

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

 



 On 10/7/2010 8:54 PM, Marcel Holtmann wrote:
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.

Regards

Marcel


Marcel,

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.

Thanks for your time.

Regards,
Bala.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[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