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, 07 Oct 2010 18:42:21 +0200
From:	Marcel Holtmann <holtmann@...ux.intel.com>
To:	Bala Shanmugam <sbalashanmugam@...eros.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

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


--
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/