"local-[bd|mac]-address" inconsistency?

"local-[bd|mac]-address" inconsistency?

[Andre Heider]

Hi,

when passing both addresses through device-tree in the same way:
$ hexdump /proc/device-tree/soc/ethernet@5020000/local-mac-address
0000000 0702 3d96 53d4

$ hexdump /proc/device-tree/soc/serial@5000400/bluetooth/local-bd-address
0000000 0703 3d96 53d4

I get this for eth (which is consistent with u-boot):
link/ether 02:07:96:3d:d4:53

But for bt it's in reverse order:
Controller 53:D4:3D:96:07:03

Is this intended? Do I really have to pass the bdaddr from u-boot in 
another way?

Regards,
Andre

Re: "local-[bd|mac]-address" inconsistency?

[Matthias Kaehlcke]

Hi Andre,

On Mon, Nov 18, 2019 at 09:20:35AM +0100, Andre Heider wrote:
> Hi,
> 
> when passing both addresses through device-tree in the same way:
> $ hexdump /proc/device-tree/soc/ethernet@5020000/local-mac-address
> 0000000 0702 3d96 53d4
> 
> $ hexdump /proc/device-tree/soc/serial@5000400/bluetooth/local-bd-address
> 0000000 0703 3d96 53d4
>
> I get this for eth (which is consistent with u-boot):
> link/ether 02:07:96:3d:d4:53
> 
> But for bt it's in reverse order:
> Controller 53:D4:3D:96:07:03
> 
> Is this intended?

Kind of.

In both cases the address is specified in the binary format used by BT/NW
stack.

When BT addresses are printed they are converted from LSB to MSB.

> Do I really have to pass the bdaddr from u-boot in another way?

One could make a case that we don't care what the 'internal' format is and
that the BD_ADDR should be specified in MSB format in the DT, and the kernel
would be in charge of converting it to LSB. However I fear it is too late to
consider a change at this point, since the binding has been in the kernel for
6 months with the current format and existing devices may rely on it.

Re: "local-[bd|mac]-address" inconsistency?

[Andre Heider]

On 18/11/2019 21:15, Matthias Kaehlcke wrote:
> Hi Andre,
> 
> On Mon, Nov 18, 2019 at 09:20:35AM +0100, Andre Heider wrote:
>> Hi,
>>
>> when passing both addresses through device-tree in the same way:
>> $ hexdump /proc/device-tree/soc/ethernet@5020000/local-mac-address
>> 0000000 0702 3d96 53d4
>>
>> $ hexdump /proc/device-tree/soc/serial@5000400/bluetooth/local-bd-address
>> 0000000 0703 3d96 53d4
>>
>> I get this for eth (which is consistent with u-boot):
>> link/ether 02:07:96:3d:d4:53
>>
>> But for bt it's in reverse order:
>> Controller 53:D4:3D:96:07:03
>>
>> Is this intended?
> 
> Kind of.
> 
> In both cases the address is specified in the binary format used by BT/NW
> stack.
> 
> When BT addresses are printed they are converted from LSB to MSB.
> 
>> Do I really have to pass the bdaddr from u-boot in another way?
> 
> One could make a case that we don't care what the 'internal' format is and
> that the BD_ADDR should be specified in MSB format in the DT, and the kernel
> would be in charge of converting it to LSB. However I fear it is too late to
> consider a change at this point, since the binding has been in the kernel for
> 6 months with the current format and existing devices may rely on it.
> 

Feared as much...

Thanks for your time,
Andre

Re: "local-[bd|mac]-address" inconsistency?

[Marcel Holtmann]

Hi Matthias,

>> when passing both addresses through device-tree in the same way:
>> $ hexdump /proc/device-tree/soc/ethernet@5020000/local-mac-address
>> 0000000 0702 3d96 53d4
>> 
>> $ hexdump /proc/device-tree/soc/serial@5000400/bluetooth/local-bd-address
>> 0000000 0703 3d96 53d4
>> 
>> I get this for eth (which is consistent with u-boot):
>> link/ether 02:07:96:3d:d4:53
>> 
>> But for bt it's in reverse order:
>> Controller 53:D4:3D:96:07:03
>> 
>> Is this intended?
> 
> Kind of.
> 
> In both cases the address is specified in the binary format used by BT/NW
> stack.
> 
> When BT addresses are printed they are converted from LSB to MSB.
> 
>> Do I really have to pass the bdaddr from u-boot in another way?
> 
> One could make a case that we don't care what the 'internal' format is and
> that the BD_ADDR should be specified in MSB format in the DT, and the kernel
> would be in charge of converting it to LSB. However I fear it is too late to
> consider a change at this point, since the binding has been in the kernel for
> 6 months with the current format and existing devices may rely on it.

we used a different property name for reason. Even while BD_ADDR is allocated from an OUI space, it has nothing in common with a MAC address.

Regards

Marcel