From: Paul Kocialkowski <contact@paulk.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] usb: Early failure when the first descriptor read fails, one way or another
Date: Sat, 28 Mar 2015 18:31:42 +0100 [thread overview]
Message-ID: <1427563902.8267.12.camel@collins> (raw)
In-Reply-To: <201503281826.20603.marex@denx.de>
Le samedi 28 mars 2015 ? 18:26 +0100, Marek Vasut a ?crit :
> On Saturday, March 28, 2015 at 06:23:58 PM, Paul Kocialkowski wrote:
> > When using an USB1 device on a controller that only supports USB2 (e.g.
> > EHCI), reading the first descriptor will fail (read 0 byte), so we can
> > abort the process at this point instead of failing later and wasting time.
> >
> > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > ---
> > common/usb.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/usb.c b/common/usb.c
> > index 32e15cd..d1b3316 100644
> > --- a/common/usb.c
> > +++ b/common/usb.c
> > @@ -950,7 +950,7 @@ int usb_new_device(struct usb_device *dev)
> > */
> > #ifndef CONFIG_USB_XHCI
> > err = usb_get_descriptor(dev, USB_DT_DEVICE, 0, desc, 64);
> > - if (err < 0) {
> > + if (err < sizeof(struct usb_device_descriptor)) {
> > debug("usb_new_device: usb_get_descriptor() failed\n");
> > return 1;
> > }
> > @@ -990,6 +990,9 @@ int usb_new_device(struct usb_device *dev)
> > case 64:
> > dev->maxpacketsize = PACKET_SIZE_64;
> > break;
> > + default:
> > + debug("usb_new_device: invalid max packet size\n");
>
> Hi,
>
> since this is an error, this should probably be a printf(). Also,
> to make the error message useful, it should state the invalid value
> due to which it failed.
Well, it is not unexpected behaviour in my use case (but I reckon it may
be generally speaking). Plugging an USB1 device on a controller that
doesn't support USB1 should normally fail, this is not some kind of
run-time error.
When this happens in Linux, it just fails (silently) and tries ohci
instead. I'm afraid there is no such mechanism in U-Boot, so the best we
can do is to treat the device as unsupported.
If you're not convinced by this, I can still make a v2 with printf, I
just don't think it's a necessity.
> Thanks!
>
> > + return 1;
> > }
> > dev->devnum = addr;
>
> Best regards,
> Marek Vasut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150328/761a9c72/attachment.sig>
next prev parent reply other threads:[~2015-03-28 17:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-28 17:23 [U-Boot] [PATCH] usb: Early failure when the first descriptor read fails, one way or another Paul Kocialkowski
2015-03-28 17:26 ` Marek Vasut
2015-03-28 17:31 ` Paul Kocialkowski [this message]
2015-03-29 10:30 ` Paul Kocialkowski
2015-03-29 23:47 ` Marek Vasut
2015-03-30 13:35 ` Paul Kocialkowski
2015-04-03 2:01 ` Marek Vasut
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=1427563902.8267.12.camel@collins \
--to=contact@paulk.fr \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.