From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] usb: Fix device detection code
Date: Wed, 5 Aug 2015 17:23:32 +0200 [thread overview]
Message-ID: <201508051723.33080.marex@denx.de> (raw)
In-Reply-To: <55C212B3.3030001@redhat.com>
On Wednesday, August 05, 2015 at 03:42:11 PM, Hans de Goede wrote:
> Hi,
>
> On 05-08-15 03:19, Marek Vasut wrote:
> > The code in question polls an USB port status via USB_REQ_GET_STATUS
> > to determine whether there is a device on the port or not. The way to
> > figure that out is to check two bits. Those are wPortChange[0] and
> > wPortStatus[0].
> >
> > The wPortChange[0] indicates whether some kind of a connection status
> > change happened on a port (a device was plugged or unplugged). The
> > wPortStatus[0] bit indicates the status of the connection (plugged or
> > unplugged).
> >
> > The current code tests whether wPortChange[0] == wPortStatus[0] and
> > if that's the case, considers the loop polling for the presence of a
> > USB device on port finished.
> >
> > This works for most USB sticks, since they come up really quickly and
> > trigger the USB port change detection before the first iteration of the
> > detection loop happens. Thus, both wPortChange[0] and wPortStatus[0]
> > are set to 1 and thus equal. The loop is existed in it's first iteration
> > and the stick is detected correctly.
> >
> > The problem is with some obscure USB sticks, which take some time before
> > they pop up on the bus after the port was enabled. In this case, both
> > the wPortChange[0] and wPortStatus[0] are 0. They are equal again, so
> > the loop again exits in the first iteration, but this is incorrect, as
> > such USB stick didn't have the opportunity to get detected on the bus.
> >
> > Rework the code such, that it checks for wPortChange[0] first to test
> > if any connection change happened at all. If no change occured, keep
> > polling. If a change did occur, test the wPortStatus[0] to see there is
> > some device present on the port and only if this is the case, break out
> > of the polling loop.
> >
> > This patch also trims down the duration of the polling loop from 10s
> > per port to 1s per port. This is still annoyingly long, but there is
> > no better option in case of U-Boot unfortunatelly. This change will
> > most likely increase the duration of 'usb start' on some platforms,
> > but this is needed to fix a bug.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Hans de Goede <hdegoede@redhat.com>
>
> Looks good to me:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
OK, let's apply it and see if anyone complains :)
Thanks for checking it!
prev parent reply other threads:[~2015-08-05 15:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 1:19 [U-Boot] [PATCH] usb: Fix device detection code Marek Vasut
2015-08-05 13:42 ` Hans de Goede
2015-08-05 15:23 ` Marek Vasut [this message]
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=201508051723.33080.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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