linux-kernel - Re: RFC: btusb firmware load help

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Oct 2010 22:36:38 +0530
From:	Bala Shanmugam <sbalashanmugam@...eros.com>
To:	Marcel Holtmann <holtmann@...ux.intel.com>
CC:	Shanmugamkamatchi Balashanmugam 
	<Shanmugamkamatchi.Balashanmugam@...eros.com>,
	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	Johannes Berg <johannes@...solutions.net>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	Deepak Dhamdhere <Deepak.Dhamdhere@...eros.com>,
	Sree Durbha <Sree.Durbha@...eros.com>
Subject: Re: RFC: btusb firmware load help

  On 10/7/2010 10:12 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.
>> 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
>
>
Thanks for your suggestion Marcel.
Can't we have same PID[3004 or later] for both the devices after loading 
the firmware by ath3k?
We need two different firmware if we plan to have two different PIDs for 
these two bluetooth devices.

Regards,
Bala.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/