On Fri, Feb 15, 2002 at 09:56:47AM +0100, Martin Diehl wrote: > On Thu, 14 Feb 2002, Greg KH wrote: > > > > +static int usb_hub_port_status(struct usb_device *hub, int port, > > > + unsigned short *status, unsigned short *change) > > > > status and change should both be u16 types, right? > > Well, I've used the same type which was used by the callers. They all have > > unsigned short x = le16_to_cpu(y); > > So I stayed with this. Note, the portstatus we read from the hub, i.e. y > in this example, is u16. Right, le16_to_cpu() returns u16, but are there > any platforms where assigning an u16 to short unsigned would be a problem? > If so, there is a lot more to fix...
Ok, I fixed this in the patch I just sent to the list. > Agreed, would be more specific. OTOH I tried to let things look similar to > other helper routines there - which use -1/0/1 return values to indicate > error/success/disconnect. Dave had other issues with this. After his patch I'll see how it all interacts. > And finally, looping there without making progress is IMHO only a minor > issue. If your USB is that noisy (or the device completely broken) things > are unuseable anyway - so the livelocked khubd isn't a big loss. And all > the user has to do to solve the situation is to disconnect the bad guy! Good point. Since the machine still works (with the exception of USB) and removal of the device should solve the problem, I don't have a problem with this. > As we are at the delays: The specs say the debounce delay should be 100ms, > restarted on disconnect. For my USB_IrDA dongle I needed 150-200ms to make > it really happy. I was just informed by one of the Brainboxes Bluetooth > users, his dongle started working once he tried with 400ms. And there is > already this RH-bug workaraound with a 400ms delay for low-speed devices. > Shouldn't we just drop this low-speed delay and always use 400 or 500 ms > debounce delay? The delay does only matter during connect - hence 500ms > instead of 100 doesn't really hurt and I'd bet a lot of non-conforming but > existing devices would become useable this way. I don't have a problem with 400ms for all devices. It would make all of the Brainbox users happy (I know I hear from enough of them with problems...) Johannes, is this ok with you? thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
