Re: [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name

On Fri, Dec 18, 2020 at 09:11:42PM -0800, John Stultz wrote:

On Wed, Nov 11, 2020 at 1:22 AM Serge Semin
[off-list ref] wrote:

quoted

In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin <redacted>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index d25aac5e0bf8..aea3800029b5 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi

@@ -1166,7 +1166,7 @@ usb_phy: usb-phy {
                        };
                };

-               dwc3: dwc3@ff100000 {
+               dwc3: usb@ff100000 {
                        compatible = "snps,dwc3";
                        reg = <0x0 0xff100000 0x0 0x100000>;

Oof. So this patch is breaking the usb gadget functionality on HiKey960 w/ AOSP.

In order to choose the right controller for gadget mode with AOSP, one
sets the "sys.usb.controller" property, which until now for HiKey960
has been "ff100000.dwc3".
After this patch, the controller isn't found and we would have to
change userland to use "ff100000.usb", which would then break booting
on older kernels (testing various LTS releases on AOSP is one of the
key uses of the HiKey960).

So while I understand the desire to unify the schema, as HiKey960
really isn't likely to be used outside of AOSP, I wonder if reverting
this one change is in the best interest of not breaking existing
userland?

The node names are not part of an ABI, are they? I expect only
compatibles and properties to be stable. If user-space looks for
something by name, it's a user-space's mistake.  Not mentioning that you
also look for specific address... Imagine remapping of addresses with
ranges (for whatever reason) - AOSP also would be broken? Addresses are
definitely not an ABI.

Best regards,
Krzysztof