Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Tue, 17 Feb 2015, Felipe Balbi wrote: On Tue, Feb 17, 2015 at 09:55:21AM -0500, Alan Stern wrote: On Mon, 16 Feb 2015, Felipe Balbi wrote: Electrical tests for resume signaling. It failed with a specific hub, however :-) But it's easy to note with dwc3/musb and a USB sniffer. Sometimes resume signalling is cut before 20ms because we had msleep(20) :-) Maybe that should be reported to the architecture maintainers. I'm not certain, but I'm pretty sure that msleep(20) should _never_ sleep for less than 20 ms. doesn't lpj calibration play a role here ? Yeah, I don't know. That's why it would be a good idea to ask the architecture maintainers. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Tue, Feb 17, 2015 at 09:55:21AM -0500, Alan Stern wrote: On Mon, 16 Feb 2015, Felipe Balbi wrote: Electrical tests for resume signaling. It failed with a specific hub, however :-) But it's easy to note with dwc3/musb and a USB sniffer. Sometimes resume signalling is cut before 20ms because we had msleep(20) :-) Maybe that should be reported to the architecture maintainers. I'm not certain, but I'm pretty sure that msleep(20) should _never_ sleep for less than 20 ms. doesn't lpj calibration play a role here ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Mon, 16 Feb 2015, Felipe Balbi wrote: Electrical tests for resume signaling. It failed with a specific hub, however :-) But it's easy to note with dwc3/musb and a USB sniffer. Sometimes resume signalling is cut before 20ms because we had msleep(20) :-) Maybe that should be reported to the architecture maintainers. I'm not certain, but I'm pretty sure that msleep(20) should _never_ sleep for less than 20 ms. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
Hi, On Sun, Feb 15, 2015 at 09:06:15AM +0800, Peter Chen wrote: On Fri, Feb 13, 2015 at 07:42:22PM -0600, Felipe Balbi wrote: On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Is this good enough ? commit 3154122f81c8411b432d5f44a196302243d5af3d Author: Felipe Balbi ba...@ti.com Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/include/linux/usb.h b/include/linux/usb.h index 7ee1b5c3b4cb..447fe29b55b4 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +/* + * USB Resume Timer: Every Host controller driver should drive the resume + * signalling on the bus for the amount of time defined by this macro. + * + * That way we will have a 'stable' behavior among all HCDs supported by Linux. + * + * Note that the USB Specification states we should drive resume for *at least* + * 20 ms, but it doesn't give an upper bound. This creates two possible + * situations which we want to avoid: + * + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes + * us to fail USB Electrical Tests, thus failing Certification + * + * (b) Some (many) devices actually need more than 20 ms of resume signalling, + * and while we can argue that's against the USB Specification, we don't have + * control over which devices a certification laboratory will be using for + * certification. If CertLab uses a device which was tested against Windows and + * that happens to have
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 10:09:37PM -0600, Felipe Balbi wrote: Greg, are you fine with v3.10+ ? I don't think it's worth backporting to anything older than that because it's unlikely that there's current development going on with those or products shipped with them have no migration path to newer kernels (from the manufacturer, that is). 3.10+ is fine, that's all I care about :) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 07:42:22PM -0600, Felipe Balbi wrote: On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Is this good enough ? commit 3154122f81c8411b432d5f44a196302243d5af3d Author: Felipe Balbi ba...@ti.com Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/include/linux/usb.h b/include/linux/usb.h index 7ee1b5c3b4cb..447fe29b55b4 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* + * USB Resume Timer: Every Host controller driver should drive the resume + * signalling on the bus for the amount of time defined by this macro. + * + * That way we will have a 'stable' behavior among all HCDs supported by Linux. + * + * Note that the USB Specification states we should drive resume for *at least* + * 20 ms, but it doesn't give an upper bound. This creates two possible + * situations which we want to avoid: + * + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes + * us to fail USB Electrical Tests, thus failing Certification + * + * (b) Some (many) devices actually need more than 20 ms of resume signalling, + * and while we can argue that's against the USB Specification, we don't have + * control over which devices a certification laboratory will be using for + * certification. If CertLab uses a device which was tested against Windows and + * that happens to have relaxed resume signalling rules, we might fall into + * situations where we fail interoperability and electrical tests. + * + * In order to avoid both conditions, we're using a 40 ms resume
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 04:22:12PM -0500, Alan Stern wrote: On Fri, 13 Feb 2015, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + How about adding a comment explaining briefly why this value is larger than 20 ms? will do, but wait for other comments before resending. -- balbi signature.asc Description: Digital signature
[PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + /** * struct usb_interface_cache - long-term representation of a device interface * @num_altsetting: number of altsettings defined. -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, 13 Feb 2015, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + How about adding a comment explaining briefly why this value is larger than 20 ms? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- btw, the electrical test bug was reproduced with both MUSB and XHCI (AM335x BeagleBone Black and AM437x Starter Kit) -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 09:07:40PM -0600, Bin Liu wrote: Greg, On Fri, Feb 13, 2015 at 8:41 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Feb 13, 2015 at 07:42:22PM -0600, Felipe Balbi wrote: On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Is this good enough ? commit 3154122f81c8411b432d5f44a196302243d5af3d Author: Felipe Balbi ba...@ti.com Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/include/linux/usb.h b/include/linux/usb.h index 7ee1b5c3b4cb..447fe29b55b4 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* + * USB Resume Timer: Every Host controller driver should drive the resume + * signalling on the bus for the amount of time defined by this macro. + * + * That way we will have a 'stable' behavior among all HCDs supported by Linux. + * + * Note that the USB Specification states we should drive resume for *at least* + * 20 ms, but it doesn't give an upper bound. This creates two possible + * situations which we want to avoid: + * + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes + * us to fail USB Electrical Tests, thus failing Certification + * + * (b) Some (many) devices actually need more than 20 ms of resume signalling, + * and while we can argue that's against the USB Specification, we don't have + * control over which devices a certification laboratory will be using for + * certification. If CertLab uses a device which was tested against Windows and + *
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Is this good enough ? commit 3154122f81c8411b432d5f44a196302243d5af3d Author: Felipe Balbi ba...@ti.com Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/include/linux/usb.h b/include/linux/usb.h index 7ee1b5c3b4cb..447fe29b55b4 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +/* + * USB Resume Timer: Every Host controller driver should drive the resume + * signalling on the bus for the amount of time defined by this macro. + * + * That way we will have a 'stable' behavior among all HCDs supported by Linux. + * + * Note that the USB Specification states we should drive resume for *at least* + * 20 ms, but it doesn't give an upper bound. This creates two possible + * situations which we want to avoid: + * + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes + * us to fail USB Electrical Tests, thus failing Certification + * + * (b) Some (many) devices actually need more than 20 ms of resume signalling, + * and while we can argue that's against the USB Specification, we don't have + * control over which devices a certification laboratory will be using for + * certification. If CertLab uses a device which was tested against Windows and + * that happens to have relaxed resume signalling rules, we might fall into + * situations where we fail interoperability and electrical tests. + * + * In order to avoid both conditions, we're using a 40 ms resume timeout, which + * should cope with both LPJ calibration errors and devices not following every + * detail of the USB Specification. + */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + /** * struct
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
On Fri, Feb 13, 2015 at 07:42:22PM -0600, Felipe Balbi wrote: On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Is this good enough ? commit 3154122f81c8411b432d5f44a196302243d5af3d Author: Felipe Balbi ba...@ti.com Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/include/linux/usb.h b/include/linux/usb.h index 7ee1b5c3b4cb..447fe29b55b4 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* + * USB Resume Timer: Every Host controller driver should drive the resume + * signalling on the bus for the amount of time defined by this macro. + * + * That way we will have a 'stable' behavior among all HCDs supported by Linux. + * + * Note that the USB Specification states we should drive resume for *at least* + * 20 ms, but it doesn't give an upper bound. This creates two possible + * situations which we want to avoid: + * + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes + * us to fail USB Electrical Tests, thus failing Certification + * + * (b) Some (many) devices actually need more than 20 ms of resume signalling, + * and while we can argue that's against the USB Specification, we don't have + * control over which devices a certification laboratory will be using for + * certification. If CertLab uses a device which was tested against Windows and + * that happens to have relaxed resume signalling rules, we might fall into + * situations where we fail interoperability and electrical tests. + * + * In order to avoid both conditions, we're using a 40 ms resume
Re: [PATCH 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
Greg, On Fri, Feb 13, 2015 at 8:41 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Feb 13, 2015 at 07:42:22PM -0600, Felipe Balbi wrote: On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com --- include/linux/usb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/usb.h b/include/linux/usb.h index f89c24a03bd9..1dd89f0db344 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* USB Resume Timer */ +#define USB_RESUME_TIMEOUT 40 /* ms */ + If you add the comment as Alan suggested, feel free to add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Is this good enough ? commit 3154122f81c8411b432d5f44a196302243d5af3d Author: Felipe Balbi ba...@ti.com Date: Fri Feb 13 14:34:25 2015 -0600 usb: define a generic USB_RESUME_TIMEOUT macro Every USB Host controller should use this new macro to define for how long resume signalling should be driven on the bus. Currently, almost every single USB controller is using a 20ms timeout for resume signalling. That's problematic for two reasons: a) sometimes that 20ms timer expires a little before 20ms, which makes us fail certification b) some (many) devices actually need more than 20ms resume signalling. Sure, in case of (b) we can state that the device is against the USB spec, but the fact is that we have no control over which device the certification lab will use. We also have no control over which host they will use. Most likely they'll be using a Windows PC which, again, we have no control over how that USB stack is written and how long resume signalling they are using. At the end of the day, we must make sure Linux passes electrical compliance when working as Host or as Device and currently we don't pass compliance as host because we're driving resume signallig for exactly 20ms and that confuses certification test setup resulting in Certification failure. Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/include/linux/usb.h b/include/linux/usb.h index 7ee1b5c3b4cb..447fe29b55b4 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); #define USB_MAXINTERFACES32 #define USB_MAXIADS (USB_MAXINTERFACES/2) +/* + * USB Resume Timer: Every Host controller driver should drive the resume + * signalling on the bus for the amount of time defined by this macro. + * + * That way we will have a 'stable' behavior among all HCDs supported by Linux. + * + * Note that the USB Specification states we should drive resume for *at least* + * 20 ms, but it doesn't give an upper bound. This creates two possible + * situations which we want to avoid: + * + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes + * us to fail USB Electrical Tests, thus failing Certification + * + * (b) Some (many) devices actually need more than 20 ms of resume signalling, + * and while we can argue that's against the USB Specification, we don't have + * control over which devices a certification laboratory will be using for + * certification. If CertLab uses a device which was tested against Windows and + * that happens to have relaxed resume signalling rules, we might fall into + * situations where we fail interoperability and electrical tests. + * + * In order to avoid both conditions,
