[PATCH v6 1/3] dt-bindings: net: document Bluetooth bindings in one place

[PATCH v6 1/3] dt-bindings: net: document Bluetooth bindings in one place

[Loic Poulain]

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@linaro.org>
---
 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).
-- 
1.9.1

[PATCH v6 2/3] dt-bindings: soc: qcom: Add local-bd-address property to WCNSS-BT

[Loic Poulain]

Add optional local-bd-address property which is a 6-byte array
storing the assigned BD address. Since having a unique BD address
is critical, a per-device property value should be allocated.
This property is usually added by the boot loader which has access
to the provisioned data.

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
---
 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/soc/qcom/qcom,wcnss.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
index 4ea39e9..042a2e4 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt
@@ -37,6 +37,11 @@ The following properties are defined to the bluetooth node:
 	Definition: must be:
 		    "qcom,wcnss-bt"
 
+- local-bd-address:
+	Usage: optional
+	Value type: <u8 array>
+	Definition: see Documentation/devicetree/bindings/net/bluetooth.txt
+
 == WiFi
 The following properties are defined to the WiFi node:
 
@@ -91,6 +96,9 @@ smd {
 
 			bt {
 				compatible = "qcom,wcnss-bt";
+
+				/* BD address 00:11:22:33:44:55 */
+				local-bd-address = [ 55 44 33 22 11 00 ];
 			};
 
 			wlan {
-- 
1.9.1

[PATCH v6 3/3] Bluetooth: btqcomsmd: retrieve BD address from DT property

[Loic Poulain]

Retrieve BD address from the local-bd-address property.
This address must be unique and is usually added in the DT
by the bootloader which has access to the provisioned data.

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
---
 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

 drivers/bluetooth/btqcomsmd.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index bd810d0..b5716f0 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -15,6 +15,8 @@
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/rpmsg.h>
+#include <linux/of.h>
+
 #include <linux/soc/qcom/wcnss_ctrl.h>
 #include <linux/platform_device.h>
 
@@ -156,6 +158,15 @@ static int btqcomsmd_probe(struct platform_device *pdev)
 	if (IS_ERR(btq->cmd_channel))
 		return PTR_ERR(btq->cmd_channel);
 
+	/* The local-bd-address property is usually injected by the
+	 * bootloader which has access to the allocated BD address.
+	 */
+	if (!of_property_read_u8_array(pdev->dev.of_node, "local-bd-address",
+				       (u8 *)&btq->bdaddr, sizeof(bdaddr_t))) {
+		BT_INFO("BD address %pMR retrieved from device-tree",
+			&btq->bdaddr);
+	}
+
 	hdev = hci_alloc_dev();
 	if (!hdev)
 		return -ENOMEM;
-- 
1.9.1

Re: [PATCH v6 3/3] Bluetooth: btqcomsmd: retrieve BD address from DT property

[Marcel Holtmann]

Hi Loic,

> Retrieve BD address from the local-bd-address property.
> This address must be unique and is usually added in the DT
> by the bootloader which has access to the provisioned data.
> 
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> ---
> 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
> 
> drivers/bluetooth/btqcomsmd.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
> index bd810d0..b5716f0 100644
> --- a/drivers/bluetooth/btqcomsmd.c
> +++ b/drivers/bluetooth/btqcomsmd.c
> @@ -15,6 +15,8 @@
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/rpmsg.h>
> +#include <linux/of.h>
> +
> #include <linux/soc/qcom/wcnss_ctrl.h>
> #include <linux/platform_device.h>
> 
> @@ -156,6 +158,15 @@ static int btqcomsmd_probe(struct platform_device *pdev)
> 	if (IS_ERR(btq->cmd_channel))
> 		return PTR_ERR(btq->cmd_channel);
> 
> +	/* The local-bd-address property is usually injected by the
> +	 * bootloader which has access to the allocated BD address.
> +	 */
> +	if (!of_property_read_u8_array(pdev->dev.of_node, "local-bd-address",
> +				       (u8 *)&btq->bdaddr, sizeof(bdaddr_t))) {
> +		BT_INFO("BD address %pMR retrieved from device-tree",
> +			&btq->bdaddr);
> +	}

any reason you are not using bt_dev_info here? I think it would be important to print the device information prefix.

Otherwise the patch set looks good to me. However I would prefer if we get an ack from Rob.

Regards

Marcel

Re: [PATCH v6 3/3] Bluetooth: btqcomsmd: retrieve BD address from DT property

[Loic Poulain]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Hi Marcel,

>
> > +     /* The local-bd-address property is usually injected by the
> > +      * bootloader which has access to the allocated BD address.
> > +      */
> > +     if (!of_property_read_u8_array(pdev->dev.of_node,
> "local-bd-address",
> > +                                    (u8 *)&btq->bdaddr,
> sizeof(bdaddr_t))) {
> > +             BT_INFO("BD address %pMR retrieved from device-tree",
> > +                     &btq->bdaddr);
> > +     }
>
> any reason you are not using bt_dev_info here? I think it would be
> important to print the device information prefix.
>

Yes, hdev does not have any allocated name/number before being registered.
I can move this after hci_register_dev if you prefer.

Regards,
Loic

[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

Re: [PATCH v6 3/3] Bluetooth: btqcomsmd: retrieve BD address from DT property

[Marcel Holtmann]

Hi Loic,

> > +     /* The local-bd-address property is usually injected by the
> > +      * bootloader which has access to the allocated BD address.
> > +      */
> > +     if (!of_property_read_u8_array(pdev->dev.of_node, "local-bd-address",
> > +                                    (u8 *)&btq->bdaddr, sizeof(bdaddr_t))) {
> > +             BT_INFO("BD address %pMR retrieved from device-tree",
> > +                     &btq->bdaddr);
> > +     }
> 
> any reason you are not using bt_dev_info here? I think it would be important to print the device information prefix.
> 
> Yes, hdev does not have any allocated name/number before being registered.
> I can move this after hci_register_dev if you prefer.

if that is possible, then that would be good.

Regards

Marcel

Re: [PATCH v6 1/3] dt-bindings: net: document Bluetooth bindings in one place

[Bjorn Andersson]

On Wed 06 Sep 05:11 PDT 2017, Loic Poulain wrote:

> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  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.

Regards,
Bjorn

Re: [PATCH v6 1/3] dt-bindings: net: document Bluetooth bindings in one place

[Marcel Holtmann]

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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html