Re: ttyACM and BREAK chars ?
On Wed, 2019-09-11 at 20:27 +0200, Oliver Neukum wrote: > Am Mittwoch, den 11.09.2019, 14:34 + schrieb Joakim Tjernlund: > > On Wed, 2019-09-11 at 16:22 +0200, Oliver Neukum wrote: > > > CAUTION: This email originated from outside of the organization. Do not > > > click links or open attachments unless you recognize the sender and know > > > the content is safe. > > > > > > > > > Am Mittwoch, den 11.09.2019, 12:39 + schrieb Joakim Tjernlund: > > > > Every now and then my ttyACM0 hangs up or sends a BREAK char to my > > > > device. > > > > I am trying to make ttyACM ignore incoming(over USB) and not emit > > > > any BREAK automatically using termios (IGN_BRK) but that does not make > > > > a difference. > > > > > > > > Is BREAK handling unimpl. in ttyACM ? > > > > > > acm_send_break() implements it. > > > > Yes, I se that funktion but I don't see how one can ignore received BREAKs > > If I set IGN_BRK on /dev/ttyACM0 I expect that every BREAK should just be > > ignored > > Handling breaks looks a bit broken on CDC-ACM. > Could you test the attached patch? > Sure, I can test it but from looking at the patch it seems like ACM already ignores BREAKs(hardcoded) and with your patch you actually start reporting them. My problem is sudden disconnects I cannot explain but I think they are connect to BREAKs I have seen these errors in dmesg though, not sure if they help the diagnose: [181780.167987] usb usb1-port6: disabled by hub (EMI?), re-enabling... [181780.168208] cdc_acm 1-6.3:1.1: acm_ctrl_irq - usb_submit_urb failed: -19 [181780.167996] usb 1-6: USB disconnect, device number 30 [181780.176548] usb 1-6-port2: attempt power cycle [181781.772847] usb 1-6.3: USB disconnect, device number 32 [181781.773134] cdc_acm 1-6.3:1.1: failed to set dtr/rts
Re: [PATCH v2] usb: host: xhci: wait CNR when doing xhci resume
On 6.9.2019 8.36, Rick Tseng wrote:
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
Thus we need to wait CNR bit to clear when xhci resmue as xhci init.
Signed-off-by: Rick Tseng
---
drivers/usb/host/xhci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 03d1e55..6c7102c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1108,6 +1108,15 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
hibernated = true;
if (!hibernated) {
+ /* Some xHC would lose power during suspend, so wait for
+* controller ready from resume as xHC init.
+*/
+ if (xhci_handshake(&xhci->op_regs->status,
+ STS_CNR, 0, 10 * 1000 * 1000)) {
+ xhci_warn(xhci, "WARN: xHC timeout for CNR clear\n");
+ spin_unlock_irq(&xhci->lock);
+ return -ETIMEDOUT;
+ }
xhci_handshake() can return -ENODEV in case controller is not reachable (still
in PCI D3).
Would be better to just show and return what xhci_handshake() returns.
I know there are places where the existing code doesn't do this, but it would be
better to add it for new code
ret = xhci_handshake(CNR bit clear)
if (ret) {
xhci_warn(xhci, "Controller not ready at resume %d\n", ret);
unlock()
return ret
}
-Mathias
[PATCH net,stable] cdc_ether: fix rndis support for Mediatek based smartphones
A Mediatek based smartphone owner reports problems with USB
tethering in Linux. The verbose USB listing shows a rndis_host
interface pair (e0/01/03 + 10/00/00), but the driver fails to
bind with
[ 355.960428] usb 1-4: bad CDC descriptors
The problem is a failsafe test intended to filter out ACM serial
functions using the same 02/02/ff class/subclass/protocol as RNDIS.
The serial functions are recognized by their non-zero bmCapabilities.
No RNDIS function with non-zero bmCapabilities were known at the time
this failsafe was added. But it turns out that some Wireless class
RNDIS functions are using the bmCapabilities field. These functions
are uniquely identified as RNDIS by their class/subclass/protocol, so
the failing test can safely be disabled. The same applies to the two
types of Misc class RNDIS functions.
Applying the failsafe to Communication class functions only retains
the original functionality, and fixes the problem for the Mediatek based
smartphone.
Tow examples of CDC functional descriptors with non-zero bmCapabilities
from Wireless class RNDIS functions are:
0e8d:000a Mediatek Crosscall Spider X5 3G Phone
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x0f
connection notifications
sends break
line coding and serial state
get/set/clear comm features
CDC Union:
bMasterInterface0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
and
19d2:1023 ZTE K4201-z
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC Union:
bMasterInterface0
bSlaveInterface 1
The Mediatek example is believed to apply to most smartphones with
Mediatek firmware. The ZTE example is most likely also part of a larger
family of devices/firmwares.
Suggested-by: Lars Melin
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ether.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 8458e88c18e9..32f53de5b1fe 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -206,7 +206,15 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct
usb_interface *intf)
goto bad_desc;
}
skip:
- if (rndis && header.usb_cdc_acm_descriptor &&
+ /* Communcation class functions with bmCapabilities are not
+* RNDIS. But some Wireless class RNDIS functions use
+* bmCapabilities for their own purpose. The failsafe is
+* therefore applied only to Communication class RNDIS
+* functions. The rndis test is redundant, but a cheap
+* optimization.
+*/
+ if (rndis && is_rndis(&intf->cur_altsetting->desc) &&
+ header.usb_cdc_acm_descriptor &&
header.usb_cdc_acm_descriptor->bmCapabilities) {
dev_dbg(&intf->dev,
"ACM capabilities %02x, not really RNDIS?\n",
--
2.20.1
Re: ttyACM and BREAK chars ?
Am Donnerstag, den 12.09.2019, 07:09 + schrieb Joakim Tjernlund: > On Wed, 2019-09-11 at 20:27 +0200, Oliver Neukum wrote: > > Am Mittwoch, den 11.09.2019, 14:34 + schrieb Joakim Tjernlund: > > > On Wed, 2019-09-11 at 16:22 +0200, Oliver Neukum wrote: > > > > CAUTION: This email originated from outside of the organization. Do not > > > > click links or open attachments unless you recognize the sender and > > > > know the content is safe. > > > > > > > > > > > > Am Mittwoch, den 11.09.2019, 12:39 + schrieb Joakim Tjernlund: > > > > > Every now and then my ttyACM0 hangs up or sends a BREAK char to my > > > > > device. > > > > > I am trying to make ttyACM ignore incoming(over USB) and not emit > > > > > any BREAK automatically using termios (IGN_BRK) but that does not > > > > > make a difference. > > > > > > > > > > Is BREAK handling unimpl. in ttyACM ? > > > > > > > > acm_send_break() implements it. > > > > > > Yes, I se that funktion but I don't see how one can ignore received BREAKs > > > If I set IGN_BRK on /dev/ttyACM0 I expect that every BREAK should just be > > > ignored > > > > Handling breaks looks a bit broken on CDC-ACM. > > Could you test the attached patch? > > > > Sure, I can test it but from looking at the patch it seems like ACM already > ignores > BREAKs(hardcoded) and with your patch you actually start reporting them. Well, what is not reported cannot really be ignored. AFAICT n_tty_receive_break() should solve the issue generically. > My problem is sudden disconnects I cannot explain but I think they are > connect to BREAKs > I have seen these errors in dmesg though, not sure if they help the diagnose: > [181780.167987] usb usb1-port6: disabled by hub (EMI?), re-enabling... The relevant fault happens likely just before that. > [181780.168208] cdc_acm 1-6.3:1.1: acm_ctrl_irq - usb_submit_urb failed: -19 > [181780.167996] usb 1-6: USB disconnect, device number 30 > [181780.176548] usb 1-6-port2: attempt power cycle > [181781.772847] usb 1-6.3: USB disconnect, device number 32 > [181781.773134] cdc_acm 1-6.3:1.1: failed to set dtr/rts Either your cabling is indeed crap, or something crashes your device. Regards Oliver
Re: [PATCH 2/3] usb: dwc3: qcom: Add interconnect support in dwc3 driver
Hi Chandana,
Thank you for the patch!
On 9/11/19 07:54, Chandana Kishori Chiluveru wrote:
> Add interconnect support in dwc3-qcom driver to vote for bus
> bandwidth.
>
> This requires for two different paths - from USB master to
> DDR slave. The other is from APPS master to USB slave.
>
> Signed-off-by: Chandana Kishori Chiluveru
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 147
> ++-
> 1 file changed, 145 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 184df4d..4b8c2ae 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -38,6 +39,9 @@
> #define PWR_EVNT_LPM_IN_L2_MASK BIT(4)
> #define PWR_EVNT_LPM_OUT_L2_MASK BIT(5)
>
> +#define USB_DDR "usb-ddr"
> +#define APPS_USB "apps-usb"
What is the benefit of adding these defines? Please remove them.
> struct dwc3_qcom {
> struct device *dev;
> void __iomem*qscratch_base;
> @@ -59,8 +63,13 @@ struct dwc3_qcom {
> enum usb_dr_modemode;
> boolis_suspended;
> boolpm_suspended;
> + struct icc_path *usb_ddr_icc_path;
> + struct icc_path *apps_usb_icc_path;
Nit: Maybe try to make the indentation style consistent with the existing code?
> };
>
> +static int usb_interconnect_enable(struct dwc3_qcom *qcom);
> +static int usb_interconnect_disable(struct dwc3_qcom *qcom);
> +
> static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
> {
> u32 reg;
> @@ -222,7 +231,7 @@ static void dwc3_qcom_enable_interrupts(struct dwc3_qcom
> *qcom)
> static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
> {
> u32 val;
> - int i;
> + int i, ret;
>
> if (qcom->is_suspended)
> return 0;
> @@ -234,6 +243,11 @@ static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
> for (i = qcom->num_clocks - 1; i >= 0; i--)
> clk_disable_unprepare(qcom->clks[i]);
>
> + /* Remove bus voting */
> + ret = usb_interconnect_disable(qcom);
> + if (ret)
> + dev_err(qcom->dev, "bus bw voting failed %d\n", ret);
> +
> qcom->is_suspended = true;
> dwc3_qcom_enable_interrupts(qcom);
>
> @@ -259,6 +273,11 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
> }
> }
>
> + /* Add bus voting */
> + ret = usb_interconnect_enable(qcom);
> + if (ret)
> + dev_err(qcom->dev, "bus bw voting failed %d\n", ret);
> +
> /* Clear existing events from PHY related to L2 in/out */
> dwc3_qcom_setbits(qcom->qscratch_base, PWR_EVNT_IRQ_STAT_REG,
> PWR_EVNT_LPM_IN_L2_MASK | PWR_EVNT_LPM_OUT_L2_MASK);
> @@ -409,6 +428,116 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom,
> int count)
> return 0;
> }
>
> +/* Interconnect path bandwidths in KBps */
> +#define USB_MEMORY_AVG_HS_BW 24
> +#define USB_MEMORY_PEAK_HS_BW 70
> +#define USB_MEMORY_AVG_SS_BW 100
> +#define USB_MEMORY_PEAK_SS_BW 250
> +#define APPS_USB_AVG_BW 0
> +#define APPS_USB_PEAK_BW 4
I would suggest to wrap the values with kBps_to_icc() or MBps_to_icc() macro.
> +
> +/**
> + * usb_interconnect_init() - Request to get interconnect path handle
> + * @qcom:Pointer to the concerned usb core.
> + *
> + */
> +static int usb_interconnect_init(struct dwc3_qcom *qcom)
> +{
> + struct device *dev = qcom->dev;
> +
> + qcom->usb_ddr_icc_path = of_icc_get(dev, USB_DDR);
> + if (IS_ERR(qcom->usb_ddr_icc_path)) {
> + dev_err(dev, "Error: (%ld) failed getting %s path\n",
> + PTR_ERR(qcom->usb_ddr_icc_path), USB_DDR);
> + return PTR_ERR(qcom->usb_ddr_icc_path);
> + }
> +
> + qcom->apps_usb_icc_path = of_icc_get(dev, APPS_USB);
> + if (IS_ERR(qcom->apps_usb_icc_path)) {
> + dev_err(dev, "Error: (%ld) failed getting %s path\n",
> + PTR_ERR(qcom->apps_usb_icc_path), APPS_USB);
> + return PTR_ERR(qcom->usb_ddr_icc_path);
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * geni_interconnect_exit() - Request to release interconnect path handle
> + * @qcom:Pointer to the concerned usb core.
> + *
> + * This function is used to release interconnect path handle.
> + */
> +static void usb_interconnect_exit(struct dwc3_qcom *qcom)
> +{
> + icc_put(qcom->usb_ddr_icc_path);
> + icc_put(qcom->apps_usb_icc_path);
> +}
> +
> +/* Currently we only use bandwidth level, so just "enable" interconnects */
> +static int usb_interconnect_enable(struct dwc3_qcom *qcom)
> +{
> + struct dwc3 *dwc;
> + int ret;
> +
> + dwc = platform_get_drvdata(qcom->dwc3);
> + if (!dwc) {
> + dev_er
RE: EHSET with hub and PCIe root hub
On Wed, 11 Sep 2019, Allen Blaylock wrote: > So I do see the PORT_TEST SetFeature Request and Response when I use tcpdump > to > make a capture using usbmon. Unfortunately I am not as familiar with the raw > usbmon output or some of the diagnostics output by usbmon so I may be missing > something. Here is a capture from the sysfs usbmon file: > > a52efe00 268933702 C Ii:002:01 0 1 = 08 > a52efe00 268933736 S Ii:002:01 -115 1 < > a546b700 268934005 S Ci:002:00 s a3 00 0003 0004 4 < > a546b700 268934303 C Ci:002:00 0 4 = 01010100 > a546b700 268934327 S Co:002:00 s 23 01 0010 0003 0 > a546b700 268934384 C Co:002:00 0 0 > a546b700 268934438 S Ci:002:00 s a3 00 0003 0004 4 < > a546b700 268934520 C Ci:002:00 0 4 = 0101 > a546b700 268980085 S Ci:002:00 s a3 00 0003 0004 4 < > a546b700 268980332 C Ci:002:00 0 4 = 0101 > a546b700 269030091 S Ci:002:00 s a3 00 0003 0004 4 < > a546b700 269030333 C Ci:002:00 0 4 = 0101 > a546b700 269080082 S Ci:002:00 s a3 00 0003 0004 4 < > a546b700 269080335 C Ci:002:00 0 4 = 0101 > a546b280 269130094 S Ci:002:00 s a3 00 0003 0004 4 < > a546b280 269130339 C Ci:002:00 0 4 = 0101 > a546b280 269130376 S Co:002:00 s 23 03 0004 0003 0 > a546b280 269130577 C Co:002:00 0 0 > a546be00 269160091 S Ci:002:00 s a3 00 0003 0004 4 < > a546be00 269160344 C Ci:002:00 0 4 = 03051000 > a546be00 269160361 S Co:002:00 s 23 01 0014 0003 0 > a546be00 269160416 C Co:002:00 0 0 > a546be00 269230118 S Ci:000:00 s 80 06 0100 0040 64 < > a546be00 269230341 C Ci:000:00 0 18 = 12010002 0040 0a1a0401 00010102 0301 > a546be00 269230358 S Co:002:00 s 23 03 0004 0003 0 > a546be00 269230425 C Co:002:00 0 0 > a546be00 269260104 S Ci:002:00 s a3 00 0003 0004 4 < > a546be00 269260354 C Ci:002:00 0 4 = 03051000 > a546be00 269260374 S Co:002:00 s 23 01 0014 0003 0 > a546be00 269260430 C Co:002:00 0 0 > a546be00 269330097 S Co:000:00 s 00 05 0004 0 > a546be00 269330372 C Co:000:00 0 0 > a546b700 269380050 S Ci:004:00 s 80 06 0100 0012 18 < > a546b700 269380327 C Ci:004:00 0 18 = 12010002 0040 0a1a0401 00010102 0301 > a546b700 269380360 S Ci:004:00 s 80 06 0200 0009 9 < > a546b700 269380453 C Ci:004:00 0 9 = 09022e00 01010080 32 > a546b700 269380468 S Ci:004:00 s 80 06 0200 002e 46 < > a546b700 269380574 C Ci:004:00 0 46 = 09022e00 01010080 32090400 0004ff00 > 0705 02020002 00070504 02000200 > a546b700 269380608 S Ci:004:00 s 80 06 0300 00ff 255 < > a546b700 269380701 C Ci:004:00 0 4 = 04030904 > a546b700 269380717 S Ci:004:00 s 80 06 0302 0409 00ff 255 < > a546b700 269380824 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 > 53005400 20005400 45005300 54004500 > a546b700 269380845 S Ci:004:00 s 80 06 0301 0409 00ff 255 < > a546b700 269380949 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 > 53005400 20005400 45005300 54004500 > a546b700 269380968 S Ci:004:00 s 80 06 0303 0409 00ff 255 < > a546b700 269381074 C Ci:004:00 0 10 = 0a034900 4f005600 3300 > a546b280 269381564 S Co:004:00 s 00 09 0001 0 > a546b280 269381704 C Co:004:00 0 0 > a560a000 269407637 S Co:002:00 s 23 03 0015 0403 0 > a560a000 269407869 C Co:002:00 -32 0 > > I was unable to make sense of it with the help of the usbmon.txt documentation > and will need some more time using wireshark and the output of tcpdump to get > familiar with decoding the raw usbmon output. Most of the usbmon output shows that a device was attached to port 3 of hub 2 and enumerated as usual over the course of about half a second. The very last two lines show the computer sending the hub a Set-Port-Test request on port 3 for test mode 4, which is Test Packet. The hub's response is a STALL, indicating that the hub doesn't understand or doesn't implement this request. Alan Stern
RE: EHSET with hub and PCIe root hub
On Thu, 12 Sep 2019, Alan Stern wrote: > On Wed, 11 Sep 2019, Allen Blaylock wrote: > > > So I do see the PORT_TEST SetFeature Request and Response when I use > > tcpdump to > > make a capture using usbmon. Unfortunately I am not as familiar with the raw > > usbmon output or some of the diagnostics output by usbmon so I may be > > missing > > something. Here is a capture from the sysfs usbmon file: > > > > a52efe00 268933702 C Ii:002:01 0 1 = 08 > > a52efe00 268933736 S Ii:002:01 -115 1 < > > a546b700 268934005 S Ci:002:00 s a3 00 0003 0004 4 < > > a546b700 268934303 C Ci:002:00 0 4 = 01010100 > > a546b700 268934327 S Co:002:00 s 23 01 0010 0003 0 > > a546b700 268934384 C Co:002:00 0 0 > > a546b700 268934438 S Ci:002:00 s a3 00 0003 0004 4 < > > a546b700 268934520 C Ci:002:00 0 4 = 0101 > > a546b700 268980085 S Ci:002:00 s a3 00 0003 0004 4 < > > a546b700 268980332 C Ci:002:00 0 4 = 0101 > > a546b700 269030091 S Ci:002:00 s a3 00 0003 0004 4 < > > a546b700 269030333 C Ci:002:00 0 4 = 0101 > > a546b700 269080082 S Ci:002:00 s a3 00 0003 0004 4 < > > a546b700 269080335 C Ci:002:00 0 4 = 0101 > > a546b280 269130094 S Ci:002:00 s a3 00 0003 0004 4 < > > a546b280 269130339 C Ci:002:00 0 4 = 0101 > > a546b280 269130376 S Co:002:00 s 23 03 0004 0003 0 > > a546b280 269130577 C Co:002:00 0 0 > > a546be00 269160091 S Ci:002:00 s a3 00 0003 0004 4 < > > a546be00 269160344 C Ci:002:00 0 4 = 03051000 > > a546be00 269160361 S Co:002:00 s 23 01 0014 0003 0 > > a546be00 269160416 C Co:002:00 0 0 > > a546be00 269230118 S Ci:000:00 s 80 06 0100 0040 64 < > > a546be00 269230341 C Ci:000:00 0 18 = 12010002 0040 0a1a0401 00010102 > > 0301 > > a546be00 269230358 S Co:002:00 s 23 03 0004 0003 0 > > a546be00 269230425 C Co:002:00 0 0 > > a546be00 269260104 S Ci:002:00 s a3 00 0003 0004 4 < > > a546be00 269260354 C Ci:002:00 0 4 = 03051000 > > a546be00 269260374 S Co:002:00 s 23 01 0014 0003 0 > > a546be00 269260430 C Co:002:00 0 0 > > a546be00 269330097 S Co:000:00 s 00 05 0004 0 > > a546be00 269330372 C Co:000:00 0 0 > > a546b700 269380050 S Ci:004:00 s 80 06 0100 0012 18 < > > a546b700 269380327 C Ci:004:00 0 18 = 12010002 0040 0a1a0401 00010102 > > 0301 > > a546b700 269380360 S Ci:004:00 s 80 06 0200 0009 9 < > > a546b700 269380453 C Ci:004:00 0 9 = 09022e00 01010080 32 > > a546b700 269380468 S Ci:004:00 s 80 06 0200 002e 46 < > > a546b700 269380574 C Ci:004:00 0 46 = 09022e00 01010080 32090400 0004ff00 > > 0705 02020002 00070504 02000200 > > a546b700 269380608 S Ci:004:00 s 80 06 0300 00ff 255 < > > a546b700 269380701 C Ci:004:00 0 4 = 04030904 > > a546b700 269380717 S Ci:004:00 s 80 06 0302 0409 00ff 255 < > > a546b700 269380824 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 > > 53005400 20005400 45005300 54004500 > > a546b700 269380845 S Ci:004:00 s 80 06 0301 0409 00ff 255 < > > a546b700 269380949 C Ci:004:00 0 34 = 22035500 53004200 20004500 48004f00 > > 53005400 20005400 45005300 54004500 > > a546b700 269380968 S Ci:004:00 s 80 06 0303 0409 00ff 255 < > > a546b700 269381074 C Ci:004:00 0 10 = 0a034900 4f005600 3300 > > a546b280 269381564 S Co:004:00 s 00 09 0001 0 > > a546b280 269381704 C Co:004:00 0 0 > > a560a000 269407637 S Co:002:00 s 23 03 0015 0403 0 > > a560a000 269407869 C Co:002:00 -32 0 > > > > I was unable to make sense of it with the help of the usbmon.txt > > documentation > > and will need some more time using wireshark and the output of tcpdump to > > get > > familiar with decoding the raw usbmon output. > > Most of the usbmon output shows that a device was attached to port 3 of > hub 2 and enumerated as usual over the course of about half a second. > > The very last two lines show the computer sending the hub a > Set-Port-Test request on port 3 for test mode 4, which is Test Packet. > The hub's response is a STALL, indicating that the hub doesn't > understand or doesn't implement this request. I should add that the USB 2.0 spec includes the following text (from section 11.24.2.13): Test mode of a downstream facing port can only be used in a well defined sequence of hub states. This sequence is defined as follows: 1) All enabled downstream facing ports of the hub containing the port to be tested must be (selectively) suspended via the SetPortFeature(PORT_SUSPEND) request. Each downstream facing port of the hub must be in the disabled, disconnected, or suspended state (see Figure 11-9). So you can see the hub probably failed the request because a non-suspended device was connected to port 3. (And who knows what was attached to the other ports -- the usbmon trace doesn't say.) Alan Stern
RE: EHSET with hub and PCIe root hub
Thank you Alan, I am still working through understanding the usbmon and this is a helpful hint. I will contact the device manufacturer and see if there is some alternative method they recommend for testing. >Most of the usbmon output shows that a device was attached to port 3 of hub 2 >and enumerated as usual over the course of about half a second. > >The very last two lines show the computer sending the hub a Set-Port-Test >request on port 3 for test mode 4, which is Test Packet. >The hub's response is a STALL, indicating that the hub doesn't understand or >doesn't implement this request. > >Alan Stern >
[PATCH] xhci: Check all endpoints for LPM timeout
If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep
checking further endpoints, as there might be periodic endpoints later
that return USB3_LPM_DISABLED due to shorter service intervals.
Without this, the code can set too high a maximum-exit-latency and
prevent the use of multiple USB3 cameras that should be able to work.
Signed-off-by: Jan Schmidt
Tested-by: Philipp Zabel
---
drivers/usb/host/xhci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 03d1e552769b..1986b88661fc 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4673,12 +4673,12 @@ static int xhci_update_timeout_for_endpoint(struct
xhci_hcd *xhci,
alt_timeout = xhci_call_host_update_timeout_for_endpoint(xhci, udev,
desc, state, timeout);
- /* If we found we can't enable hub-initiated LPM, or
+ /* If we found we can't enable hub-initiated LPM, and
* the U1 or U2 exit latency was too high to allow
-* device-initiated LPM as well, just stop searching.
+* device-initiated LPM as well, then we will disable LPM
+* for this device, so stop searching any further.
*/
- if (alt_timeout == USB3_LPM_DISABLED ||
- alt_timeout == USB3_LPM_DEVICE_INITIATED) {
+ if (alt_timeout == USB3_LPM_DISABLED) {
*timeout = alt_timeout;
return -E2BIG;
}
--
2.21.0
Dear Friend,
Dear Friend, Hello how are you doing? Please, I am still waiting for your reply on the message I sent you yesterday Thanks Mrs Jessica Becker.
Re: [PATCH] xhci: Check all endpoints for LPM timeout
On Fri, 2019-09-13 at 00:49 +1000, Jan Schmidt wrote: > If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep > checking further endpoints, as there might be periodic endpoints later > that return USB3_LPM_DISABLED due to shorter service intervals. > > Without this, the code can set too high a maximum-exit-latency and > prevent the use of multiple USB3 cameras that should be able to work. > > Signed-off-by: Jan Schmidt > Tested-by: Philipp Zabel This fixes the capture from multiple Oculus Sensors, as described in the "Not enough bandwidth with Magewell XI100DUSB-HDMI" thread: https://lore.kernel.org/linux-usb/ca+gwmce-h9lpcv1hhfecrz_2w9meqlojy42dcjvpxteawsu...@mail.gmail.com/ regards Philipp
RE: EHSET with hub and PCIe root hub
>I should add that the USB 2.0 spec includes the following text (from section
>11.24.2.13):
>
>Test mode of a downstream facing port can only be used in
>a well defined sequence of hub states. This sequence is
>defined as follows:
>
>1) All enabled downstream facing ports of the hub containing
>the port to be tested must be (selectively) suspended via
>the SetPortFeature(PORT_SUSPEND) request. Each downstream
>facing port of the hub must be in the disabled,
>disconnected, or suspended state (see Figure 11-9).
>
>So you can see the hub probably failed the request because a non-suspended
>device was connected to port 3. (And who knows what was attached to the other
>ports -- the usbmon trace doesn't say.)
>
>Alan Stern
This was very helpful.
I was able to get the USB3503 to generate test packets by adding a
SetPortFeature(PORT_SUSPEND) request to suspend the port before setting the
PORT_TEST feature. Is there a way to tell that a device is a hub but not a root
hub so ports on root hub ports aren't suspended prior to calling
SetPortFeature(PORT_TEST)?
I tried to use hub_udev->maxchild to determine if something was a hub but this
appears misguided since root hubs can have multiple children, nothing else in
the usb_device structure jumped out as being directly related to a hub.
--- a/drivers/usb/misc/ehset.c
+++ b/drivers/usb/misc/ehset.c
@@ -62,6 +62,16 @@ static int ehset_probe(struct usb_interface *intf,
NULL, 0, 1000);
break;
case TEST_PACKET_PID:
+ if(hub_udev->maxchild)
+ {
+ ret = usb_control_msg(hub_udev,
usb_sndctrlpipe(hub_udev, 0),
+ USB_REQ_SET_FEATURE,
USB_RT_PORT,
+ USB_PORT_FEAT_SUSPEND, portnum,
+ NULL, 0, 1000);
+ if (ret < 0)
+ break;
+
+ }
ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
USB_REQ_SET_FEATURE, USB_RT_PORT,
USB_PORT_FEAT_TEST,
RE: EHSET with hub and PCIe root hub
On Thu, 12 Sep 2019, Allen Blaylock wrote: > >I should add that the USB 2.0 spec includes the following text (from section > >11.24.2.13): > > > >Test mode of a downstream facing port can only be used in > >a well defined sequence of hub states. This sequence is > >defined as follows: > > > >1) All enabled downstream facing ports of the hub containing > >the port to be tested must be (selectively) suspended via > >the SetPortFeature(PORT_SUSPEND) request. Each downstream > >facing port of the hub must be in the disabled, > >disconnected, or suspended state (see Figure 11-9). > > > >So you can see the hub probably failed the request because a non-suspended > >device was connected to port 3. (And who knows what was attached to the > >other ports -- the usbmon trace doesn't say.) > > > >Alan Stern > > This was very helpful. > > I was able to get the USB3503 to generate test packets by adding a > SetPortFeature(PORT_SUSPEND) request to suspend the port before setting the > PORT_TEST feature. Is there a way to tell that a device is a hub but not a > root hub so ports on root hub ports aren't suspended prior to calling > SetPortFeature(PORT_TEST)? > > I tried to use hub_udev->maxchild to determine if something was a hub but > this appears misguided since root hubs can have multiple children, nothing > else in the usb_device structure jumped out as being directly related to a > hub. That's a perfectly good way to see that the device really is a hub. In addition, if hub_udev->parent == NULL then hub_udev is a root hub, otherwise it isn't. Alan Stern
