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

[Jesse Sung]

2012/10/11 Andy Whitcroft <apw at canonical.com>:
> 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 think he is talking about this:
http://article.gmane.org/gmane.linux.bluez.kernel/29643

It seems that some intel devices need specific initialization before they can
be used, just like broadcom devices need patchram. Upstream would like to
see a more general solution that can be used by intel, broadcom, and maybe
upcoming atheros devices.

Dunno how long will it take to get an solution, but there are already a lot
of these devices in users machines.

Thanks,
Jesse