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

Nicolas Saenz Julienne nsaenzjulienne at suse.de
Wed Jun 24 12:55:30 CEST 2020


Hi Marek,

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.

> Otherwise the series looks good to me, thanks.

Thanks!

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200624/a72cb35a/attachment.sig>


More information about the U-Boot mailing list