On 2/8/21 8:27 PM, Samuel Holland wrote: > On 2/8/21 5:43 AM, Marek Vasut wrote: >> On 2/8/21 6:57 AM, Samuel Holland wrote: >>> Resetting an XHCI controller inside xhci_register undoes any register >>> setup performed by the platform driver. And at least on the Allwinner >>> H6, resetting the XHCI controller also resets the PHY, which prevents >>> the controller from working. That means the controller must be taken out >>> of reset before initializing the PHY, which must be done before calling >>> xhci_register. >>> >>> The logic in the XHCI core was added to support the Raspberry Pi 4 >>> (although this was not mentioned in the commit log!), which uses the >>> xhci-pci platform driver. Move the reset logic to the platform driver, >>> where it belongs, and where it cannot interfere with other platform >>> drivers. >> >> Are there any other XHCI drivers using the XHCI core code which might >> stop resetting correctly due to this patch ? > > Since commit 0b80371b350e was merged, the only new call to xhci_register > is in USB_MTU3. Neither the binding for "mediatek,mtu3" nor any device > tree node containing that compatible string has a "resets" property. And > there have been no calls to reset_(de)assert since then, either. So I do
...no calls to reset_(de)assert *removed from any driver* since then... > not see any other drivers that would be likely to break. > > Samuel >
