Hi Marcel,
On Thu, May 8, 2014 at 4:17 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Petri,
>
>> After hardware reset, some BCM Bluetooth adapters obtain their initial firmware
>> from OTPROM chip. Once this initial firmware is running, the firmware can be
>> further upgraded over HCI interface with .hcd files provided by Broadcom. This
>> is also known as "patch RAM" support. This change implements that.
>>
>> If the .hcd file is not found in /lib/firmware, BCM Bluetooth adapter continues
>> to operate with the initial firmware. Sample kernel log:
>> hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
>> Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-22be.hcd not found
>>
>> If the .hcd file is found, btusb driver pushes it to the BCM Bluetooth adapter and
>> it starts using the new firmware. Sample kernel log:
>> hotplug: sys=firmware act=add fw=brcm/BCM20702A0-0a5c-22be.hcd dev=...
>> Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=1000 lmp_ver=06 lmp_subver=220e
>> Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=1389 lmp_ver=06 lmp_subver=220e
>>
>> Above, we can see that hci_rev goes from 1000 to 1389 as a result of the upgrade.
>
> so I tested this with an off the shelf USB dongle now and a firmware converted with the hex2hcd utility (which we most likely should just include in bluez.git).
>
> [193812.000971] Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=1000 lmp_ver=06 lmp_subver=220e
> [193812.738603] Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=153a lmp_ver=06 lmp_subver=220e
>
> Of course I have no idea what kind of bugs this new firmware now fixes. I am also almost certain that just based on the lmp_subver and hci_rev we could pick a firmware to load. And it would be nice if Broadcom starts putting firmware files in linux-firmware.git like any other company.
>
> Anyhow, one minor thing that bugs me is this:
>
> [193452.790194] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e8.hcd not found
>
> While I want the firmware loading available for all Broadcom controllers, I do think we might have to mark some of them as firmware absolutely required since otherwise they will not work. And in that case we should print the error. Otherwise we might just silently not print anything. Thoughts?
>
I understand. So, we really need two cases,
BTUSB_BCM_PATCHRAM_REQUIRED and BTUSB_BCM_PATCHRAM_OPTIONAL.
For BTUSB_BCM_PATCHRAM_REQUIRED, I would go with:
BT_ERR("%s: BCM: required patch %s not found, adapter setup failed",
hdev->name, fw_name);
return -ENOENT;
For BTUSB_BCM_PATCHRAM_OPTIONAL, I would still display informational message:
BT_INFO("%s: BCM: optional patch %s not found, operating with
default firmware", hdev->name, fw_name);
return 0;
Can we easily access id->driver_info flags in btusb_setup_bcm_patchram()?
Thanks for applying this patch.
-- Petri
>> Signed-off-by: Petri Gynther <pgynther@xxxxxxxxxx>
>> ---
>> drivers/bluetooth/btusb.c | 155 +++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 154 insertions(+), 1 deletion(-)
>
> Patch has been applied to bluetooth-next tree.
>
> Regards
>
> Marcel
>
--
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
