RE: [PATCH 1/2] dt-bindings: usb: generic-ehci: add a quirk property to avoid stuck

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert-san,

Thank you for your review!

> From: Geert Uytterhoeven, Sent: Saturday, January 18, 2020 1:03 AM
> 
> Hi Shimoda-san,
> 
> Thanks for your patch!
> 
> On Fri, Jan 17, 2020 at 11:54 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> > Since EHCI/OHCI controllers on R-Car Gen3 SoCs are possible to
> > be getting stuck very rarely after a full/low usb device was
> > disconnected. To detect/recover from such a situation, the controllers
> > require a special way which poll the EHCI PORTSC register and changes
> > the OHCI functional state.
> 
> Oops... Is this limited to the EHCI/OHCI implementation on R-Car Gen3?
> Or can it happen on any EHCI/OHCI controller?

This is limited on R-Car Gen3 (and perhaps RZ/A2 and RZ/G2).
But, R-Mobile A1 and R-Car Gen1/2 don't have this issue.
And I don't know any other EHCI/OHCI controller has this issue.

> > --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> > +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> > @@ -63,6 +63,11 @@ properties:
> >      description:
> >        Set this flag to force EHCI reset after resume.
> >
> > +  needs-polling-to-avoid-stuck:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description:
> > +      Set this flag to avoid getting EHCI stuck.
> > +
> >    companion:
> >      $ref: /schemas/types.yaml#/definitions/phandle
> >      description:
> 
> If this issue is specific to the EHCI/OHCI implementation on R-Car Gen3,
> I don't think this is the best solution to handle it.
> It might be better to add family/SoC-specific compatible values for the
> EHCI/OHCI controllers in R-Car Gen3 SoCs, cfr. the (undocumented)
> "ibm,usb-ehci-440epx" and "allwinner,sun4i-a10-ehci" compatible values
> in the example in the DT bindings file (probably we should have done so
> from the start, like for all other devices).
> Then the driver can handle the issue based on the compatible value.

I understood it. And I'm also think adding family/SoC-specific compatible
values are better.

> Besides, what about DT backwards compatibility?
> To enable this quirk handling, the DT must be updated first.
> This is true for solutions based on either a DT property or on a
> different compatible value.
> Of course, you can always use soc_device_match()...

In this case, I should apply this quirk to some SoCs,
I think using DT is better than soc_device_match().

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux