On Fri, Nov 24, 2023 at 03:50:05PM +0100, Hardik Gajjar wrote: > On Thu, Nov 23, 2023 at 01:17:03PM -0500, Alan Stern wrote: > > On Thu, Nov 23, 2023 at 09:19:48AM +0100, Hardik Gajjar wrote: > > > There is a potential delay in announcing downstream USB bus activity to > > > Linux USB drivers due to the default interrupt endpoint having a poll > > > interval of 256ms. > > > > > > Microchip has recommended ignoring the device descriptor and reducing > > > that value to 32ms, as it was too late to modify it in silicon. > > > > > > This patch aims to speed up the USB enumeration process, facilitating > > > the successful completion of Apple CarPlay certifications and enhancing > > > user experience when utilizing USB devices through the Microchip Multihost > > > Hub. > > > > > > A new quirk, USB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL, accelerates the > > > notification process by changing the Endpoint interrupt poll interval > > > from 256ms to 32ms. > > > > But this is meant to apply only to hubs, right? So shouldn't it be a > > HUB_QUIRK_32_MS_INTR_INTERVAL macro, used in hub.c's hub_id_table, > > rather than a general USB quirk? > > Thank you, Alan, for the feedback. To confirm my understanding, are you suggesting > moving all implementations to hub.c, adding the hub-specific quirk, and using the > same quirk to update the bInterval value parsed by usb_get_configuration() in > usb_enumerate_device()?" Basically, yes. The update should be performed in the hub_probe() routine if the quirk flag is set, before hub_configure() is called. It might be necessary to add a usb_set_interface() call as well, in case the old bInterval value has already been cached by the host controller driver. Alan Stern
