diff mbox series

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

Message ID 1504699898-28011-1-git-send-email-loic.poulain@linaro.org
State Accepted
Commit 28517c02e1dd8fef7a0eab5e9f18013a0e297aba
Headers show
Series [v6,1/3] dt-bindings: net: document Bluetooth bindings in one place | expand

Commit Message

Loic Poulain Sept. 6, 2017, 12:11 p.m. UTC 
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

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Marcel Holtmann Sept. 6, 2017, 5:24 p.m. UTC | #1 
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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Andersson Sept. 6, 2017, 11:26 p.m. UTC | #2 
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@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).


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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marcel Holtmann Sept. 7, 2017, 6:14 a.m. UTC | #3 
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@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).

> 

> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox series

Patch

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).