[RFC][Precise][PATCH 0/2] UBUNTU: SAUCE: Bluetooth: Support for loading Broadcom bluetooth firmware

[Tim Gardner]

On 10/11/2012 05:42 AM, Andy Whitcroft wrote:
> On Thu, Oct 11, 2012 at 06:52:58PM +0800, Jesse Sung wrote:
>> From: Wen-chien Jesse Sung <jesse.sung at canonical.com>
>>
>> BugLink: https://launchpad.net/bugs/1065400
>>
>> Broadcom bluetooth chips require a tool called patchram uploader [1]
>> to load firmware. This applies to at least BCM20702 and BCM43142.
>> Although some of the devices have an OTPROM that contains required
>> firmware, but it is found that these devices would not have HFP/HSP
>> support unless a upgraded firmware is loaded via patchram uploader.
>>
>> This tool requires hci device to do the firmware loading, but
>> this may cause some race condition between patchram tool and
>> bluetoothd or something that also works on hci interface.
>>
>> Also it needs some hooks to make firmware loads after bootup,
>> s3, s4, rfkill, and device hotplug events. Implement this loader
>> in kernel module would make things more easier.
>>
>> This patchset implements the patchram loader in btusb. It uploads
>> patchram firmware at the first hci open. Although this patchset
>> is rejected by upstream [2][3][4], it still could be a temporary
>> workaround before a final solution is landed in upstream.
>>
>> Since this patchset only affects people who have these modules,
>> and fails to do request_firmware() does not trigger an error,
>> this workaround should be safe for current users.
>>
>> [1] http://marc.info/?l=linux-bluetooth&m=132039175324993&w=2
>> [2] http://marc.info/?l=linux-bluetooth&m=134933588701899&w=2
>> [3] http://marc.info/?t=134933604300005&r=1&w=2
>> [4] http://marc.info/?l=linux-bluetooth&m=134933588701899&w=2
>>
>> Wen-chien Jesse Sung (2):
>>   Add a load_firmware callback to struct hci_dev
>>   Implement broadcom patchram firmware loader
> 
> Upstream seemed pretty against the way this works, and how often we load
> the firmware.  How far away are we from getting a working solution that
> might be acceptable.  I note he pointed us to the work intel is doing on
> a similar device?  Is that done yet?
> 
> -apw
> 

I don't think this looks _too_ bad, and we're unlikely to get an
upstream solution in a timely manner. Plus, it only affects BT devices
that are specifically marked BTUSB_BCM_PATCHRAM (which I assume Jesse
has tested).

rtg
-- 
Tim Gardner tim.gardner at canonical.com