| Message ID | 20240221-asahi-keyboards-v1-2-814b2e741790@jannau.net |
|---|---|
| State | Superseded |
| Delegated to: | Marek Vasut |
| Headers | show |
| Series | USB keyboard improvements for asahi / desktop systems | expand |
On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: > From: Janne Grunau <j@jannau.net> > > Apple USB keyboards carry the HID keyboard boot protocol on the second > interface. Using the second interface in the USB keyboard driver does > not work since the xhci has not allocated a transfer ring. So, what does this patch do ? That is not clear from the commit message. btw. missing SoB line.
On Wed, Feb 21, 2024, at 13:39, Marek Vasut wrote: > On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: >> From: Janne Grunau <j@jannau.net> >> >> Apple USB keyboards carry the HID keyboard boot protocol on the second >> interface. Using the second interface in the USB keyboard driver does >> not work since the xhci has not allocated a transfer ring. > > So, what does this patch do ? That is not clear from the commit message. rewritten for v2: | usb: xhci: Set up endpoints for the first 2 interfaces | | The xhci driver currently only does the necessary initialization for | endpoints found in the first interface descriptor. Apple USB keyboards | (released 2021) use the second interface descriptor for the HID keyboard | boot protocol. To allow USB drivers to use endpoints from other | interface descriptors the xhci driver needs to ensure these endpoints | are initialized as well. | Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors | are initialized and useable. Currently defined to 2 as that is enough to | make the Apple keyboard usable. > > btw. missing SoB line. added Thanks Janne
On 2/25/24 4:28 PM, Janne Grunau wrote: > > > On Wed, Feb 21, 2024, at 13:39, Marek Vasut wrote: >> On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: >>> From: Janne Grunau <j@jannau.net> >>> >>> Apple USB keyboards carry the HID keyboard boot protocol on the second >>> interface. Using the second interface in the USB keyboard driver does >>> not work since the xhci has not allocated a transfer ring. >> >> So, what does this patch do ? That is not clear from the commit message. > > rewritten for v2: > | usb: xhci: Set up endpoints for the first 2 interfaces > | > | The xhci driver currently only does the necessary initialization for > | endpoints found in the first interface descriptor. Apple USB keyboards > | (released 2021) use the second interface descriptor for the HID keyboard > | boot protocol. To allow USB drivers to use endpoints from other > | interface descriptors the xhci driver needs to ensure these endpoints > | are initialized as well. > | Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors > | are initialized and useable. Currently defined to 2 as that is enough to > | make the Apple keyboard usable. Would it make sense to make this a tunable Kconfig option ?
> Date: Sun, 25 Feb 2024 22:47:41 +0100 > From: Marek Vasut <marex@denx.de> > > On 2/25/24 4:28 PM, Janne Grunau wrote: > > > > > > On Wed, Feb 21, 2024, at 13:39, Marek Vasut wrote: > >> On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: > >>> From: Janne Grunau <j@jannau.net> > >>> > >>> Apple USB keyboards carry the HID keyboard boot protocol on the second > >>> interface. Using the second interface in the USB keyboard driver does > >>> not work since the xhci has not allocated a transfer ring. > >> > >> So, what does this patch do ? That is not clear from the commit message. > > > > rewritten for v2: > > | usb: xhci: Set up endpoints for the first 2 interfaces > > | > > | The xhci driver currently only does the necessary initialization for > > | endpoints found in the first interface descriptor. Apple USB keyboards > > | (released 2021) use the second interface descriptor for the HID keyboard > > | boot protocol. To allow USB drivers to use endpoints from other > > | interface descriptors the xhci driver needs to ensure these endpoints > > | are initialized as well. > > | Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors > > | are initialized and useable. Currently defined to 2 as that is enough to > > | make the Apple keyboard usable. > > Would it make sense to make this a tunable Kconfig option ? Maybe, but it should probably be enabled everywhere where CONFIG_USB_KEYBOARD as folks will connect their Apple keyboard to non-Apple hardware as well. And I think someone mentioned on the #asahi irc channel that there are othe keyboards that have the boot protocol on the second interface descriptor. Cheers, Mark
Hej, On Sun, Feb 25, 2024, at 22:47, Marek Vasut wrote: > On 2/25/24 4:28 PM, Janne Grunau wrote: >> >> >> On Wed, Feb 21, 2024, at 13:39, Marek Vasut wrote: >>> On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: >>>> From: Janne Grunau <j@jannau.net> >>>> >>>> Apple USB keyboards carry the HID keyboard boot protocol on the second >>>> interface. Using the second interface in the USB keyboard driver does >>>> not work since the xhci has not allocated a transfer ring. >>> >>> So, what does this patch do ? That is not clear from the commit message. >> >> rewritten for v2: >> | usb: xhci: Set up endpoints for the first 2 interfaces >> | >> | The xhci driver currently only does the necessary initialization for >> | endpoints found in the first interface descriptor. Apple USB keyboards >> | (released 2021) use the second interface descriptor for the HID keyboard >> | boot protocol. To allow USB drivers to use endpoints from other >> | interface descriptors the xhci driver needs to ensure these endpoints >> | are initialized as well. >> | Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors >> | are initialized and useable. Currently defined to 2 as that is enough to >> | make the Apple keyboard usable. > > Would it make sense to make this a tunable Kconfig option ? I thought about that but I don't think it's worth it. We would have to default it to 2 (at least when the USB keyboard driver is enabled) since we can't predict which devices will be connected. Why would anyone chose a different value than the fixed value? I can't think of convincing reasons. Janne
On 2/27/24 8:38 AM, Janne Grunau wrote: > Hej, > > On Sun, Feb 25, 2024, at 22:47, Marek Vasut wrote: >> On 2/25/24 4:28 PM, Janne Grunau wrote: >>> >>> >>> On Wed, Feb 21, 2024, at 13:39, Marek Vasut wrote: >>>> On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: >>>>> From: Janne Grunau <j@jannau.net> >>>>> >>>>> Apple USB keyboards carry the HID keyboard boot protocol on the second >>>>> interface. Using the second interface in the USB keyboard driver does >>>>> not work since the xhci has not allocated a transfer ring. >>>> >>>> So, what does this patch do ? That is not clear from the commit message. >>> >>> rewritten for v2: >>> | usb: xhci: Set up endpoints for the first 2 interfaces >>> | >>> | The xhci driver currently only does the necessary initialization for >>> | endpoints found in the first interface descriptor. Apple USB keyboards >>> | (released 2021) use the second interface descriptor for the HID keyboard >>> | boot protocol. To allow USB drivers to use endpoints from other >>> | interface descriptors the xhci driver needs to ensure these endpoints >>> | are initialized as well. >>> | Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors >>> | are initialized and useable. Currently defined to 2 as that is enough to >>> | make the Apple keyboard usable. >> >> Would it make sense to make this a tunable Kconfig option ? > > I thought about that but I don't think it's worth it. We would have to default it to 2 (at least when the USB keyboard driver is enabled) since we can't predict which devices will be connected. > Why would anyone chose a different value than the fixed value? I can't think of convincing reasons. All right Reviewed-by: Marek Vasut <marex@denx.de>
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 534c4b973f..741e186ee0 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -606,24 +606,28 @@ static int xhci_set_configuration(struct usb_device *udev) int slot_id = udev->slot_id; struct xhci_virt_device *virt_dev = ctrl->devs[slot_id]; struct usb_interface *ifdesc; + unsigned int ifnum; + unsigned int max_ifnum = min((unsigned int)USB_MAX_ACTIVE_INTERFACES, + (unsigned int)udev->config.no_of_if); out_ctx = virt_dev->out_ctx; in_ctx = virt_dev->in_ctx; - num_of_ep = udev->config.if_desc[0].no_of_ep; - ifdesc = &udev->config.if_desc[0]; - ctrl_ctx = xhci_get_input_control_ctx(in_ctx); /* Initialize the input context control */ ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG); ctrl_ctx->drop_flags = 0; - /* EP_FLAG gives values 1 & 4 for EP1OUT and EP2IN */ - for (cur_ep = 0; cur_ep < num_of_ep; cur_ep++) { - ep_flag = xhci_get_ep_index(&ifdesc->ep_desc[cur_ep]); - ctrl_ctx->add_flags |= cpu_to_le32(1 << (ep_flag + 1)); - if (max_ep_flag < ep_flag) - max_ep_flag = ep_flag; + for (ifnum = 0; ifnum < max_ifnum; ifnum++) { + ifdesc = &udev->config.if_desc[ifnum]; + num_of_ep = ifdesc->no_of_ep; + /* EP_FLAG gives values 1 & 4 for EP1OUT and EP2IN */ + for (cur_ep = 0; cur_ep < num_of_ep; cur_ep++) { + ep_flag = xhci_get_ep_index(&ifdesc->ep_desc[cur_ep]); + ctrl_ctx->add_flags |= cpu_to_le32(1 << (ep_flag + 1)); + if (max_ep_flag < ep_flag) + max_ep_flag = ep_flag; + } } xhci_inval_cache((uintptr_t)out_ctx->bytes, out_ctx->size); @@ -637,9 +641,12 @@ static int xhci_set_configuration(struct usb_device *udev) xhci_endpoint_copy(ctrl, in_ctx, out_ctx, 0); /* filling up ep contexts */ - err = xhci_init_ep_contexts_if(udev, ctrl, virt_dev, ifdesc); - if (err < 0) - return err; + for (ifnum = 0; ifnum < max_ifnum; ifnum++) { + ifdesc = &udev->config.if_desc[ifnum]; + err = xhci_init_ep_contexts_if(udev, ctrl, virt_dev, ifdesc); + if (err < 0) + return err; + } return xhci_configure_endpoints(udev, false); } diff --git a/include/usb.h b/include/usb.h index 09e3f0cb30..3aafdc8bfd 100644 --- a/include/usb.h +++ b/include/usb.h @@ -49,6 +49,12 @@ extern bool usb_started; /* flag for the started/stopped USB status */ */ #define USB_TIMEOUT_MS(pipe) (usb_pipebulk(pipe) ? 5000 : 1000) +/* + * The xhcd hcd driver prepares only a limited number interfaces / endpoints. + * Define this limit so that drivers do not exceed it. + */ +#define USB_MAX_ACTIVE_INTERFACES 2 + /* device request (setup) */ struct devrequest { __u8 requesttype;
From: Janne Grunau <j@jannau.net> Apple USB keyboards carry the HID keyboard boot protocol on the second interface. Using the second interface in the USB keyboard driver does not work since the xhci has not allocated a transfer ring. --- drivers/usb/host/xhci.c | 31 +++++++++++++++++++------------ include/usb.h | 6 ++++++ 2 files changed, 25 insertions(+), 12 deletions(-)