Hi Bjorn,
>> In the same way as Ethernet, gather the Bluetooth related bindings in
>> one file. Introduce the bluetooth-bd-address property which can be used
>> to store the assigned BD address.
>>
>> Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxxx>
>> ---
>> v2: Set device as unconfigured if default address detected
>> Add warning if BD addr retrieved from DT
>> v3: if no addr retrieved from DT, unconditionally set
>> the invalid BD addr flag.
>> swap and set bdaddr in the platform probe
>> v4: Add dt-bindings documentation
>> split patch in two parts (setup, dt prop)
>> use local-bd-address name instead of local-mac-address
>> v5: remove 2/3 merged in bluetooth-next tree
>> Add bluetooth.txt for common BT bindings
>> expect local-bd-address in little-endian format
>> v6: use of_property_read_u8_array instead of of_get_property
>>
>> Documentation/devicetree/bindings/net/bluetooth.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/bluetooth.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/bluetooth.txt b/Documentation/devicetree/bindings/net/bluetooth.txt
>> new file mode 100644
>> index 0000000..94797df
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/bluetooth.txt
>> @@ -0,0 +1,5 @@
>> +The following properties are common to the Bluetooth controllers:
>> +
>> +- local-bd-address: array of 6 bytes, specifies the BD address that was
>> + uniquely assigned to the Bluetooth device, formatted with least significant
>> + byte first (little-endian).
>
> Is there a good reason for making this little endian?
>
> Sure it's only going to be read and written by computers, but for anyone
> reading the generated DT it sure looks like the values are reversed.
the Bluetooth spec has a string notation and defines how it is packed as 6 octet binary.
"On the baseband level the BD_ADDR is represented as 48 bits. On the Link Layer the public and random device address are represented as 48-bit addresses."
"On the UI level the Bluetooth address shall be represented as 12 hexadecimal characters, possibly divided into sub-parts separated by ‘:’ (e.g., ‘000C3E3A4B69’ or ‘00:0C:3E:3A:4B:69’). On the UI level any number shall have the MSB -> LSB (from left to right) ‘natural’ ordering.”
However on the wire level it is LSB -> MSB. See our ba2str function.
int str2ba(const char *str, bdaddr_t *ba)
{
int i;
for (i = 5; i >= 0; i--, str += 3)
ba->b[i] = strtol(str, NULL, 16);
return 0;
}
I would prefer the boot loader actually providing the BD Address in the correct byte order as the protocol expects and not yet another form. The string representation is just for reference since that is what most people have seen so far.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
