On Mon, 2 Jul 2018, Paul Menzel wrote: > Dear Alan, > > > Am 02.07.2018 um 18:03 schrieb Alan Stern: > > On Mon, 2 Jul 2018, Paul Menzel wrote: > > >> Am 02.07.2018 um 17:45 schrieb Alan Stern: > >>> On Sun, 1 Jul 2018, Paul Menzel wrote: > >>> > >>>> Currently, on the AMD board Asus F2A85-M Pro there is a 100 ms delay as > >>>> the USB bus of each of the two OHCI PCI devices is reset. As a 50 ms > >>>> delay is done per the USB specification. > >>>> > >>>> Commit c6187597 (OHCI: final fix for NVIDIA problems (I hope)) > >>>> unconditionally does the bus reset for > >>>> all chipsets, while it was only doen for NVIDIA chipsets before. > >>> > >>> I don't follow this at all. Prior to that commit, the bus reset (i.e., > >>> > >>> writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL); > >>> > >>> ) was performed unconditionally for _all_ controllers. (However, the > >>> 50-ms delay was used only for NVIDIA hardware.) Following that commit, > >>> the reset is performed for all controllers, but only if the HCFS > >>> bitfield is nonzero. > >>> > >>>> As it should not be needed for non-NVIDIA chipsets, only do the reset > >>>> for Nvidia devices. > >>> > >>> Therefore this reasoning is wrong. > >> > >> True. Thank you for checking that. > >> > >>>> Tested on Asus F2A85-M PRO and ASRock E350M1. The USB keyboard works and > >>>> the LUKS passphrase can be entered. > >>> > >>> Unfortunately, there is a wide variety of OHCI controller hardware > >>> available. Something that works on one or two controllers might not > >>> work on another. > >> > >> The problem is, that currently 100 ms sleep is over 10 % of the overall > >> execution time of the Linux kernel here. So I really like to not sleep > >> if it’s not needed. > > > > It would be nice to execute the probes in parallel; that would reduce > > the total delay to 50 ms. However, that is the subject of a separate > > discussion. > > > >>> Besides, doesn't it seem like a bad idea to reset the controller while > >>> leaving devices on the USB bus in whatever state they happened to be? > >> > >> Yes, it’s probably not optimal. > >> > >> I wonder if the reset is needed, if the firmware has already initialized > >> the device. > > > > The devices on the bus need to be reset, because the OS has no idea of > > what they are and what the firmware has them doing. > > > > For example, the firmware may have assigned bus address 2 to a > > keyboard. But the OS can initialize the devices in a different order, > > and it might want to assign bus address 2 to a USB drive. Then you'd > > have two devices trying to use the same address at the same time, which > > would not be a good thing. > > Understood. > > So, what would be a way forward? Add a whitelist for boards or chipsets > not needing the 50 ms delay? The 50-ms delay isn't for the board or the chipset; it is for the USB devices that are plugged into the controller. It is required by the USB spec, so we can't get rid of it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
