[PATCH 1/1] usb: xhci: handle Config Error Change (CEC) in xhci driver
Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends when the root port
fails to configure its link partner, e.g. the port fails to exchange
port capabilities information using Port Capability LMPs.
Then the Port Status Change Events will be blocked until all status
change bits(CEC is one of the change bits) are cleared('0') (refer to
xHCI spec 4.19.2). Otherwise, the port status change event for this
root port will not be generated anymore, then root port would look
like dead for user and can't be recovered until a Host Controller
Reset(HCRST).
This patch is to check CEC bit in PORTSC in xhci_get_port_status()
and set a Config Error in the return status if CEC is set. This will
cause a ClearPortFeature request, where CEC bit is cleared in
xhci_clear_port_change_bit().
[Mathias Nyman contributed the idea. The commit log is based on patch
posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2]
Signed-off-by: Lu Baolu
Cc: stable # v3.2+
---
drivers/usb/host/xhci-hub.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..0827d7c 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -387,6 +387,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
status = PORT_PLC;
port_change_bit = "link state";
break;
+ case USB_PORT_FEAT_C_PORT_CONFIG_ERROR:
+ status = PORT_CEC;
+ port_change_bit = "config error";
+ break;
default:
/* Should never happen */
return;
@@ -588,6 +592,8 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd,
status |= USB_PORT_STAT_C_LINK_STATE << 16;
if ((raw_port_status & PORT_WRC))
status |= USB_PORT_STAT_C_BH_RESET << 16;
+ if ((raw_port_status & PORT_CEC))
+ status |= USB_PORT_STAT_C_CONFIG_ERROR << 16;
}
if (hcd->speed != HCD_USB3) {
@@ -1005,6 +1011,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
case USB_PORT_FEAT_C_OVER_CURRENT:
case USB_PORT_FEAT_C_ENABLE:
case USB_PORT_FEAT_C_PORT_LINK_STATE:
+ case USB_PORT_FEAT_C_PORT_CONFIG_ERROR:
xhci_clear_port_change_bit(xhci, wValue, wIndex,
port_array[wIndex], temp);
break;
@@ -1069,7 +1076,7 @@ int xhci_hub_status_data(struct usb_hcd *hcd, char *buf)
*/
status = bus_state->resuming_ports;
- mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC;
+ mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC;
spin_lock_irqsave(&xhci->lock, flags);
/* For each port, did anything change? If so, set that bit in buf. */
--
2.1.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
[PATCH] dwc3: make LPM configurable in DT
LPM capability is hardware property, so now it's moved to DT.
Signed-off-by: Robert Baldyga
---
Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
drivers/usb/dwc3/Kconfig | 7 ---
drivers/usb/dwc3/core.c| 3 +++
drivers/usb/dwc3/core.h| 1 +
drivers/usb/dwc3/host.c| 5 ++---
drivers/usb/dwc3/platform_data.h | 1 +
6 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index cd7f045..36b9148 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -14,6 +14,7 @@ Optional properties:
- phys: from the *Generic PHY* bindings
- phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - usb3_lpm_capable: determines if platform is USB3 LPM capable
- snps,disable_scramble_quirk: true when SW should disable data scrambling.
Only really useful for FPGA builds.
- snps,has-lpm-erratum: true when DWC3 was configured with LPM Erratum enabled
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index edbf9c8..827c4f8 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -104,11 +104,4 @@ config USB_DWC3_DEBUG
help
Say Y here to enable debugging messages on DWC3 Driver.
-config DWC3_HOST_USB3_LPM_ENABLE
- bool "Enable USB3 LPM Capability"
- depends on USB_DWC3_HOST=y || USB_DWC3_DUAL_ROLE=y
- default n
- help
- Select this when you want to enable USB3 LPM with dwc3 xhci host.
-
endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9f0e209..a8d4d6d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -811,6 +811,8 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->needs_fifo_resize = of_property_read_bool(node,
"tx-fifo-resize");
+ dwc->usb3_lpm_capable = of_property_read_bool(node,
+ "usb3_lpm_capable");
dwc->dr_mode = of_usb_get_dr_mode(node);
dwc->disable_scramble_quirk = of_property_read_bool(node,
@@ -848,6 +850,7 @@ static int dwc3_probe(struct platform_device *pdev)
hird_threshold = pdata->hird_threshold;
dwc->needs_fifo_resize = pdata->tx_fifo_resize;
+ dwc->usb3_lpm_capable = pdata->usb3_lpm_capable;
dwc->dr_mode = pdata->dr_mode;
dwc->disable_scramble_quirk = pdata->disable_scramble_quirk;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index d201910..622f65f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -812,6 +812,7 @@ struct dwc3 {
unsignedsetup_packet_pending:1;
unsignedstart_config_issued:1;
unsignedthree_stage_setup:1;
+ unsignedusb3_lpm_capable:1;
unsigneddisable_scramble_quirk:1;
unsignedu2exit_lfps_quirk:1;
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 12bfd3c..507eddf 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -49,9 +49,8 @@ int dwc3_host_init(struct dwc3 *dwc)
memset(&pdata, 0, sizeof(pdata));
-#ifdef CONFIG_DWC3_HOST_USB3_LPM_ENABLE
- pdata.usb3_lpm_capable = 1;
-#endif
+ if (dwc->usb3_lpm_capable)
+ pdata.usb3_lpm_capable = 1;
ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
if (ret) {
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index a3a3b6d5..a2bd464 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,6 +24,7 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+ bool usb3_lpm_capable;
unsigned is_utmi_l1_suspend:1;
u8 hird_threshold;
--
1.9.1
--
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
USB3 bug
Hi I am experiencing a problem when i attach two USB3 devices. With one USB3 device directly in machine everything works: [0.00] DMI: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F5 06/23/2014 ... [0.701476] xhci_hcd :00:14.0: xHCI Host Controller [0.701479] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 1 [0.701558] xhci_hcd :00:14.0: cache line size of 64 is not supported [0.701615] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [0.701616] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.701617] usb usb1: Product: xHCI Host Controller [0.701618] usb usb1: Manufacturer: Linux 3.19.0-031900-generic xhci-hcd [0.701619] usb usb1: SerialNumber: :00:14.0 [0.701686] hub 1-0:1.0: USB hub found [0.701701] hub 1-0:1.0: 14 ports detected [0.703873] xhci_hcd :00:14.0: xHCI Host Controller [0.703875] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [0.703901] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [0.703903] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.703903] usb usb2: Product: xHCI Host Controller [0.703904] usb usb2: Manufacturer: Linux 3.19.0-031900-generic xhci-hcd [0.703905] usb usb2: SerialNumber: :00:14.0 [0.703963] hub 2-0:1.0: USB hub found [0.703974] hub 2-0:1.0: 6 ports detected [0.704394] usb: failed to peer usb2-port4 and usb1-port5 by location (usb2-port4:none) (usb1-port5:usb2-port3) [0.704395] usb usb2-port4: failed to peer to usb1-port5 (-16) [0.704396] usb: port power management may be unreliable [0.704651] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.704655] ehci-pci: EHCI PCI platform driver [0.704716] ehci-pci :00:1a.0: EHCI Host Controller [0.704719] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 3 [0.704729] ehci-pci :00:1a.0: debug port 2 [0.708619] ehci-pci :00:1a.0: cache line size of 64 is not supported [0.708629] ehci-pci :00:1a.0: irq 16, io mem 0xf7e1c000 [0.716701] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [0.716719] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [0.716720] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.716721] usb usb3: Product: EHCI Host Controller [0.716722] usb usb3: Manufacturer: Linux 3.19.0-031900-generic ehci_hcd [0.716723] usb usb3: SerialNumber: :00:1a.0 [0.716804] hub 3-0:1.0: USB hub found [0.716807] hub 3-0:1.0: 2 ports detected [0.716936] ehci-pci :00:1d.0: EHCI Host Controller [0.716939] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 4 [0.716949] ehci-pci :00:1d.0: debug port 2 [0.720834] ehci-pci :00:1d.0: cache line size of 64 is not supported [0.720843] ehci-pci :00:1d.0: irq 23, io mem 0xf7e1b000 [0.732713] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [0.732733] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [0.732734] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.732735] usb usb4: Product: EHCI Host Controller [0.732736] usb usb4: Manufacturer: Linux 3.19.0-031900-generic ehci_hcd [0.732737] usb usb4: SerialNumber: :00:1d.0 [0.732823] hub 4-0:1.0: USB hub found [0.732826] hub 4-0:1.0: 2 ports detected [0.732898] ehci-platform: EHCI generic platform driver [0.732905] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [0.732908] ohci-pci: OHCI PCI platform driver [0.732916] ohci-platform: OHCI generic platform driver [0.732922] uhci_hcd: USB Universal Host Controller Interface driver [1.461325] usb 3-1: new high-speed USB device number 2 using ehci-pci [1.461337] usb 1-1: new low-speed USB device number 2 using xhci_hcd [1.461344] usb 4-1: new high-speed USB device number 2 using ehci-pci [1.593777] usb 3-1: New USB device found, idVendor=8087, idProduct=8008 [1.593778] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1.594044] hub 3-1:1.0: USB hub found [1.594152] hub 3-1:1.0: 6 ports detected [1.594584] usb 1-1: New USB device found, idVendor=0603, idProduct=00f2 [1.594586] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1.594587] usb 1-1: Product: USB Keyboard [1.594599] usb 1-1: Manufacturer: NOVATEK [1.594671] usb 1-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [1.594673] usb 1-1: ep 0x82 - rounding interval to 64 microframes, ep desc says 80 microframes [1.761567] usb 1-4: new high-speed USB device number 3 using xhci_hcd ... [1.890557] usb 1-4: New USB device found, idVendor=2013, idProduct=0258 [1.890559] usb 1-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [1.890570] usb 1-4: Product: PCTV 461 [1.890571] usb 1-4: Manufacturer: PCTV [1.890572] usb 1-4: SerialNumber: 0011421483 [1.902068] usb 4-1: New USB device found, idVendor=8087, idProduct=8000 [1.902070] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1.902327] hub 4-1:1.0: USB hub f
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, Mar 04, 2015 at 02:46:33PM +, Ian Campbell wrote: > On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote: > > On 03/04/2015 03:29 PM, Ian Campbell wrote: > > > On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote: > > >> On 04/03/15 14:09, Juergen Gross wrote: > > >>> > > >>> The main question whether it is worth to consider this alternative is > > >>> the performance aspect. Does anyone have an idea which USB devices would > > >>> typically be used via pvusb? I'd suspect memory sticks and USB disks > > >>> and perhaps webcams being the most performance relevant ones. Is an > > >>> additional copy operation of user data acceptable here? > > >> > > >> I have no idea. We (XenServer) have no use cases at all for USB device > > >> passthrough. > > > I've seen XenServer customers asking for USB passthru functionality on IRC channels.. > > > My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough > > > that anyone would care. qdisk has acceptable for disks, so it's probably > > > ok for usb too. > > > > While I can accept the bus speed reasoning, I doubt qdisk is copying > > data between user and kernel space under normal circumstances. I think > > disk I/Os are done using DMA to/from the user buffer directly. > > I thought there was at least one copy on the datapath with qdisk, > wherever it is. But I don't know for sure. > > > > For usb 3 onwards, well, maybe when we care about those we'll decide > > > that a kernel space driver is needed, but for now it seems like > > > userspace would be ok. > > > > Do you have another feeling about the probability of a need to do usb 3? > > If it is already on the horizon I wouldn't want to do the user space > > backend now and the kernel one next year. :-) > > Well, what is *your* use case for USB passthru? I don't actually have > one myself. > > I'd speculate that people are more interested in passing in > low/medium/high speed devices rather than the superfast usb3 disks etc. > But I have no reason to back that up. > People seem to ask/need USB passthru support for various use cases including passing thru: webcams, video grabbers, printers, mobile broadband modems, copy protection dongles, gaming controllers, you name it.. -- Pasi -- 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 0/8 v4] ARM OMAP2+ GPMC: fixes and bus children
On 06/03/15 02:58, Tony Lindgren wrote: > * Robert ABEL [150227 08:00]: >> These are the changes I proposed in these patch series: [1], [2], [3], [4] >> rebased to 3.19 as well as new changes for little bugs I noticed while >> preparing this patch series as well as changes introduced via comments. >> >> 1. DEBUG was undefined in source code --> remove offending lines >> 2. add capability to have busses as children of the GPMC and multiple >>devices on a bus. See [2] for an example DTS syntax. >> 3. debug output was unaligned --> align it >> 4. output for copy-pasting to DTS had erroneous timing outputs and >>made it hard to copy-paste --> correct timing values, add comments >>as DTS comments. >> 5. WAITMONITORINGTIME is expressed as GPMC_CLK cycles for all accesses. >>GPMCFCLKDIVIDER is used as a divider, so it must always be programmed. >> 6. GPMCFCLKDIVIDER is calculated according to WAITMONITORINGTIME for >>asynchronous accesses inside the driver --> asynchronous accesses now >>completely decoupled from gpmc,sync-clk-ps. >> 7. WAITMONITORINGTIME was being programmed/shown in GPMC_FCLK cycles instead >>of GPMC_CLK cycles --> add clock domain information where necessary. >> 8. Calculated values for WAITMONITORINGTIME and CLKACTIVATIONTIME that were >>outside the defined range would not raise an error. >>DEVICESIZE, ATTACHEDDEVICEPAGELENGTH, WAITMONITORINGTIME and >>CLKACTIVATIONTIME would not be marked as incorrect on DTS output. >>--> Fix all of these. > > Thanks for fixing all these issues: > > Acked-by: Tony Lindgren Thanks. Patches are added to my git tree at g...@github.com:rogerq/linux.git in the branch for-v4.1/gpmc-omap cheers, -roger > > >> [1]: https://lkml.org/lkml/2015/2/12/495 >> [2]: https://lkml.org/lkml/2015/2/16/337 >> [3]: https://lkml.org/lkml/2015/2/24/609 >> [4]: https://lkml.org/lkml/2015/2/26/387 >> >> Robert ABEL (9): >> ARM OMAP2+ GPMC: don't undef DEBUG >> ARM OMAP2+ GPMC: add bus children >> ARM OMAP2+ GPMC: fix debug output alignment >> ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS >> ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER >> ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME >> ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug >> ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters >> >> arch/arm/mach-omap2/gpmc-nand.c| 17 +- >> arch/arm/mach-omap2/gpmc-onenand.c | 4 +- >> arch/arm/mach-omap2/usb-tusb6010.c | 4 +- >> drivers/memory/Makefile| 2 + >> drivers/memory/omap-gpmc.c | 313 >> + >> include/linux/omap-gpmc.h | 2 +- >> 6 files changed, 265 insertions(+), 77 deletions(-) >> >> -- >> 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: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 2015-03-04 09:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? Biggest use-cases I can think of for USB pass-through would be hardware 'security' devices (fingerprint readers, Yubikeys, SafeNet dongles), webcams, and some of the more exotic input devices. Webcams and input devices are probably the most significant performance-wise. -- 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
Why is USB_DT_HUB not used?
As far as I can grep, the only hcd that uses the named constants USB_DT_HUB and USB_DT_SS_HUB is xhci. even dummy_hcd which uses USB_DT_SS_HUB to check that uscore asked for a superspeed hub descriptor still uses the numeric value when filling the buffer. Was this just overlooked? Will a patch series to fix this be welcome? -- 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: Why is USB_DT_HUB not used?
Hello. On 3/6/2015 4:16 PM, Tal Shorer wrote: As far as I can grep, the only hcd that uses the named constants USB_DT_HUB and USB_DT_SS_HUB is xhci. even dummy_hcd which uses USB_DT_SS_HUB to check that uscore asked for a superspeed hub descriptor still uses the numeric value when filling the buffer. Was this just overlooked? Most probably. Will a patch series to fix this be welcome? I already have such series, just need to write change-logs and post. So don't worry. :-) WBR, Sergei -- 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
[PATCH 1/2] xhci: fix reporting of 0-sized URBs in control endpoint
From: Aleksander Morgado
When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb->actual_length was set already by a previous COMP_SHORT_TX event.
The driver checks this by seeing whether urb->actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb->actual_length = 0.
This patch changes the xhci driver to rely on a new td->urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.
This fixes a bug which affected the HSO plugin, which relies on URBs with
urb->actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.
Cc:
Signed-off-by: Aleksander Morgado
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 10 --
drivers/usb/host/xhci.h | 3 +++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b46b5b9..5fb66db 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1946,7 +1946,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
if (event_trb != ep_ring->dequeue) {
/* The event was for the status stage */
if (event_trb == td->last_trb) {
- if (td->urb->actual_length != 0) {
+ if (td->urb_length_set) {
/* Don't overwrite a previously set error code
*/
if ((*status == -EINPROGRESS || *status == 0) &&
@@ -1960,7 +1960,13 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
td->urb->transfer_buffer_length;
}
} else {
- /* Maybe the event was for the data stage? */
+ /*
+* Maybe the event was for the data stage? If so, update
+* already the actual_length of the URB and flag it as
+* set, so that it is not overwritten in the event for
+* the last TRB.
+*/
+ td->urb_length_set = true;
td->urb->actual_length =
td->urb->transfer_buffer_length -
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 3b97f05..d066393 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1,3 +1,4 @@
+
/*
* xHCI host controller driver
*
@@ -1291,6 +1292,8 @@ struct xhci_td {
struct xhci_segment *start_seg;
union xhci_trb *first_trb;
union xhci_trb *last_trb;
+ /* actual_length of the URB has already been set */
+ boolurb_length_set;
};
/* xHCI command default timeout value */
--
1.8.3.2
--
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
[PATCH 0/2] xhci fixes for 4.0-rc
Hi Greg Two more patches for usb-linus. One fixes short transfers on control endpoints with 0 data transferred. The other one is a Intel xhci HW issue workaround for PME events -Mathias Aleksander Morgado (1): xhci: fix reporting of 0-sized URBs in control endpoint Mathias Nyman (1): xhci: Workaround for PME stuck issues in Intel xhci drivers/usb/host/xhci-pci.c | 30 ++ drivers/usb/host/xhci-ring.c | 10 -- drivers/usb/host/xhci.h | 4 3 files changed, 42 insertions(+), 2 deletions(-) -- 1.8.3.2 -- 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
[PATCH 2/2] xhci: Workaround for PME stuck issues in Intel xhci
The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
workaround for a Stuck PME that might either block PME events in suspend,
or create spurious PME events preventing runtime suspend.
Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
PMCTRL register at offset 0x80a4, in both suspend resume callbacks
Without this, xhci connected usb devices might never be able to wake up the
system from suspend, or prevent device from going to suspend (xhci d3)
Cc:
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-pci.c | 30 ++
drivers/usb/host/xhci.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7f76c8a..fd53c9e 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -37,6 +37,9 @@
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI 0x8c31
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI 0x9c31
+#define PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI0x22b5
+#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI0xa12f
+#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
static const char hcd_name[] = "xhci_hcd";
@@ -133,6 +136,12 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ (pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
+pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI ||
+pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI)) {
+ xhci->quirks |= XHCI_PME_STUCK_QUIRK;
+ }
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_EJ168) {
xhci->quirks |= XHCI_RESET_ON_RESUME;
@@ -159,6 +168,21 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
"QUIRK: Resetting on resume");
}
+/*
+ * Make sure PME works on some Intel xHCI controllers by writing 1 to clear
+ * the Internal PME flag bit in vendor specific PMCTRL register at offset
0x80a4
+ */
+static void xhci_pme_quirk(struct xhci_hcd *xhci)
+{
+ u32 val;
+ void __iomem *reg;
+
+ reg = (void __iomem *) xhci->cap_regs + 0x80a4;
+ val = readl(reg);
+ writel(val | BIT(28), reg);
+ readl(reg);
+}
+
/* called during probe() after chip reset completes */
static int xhci_pci_setup(struct usb_hcd *hcd)
{
@@ -283,6 +307,9 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
pdev->no_d3cold = true;
+ if (xhci->quirks & XHCI_PME_STUCK_QUIRK)
+ xhci_pme_quirk(xhci);
+
return xhci_suspend(xhci, do_wakeup);
}
@@ -313,6 +340,9 @@ static int xhci_pci_resume(struct usb_hcd *hcd, bool
hibernated)
if (pdev->vendor == PCI_VENDOR_ID_INTEL)
usb_enable_intel_xhci_ports(pdev);
+ if (xhci->quirks & XHCI_PME_STUCK_QUIRK)
+ xhci_pme_quirk(xhci);
+
retval = xhci_resume(xhci, hibernated);
return retval;
}
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index d066393..265ab17 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1566,6 +1566,7 @@ struct xhci_hcd {
#define XHCI_SPURIOUS_WAKEUP (1 << 18)
/* For controllers with a broken beyond repair streams implementation */
#define XHCI_BROKEN_STREAMS(1 << 19)
+#define XHCI_PME_STUCK_QUIRK (1 << 20)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
--
1.8.3.2
--
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 1/2] xhci: fix reporting of 0-sized URBs in control endpoint
Hello. On 03/06/2015 06:14 PM, Mathias Nyman wrote: From: Aleksander Morgado When a control transfer has a short data stage, the xHCI controller generates two transfer events: a COMP_SHORT_TX event that specifies the untransferred amount, and a COMP_SUCCESS event. But when the data stage is not short, only the COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless urb->actual_length was set already by a previous COMP_SHORT_TX event. The driver checks this by seeing whether urb->actual_length == 0, but this alone is the wrong test, as it is entirely possible for a short transfer to have an urb->actual_length = 0. This patch changes the xhci driver to rely on a new td->urb_length_set flag, which is set to true when a COMP_SHORT_TX event is received and the URB length updated at that stage. This fixes a bug which affected the HSO plugin, which relies on URBs with urb->actual_length == 0 to halt re-submitting the RX URB in the control endpoint. Cc: Signed-off-by: Aleksander Morgado Signed-off-by: Mathias Nyman [...] diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 3b97f05..d066393 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1,3 +1,4 @@ + /* * xHCI host controller driver * Hm, I thought you've dropped this new line... WBR, Sergei -- 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 v2] Remove deprecated IRQF_DISABLED flag entirely
* Valentin Rothberg [150305 06:24]:
> The IRQF_DISABLED is a NOOP and has been scheduled for removal since
> Linux v2.6.36 by commit 6932bf37bed4 ("genirq: Remove IRQF_DISABLED from
> core code").
>
> According to commit e58aa3d2d0cc ("genirq: Run irq handlers with
> interrupts disabled") running IRQ handlers with interrupts enabled can
> cause stack overflows when the interrupt line of the issuing device is
> still active.
>
> This patch ends the grace period for IRQF_DISABLED (i.e., SA_INTERRUPT
> in older versions of Linux) and removes the definition and all remaining
> usages of this flag.
>
> Signed-off-by: Valentin Rothberg
Acked-by: Tony Lindgren
--
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 v2] Remove deprecated IRQF_DISABLED flag entirely
On Thu, Mar 05, 2015 at 03:23:08PM +0100, Valentin Rothberg wrote:
> The IRQF_DISABLED is a NOOP and has been scheduled for removal since
> Linux v2.6.36 by commit 6932bf37bed4 ("genirq: Remove IRQF_DISABLED from
> core code").
>
> According to commit e58aa3d2d0cc ("genirq: Run irq handlers with
> interrupts disabled") running IRQ handlers with interrupts enabled can
> cause stack overflows when the interrupt line of the issuing device is
> still active.
>
> This patch ends the grace period for IRQF_DISABLED (i.e., SA_INTERRUPT
> in older versions of Linux) and removes the definition and all remaining
> usages of this flag.
>
> Signed-off-by: Valentin Rothberg
> ---
> The bigger hunk in Documentation/scsi/ncr53c8xx.txt is removed entirely
> as IRQF_DISABLED is gone now; the usage in older kernel versions
> (including the old SA_INTERRUPT flag) should be discouraged. The
> trouble of using IRQF_SHARED is a general problem and not specific to
> any driver.
>
> I left the reference in Documentation/PCI/MSI-HOWTO.txt untouched since
> it has already been removed in linux-next by commit b0e1ee8e1405
> ("MSI-HOWTO.txt: remove reference on IRQF_DISABLED").
>
> All remaining references are changelogs that I suggest to keep.
>
> Changelog
>
> v2: Correct previous change to drivers/mtd/nand/hisi504_nand.c that
> broke compilation. Reported by Dan Carpenter.
> ---
> Documentation/scsi/ncr53c8xx.txt | 25 -
> Documentation/scsi/tmscsim.txt | 4
> arch/mips/loongson/loongson-3/hpet.c | 2 +-
> drivers/block/cpqarray.c | 4 ++--
> drivers/bus/omap_l3_noc.c| 4 ++--
> drivers/bus/omap_l3_smx.c| 10 --
> drivers/mtd/nand/hisi504_nand.c | 3 +--
> drivers/usb/isp1760/isp1760-core.c | 3 +--
> drivers/usb/isp1760/isp1760-udc.c| 4 ++--
> include/linux/interrupt.h| 3 ---
> 10 files changed, 13 insertions(+), 49 deletions(-)
>
For this piece:
> diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
> index 289ad3ac3e80..8dcc7b8fee40 100644
> --- a/drivers/mtd/nand/hisi504_nand.c
> +++ b/drivers/mtd/nand/hisi504_nand.c
> @@ -758,8 +758,7 @@ static int hisi_nfc_probe(struct platform_device *pdev)
>
> hisi_nfc_host_init(host);
>
> - ret = devm_request_irq(dev, irq, hinfc_irq_handle, IRQF_DISABLED,
> - "nandc", host);
> + ret = devm_request_irq(dev, irq, hinfc_irq_handle, 0x0, "nandc", host);
> if (ret) {
> dev_err(dev, "failed to request IRQ\n");
> goto err_res;
Acked-by: Brian Norris
Sorry for the oversight in review, and thanks for the fixup.
Brian
--
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 1/2] xhci: fix reporting of 0-sized URBs in control endpoint
On Fri, Mar 6, 2015 at 7:08 PM, Sergei Shtylyov wrote: > Hello. > > On 03/06/2015 06:14 PM, Mathias Nyman wrote: > >> From: Aleksander Morgado > > >> When a control transfer has a short data stage, the xHCI controller >> generates >> two transfer events: a COMP_SHORT_TX event that specifies the >> untransferred >> amount, and a COMP_SUCCESS event. But when the data stage is not short, >> only the >> COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length >> to >> urb->transfer_buffer_length while processing the COMP_SUCCESS event, >> unless >> urb->actual_length was set already by a previous COMP_SHORT_TX event. > > >> The driver checks this by seeing whether urb->actual_length == 0, but this >> alone >> is the wrong test, as it is entirely possible for a short transfer to have >> an >> urb->actual_length = 0. > > >> This patch changes the xhci driver to rely on a new td->urb_length_set >> flag, >> which is set to true when a COMP_SHORT_TX event is received and the URB >> length >> updated at that stage. > > >> This fixes a bug which affected the HSO plugin, which relies on URBs with >> urb->actual_length == 0 to halt re-submitting the RX URB in the control >> endpoint. > > >> Cc: >> Signed-off-by: Aleksander Morgado >> Signed-off-by: Mathias Nyman > > > [...] > >> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h >> index 3b97f05..d066393 100644 >> --- a/drivers/usb/host/xhci.h >> +++ b/drivers/usb/host/xhci.h >> @@ -1,3 +1,4 @@ >> + >> /* >>* xHCI host controller driver >>* > > >Hm, I thought you've dropped this new line... > Ouch; sorry for that. How do I fix that now? Submit another patch just removing it? Or resubmit a v6 of the patch? I think Greg already cherry-picked it to his branch. -- Aleksander https://aleksander.es -- 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] Remove deprecated IRQF_DISABLED flag entirely
On Thu, Mar 5, 2015 at 5:11 AM, Hannes Reinecke wrote:
> On 03/05/2015 01:59 PM, Valentin Rothberg wrote:
>> The IRQF_DISABLED is a NOOP and has been scheduled for removal since
>> Linux v2.6.36 by commit 6932bf37bed4 ("genirq: Remove IRQF_DISABLED from
>> core code").
>>
>> According to commit e58aa3d2d0cc ("genirq: Run irq handlers with
>> interrupts disabled") running IRQ handlers with interrupts enabled can
>> cause stack overflows when the interrupt line of the issuing device is
>> still active.
>>
>> This patch ends the grace period for IRQF_DISABLED (i.e., SA_INTERRUPT
>> in older versions of Linux) and removes the definition and all remaining
>> usages of this flag.
>>
>> Signed-off-by: Valentin Rothberg
>> ---
>> The bigger hunk in Documentation/scsi/ncr53c8xx.txt is removed entirely
>> as IRQF_DISABLED is gone now; the usage in older kernel versions
>> (including the old SA_INTERRUPT flag) should be discouraged. The
>> trouble of using IRQF_SHARED is a general problem and not specific to
>> any driver.
>>
>> I left the reference in Documentation/PCI/MSI-HOWTO.txt untouched since
>> it has already been removed in linux-next by commit b0e1ee8e1405
>> ("MSI-HOWTO.txt: remove reference on IRQF_DISABLED").
>>
>> All remaining references are changelogs that I suggest to keep.
>
> While you're at it: having '0x0' as a value for the irq flags looks
> a bit silly, and makes you wonder what the parameter is for.
>
> I would rather like to have
>
> #define IRQF_NONE 0x0
>
> and use it for these cases.
> That way the scope of that parameter is clear.
No, that would imply that IRQ never triggers whereas passing 0 means
we keep triggers that have been set by the platform.
Thanks.
--
Dmitry
--
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
[PATCH v2] usb: gadget: f_mass_storage: use defined constant instead of numeric value
replace numeric value with TYPE_NO_LUN (defined in )
Signed-off-by: Tal Shorer
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 811929c..6d5ca2b 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -1085,7 +1085,7 @@ static int do_inquiry(struct fsg_common *common, struct
fsg_buffhd *bh)
if (!curlun) { /* Unsupported LUNs are okay */
common->bad_lun_okay = 1;
memset(buf, 0, 36);
- buf[0] = 0x7f; /* Unsupported, no device-type */
+ buf[0] = TYPE_NO_LUN; /* Unsupported, no device-type */
buf[4] = 31;/* Additional length */
return 36;
}
--
2.2.2
--
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
Driver problem with USB chipset VIA VL812-B2
Bug report, in kernel.org suggested format. [1.] One line summary of the problem: Excessive CPU load when USB 3.0 hub with VIA VL812-B2 chipset is plugged into port served by internal (root) USB 3.0 hub [2.] Full description of the problem/report: I have a HooToo HT-UH005 4-Port USB 3.0 hub (VIA VL812-B2 chipset) . I'm using it with a HP Pavilion 17-e049wm laptop (quad CPU). This computer has two USB 3.0 ports. When the computer is quiescent the CPU load is normally 0% to 1%. That's the same whether there are USB 2.0 or 3.0 devices plugged into its onboard USB 3.0 ports, or not. As soon as I plug the HT-UH005 hub into one of those USB 3.0 ports, one or several "kworker" and "ksoftirqd" threads appear which create CPU loads of 17% and 7%, respectively, for a total of 24 to 25% CPU load. That's just because the HT-UH005 was plugged in. No peripherals attached to the HT-UH005. Stranger still, when I unplug the HT-UH005 the kworker, and ksoftirqd threads *continue* to consume 24 to 25% CPU. That's with the HT-UH005 disconnected after it was previously connected. This goes on indefinitely. The only way I can get things back to normal is to reboot or to manually stop and restart (unbind and then bind) the xhci_hcd driver that's servicing the internal hub that runs the computer's two USB 3.0 ports. The shell script I've created that seems to reset things: (run as root) #!/bin/bash echo -n ":00:10.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind sleep 1 echo -n ":00:10.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind The VIA VL812-B2 chipset has had firmware updated to version 9091. The same bug appeared with firmware version 9081, which is the reason for the update. I have confirmed that the exact same bug occurs using a 7-port USB 3.0 hub that's using GenesysLogic chipset (3520 or 3521). [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel version (from /proc/version): Linux version 4.0.0-04rc2-generic (kernel@gloin) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201503031836 SMP Tue Mar 3 18:37:51 UTC 2015 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) (N/A) [6.] A small shell script or example program which triggers the problem (if possible) All that is necessary to trigger the problem is to plug one of the aforementioned USB 3.0 hubs into one of the computer's USB 3.0 ports. [7.] Environment Description:Ubuntu 14.10 Release:14.10 [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux warren-laptop3 4.0.0-04rc2-generic #201503031836 SMP Tue Mar 3 18:37:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.9.1 Gnu make 4.0 binutils 2.24.90.20141014 util-linux 2.25.1 mount debug module-init-tools 18 e2fsprogs 1.42.10 pcmciautils018 PPP2.4.5 Linux C Library2.19 Dynamic linker (ldd) 2.19 Procps 3.3.9 Net-tools 1.60 Kbd1.15.5 Sh-utils 8.23 wireless-tools 30 Modules Loaded hidp ctr ccm snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm hp_wmi snd_seq_midi sparse_keymap snd_seq_midi_event arc4 snd_rawmidi ath9k ath9k_common kvm ath9k_hw snd_seq crct10dif_pclmul crc32_pclmul snd_seq_device ghash_clmulni_intel snd_timer ath uvcvideo aesni_intel videobuf2_vmalloc mac80211 aes_x86_64 videobuf2_memops lrw gf128mul glue_helper ablk_helper bnep cryptd videobuf2_core v4l2_common videodev ath3k rfcomm serio_raw cfg80211 joydev media btusb rtsx_pci_ms snd bluetooth memstick k10temp soundcore shpchp i2c_piix4 hp_accel lis3lv02d input_polldev video wmi hp_wireless binfmt_misc cuse parport_pc ppdev lp nls_iso8859_1 parport mac_hid rtsx_pci_sdmmc hid_generic psmouse r8169 rtsx_pci mii usbhid hid ahci libahci [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 19 model name : AMD A10-5750M APU with Radeon(tm) HD Graphics stepping: 1 microcode : 0x6001119 cpu MHz : 2500.000 cache size : 2048 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes
Re: Driver problem with USB chipset VIA VL812-B2
On Fri, Mar 06, 2015 at 05:11:32PM -0700, Warren Severin wrote: > Bug report, in kernel.org suggested format. I'm no longer the xHCI driver maintainer, and this isn't even the email that was listed in the maintainers file, so I'm wondering where you found it? Please work with the new maintainer, Mathias Nyman. Sarah Sharp > [1.] One line summary of the problem: > > Excessive CPU load when USB 3.0 hub with VIA VL812-B2 chipset is > plugged into port served by internal (root) USB 3.0 hub > > > [2.] Full description of the problem/report: > > I have a HooToo HT-UH005 4-Port USB 3.0 hub (VIA VL812-B2 chipset) . > I'm using it with a HP Pavilion 17-e049wm laptop (quad CPU). This > computer has two USB 3.0 ports. > > When the computer is quiescent the CPU load is normally 0% to 1%. > That's the same whether there are USB 2.0 or 3.0 devices plugged > into its onboard USB 3.0 ports, or not. > > As soon as I plug the HT-UH005 hub into one of those USB 3.0 ports, > one or several "kworker" and "ksoftirqd" threads appear which create > CPU loads of 17% and 7%, respectively, for a total of 24 to 25% CPU > load. That's just because the HT-UH005 was plugged in. No > peripherals attached to the HT-UH005. > > Stranger still, when I unplug the HT-UH005 the kworker, and > ksoftirqd threads *continue* to consume 24 to 25% CPU. That's with > the HT-UH005 disconnected after it was previously connected. This > goes on indefinitely. The only way I can get things back to normal > is to reboot or to manually stop and restart (unbind and then bind) > the xhci_hcd driver that's servicing the internal hub that runs the > computer's two USB 3.0 ports. > > The shell script I've created that seems to reset things: > (run as root) > #!/bin/bash > echo -n ":00:10.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind > sleep 1 > echo -n ":00:10.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind > > The VIA VL812-B2 chipset has had firmware updated to version 9091. > The same bug appeared with firmware version 9081, which is the > reason for the update. > > I have confirmed that the exact same bug occurs using a 7-port USB > 3.0 hub that's using GenesysLogic chipset (3520 or 3521). > > > [3.] Keywords (i.e., modules, networking, kernel): > > > [4.] Kernel version (from /proc/version): > > Linux version 4.0.0-04rc2-generic (kernel@gloin) (gcc version > 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201503031836 SMP Tue Mar 3 > 18:37:51 UTC 2015 > > > [5.] Output of Oops.. message (if applicable) with symbolic information > resolved (see Documentation/oops-tracing.txt) > (N/A) > > [6.] A small shell script or example program which triggers the > problem (if possible) > > All that is necessary to trigger the problem is to plug one of the > aforementioned USB 3.0 hubs into one of the computer's USB 3.0 > ports. > > > [7.] Environment > > Description: Ubuntu 14.10 > Release: 14.10 > > > [7.1.] Software (add the output of the ver_linux script here) > > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux warren-laptop3 4.0.0-04rc2-generic #201503031836 SMP Tue > Mar 3 18:37:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > Gnu C 4.9.1 > Gnu make 4.0 > binutils 2.24.90.20141014 > util-linux 2.25.1 > mount debug > module-init-tools 18 > e2fsprogs 1.42.10 > pcmciautils018 > PPP2.4.5 > Linux C Library2.19 > Dynamic linker (ldd) 2.19 > Procps 3.3.9 > Net-tools 1.60 > Kbd1.15.5 > Sh-utils 8.23 > wireless-tools 30 > Modules Loaded hidp ctr ccm snd_hda_codec_realtek > snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel > snd_hda_controller snd_hda_codec snd_hwdep snd_pcm hp_wmi > snd_seq_midi sparse_keymap snd_seq_midi_event arc4 snd_rawmidi ath9k > ath9k_common kvm ath9k_hw snd_seq crct10dif_pclmul crc32_pclmul > snd_seq_device ghash_clmulni_intel snd_timer ath uvcvideo > aesni_intel videobuf2_vmalloc mac80211 aes_x86_64 videobuf2_memops > lrw gf128mul glue_helper ablk_helper bnep cryptd videobuf2_core > v4l2_common videodev ath3k rfcomm serio_raw cfg80211 joydev media > btusb rtsx_pci_ms snd bluetooth memstick k10temp soundcore shpchp > i2c_piix4 hp_accel lis3lv02d input_polldev video wmi hp_wireless > binfmt_misc cuse parport_pc ppdev lp nls_iso8859_1 parport mac_hid > rtsx_pci_sdmmc hid_generic psmouse r8169 rtsx_pci mii usbhid hid > ahci libahci > > > [7.2.] Processor information (from /proc/cpuinfo): > > processor : 0 > vendor_id : AuthenticAMD > cpu family: 21 > model : 19 > model name: AMD A10-5750M APU with Radeon(tm) HD Graphics > stepping : 1 > microcode : 0x6001119 > cpu MHz : 2500.000 > cache size: 2048 KB > physical id : 0
Re: [PATCH] dwc3: make LPM configurable in DT
Hi,
On Fri, Mar 06, 2015 at 11:08:53AM +0100, Robert Baldyga wrote:
> LPM capability is hardware property, so now it's moved to DT.
you need a better commit log here.
> Signed-off-by: Robert Baldyga
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> drivers/usb/dwc3/Kconfig | 7 ---
> drivers/usb/dwc3/core.c| 3 +++
> drivers/usb/dwc3/core.h| 1 +
> drivers/usb/dwc3/host.c| 5 ++---
> drivers/usb/dwc3/platform_data.h | 1 +
> 6 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index cd7f045..36b9148 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -14,6 +14,7 @@ Optional properties:
> - phys: from the *Generic PHY* bindings
> - phy-names: from the *Generic PHY* bindings
> - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
> + - usb3_lpm_capable: determines if platform is USB3 LPM capable
needs a snps, prefix
> @@ -848,6 +850,7 @@ static int dwc3_probe(struct platform_device *pdev)
> hird_threshold = pdata->hird_threshold;
>
> dwc->needs_fifo_resize = pdata->tx_fifo_resize;
> + dwc->usb3_lpm_capable = pdata->usb3_lpm_capable;
> dwc->dr_mode = pdata->dr_mode;
>
> dwc->disable_scramble_quirk = pdata->disable_scramble_quirk;
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index d201910..622f65f 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -812,6 +812,7 @@ struct dwc3 {
> unsignedsetup_packet_pending:1;
> unsignedstart_config_issued:1;
> unsignedthree_stage_setup:1;
> + unsignedusb3_lpm_capable:1;
missing kdoc for this new field.
>
> unsigneddisable_scramble_quirk:1;
> unsignedu2exit_lfps_quirk:1;
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index 12bfd3c..507eddf 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -49,9 +49,8 @@ int dwc3_host_init(struct dwc3 *dwc)
>
> memset(&pdata, 0, sizeof(pdata));
>
> -#ifdef CONFIG_DWC3_HOST_USB3_LPM_ENABLE
> - pdata.usb3_lpm_capable = 1;
> -#endif
> + if (dwc->usb3_lpm_capable)
> + pdata.usb3_lpm_capable = 1;
pdata.usb3_lpm_capable = dwc->usb3_lpm_capable; ??
drop the branch altogether
> diff --git a/drivers/usb/dwc3/platform_data.h
> b/drivers/usb/dwc3/platform_data.h
> index a3a3b6d5..a2bd464 100644
> --- a/drivers/usb/dwc3/platform_data.h
> +++ b/drivers/usb/dwc3/platform_data.h
> @@ -24,6 +24,7 @@ struct dwc3_platform_data {
> enum usb_device_speed maximum_speed;
> enum usb_dr_mode dr_mode;
> bool tx_fifo_resize;
> + bool usb3_lpm_capable;
add kdoc for this too.
--
balbi
signature.asc
Description: Digital signature
