Thread (110 messages) 110 messages, 17 authors, 2021-08-19

Re: [PATCH 29/29] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

From: Serge Semin <hidden>
Date: 2021-07-21 10:14:17
Also in: linux-arm-kernel, linux-arm-msm, linux-devicetree, lkml

Hi Greg,
@Krzysztof, @Rob, please join the discussion so to finally get done
with the concerned issue.

On Wed, Jul 21, 2021 at 09:38:54AM +0200, Greg Kroah-Hartman wrote:
On Wed, Jul 14, 2021 at 03:48:07PM +0300, Serge Semin wrote:
quoted
Hello John,

On Tue, Jul 13, 2021 at 05:07:00PM -0700, John Stultz wrote:
quoted
On Tue, Oct 20, 2020 at 5:10 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>
quoted
I know folks like to ignore this, but this patch breaks AOSP on db845c. :(
Sorry to hear that. Alas there is no much can be done about it.
Yes there is, we can revert the change.  We do not break existing
configurations, sorry.
By reverting this patch we'll get back to the broken dt-bindings
since it won't comply to the current USB DT-nodes requirements
which at this state well describe the latest DT spec:
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3
Thus the dtbs_check will fail for these nodes.

Originally this whole patchset was connected with finally getting the
DT-node names in order to comply with the standard requirement and it
was successful mostly except a few patches which still haven't been
merged in.

Anyway @Krzysztof has already responded to the complain regarding this
issue here:
https://lore.kernel.org/lkml/20201221210423.GA2504@kozik-lap/ (local)
but noone cared to respond on his reasonable questions in order to
get to a suitable solution for everyone. Instead we are
getting another email with the same request to revert the changes.
Here is the quote from the Krzysztof email so we could continue the
discussion:

On Mon, 21 Dec 2020 13:04:27 -0800 (PST), Krzysztof Kozlowski [off-list ref] wrote:
On Mon, Dec 21, 2020 at 12:24:11PM -0800, John Stultz wrote:
quoted
On Sat, Dec 19, 2020 at 3:06 AM Krzysztof Kozlowski [off-list ref] wrote:
quoted
...

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.
quoted
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.
quoted
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?
quoted
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
So the main question is how is the DT-node really connected with ABI
and is supposed to be stable in that concern?

As I see it even if it affects the configfs node name, then we may
either need to break that connection and somehow deliver DT-node-name
independent interface to the user-space or we have no choice but to
export the node with an updated name and ask of user-space to deal
with it. In both suggested cases the DT-node name will still conform
to the USB-node name DT spec. Currently we are at the second one.

Regards,
-Sergey
thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help