Re: [PATCH] usb/host/pci-quirks: Only reset USB bus on NVIDIA devices

From: Paul Menzel
Date: Mon Jul 02 2018 - 11:52:51 EST

[Taking stable@ out of CC. I just started to use `git send-email`.]

Dear Alan,

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.

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.

Kind regards,