Re: [PATCH RFC v3 02/10] usb: misc: qcom_eud: add sysfs attribute for port selection

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 3/13/26 1:45 PM, Greg Kroah-Hartman wrote:
> On Fri, Mar 13, 2026 at 01:10:10PM +0100, Konrad Dybcio wrote:
>> On 3/11/26 2:16 PM, Greg Kroah-Hartman wrote:
>>> On Mon, Mar 09, 2026 at 01:33:29PM -0700, Elson Serrao wrote:
>>>> EUD can be mapped to either the primary USB port or the secondary USB port
>>>> depending on the value of the EUD_PORT_SEL register. Add a 'port' sysfs
>>>> attribute to allow userspace to select which port EUD should operate on
>>>> and update the ABI documentation. This is needed for systems with dual
>>>> USB ports where EUD needs to be accessible on either port depending on the
>>>> system configuration and use case.
>>>>
>>>> Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com>
>>>> ---
>>>>  Documentation/ABI/testing/sysfs-driver-eud | 16 ++++++++
>>>>  drivers/usb/misc/qcom_eud.c                | 43 ++++++++++++++++++++++
>>>>  2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud
>>>> index 2bab0db2d2f0..67223f73ee60 100644
>>>> --- a/Documentation/ABI/testing/sysfs-driver-eud
>>>> +++ b/Documentation/ABI/testing/sysfs-driver-eud
>>>> @@ -7,3 +7,19 @@ Description:
>>>>  		EUD based on a 1 or a 0 value. By enabling EUD,
>>>>  		the user is able to activate the mini-usb hub of
>>>>  		EUD for debug and trace capabilities.
>>>> +
>>>> +What:		/sys/bus/platform/drivers/qcom_eud/.../port
>>>> +Date:		January 2026
>>>> +Contact:	Elson Serrao <elson.serrao@oss.qualcomm.com>
>>>> +Description:
>>>> +		Selects which USB port the Embedded USB Debugger (EUD)
>>>> +		is mapped to on platforms providing multiple High-Speed
>>>> +		USB ports.
>>>> +
>>>> +		Valid values:
>>>> +		  0 - Primary USB port
>>>> +		  1 - Secondary USB port
>>>
>>> Why not use "primary" and "secondary" as values instead?  That makes
>>> this much simpler to understand.
>>
>> It's not inconceivable that future iterations of this hardware will let
>> one mux between more than two USB PHYs/ports (there are already a multitude
>> of SoCs where we have 4 or more USB controllers and >= that ports)
> 
> Great, and how will that be defined?  As a number?  Name?  Something
> else?

Perhaps it makes more sense to me, since if I look at the other
computer, the controllers are named USB0, USB1 and so on.. We follow
this naming in DT too, so it felt natural

How they end up mapping to physical connectors is of course up to the
implementer.

Ultimately, I don't mind either

Konrad