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

From: Krzysztof Kozlowski <[email-masked]>
Date: Mon, 21 Dec 2020 22:04:23 +0100

On Mon, Dec 21, 2020 at 12:24:11PM -0800, John Stultz wrote:
> On Sat, Dec 19, 2020 at 3:06 AM Krzysztof Kozlowski <[email-masked]> wrote:
> > On Fri, Dec 18, 2020 at 09:11:42PM -0800, John Stultz wrote:
> > > On Wed, Nov 11, 2020 at 1:22 AM Serge Semin
> > > <[email-masked]> wrote:
> > > >
> > > > 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 <[email-masked]>
> > > > Acked-by: Krzysztof Kozlowski <[email-masked]>
> > > > ---
> > > >  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.
> 
> Though that is how it's exported through sysfs.

The ABI is the format of sysfs file for example in /sys/devices. However
the ABI is not the exact address or node name of each device.

> In AOSP it is then used to setup the configfs gadget by writing that
> value into /config/usb_gadget/g1/UDC.
> 
> Given there may be multiple controllers on a device, or even if its
> just one and the dummy hcd driver is enabled, I'm not sure how folks
> reference the "right" one without the node name?

I think it is the same type of problem as for all other subsystems, e.g.
mmc, hwmon/iio.  They usually solve it either with aliases or with
special property with the name/label.

> I understand the fuzziness with sysfs ABI, and I get that having
> consistent naming is important, but like the eth0 -> enp3s0 changes,
> it seems like this is going to break things.

One could argue whether interface name is or is not ABI. But please tell
me how the address of a device in one's representation (for example DT)
is a part of a stable interface?

> Greg? Is there some better way AOSP should be doing this?

If you need to find specific device, maybe go through the given bus and
check compatibles?

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel