Discussion:
[PATCH] hub.c - "hub.c: connect-debounce failed, port N disabled"
Michal Cihar
2002-11-06 08:59:55 UTC
Permalink
Hi

I was having problems with my usb device, that failed with "hub.c:
connect-debounce failed, port N disabled". This problem appears in all
kernels from 2.4.19pre2 (including those 2.5.x I have tested, but there
most probably with all 2.5.x as the impacted code seems to be same).
Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it
is being read once. Don't ask me why, but thats what I find out.
Following patch fixes this and IMHO should break anything else (it just
leaves debounce look if device seems to be connected).

For those who noticed: yes this patch has already appeared here few
weeks ago, but it was a bit hidden in thread and there was no reaction
at all. Any comments?

Regards
Michal Cihar

--- linux-2.4.19-orig/drivers/usb/hub.c 2002-09-10 15:25:42.000000000 +0200
+++ linux/drivers/usb/hub.c 2002-09-11 11:12:04.000000000 +0200
@@ -655,6 +655,7 @@
}
else
delay_time += HUB_DEBOUNCE_STEP;
+ if (portstatus&USB_PORT_STAT_CONNECTION) return 0;
}
return ((portstatus&USB_PORT_STAT_CONNECTION)) ? 0 : 1;
}



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Pete Zaitcev
2002-11-06 22:18:20 UTC
Permalink
Date: Wed, 06 Nov 2002 09:59:55 +0100
connect-debounce failed, port N disabled". [...]
Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it
is being read once. Don't ask me why, but thats what I find out.
Following patch fixes this and IMHO should break anything else (it just
leaves debounce look if device seems to be connected).
--- linux-2.4.19-orig/drivers/usb/hub.c 2002-09-10 15:25:42.000000000 +0200
+++ linux/drivers/usb/hub.c 2002-09-11 11:12:04.000000000 +0200
@@ -655,6 +655,7 @@
}
else
delay_time += HUB_DEBOUNCE_STEP;
+ if (portstatus&USB_PORT_STAT_CONNECTION) return 0;
}
return ((portstatus&USB_PORT_STAT_CONNECTION)) ? 0 : 1;
}
I saw this patch floating around internally, and IIRC I was
able to ignore it until the user changed his cabling.
It defeats the purpose of the whole debouncing routine completely.
Not that the said routine makes a lot of sense otherwise.

Interestingly, JE was up in arms against a simple 400ms delay
in this place, which always worked before. Now, someone came
with the debonce routine and lo and behold: it always delays
for the same 400ms -- the loop has no early break! So, why
don't we just restore the delay? It worked just fine in 2.2 kernel.

The resetting of delay_time in case of change bit present
also looks bogus, because it has not high bound.

All in all, the patch above is garbage, but the routine is
dubious on two counts and I would like the author to comment.

-- Pete


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Johannes Erdfelt
2002-11-06 23:24:31 UTC
Permalink
Post by Pete Zaitcev
Date: Wed, 06 Nov 2002 09:59:55 +0100
connect-debounce failed, port N disabled". [...]
Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it
is being read once. Don't ask me why, but thats what I find out.
What device is this?

It sounds horribly broken if it clears STAT_CONNECTION when there is a
device connected.
Post by Pete Zaitcev
Following patch fixes this and IMHO should break anything else (it just
leaves debounce look if device seems to be connected).
--- linux-2.4.19-orig/drivers/usb/hub.c 2002-09-10 15:25:42.000000000 +0200
+++ linux/drivers/usb/hub.c 2002-09-11 11:12:04.000000000 +0200
@@ -655,6 +655,7 @@
}
else
delay_time += HUB_DEBOUNCE_STEP;
+ if (portstatus&USB_PORT_STAT_CONNECTION) return 0;
}
return ((portstatus&USB_PORT_STAT_CONNECTION)) ? 0 : 1;
}
I saw this patch floating around internally, and IIRC I was
able to ignore it until the user changed his cabling.
It defeats the purpose of the whole debouncing routine completely.
Not that the said routine makes a lot of sense otherwise.
Interestingly, JE was up in arms against a simple 400ms delay
in this place, which always worked before. Now, someone came
with the debonce routine and lo and behold: it always delays
for the same 400ms -- the loop has no early break! So, why
don't we just restore the delay? It worked just fine in 2.2 kernel.
I just wanted to make sure there was a way other than penalizing every
device.

Unfortunately, I have no devices that exhibit this problem, so I had to
go on the word of other people.

It was my understanding that this patch goes above and beyond the patch
you had to catch some additionally broken devices.
Post by Pete Zaitcev
The resetting of delay_time in case of change bit present
also looks bogus, because it has not high bound.
Yes, I was just noticing that too.
Post by Pete Zaitcev
All in all, the patch above is garbage, but the routine is
dubious on two counts and I would like the author to comment.
I'll see if I have the email in my archives. I forget who originally
wrote this patch.

JE



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Pete Zaitcev
2002-11-07 00:14:06 UTC
Permalink
Date: Wed, 6 Nov 2002 18:24:31 -0500
Post by Pete Zaitcev
Interestingly, JE was up in arms against a simple 400ms delay
in this place, which always worked before. Now, someone came
with the debonce routine and lo and behold: it always delays
for the same 400ms -- the loop has no early break! So, why
don't we just restore the delay? It worked just fine in 2.2 kernel.
I just wanted to make sure there was a way other than penalizing every
device.
I happen to agree with you that we ought not to waste 400ms
if there is an other way. I was just pointing out that the
current debounce routine continues to waste those 400m.

I would understand if we had the loop written like this:

#define HUB_DEB_TOUT 400
#define HUB_DEB_STEP 30 // small enough for stable counts to make sense

connection = 0;
stable_count = 0;
for (delay_time = 0; delay_time < HUB_DEB_TOUT; delay_time += HUB_DEB_STEP) {
wait_ms(HUB_DEBOUNCE_STEP);
ret = usb_hub_port_status(hub, port, &portstatus, &portchange);
if ((portstatus & USB_PORT_STAT_CONNECTION) == connection) {
if (++stable_count == 3) /* Does not seem to bounce, proceed */
break;
} else {
stable_count = 0; /* Bitch bounces */
}
connection = portstatus & USB_PORT_STAT_CONNECTION;
if (portchange & USB_PORT_STAT_C_CONNECTION) {
usb_clear_port_feature(hub, port+1, USB_PORT_FEAT_C_CONNECTION);
}
}

But no, this is not what it does either.

-- Pete


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Michal Cihar
2002-11-07 08:55:08 UTC
Permalink
Post by Johannes Erdfelt
Post by Pete Zaitcev
Date: Wed, 06 Nov 2002 09:59:55 +0100
connect-debounce failed, port N disabled". [...]
Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it
is being read once. Don't ask me why, but thats what I find out.
What device is this?
This is DIVA MP3 player, but AFAIK this patch "solves" simmilar problem
with some card reader.
Post by Johannes Erdfelt
It sounds horribly broken if it clears STAT_CONNECTION when there is a
device connected.
Yes...
Post by Johannes Erdfelt
Post by Pete Zaitcev
All in all, the patch above is garbage, but the routine is
dubious on two counts and I would like the author to comment.
I don't say it's good solution, but it is the only one I could found
with my poor usb and kernel knowledge. And it works. The code that was
in kernels before 2.4.19pre2 worked also fine.
Post by Johannes Erdfelt
I'll see if I have the email in my archives. I forget who originally
wrote this patch.
Me, but here it was first time sent probably by Olaf Hering.

Michal Cihar



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Thomas Wahrenbruch
2002-11-07 16:09:44 UTC
Permalink
Hi all,

this is a driver for the KOBIL USB smartcard readers USB TWIN, KAAN Standard
Plus / SecOVID Reader Plus and KAAN Professional / B1 Professional.
(More information about these readers can be found on our homepage:
http://www.kobil.com )

The patch was created for kernel version 2.4.18.

Because this is my first Linux driver, I don't think that it's perfect...
(especially the kobil_write method...) But it worked very well on my machine.

Please report any bugs, suggestions to me.

Note that you need a modified CT-API, if you want to
use this driver. This CT-API isn't yet public available, but I can send it on
demand for testing purposes.

Also note, that this driver only supports the newest readers (converters).


Best regards,

Thomas
Alan Cox
2002-11-08 17:56:09 UTC
Permalink
Post by Thomas Wahrenbruch
Because this is my first Linux driver, I don't think that it's perfect...
(especially the kobil_write method...) But it worked very well on my machine.
Its a lot better than most "my first driver"'s
Post by Thomas Wahrenbruch
+
+ // allocate memory for transfer buffer
+ transfer_buffer = (unsigned char *) kmalloc(transfer_buffer_length * sizeof(char), GFP_KERNEL);
+ if (! transfer_buffer) {
+ return (-1);
+ } else {
+ memset(transfer_buffer, 0, transfer_buffer_length);
+ }
+
+ // allocate write_urb
+ if (!port->write_urb) {
+ dbg( __FUNCTION__ " Allocating port->write_urb");
+ port->write_urb = usb_alloc_urb(0);
+ if (!port->write_urb) {
+ dbg( __FUNCTION__ " usb_alloc_urb failed");
But you dont free the transfer buffer..
Post by Thomas Wahrenbruch
+ return (-1);
+ }
+ }
+
+ // allocate memory for write_urb transfer buffer
+ port->write_urb->transfer_buffer = (unsigned char *) kmalloc(write_urb_transfer_buffer_length * sizeof(char), GFP_KERNEL);
+ if (! port->write_urb->transfer_buffer) {
And here you don't free the write urb or main transfer buffer
Post by Thomas Wahrenbruch
+static int kobil_write (struct usb_serial_port *port, int from_user,
+ const unsigned char *buf, int count)
+{
+ int length = 0;
+ int result = 0;
+ int todo = 0;
+ struct kobil_private * priv;
+
+ if (count == 0) {
+ dbg( __FUNCTION__ " write request of 0 bytes");
+ return (0);
+ }
+
+ if (port->write_urb->status == -EINPROGRESS) {
+ dbg( __FUNCTION__ " Already writing");
+ return (0);
0 is end of file rather than writing. I'd expect the code here to be a
while loop with a sleep that exited when the urb became free or if you
said O_NDELAY
Post by Thomas Wahrenbruch
+ }
+
+ if (count > KOBIL_BUF_LENGTH) {
+ dbg( __FUNCTION__ " Error: write request bigger than buffer size");
+ return (0);
+ }
Much better to do
count = min(count, KOBIL_BUF_LENGTH);

then the write will be done piece by piece. If you error it 0 is EOF not
an error
Post by Thomas Wahrenbruch
+
+ down (&port->sem);
But by now your check for write_urb->status is not valid on an SMP box
or with pre-emption. Don't you need to take the semaphore first. Or
would it not be simpler to take the semaphore to use the URB and drop it
when the URB ceases to be in progress (down in an irq path is naughty up
is just fine)

That would remove the write status race, the delay handling and turn it
all into a single if(down_interruptible())

[Aside - there is an old saying in SMP OS design "lock data not code" -
what that really is trying to say is that locking is about resources and
control of the resource not about which bits of code require locks]
Post by Thomas Wahrenbruch
+
+ case TIOCMGET: // 0x5415
+ // allocate memory for transfer buffer
+ transfer_buffer = (unsigned char *) kmalloc(transfer_buffer_length * sizeof(char), GFP_KERNEL);
+ if (! transfer_buffer) {
+ return (-1);
You want to return a proper error code (I guess -ENOBUFS)
Post by Thomas Wahrenbruch
+ transfer_buffer = (unsigned char *) kmalloc(transfer_buffer_length * sizeof(char), GFP_KERNEL);
sizeof(char) is one.


Hope these comments help

Alan



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Thomas Wahrenbruch
2002-11-11 14:48:32 UTC
Permalink
Hi again,

I changed some return values in the ioctl() and open() method.
The allocated memory for the write_urb is now freed in the close() method.
(Thanks Alan Cox for pointing out these errors)

Discard the urb ststus check in the write function.

Please comment.

Best regards,

Thomas

Johannes Erdfelt
2002-11-07 17:23:35 UTC
Permalink
Post by Michal Cihar
Post by Johannes Erdfelt
Date: Wed, 06 Nov 2002 09:59:55 +0100
connect-debounce failed, port N disabled". [...]
Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it
is being read once. Don't ask me why, but thats what I find out.
What device is this?
This is DIVA MP3 player, but AFAIK this patch "solves" simmilar problem
with some card reader.
The device has a hub builtin?

JE



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Michal Cihar
2002-11-08 09:58:40 UTC
Permalink
Post by Johannes Erdfelt
Post by Michal Cihar
This is DIVA MP3 player, but AFAIK this patch "solves" simmilar problem
with some card reader.
The device has a hub builtin?
No

Michal Cihar



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Johannes Erdfelt
2002-11-08 16:27:34 UTC
Permalink
Post by Johannes Erdfelt
Post by Michal Cihar
This is DIVA MP3 player, but AFAIK this patch "solves" simmilar problem
with some card reader.
The device has a hub builtin?
No
But the hub is what is disconnecting the port. What hub are you using?

JE



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Michal Cihar
2002-11-08 16:36:10 UTC
Permalink
Post by Johannes Erdfelt
Post by Johannes Erdfelt
Post by Michal Cihar
This is DIVA MP3 player, but AFAIK this patch "solves" simmilar problem
with some card reader.
The device has a hub builtin?
No
But the hub is what is disconnecting the port. What hub are you using?
Some VIA, I don't remember those numbers, but the chipsets vere apollo 3
and kt 266. But AFAIK it is *not* hub dependant problem. I could test it
on SiS 7001 on monday...

Michal Cihar



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Martin Diehl
2002-11-08 23:08:07 UTC
Permalink
Post by Johannes Erdfelt
But the hub is what is disconnecting the port. What hub are you using?
Hm, IMHO the hub doesn't disconnect (how would it?) it merely reports the
device gets disconnected. Sure, it's minor nitpicking, but IMHO important
for understanding the problem. The point is the difference between a
device being plugged (i.e. appears physically attached to the port) and
the port _detecting_ the plugged device and thus reporting a connection.

Basically, device detection happens due to some resistor in the device
which pulls one of the data lines to a certain voltage level. This voltage
is derived from the bus power. Particularly when a buspowered device gets
attached the hub's downstream port has to drive considerable power to the
device while the electrical contacts are still bouncing (and the device
is probably just charging some large capacitors).

Therefore it's completely _expected behavior_ for the downstream port to
see the pullup resistor applyied and disappearing several times. Depending
when we ask the hub for the port state we'll see it either connected or
not. The whole point of the debounce delay is to ensure there was some
interval without any transient connection state change.

That's why it would be important to know whether the debounce-failure is
due to some error when reading the portstatus or if we are really leaving
there after 400ms without transient connection change but finally seeing
no connection there. And if a further increase of the delay helps.

Martin



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Johannes Erdfelt
2002-11-08 23:10:26 UTC
Permalink
Post by Martin Diehl
Post by Johannes Erdfelt
But the hub is what is disconnecting the port. What hub are you using?
Hm, IMHO the hub doesn't disconnect (how would it?) it merely reports the
device gets disconnected. Sure, it's minor nitpicking, but IMHO important
for understanding the problem. The point is the difference between a
device being plugged (i.e. appears physically attached to the port) and
the port _detecting_ the plugged device and thus reporting a connection.
Yes, important distinction.

However, the problem isn't that the device is getting disconnected, the
problem is the hub is saying that it got disconnected when it
apparentely isn't.
Post by Martin Diehl
Basically, device detection happens due to some resistor in the device
which pulls one of the data lines to a certain voltage level. This voltage
is derived from the bus power. Particularly when a buspowered device gets
attached the hub's downstream port has to drive considerable power to the
device while the electrical contacts are still bouncing (and the device
is probably just charging some large capacitors).
Therefore it's completely _expected behavior_ for the downstream port to
see the pullup resistor applyied and disappearing several times. Depending
when we ask the hub for the port state we'll see it either connected or
not. The whole point of the debounce delay is to ensure there was some
interval without any transient connection state change.
That's why it would be important to know whether the debounce-failure is
due to some error when reading the portstatus or if we are really leaving
there after 400ms without transient connection change but finally seeing
no connection there. And if a further increase of the delay helps.
The bug fix was for a hub that cleared the connect bit always after the
first read or something.

So either that means:

a) The hub is broken and clearing the bit when it shouldn't
b) The device really is disconnected per the spec
c) The debounce routine is broken

I don't know how it could work if b was the case.

I'll have to reread the spec to see if c is the case.

JE



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Martin Diehl
2002-11-07 00:44:36 UTC
Permalink
Post by Pete Zaitcev
Date: Wed, 06 Nov 2002 09:59:55 +0100
connect-debounce failed, port N disabled". [...]
Problems seems to be in clearing USB_PORT_STAT_CONNECTION flag after it
is being read once. Don't ask me why, but thats what I find out.
Following patch fixes this and IMHO should break anything else (it just
leaves debounce look if device seems to be connected).
--- linux-2.4.19-orig/drivers/usb/hub.c 2002-09-10 15:25:42.000000000 +0200
+++ linux/drivers/usb/hub.c 2002-09-11 11:12:04.000000000 +0200
@@ -655,6 +655,7 @@
}
else
delay_time += HUB_DEBOUNCE_STEP;
+ if (portstatus&USB_PORT_STAT_CONNECTION) return 0;
}
return ((portstatus&USB_PORT_STAT_CONNECTION)) ? 0 : 1;
}
I saw this patch floating around internally, and IIRC I was
able to ignore it until the user changed his cabling.
It defeats the purpose of the whole debouncing routine completely.
Right - we would just bail out there with any device just in case we see
some transient STAT_CONNECTION during the debounce delay, i.e. probably
way too early. OTOH the HUB_DEBOUNCE_STEP is already 100msec here which
should be sufficiently long for most devices to have the connect settled.
Post by Pete Zaitcev
Not that the said routine makes a lot of sense otherwise.
Interestingly, JE was up in arms against a simple 400ms delay
in this place, which always worked before. Now, someone came
with the debonce routine and lo and behold: it always delays
for the same 400ms -- the loop has no early break! So, why
don't we just restore the delay? It worked just fine in 2.2 kernel.
The 400ms delay was there, right - but only for low speed devices. Full
and highspeed devices had no delay at all which was a clear violation of
the specs. USB (see the comment on top of said function for the exact
reference) grants 100ms for the device and hub to agree about the connect
becoming stable.

We know there are devices in the field which don't conform to this
requirement. This is why the delay was increased to 400ms. It doesn't hurt
that much for conforming devices and should also work around most
nonconforming. As you've noticed this also ensures nothing would break if
it was working with the old 400ms for lowspeed delay, because the 400ms
are a lower bound now.
Post by Pete Zaitcev
The resetting of delay_time in case of change bit present
also looks bogus, because it has not high bound.
That's what the specs say: whenever we detect a transient disconnect
before the debounce timer expires, the timer must be restarted.

Right, we have no limit here. OTOH, if a devices doesn't manage to get a
stable connect state after some time, it will never be useable and, even
worse, likely cause considerable trouble to other devices on the bus. The
obvious solution in this situation is to disconnect the device. This would
both remove the offender and exit the debounce loop due to portstatus
becoming stable ~STAT_CONNECTION. IIRC we discussed this with Greg at that
time and he agreed with this approach.
Post by Pete Zaitcev
All in all, the patch above is garbage, but the routine is
dubious on two counts and I would like the author to comment.
Hereby done ;-)

As for the original poster's problem, the first thing I would try is to
increase the overall HUB_DEBOUNCE_TIMEOUT. Maybe this devices needs even
more than 400ms.

Furthermore, there are only two possibilities how the debounce routine
could exit with error return: either there was a real error when trying to
read the portstatus from the controlling hub or we had the debounce
timeout completed (i.e. the hub reported no connection change during the
last 400ms) but with the port being in disconnected state all that time.

Maybe we could improve what we do in both cases:

* If we fail to get the portstatus (which error?) it's probably worth to
ignore the error (increment some error counter with upper bound) and
simply assume there was a transient change, i.e. just go on debouncing
with the timer restarted.

* If we finish debouncing because the portstatus appears stable during the
last HUB_DEBOUNCE_TIMEOUT but the port appears disconnected at this point
we could just try another (longer) debouncing. This would also allow to
shorten the normal first try to 100ms as said by the spec and let the
second one catch all the slower devices - say additional 500ms or even
more. This would speed up the enumeration for conforming devices and add
more patience for nonconforming.

OTOH, if we just replace the whole debouncing by a fixed 400ms delay (for
all speeds!) we are risking to hide the symptoms: if a port doesn't report
a stable connection after 400ms and we ignore this (...because there was
enough waiting), we'll end up with enumeration likely running into trouble
now with SetAddress or GetDescriptor requests.

Martin



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Loading...