-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
usb: device_next: add BT HCI USB transport layer #53870
usb: device_next: add BT HCI USB transport layer #53870
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good
/* | ||
* Bluetooth subsystem does not support multiple HCI instances, | ||
* but we are almost ready for it. | ||
*/ | ||
BT_HCI_DESCRIPTOR_DEFINE(0) | ||
BT_HCI_CLASS_DATA_DEFINE(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this relates to #51503 too. Along with making the HCI driver DTS-based, it becomes more natural to declare multiple instances. That said, the host stack treats the controller as singleton. There's a single bt_dev
struct that's accessed as a global variable in several places of the host. To make the host truly multi-HCI aware there would need to be this bt_dev
context per controller instance that's then passed around as a parameter in most existing Bluetooth APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhedberg @jfischer-no does anything need to be done here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understood @carlescufi, not in the near future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly code style comments, and some questions
* RAM usage efficient. | ||
*/ | ||
NET_BUF_POOL_FIXED_DEFINE(bt_hci_ep_pool, | ||
3, 512, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why these specific numbers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Three endpoints, maximum three transfers used synchronously, 512 is the maximum packet size of a high speed bulk endpoint. I will add a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If 512 is a maximum defined by the USB specification, then I'd suggest to #define
that value and use that
#define USB_BT_HCI_PROTOCOL 0x01 | ||
|
||
#define BT_HCI_DEFAULT_BULK_EP_MPS 0 /* Get maximum supported */ | ||
#define BT_HCI_DEFAULT_INT_EP_MPS 64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part B page 1667 suggests 16 bytes Max Packet Size as the default.
45b80bc
to
1839950
Compare
} | ||
|
||
bi = udc_get_buf_info(buf); | ||
memset(bi, 0, sizeof(struct udc_buf_info)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the intention is to clear a struct like here, it may be more readable to use the pointer to the struct for the sizeof
memset(bi, 0, sizeof(struct udc_buf_info)); | |
memset(bi, 0, sizeof(*bi)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it is not more readable.
case BT_BUF_ISO_OUT: { | ||
struct bt_hci_iso_hdr *iso_hdr; | ||
|
||
hdr_len = sizeof(*iso_hdr); | ||
iso_hdr = (struct bt_hci_iso_hdr *)data; | ||
len = bt_iso_hdr_len(sys_le16_to_cpu(iso_hdr->len)) + hdr_len; | ||
break; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this driver otherwise doesn't support ISO, should this be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, but then it must later be added for H4 support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems odd to only partially add ISO/H4 support
Zero data payload size for isochronous endpoints is a is a valid setting for default interface. Also do not update MPS of control endpoint since it is set by the driver. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
1839950
to
731bac6
Compare
Cherry-picked first commit from #53998 and added interface descriptor for ISO endpoints (still unused). |
731bac6
to
2bd4e0e
Compare
Add Bluetooth HCI USB transport layer implementation for the new experimental USB device support based on the existing implementation subsys/usb/device/class/bluetooth.c. This implementation, unlike existing one, contains the interface descriptors for isochronous endpoints. Since we do not support voice channels, these are just there to avoid issues with Linux kernel btusb driver when this implementation is part of a composite configuration. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Enable Bluetooth HCI USB tranport layer from new experimental USB device support. Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2bd4e0e
to
cf07ae8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor suggestions left, otherwise LGTM
|
||
static uint8_t bt_hci_get_int_in(struct usbd_class_node *const c_nd) | ||
{ | ||
struct usbd_bt_hci_desc *desc = c_nd->data->desc; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
struct usbd_bt_hci_desc *desc = c_nd->data->desc; | |
const struct usbd_bt_hci_desc *desc = c_nd->data->desc; |
|
||
static uint8_t bt_hci_get_bulk_in(struct usbd_class_node *const c_nd) | ||
{ | ||
struct usbd_bt_hci_desc *desc = c_nd->data->desc; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
struct usbd_bt_hci_desc *desc = c_nd->data->desc; | |
const struct usbd_bt_hci_desc *desc = c_nd->data->desc; |
|
||
static uint8_t bt_hci_get_bulk_out(struct usbd_class_node *const c_nd) | ||
{ | ||
struct usbd_bt_hci_desc *desc = c_nd->data->desc; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
struct usbd_bt_hci_desc *desc = c_nd->data->desc; | |
const struct usbd_bt_hci_desc *desc = c_nd->data->desc; |
/* | ||
* Bluetooth subsystem does not support multiple HCI instances, | ||
* but we are almost ready for it. | ||
*/ | ||
BT_HCI_DESCRIPTOR_DEFINE(0) | ||
BT_HCI_CLASS_DATA_DEFINE(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhedberg @jfischer-no does anything need to be done here?
Add Bluetooth HCI USB transport layer implementation for the new USB device support,
porting of subsys/usb/device/class/bluetooth.c without H4 bloat.