Message-ID: <4edabcb3.7e65.1898d54679e.Coremail.18500469033@163.com>
Date:   Tue, 25 Jul 2023 21:54:26 +0800 (CST)
From:   "Dingyan Li" <18500469033@....com>
To:     "Greg KH" <gregkh@...uxfoundation.org>
Cc:     "Oliver Neukum" <oneukum@...e.com>, stern@...land.harvard.edu,
        sebastian.reichel@...labora.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH] USB: add usbfs ioctl to get specific superspeedplus
 rates


At 2023-07-25 21:24:32, "Greg KH" <gregkh@...uxfoundation.org> wrote:
>On Mon, Jul 24, 2023 at 11:47:49AM +0200, Oliver Neukum wrote:
>> On 21.07.23 16:51, Greg KH wrote:
>> 
>> > > 1. By saying "be documented somewhere", do you mean there is extra
>> > >      documentation work which needs to be done? Sorry that I missed this
>> > >      part since it's the first time for me to work on a kernel patch.
>> > 
>> > It needs to be documented somewhere, otherwise no one knows how to use
>> > it.
>> > 
>> > > 2. If no error, returned values are "enum usb_ssp_rate" defined in include/linux/usb/ch9.h
>> > > 3. ssp rate is only valid for superspeedplus. For other speeds, it should be
>> > >      USB_SSP_GEN_UNKNOWN.
>> > 
>> > Ok, that should be documented.
>> 
>> Documentation would be good.
>> Where should it go, though? These enums are part of the uapi
>> hierarchy. Now, documentation for uapi would be good, but we
>> should not mix it with documentation for ioctl
>> That is if an ioctl uses an enum out of uapi it needs to be
>> explicitly mentioned by name, but documenting the semantics
>> of the enum _there_ would be wrong.
>> 
>> > 
>> > > 4. I found in libusb, there are two ways to get speed value for a device.
>> > >      One way is via sysfs, which has supported 20Gbps now. Another way is
>> > >      to use ioctl USBDEVFS_GET_SPEED. This is when I found this ioctl can only
>> > >      return USB_SPEED_SUPER_PLUS at most, it cannot determine current ssp rate
>> > >      further, no matter Gen1x2(10Gbps), Gen2x1(10Gbps) or Gen2x2(20Gbps). So I
>> > >      thought maybe it's good to provide a similar way like ioctl USBDEVFS_GET_SPEED
>> > >      in order to get ssp rates.
>> > 
>> > If libusb doesn't need this ioctl, who would use it?  We only add apis
>> > that are actually going to be used.
>> > 
>> > So if libusb doesn't use it, we need a real-world user for us to be able
>> > to add this.
>> 
>> I am sorry, but that looks pretty much like a question of API design to me.
>> To what extent is libusb supposed to be functional without sysfs? There is
>> no technical answer to this. It is a question of design goals.
>> 
>> If we follow the precedent of c01b244ad848a
>> ("USB: add usbfs ioctl to retrieve the connection speed")
>> then we should apply an updated version of Dingyan Li's patch, preferably
>> coupled with a patch for libusb or we go and deprecate some ioctls.
>
>We can never "deprecate" ioctls, sorry.
>
>So unless there is some actual need from userspace tools like libusb (or
>anything else?) that requires this new ioctl, let's not add it otherwise
>we are signing ourselves up to support it for forever.
>
>thanks,
>

>greg k-h

If we can't "deprecate" ioctls, can we change the returned contents of existing ones?

I found even in usbfs, we got two different ioctls which can be used to get device speed,
including USBDEVFS_GET_SPEED and USBDEVFS_CONNINFO_EX. Maybe we can reduce
some redundancy there.

And by saying actual needs, you mean it's not enough to just add this new ioctl to libusb and
imagine this part of libusb will be used by anyone in the future. There must be some real-world
requests for now which make libusb have to use this new ioctl, right?


Regards,
Dingyan

Powered by blists - more mailing lists