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
