On Thu, Jul 22, 2021 at 01:09:05PM -0700, John Stultz wrote:

On Thu, Jul 22, 2021 at 12:17 PM Bjorn Andersson
[off-list ref] wrote:

quoted

quoted

On Jul 21, 2021, 1:45 PM +0200, Krzysztof Kozlowski wrote:

quoted

I had impression that kernel defines interfaces which should be used and
are stable (e.g. syscalls, sysfs and so on). This case is example of
user-space relying on something not being marked as part of ABI. Instead
they found something working for them and now it is being used in "we
cannot break existing systems". Basically, AOSP unilaterally created a
stable ABI and now kernel has to stick to it.

Really, all normal systems depend on aliases or names and here we have
dependency on device address. I proposed way how AOSP should be fixed.
Anything happened? Nope.

First time he sent a possible solution for the problem:
https://lore.kernel.org/lkml/20201221210423.GA2504@kozik-lap/ (local)

To sum up you could have used one of the more portable approaches
1. add an udc alias to the controller and use it then to refer to the
corresponding USB controller

Is there such a thing as "UDC alias"? Or are you suggesting that we
should add such feature?

I think it would be wonderful if we could identify the UDCs on our
boards as "USB1" and "USB2", or "the one and only USB-C connector". But
unless that will fall back to the existing naming it would break John's
_existing_ userspace.

Well, I'd not hold up the existing userspace I'm using as sacrosanct
(AOSP devices still usually don't have to work cross-kernel versions -
devboards being the main exception). I'm fine if we can rework
userland as proposed, so that the issues can be avoided, but I
honestly don't have enough context to really understand what that
looks like (no idea what udc aliases are).

And whatever we do, the main constraint is that userland has to be
able to work with existing LTS kernels and newer kernels.

As I said in my response to Bjorn even if it is added to the kernel it
won't get to the official LTSes as it would be a new kernel feature.
New features aren't normally backported to the older kernels.

quoted

quoted

2. search through DT-nodes looking for a specific compatible/reg
DT-properties.

We could define that this is the way, but again we didn't yesterday so
your proposal is not backwards compatible.

It may be backwards compatible, but I'm still not clear exactly how it
would work.

I guess if we look through all
sys/bus/platform/devices/*/of_node/compatbile strings for the desired
"snps,dwc3", then find which of the directories have the desired
address in the string? (The suggestion for looking at reg seems
better, but I don't get a char value out of the dwc3 of_node/reg
file).

The algorithm is simple:
1) You know what USB controllers you have on your platform. They are
supposed to be compatible with snps,dwc3 string and have some pre-defined
base address.
2) Find all the files in the directory /sys/class/udc/.
3) Walk through all the directories in /sys/bus/platform/devices/ with
names found in 2) and stop on the device with matching compatible/base
address defined in 1).

In my case the strings could be retrieved like this:
USB_NAME_COMPAT=$(/sys/bus/platform/devices/1f100000.usb/of_node/compatible | tr '\0' '\t' | cut -f1)
USB_DEVICE_ADDR="$(head -c 4 /sys/bus/platform/devices/1f100000.usb/of_node/reg | hexdump -ve '/1 "%02x"' | sed -e 's/^0*//g')"

Regards,
-Sergey

It seems much more straightforward to do an `ls /sys/class/udc/$GADGET_ADDR.*`

But again, if folks decide the names can be rearranged to usb.<addr>
in the future, that would break too.

thanks
-john