From: Greg KH <gregkh@linuxfoundation.org>
To: Hardik Gajjar <hgajjar@de.adit-jv.com>
Cc: mathias.nyman@intel.com, stern@rowland.harvard.edu,
yangyingliang@huawei.com, jinpu.wang@ionos.com,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
erosca@de.adit-jv.com
Subject: Re: [PATCH v2] usb: core: hub: Add quirks for reducing device address timeout
Date: Tue, 10 Oct 2023 13:25:02 +0200 [thread overview]
Message-ID: <2023101054-thread-manliness-52a4@gregkh> (raw)
In-Reply-To: <20231010103143.GA107162@vmlxhi-118.adit-jv.com>
On Tue, Oct 10, 2023 at 12:31:43PM +0200, Hardik Gajjar wrote:
> On Mon, Oct 09, 2023 at 07:43:09PM +0200, Greg KH wrote:
> > On Mon, Oct 09, 2023 at 06:14:02PM +0200, Hardik Gajjar wrote:
> > > Currently, the timeout for the set address command is fixed at
> > > 5 seconds in the xhci driver. This means the host waits up to 5
> > > seconds to receive a response for the set_address command from
> > > the device.
> > >
> > > In the automotive context, most smartphone enumerations, including
> > > screen projection, should ideally complete within 3 seconds.
> > > Achieving this is impossible in scenarios where the set_address is
> > > not successful and waits for a timeout.
> > >
> > > The shortened address device timeout quirks provide the flexibility
> > > to align with a 3-second time limit in the event of errors.
> > > By swiftly triggering a failure response and swiftly initiating
> > > retry procedures, these quirks ensure efficient and rapid recovery,
> > > particularly in automotive contexts where rapid smartphone enumeration
> > > and screen projection are vital.
> >
> > So you have known-broken devices where you want a shorter error timeout?
> > But you don't list those devices in this patch adding the quirk
> > settings, shouldn't that be required, otherwise this looks like an
> > unused quirk.
> Yes, we have identified the device (hub) that is causing the issue. However,
> I would prefer not to force this timeout globally. Instead, I can dynamically
> control it by writing to the /sys/bus/usb/drivers/hub/module/parameter/quirks
> file from init.rc (Android) during the boot-up process.
Then add that device to the quirk list please so that everyone doesn't
have to figure this out on their own for that broken device. That's why
we have a quirk list in the kernel.
> > > static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
> > > - enum xhci_setup_dev setup)
> > > + enum xhci_setup_dev setup, int timeout)
> >
> > What is the units of timeout here?
> The timeout is in jiffies. Should we consider adding 'jiffies' in the variable name
> for clarity? I searched the kernel source code but couldn't find a reference for the
> unit of timeout in jiffies.
> Nevertheless, I will add a comment in patch v3 for clarification.
You should not pass around jiffies in the kernel in an int, please pass
around a unit of time and then when you actually need to tell the kernel
to sleep, you can use the time to convert to whatever unit the delay
function needs.
> > > +/* short device address timeout */
> > > +#define USB_QUIRK_SHORT_DEVICE_ADDR_TIMEOUT BIT(16)
> >
> > Don't you also need to have a Documentation/ update for the new
> > user/kernel api you are adding?
> >
> When you recommend Documentation, I assume you suggest to add the
> detailed comment in quirks.h to clear intention of the change.
No, please document the info that you have in the changelog in someplace
where people will know what flag to use in the module option. That's
already documented for the other flags somewhere, right?
thanks,
greg k-h
next prev parent reply other threads:[~2023-10-10 11:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <--in-reply-to=20231006153808.9758-1-hgajjar@de.adit-jv.com>
2023-10-09 16:14 ` [PATCH v2] usb: core: hub: Add quirks for reducing device address timeout Hardik Gajjar
2023-10-09 17:43 ` Greg KH
2023-10-10 10:31 ` Hardik Gajjar
2023-10-10 11:25 ` Greg KH [this message]
2023-10-09 19:16 ` Alan Stern
2023-10-10 10:50 ` Hardik Gajjar
2023-10-10 13:40 ` Mathias Nyman
2023-10-11 8:50 ` [PATCH v3] " Hardik Gajjar
2023-10-11 9:02 ` Greg KH
2023-10-11 12:05 ` Hardik Gajjar
2023-10-11 15:23 ` Greg KH
2023-10-11 16:45 ` [PATCH v4] " Hardik Gajjar
2023-10-16 17:58 ` Greg KH
2023-10-17 16:10 ` Hardik Gajjar
2023-10-17 16:53 ` Greg KH
2023-10-17 18:59 ` Alan Stern
2023-10-21 10:15 ` Greg KH
2023-10-23 16:13 ` Hardik Gajjar
2023-10-24 15:44 ` Alan Stern
2023-10-25 14:11 ` [PATCH v5] usb: Reduce 'set_address' command timeout with a new quirk Hardik Gajjar
2023-10-25 14:13 ` Hardik Gajjar
2023-10-25 14:44 ` Alan Stern
2023-10-25 16:00 ` Sergey Shtylyov
2023-10-25 16:16 ` Sergey Shtylyov
2023-10-25 16:16 ` Sergey Shtylyov
2023-10-25 16:40 ` Hardik Gajjar
2023-10-26 10:15 ` [PATCH v6] usb: Reduce the 'SET_ADDRESS' request " Hardik Gajjar
2023-10-26 13:08 ` Mathias Nyman
2023-10-26 16:00 ` Sergey Shtylyov
2023-10-26 18:34 ` Alan Stern
2023-10-27 9:57 ` Hardik Gajjar
2023-10-27 14:45 ` Alan Stern
2023-10-11 10:50 ` [PATCH v3] usb: core: hub: Add quirks for reducing device address timeout kernel test robot
2023-10-11 14:15 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023101054-thread-manliness-52a4@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=erosca@de.adit-jv.com \
--cc=hgajjar@de.adit-jv.com \
--cc=jinpu.wang@ionos.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=stern@rowland.harvard.edu \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox