[PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core

Marek Vasut marex at denx.de
Tue Feb 9 10:45:25 CET 2021


On 2/9/21 3:28 AM, Samuel Holland wrote:
> 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.

All right, thanks for checking.

I would still prefer the reset logic to stay in core if that's possible, 
and ideally fix the other drivers to use that reset logic instead of 
implementing their own thing. If that's not possible, get a RB from Bin, 
since that's the expert on xhci, and then lets merge this stuff.


More information about the U-Boot mailing list