Hi Geert-san again,

From: Yoshihiro Shimoda, Sent: Monday, January 20, 2020 5:05 PM

quoted

quoted

--- 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