From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753269AbdLDGsh convert rfc822-to-8bit (ORCPT ); Mon, 4 Dec 2017 01:48:37 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:44361 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753091AbdLDGse (ORCPT ); Mon, 4 Dec 2017 01:48:34 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: [PATCH 3/3] bluetooth: hci_ll: Add optional nvmem MAC address source From: Marcel Holtmann In-Reply-To: <1512357682-8911-4-git-send-email-david@lechnology.com> Date: Mon, 4 Dec 2017 07:48:31 +0100 Cc: devicetree@vger.kernel.org, linux-bluetooth@vger.kernel.org, Rob Herring , Mark Rutland , "Gustavo F. Padovan" , Johan Hedberg , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: References: <1512357682-8911-1-git-send-email-david@lechnology.com> <1512357682-8911-4-git-send-email-david@lechnology.com> To: David Lechner X-Mailer: Apple Mail (2.3445.4.7) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, > This adds an optional nvmem consumer to get a MAC address from an external > source. The MAC address is then set in the Bluetooth chip after the > firmware has been loaded. > > This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS > EV3). > > Signed-off-by: David Lechner > --- > drivers/bluetooth/hci_ll.c | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c > index 974a788..dd3b5c2 100644 > --- a/drivers/bluetooth/hci_ll.c > +++ b/drivers/bluetooth/hci_ll.c > @@ -53,10 +53,12 @@ > #include > #include > #include > +#include > > #include "hci_uart.h" > > /* Vendor-specific HCI commands */ > +#define HCI_VS_WRITE_BD_ADDR 0xfc06 > #define HCI_VS_UPDATE_UART_HCI_BAUDRATE 0xff36 the first patch should to add support for hdev->set_bdaddr. If the hardware supports changing the BD_ADDR, then it should also be exposed via Set Public Address mgmt command. For this it is required that the writing of the BD_ADDR is non-persistent over power cycles. > > /* HCILL commands */ > @@ -89,6 +91,7 @@ struct ll_device { > struct serdev_device *serdev; > struct gpio_desc *enable_gpio; > struct clk *ext_clk; > + u8 *bdaddr; I would prefer if we just store it as bdaddr_t. That will work just fine when you created the set_bdaddr helper function that you need for hdev->set_bdaddr anyway. > }; > > struct ll_struct { > @@ -698,6 +701,19 @@ static int ll_setup(struct hci_uart *hu) > if (err) > return err; > > + /* Set MAC address, if any */ > + if (lldev->bdaddr) { And here I would really prefer to use bacmp. And example here would be btqcomsmd.c on how it is done. > + struct sk_buff *skb; > + > + skb = __hci_cmd_sync(hu->hdev, HCI_VS_WRITE_BD_ADDR, 6, > + lldev->bdaddr, HCI_INIT_TIMEOUT); > + if (IS_ERR(skb)) > + bt_dev_err(hu->hdev, "Failed to set MAC address (%ld)", > + PTR_ERR(skb)); > + else > + kfree_skb(skb); > + } > + > /* Operational speed if any */ > if (hu->oper_speed) > speed = hu->oper_speed; > @@ -726,6 +742,7 @@ static int hci_ti_probe(struct serdev_device *serdev) > { > struct hci_uart *hu; > struct ll_device *lldev; > + struct nvmem_cell *bdaddr_cell; > u32 max_speed = 3000000; While this is unrelated to this patch, when I seed the u32 speed and the direct use of it in a __hci_cmd_sync, then that is pretty obviously not endian safe. You might really want to fix that as well. > lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL); > @@ -747,6 +764,22 @@ static int hci_ti_probe(struct serdev_device *serdev) > of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed); > hci_uart_set_speeds(hu, 115200, max_speed); > > + /* optional MAC address from nvram */ > + bdaddr_cell = nvmem_cell_get(&serdev->dev, "mac-address”); I prefer really to use the term “bd-address” like we discussed for the btqcomsmd.c driver as well. > + if (IS_ERR(bdaddr_cell)) { > + int err = PTR_ERR(bdaddr_cell); > + > + if (err != -ENOENT) { > + if (err != -EPROBE_DEFER) err != -ENOENT && err != -EPROBE_DEFER > + dev_err(&serdev->dev, > + "Failed to get \"mac-address\" nvmem cell\n”); Also this is at most a warning. And more important, I would actually set the quirk BDADDR_INVALID here so that the device gets flagged as not having a valid address. The Set Public Address mgmt command can then be used from userspace to handle that situation. > + return err; > + } > + } else { > + lldev->bdaddr = nvmem_cell_read(bdaddr_cell, NULL); > + nvmem_cell_put(bdaddr_cell); > + } > + > return hci_uart_register_device(hu, &llp); > } Regards Marcel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcel Holtmann Subject: Re: [PATCH 3/3] bluetooth: hci_ll: Add optional nvmem MAC address source Date: Mon, 4 Dec 2017 07:48:31 +0100 Message-ID: References: <1512357682-8911-1-git-send-email-david@lechnology.com> <1512357682-8911-4-git-send-email-david@lechnology.com> Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Mark Rutland , "Gustavo F. Padovan" , Johan Hedberg , netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Lechner Return-path: In-Reply-To: <1512357682-8911-4-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org> Sender: linux-bluetooth-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org Hi David, > This adds an optional nvmem consumer to get a MAC address from an external > source. The MAC address is then set in the Bluetooth chip after the > firmware has been loaded. > > This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS > EV3). > > Signed-off-by: David Lechner > --- > drivers/bluetooth/hci_ll.c | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c > index 974a788..dd3b5c2 100644 > --- a/drivers/bluetooth/hci_ll.c > +++ b/drivers/bluetooth/hci_ll.c > @@ -53,10 +53,12 @@ > #include > #include > #include > +#include > > #include "hci_uart.h" > > /* Vendor-specific HCI commands */ > +#define HCI_VS_WRITE_BD_ADDR 0xfc06 > #define HCI_VS_UPDATE_UART_HCI_BAUDRATE 0xff36 the first patch should to add support for hdev->set_bdaddr. If the hardware supports changing the BD_ADDR, then it should also be exposed via Set Public Address mgmt command. For this it is required that the writing of the BD_ADDR is non-persistent over power cycles. > > /* HCILL commands */ > @@ -89,6 +91,7 @@ struct ll_device { > struct serdev_device *serdev; > struct gpio_desc *enable_gpio; > struct clk *ext_clk; > + u8 *bdaddr; I would prefer if we just store it as bdaddr_t. That will work just fine when you created the set_bdaddr helper function that you need for hdev->set_bdaddr anyway. > }; > > struct ll_struct { > @@ -698,6 +701,19 @@ static int ll_setup(struct hci_uart *hu) > if (err) > return err; > > + /* Set MAC address, if any */ > + if (lldev->bdaddr) { And here I would really prefer to use bacmp. And example here would be btqcomsmd.c on how it is done. > + struct sk_buff *skb; > + > + skb = __hci_cmd_sync(hu->hdev, HCI_VS_WRITE_BD_ADDR, 6, > + lldev->bdaddr, HCI_INIT_TIMEOUT); > + if (IS_ERR(skb)) > + bt_dev_err(hu->hdev, "Failed to set MAC address (%ld)", > + PTR_ERR(skb)); > + else > + kfree_skb(skb); > + } > + > /* Operational speed if any */ > if (hu->oper_speed) > speed = hu->oper_speed; > @@ -726,6 +742,7 @@ static int hci_ti_probe(struct serdev_device *serdev) > { > struct hci_uart *hu; > struct ll_device *lldev; > + struct nvmem_cell *bdaddr_cell; > u32 max_speed = 3000000; While this is unrelated to this patch, when I seed the u32 speed and the direct use of it in a __hci_cmd_sync, then that is pretty obviously not endian safe. You might really want to fix that as well. > lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL); > @@ -747,6 +764,22 @@ static int hci_ti_probe(struct serdev_device *serdev) > of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed); > hci_uart_set_speeds(hu, 115200, max_speed); > > + /* optional MAC address from nvram */ > + bdaddr_cell = nvmem_cell_get(&serdev->dev, "mac-address”); I prefer really to use the term “bd-address” like we discussed for the btqcomsmd.c driver as well. > + if (IS_ERR(bdaddr_cell)) { > + int err = PTR_ERR(bdaddr_cell); > + > + if (err != -ENOENT) { > + if (err != -EPROBE_DEFER) err != -ENOENT && err != -EPROBE_DEFER > + dev_err(&serdev->dev, > + "Failed to get \"mac-address\" nvmem cell\n”); Also this is at most a warning. And more important, I would actually set the quirk BDADDR_INVALID here so that the device gets flagged as not having a valid address. The Set Public Address mgmt command can then be used from userspace to handle that situation. > + return err; > + } > + } else { > + lldev->bdaddr = nvmem_cell_read(bdaddr_cell, NULL); > + nvmem_cell_put(bdaddr_cell); > + } > + > return hci_uart_register_device(hu, &llp); > } Regards Marcel