23.12.2014 08:36, Arseny Solokha пишет: >> On Sat, 6 Dec 2014, Arseny Solokha wrote: >> >>> From: Arseny Solokha <asolokha@xxxxxxxxxx> >>> >>> Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)") >>> introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development >>> board. The code path that was previously specific to NVIDIA controllers >>> had then become taken for all chips. >>> >>> However, the M5237 installed on the board wedges solid when accessing >>> its base+OHCI_FMINTERVAL register, making it impossible to boot any >>> kernel newer than 3.1.8 on this particular and apparently other similar >>> machines. >>> >>> Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237. >>> >>> The patch is suitable for the -next tree as well as all maintained >>> kernels up to 3.2 inclusive. >>> >>> Signed-off-by: Arseny Solokha <asolokha@xxxxxxxxxx> >>> --- >>> Changes in v2: >>> - review comments applied >> >> Much better this time. >> >> Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > Meanwhile, I discovered a similar thread where the issue was previously > discussed, and have tried to implement a workaround suggested in [1]. No luck so > far: even if the code manages to check a value returned by > readl(base + OHCI_FMINTERVAL), it then still hangs during device unregistering. > > Of course, unregistering a device instead of just not accessing OHCI_FMINTERVAL > like in my or Nikita's patch is also possible but it requires hardcoding all > flawed device IDs instead of figuring out misbehaving devices at boot time. In my case root cause was elsewhere - USB port that I thought was driven by ULI, actually was not. And ULI's builtin OHCI was not hardware-enabled (but still was available on bus). I workarounded it by masking entire device in platform-specific quirk. Nikita -- 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