Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 25 Jul 2023 15:24:32 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Oliver Neukum <oneukum@suse.com>
Cc:     Dingyan Li <18500469033@163.com>, stern@rowland.harvard.edu,
        sebastian.reichel@collabora.com, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: add usbfs ioctl to get specific superspeedplus rates
Message-ID: <2023072546-denture-half-5ceb@gregkh>
References: <20230721084039.9728-1-18500469033@163.com>
 <2023072105-lethargic-saddling-ad97@gregkh>
 <130b453c.5c8f.1897872ce54.Coremail.18500469033@163.com>
 <2023072159-carol-underfeed-43eb@gregkh>
 <781b3f95-96e7-af83-e089-887ec7f2d255@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <781b3f95-96e7-af83-e089-887ec7f2d255@suse.com>
Precedence: bulk

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