On Thu, 26 Apr 2012, Greg KH wrote: > On Thu, Apr 26, 2012 at 02:28:59PM -0400, Alan Stern wrote: > > This patch (as1549) fixes a rare problem affecting at least one OHCI > > controller: The controller requires a delay of at least 1 microsecond > > following a reset, even though it says that it is ready immediately. > > > > The fix is to do the delay first, before checking whether the reset is > > complete in the retry loop. > So we just slowed down the init sequence here by 1us for all systems due > to one specific broken machine? All systems with PCI-based OHCI controllers -- but Calin isn't certain there's only one machine with this hardware bug. Furthermore, it's not clear whether things will slow down at all. If the controller takes more than 1 us to reset anyway, this change won't make any difference. I haven't tested to see how many iterations the loop takes on my machine. > When we have systems that are working really hard to tweak out the > fastest boot speed possible, is this really advisable? I don't know how hard those systems are working to improve boot speed. If they have reached the point where a couple of microseconds makes a noticeable difference then they have gotten a lot farther than I ever thought they could. Other changes could have a bigger impact on boot speed. For example, the ehci_bios_handoff() routine has a loop that waits for 10 ms on each iteration. If that delay were reduced to 5 ms, we could expect to save a couple of milliseconds on average. That's a factor of 2000 more than the OHCI change under discussion. > How about a hardware-specific quirk here for such broken hardware > instead? If you and Calin think it's really necessary. On the other hand, if you prefer to reject this patch on the basis that it helps only one machine, I don't mind. 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
