mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Ray Chi <raychi@google.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	mathias.nyman@linux.intel.com,
	Albert Wang <albertccwang@google.com>,
	Badhri Jagan Sridharan <badhri@google.com>,
	Puma Hsu <pumahsu@google.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch v2] usb: core: stop USB enumeration if too many retries
Date: Fri, 2 Sep 2022 13:07:49 -0400	[thread overview]
Message-ID: <YxI4ZViLkZOjN/Bh@rowland.harvard.edu> (raw)
In-Reply-To: <CAPBYUsApTYex027qBe-=EyUxDHb8MMQscX+2jqZ98zXxN-0tHA@mail.gmail.com>

On Sat, Sep 03, 2022 at 12:08:04AM +0800, Ray Chi wrote:
> On Fri, Sep 2, 2022 at 10:49 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Fri, Sep 02, 2022 at 05:15:35PM +0800, Ray Chi wrote:
> > > If a broken accessory connected to a USB host, usbcore might
> > > keep doing enumeration retries and it will take a long time to
> > > cause system unstable.
> > >
> > > This patch provides a quirk to specific USB ports of the hub to
> > > stop USB enumeration if needed.
> >
> > This seems very awkward.  Why not have a quirk that prevents USB
> > enumeration completely, instead of after some number of retries?  After
> > all, if the port is connected to a broken accessory, there's no reason
> > to try enumerating it even once.
> >
> > For that matter, have you tried using the existing "disabled" port
> > attribute instead of adding a new quirk?  Does it already solve your
> > problem?
> >
> 
> Since we don't know if the connected accessory is normal or broken, doing port
> initialization is necessary.

I don't understand.  If you don't know whether the accessory is broken, 
how do you know whether to set the quirk?

On the other hand, if you always set the quirk even before you know 
whether the accessory is broken, why make it a quirk at all?  Why not 
make it the normal behavior of the driver?

> > > +              * Some USB hosts can't take a long time to keep doing enumeration
> > > +              * retry. After doing half of the retries, we would turn off the port
> > > +              * power to stop enumeration if the quirk is set.
> >
> > What made you decide that half of the retries was the right place to
> > stop?  Why not do all the retries?
> 
> Since some normal devices will be timeout in the first attempt, I set
> the condition to half
> of the retries. All the retries will take 12*timeout seconds. It is
> too long so that a watchdog
> timeout problem may happen.

Why not set CONFIG_USB_FEW_INIT_RETRIES instead?

> > If the quirk prevented enumeration completely then this function
> > wouldn't be needed.
> 
> The enumeration is still needed as above.
> 
> >
> > > +
> > >  /* Check if a port is power on */
> > >  int usb_port_is_power_on(struct usb_hub *hub, unsigned int portstatus)
> > >  {
> > > @@ -4855,6 +4879,11 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
> > >                                       buf->bMaxPacketSize0;
> > >                       kfree(buf);
> > >
> > > +                     if (r < 0 && (port_dev->quirks & USB_PORT_QUIRK_STOP_ENUM)) {
> >
> > How come this line tests the quirk but doesn't call
> > hub_port_stop_enumerate()?
> 
> Since the quirk is used to stop enumeration and reduce the total time.
> If the port has the quirk, I think the port doesn't need to do
> set_address after the port gets
> failures in the new scheme. It will add 2 attempts * timeout (defined
> in hc_driver) seconds.

I still can't tell what you're trying to accomplish.  You need to do a 
much better job of explaining the point of this.  For instance, you 
might describe in detail a situation where the quirk is needed, 
explaining what sort of behavior of the system would lead you to set the 
quirk, and why.

Alan Stern

  reply	other threads:[~2022-09-02 17:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-02  9:15 Ray Chi
2022-09-02 14:49 ` Alan Stern
2022-09-02 16:08   ` Ray Chi
2022-09-02 17:07     ` Alan Stern [this message]
2022-09-05  8:36       ` Ray Chi
2022-09-05 15:18         ` Alan Stern
2022-09-08 11:11           ` Ray Chi

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=YxI4ZViLkZOjN/Bh@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=albertccwang@google.com \
    --cc=badhri@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=pumahsu@google.com \
    --cc=raychi@google.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

all inboxes | Powered by JetHome®