From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 4/4] usb: Change power-on / scanning timeout handling
Date: Mon, 14 Mar 2016 20:47:34 +0100 [thread overview]
Message-ID: <56E71556.7010003@redhat.com> (raw)
In-Reply-To: <56E6F555.5020807@wwwdotorg.org>
Hi,
On 14-03-16 18:31, Stephen Warren wrote:
> On 03/14/2016 04:18 AM, Stefan Roese wrote:
<snip>
>> @@ -120,7 +121,21 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
>> pgood_delay = max(pgood_delay,
>> (unsigned)simple_strtol(env, NULL, 0));
>> debug("pgood_delay=%dms\n", pgood_delay);
>> - mdelay(pgood_delay + 1000);
>> +
>> + /*
>> + * Do a minimum delay of the larger value of 100ms or pgood_delay
>> + * so that the power can stablize before the devices are queried
>> + */
>> + dev->query_delay = get_timer(0) + max(100, (int)pgood_delay);
>> +
>> + /*
>> + * Record the power-on timeout here. The max. delay (timeout)
>> + * will be done based on this value in the USB port loop in
>> + * usb_hub_configure() later.
>> + */
>> + dev->connect_timeout = get_timer(0) + pgood_delay + 1000;
>
> I'd be tempted to make that:
>
> dev->connect_timeout = dev->query_delay + 1000;
>
> That way, if the max() used in the calculation of dev->query_delay was dominated by the 100 not the pgood_delay, then we still get a 1000ms time for the device to connect after the power is stable.
Ack, good catch.
> Currently, if pgood_delay<=100 (is that legal?) then the delta might be as little as 900ms (for pgood_delay==0).
AFAIK it is not legal, but guess what the firmware authors of cheap hubs put in the
descriptor when 0 seems to work just fine ?
Rule of thumb: Never trust usb descriptors.
Regards,
Hans
>
>> static LIST_HEAD(usb_scan_list);
>
> You could put that onto the stack in usb_hub_configure() and pass it as a parameter to usb_device_list_scan(). That would avoid some globals, which might make it easier to apply this technique across multiple controllers/hubs/... in the future?
>
>> +static int usb_scan_port(struct usb_device_scan *usb_scan)
>
>> + ret = usb_get_port_status(dev, i + 1, portsts);
>> + if (ret < 0) {
>> + debug("get_port_status failed\n");
>> + return 0;
>
> Shouldn't this cause a timeout eventually if it repeats forever?
>
>> + /* Test if the connection came up, and if so, exit. */
>> + if (portstatus & USB_PORT_STAT_CONNECTION) {
>
> If you invert that test, you can return early and remove and indentation level from the rest of the function.
>
>> + debug("devnum=%d port=%d: USB dev found\n", dev->devnum, i + 1);
>> + /* Remove this device from scanning list */
>> + list_del(&usb_scan->list);
>> +
>> + /* A new USB device is ready at this point */
>> +
>> + debug("Port %d Status %X Change %X\n",
>> + i + 1, portstatus, portchange);
>
> It might be nice to print this a little earlier (outside the USB_PORT_STAT_CONNECTION if block) so that any USB_PORT_STAT_C_CONNECTION triggers the print, not just if C_CONNECTION && CONNECTION. That might help debug, and match the existing code.
>
>> + if (portchange & USB_PORT_STAT_C_CONNECTION) {
> > + debug("port %d connection change\n", i + 1);
> > + usb_hub_port_connect_change(dev, i);
> > + }
>
> That test is always true, or the function would have returned earlier.
>
>> +static int usb_device_list_scan(void)
> ...
>> + static int running;
>> + int ret = 0;
>> +
>> + /* Only run this loop once for each controller */
>> + if (running)
>> + return 0;
>> +
>> + running = 1;
> ...
>> +out:
>> + /*
>> + * This USB controller has has finished scanning all its connected
>> + * USB devices. Set "running" back to 0, so that other USB controllers
>> + * will scan their devices too.
>> + */
>> + running = 0;
>
> Doesn't this function only get called a single time from usb_hub_configure()? If so, I don't think the "running" variable is required.
>
>> static int usb_hub_configure(struct usb_device *dev)
>
>> + for (i = 0; i < dev->maxchild; i++) {
>> + struct usb_device_scan *usb_scan;
>>
>> + usb_scan = calloc(1, sizeof(*usb_scan));
>> + if (!usb_scan) {
>> + printf("Can't allocate memory for USB device!\n");
>> + return -ENOMEM;
>
> I think there should be some resource cleanup for the previously allocated list entries here. Perhaps that's what you meant in your other email where you talked about some missing free()s?
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
next prev parent reply other threads:[~2016-03-14 19:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 10:18 [U-Boot] [PATCH v3 0/4] usb: Reduce USB scanning time Stefan Roese
2016-03-14 10:18 ` [U-Boot] [PATCH v3 1/4] usb: legacy_hub_port_reset(): Speedup hub reset handling Stefan Roese
2016-03-14 10:18 ` [U-Boot] [PATCH v3 2/4] usb: Remove 200 ms delay in usb_hub_port_connect_change() Stefan Roese
2016-03-14 17:06 ` Stephen Warren
2016-03-14 10:18 ` [U-Boot] [PATCH v3 3/4] usb: Don't reset the USB hub a 2nd time Stefan Roese
2016-03-14 10:18 ` [U-Boot] [PATCH v3 4/4] usb: Change power-on / scanning timeout handling Stefan Roese
2016-03-14 12:45 ` Hans de Goede
2016-03-14 13:19 ` Stefan Roese
2016-03-14 17:31 ` Stephen Warren
2016-03-14 19:47 ` Hans de Goede [this message]
2016-03-15 9:46 ` Stefan Roese
2016-03-15 15:42 ` Stephen Warren
2016-03-14 17:51 ` Stephen Warren
2016-03-15 13:16 ` Stefan Roese
2016-03-15 15:52 ` Stephen Warren
2016-03-15 16:00 ` Stefan Roese
2016-03-15 16:07 ` Stephen Warren
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=56E71556.7010003@redhat.com \
--to=hdegoede@redhat.com \
--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