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

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Tony Prisk <linux@prisktech.co.nz>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	USB list <linux-usb@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH 1/2] dt-bindings: usb: generic-ehci: add a quirk property to avoid stuck
Date: Thu, 23 Jan 2020 08:17:47 +0000	[thread overview]
Message-ID: <TYAPR01MB4544596E4415FBD3101934D8D80F0@TYAPR01MB4544.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <TYAPR01MB4544EF1219B2670289410772D8320@TYAPR01MB4544.jpnprd01.prod.outlook.com>

Hi Geert-san again,

> From: Yoshihiro Shimoda, Sent: Monday, January 20, 2020 5:05 PM
> > > --- 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.

I'm trying to add some undocumented compatible values, but it seems hard
to add because:
- Some dts[i] files have undocumented compatible strings.
 # We can find it by using the following command:
 # $ grep "generic-ehci" `find -name "*.dts*"` | grep ","

- I tried to use "oneOf:" and "contains:" combination, but it failed.

- This generic-ehci.yaml uses "contains:" for the compatible now.
  So, even if compatible property has undocumented compatible string,
  make dtbs_check command succeeded (except node names).

- In my opinion, almost all user (excect R-Car SoCs) doesn't needs
  specific compatible values, so that adding such compatible values
  causes less usability in the future.

So, I suspended adding specific compatible values and I'll use
soc_device_match() for this workaround for now...

Best regards,
Yoshihiro Shimoda