[PATCH v5 4/4] usb: xhci: Add reset controller support

Marek Vasut marex at denx.de
Wed Jun 24 12:58:41 CEST 2020


On 6/24/20 12:55 PM, Nicolas Saenz Julienne wrote:
> Hi Marek,

Hi,

> On Mon, 2020-06-22 at 17:34 +0200, Marek Vasut wrote:
>> On 6/22/20 5:30 PM, Nicolas Saenz Julienne wrote:
>> [...]
>>
>>> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
>>> index 1170c0ac69..7d34103fd5 100644
>>> --- a/include/usb/xhci.h
>>> +++ b/include/usb/xhci.h
>>> @@ -16,6 +16,7 @@
>>>  #ifndef HOST_XHCI_H_
>>>  #define HOST_XHCI_H_
>>>  
>>> +#include <reset.h>
>>>  #include <asm/types.h>
>>>  #include <asm/cache.h>
>>>  #include <asm/io.h>
>>> @@ -1209,6 +1210,7 @@ struct xhci_ctrl {
>>>  #if CONFIG_IS_ENABLED(DM_USB)
>>>  	struct udevice *dev;
>>>  #endif
>>> +	struct reset_ctl reset;
>>
>> Should all this reset logic be protected by if CONFIG_IS_ENABLED(DM_RESET) ?
> 
> As far as building the code there shouldn't be any issues, function/structures
> are defined in either case.
> 
> That said I can see how there could be a runtime issue for the
> !CONFIG_IS_ENABLED(DM_RESET) case, as xhci_reset_hw() will return an error and
> make xchi_register() fail.
> 
> So I can either protect everything with preprocessor conditionals, both in the
> struct as in xhci_register(), or catch -ENOTSUPP in xhci_register() and
> continue the registration as usual. I prefer the later as it adds less
> preprocessor churn, but I'll go the other way if you prefer it.

I agree, lets go with the later, thanks.


More information about the U-Boot mailing list