Hi Bing,
>>> +static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
>>> + const bdaddr_t *bdaddr)
>>> +{
>>> + struct sk_buff *skb;
>>> + u8 buf[8];
>>> + long ret;
>>> +
>>> + buf[0] = 0xfe;
>>> + buf[1] = sizeof(bdaddr_t);
>>> + bacpy((bdaddr_t *)&buf[2], bdaddr);
>>
>> you could define a packed struct for this or just use memcpy here instead.
>
> In Amitkumar's original patch, it was like this:
>
> + memcpy((u8 *)buf + 2, bdaddr, sizeof(bdaddr_t));
you do not need the cast:
memcpy(buf + 2, bdaddr, sizeof(bdaddr_t));
>
> I felt that it'd be better to use bacpy so I changed memcpy to bacpy while applying the patch.
> I can change it back to memcpy if it looks ok to you. Otherwise I can define a packed struct.
I am fine with the memcpy actually.
>>> +
>>> + skb = __hci_cmd_sync(hdev, 0xfc22, sizeof(buf), buf, HCI_INIT_TIMEOUT);
>>
>> Is this opcode writing the address into flash and making it permanent or will a reboot restore it to
>> its original address?
>
> A reboot restores it to its original address. I will add this information in v2.
>
>>
>> I am asking because for Ericsson chips this exact command with user_id 0xfe was actually making a
>> permanent change of the BD_ADDR. What we want here is a volatile change of the address.
>
> For Marvell devices it makes a temporary bdaddr change.
Good.
I just know way too much details of all these vendor specific details of the original Bluetooth chips ;)
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
