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,
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
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
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):
From: Aleksander Morgado aleksan...@aleksander.es
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
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
On 06/03/15 02:58, Tony Lindgren wrote:
* Robert ABEL ra...@cit-ec.uni-bielefeld.de [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
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
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
LPM capability is hardware property, so now it's moved to DT.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
drivers/usb/dwc3/Kconfig | 7 ---
drivers/usb/dwc3/core.c| 3 +++
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
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
On Fri, Mar 6, 2015 at 7:08 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
Hello.
On 03/06/2015 06:14 PM, Mathias Nyman wrote:
From: Aleksander Morgado aleksan...@aleksander.es
When a control transfer has a short data stage, the xHCI controller
generates
two transfer
Hello.
On 03/06/2015 06:14 PM, Mathias Nyman wrote:
From: Aleksander Morgado aleksan...@aleksander.es
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.
* Valentin Rothberg valentinrothb...@gmail.com [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
On Thu, Mar 5, 2015 at 5:11 AM, Hannes Reinecke h...@suse.de 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
replace numeric value with TYPE_NO_LUN (defined in scsi/scsi.h)
Signed-off-by: Tal Shorer tal.sho...@gmail.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/function/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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 r.bald...@samsung.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
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
19 matches
Mail list logo