When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
(USB: Allow USB 3.0 ports
Hi Sarah and Mathias,
As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011,
I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk
can't work in SuperSpeed after several times of hotplug. After doing some
experiments and bisection, I found the bug is
I have a proposal for you.
--
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
Hi Alan,
Thanks for reviewing.
On Thu, 10 Jul 2014, Alan Stern wrote:
On Thu, 10 Jul 2014, Peter Griffin wrote:
This driver adds support for the USB HCD present in STi
SoC's from STMicroelectronics. It has been tested on the
stih416-b2020 board.
This driver file, along with the
Signed-off-by: Søren Holm s...@sgh.dk
Cc: sta...@vger.kernel.org
---
drivers/usb/serial/sierra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index 6f7f01e..c55548a 100644
--- a/drivers/usb/serial/sierra.c
+++
On Thu, 10 Jul 2014, Peter Griffin wrote:
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/MAINTAINERS b/MAINTAINERS
index 702ca10..359a64e 100644
--- a/MAINTAINERS
+++
On Thu, 10 Jul 2014, Peter Griffin wrote:
This driver adds support for the USB HCD present in STi
SoC's from STMicroelectronics. It has been tested on the
stih416-b2020 board.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
drivers/usb/host/Kconfig | 17 ++
On Thu, 10 Jul 2014, Peter Griffin wrote:
This patch documents the device tree documentation required for
the ST HCD controller found in STMicroelectronics SoCs.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/usb/st-hcd.txt | 51
oh...
I just noticed that qcserial.c also handles this exact same USB-id.
Will that pose a problem or is this the way things should be?
Fredag den 11. juli 2014 09:53:53 skrev Søren Holm:
Signed-off-by: Søren Holm s...@sgh.dk
Cc: sta...@vger.kernel.org
---
drivers/usb/serial/sierra.c | 1 +
Søren Holm s...@sgh.dk writes:
oh...
I just noticed that qcserial.c also handles this exact same USB-id.
Will that pose a problem or is this the way things should be?
The device should be handled by only one of the drivers. If it is going
to be handled by sierra driver then we should
The transport offset of the IPv4 packet should be fixed and wouldn't
be out of the hw limitation, so the r8152_csum_workaround() should
be used for IPv6 packets.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork:
The device should be handled by only one of the drivers. If it is going
to be handled by sierra driver then we should remove the entry from
the qcserial driver.
My memory is on vacation... Was it so that the qcserial driver fails
on
Hi Alan and Davids,
On Thu, Jul 10, 2014 at 04:50:03PM +0100, One Thousand Gnomes wrote:
On Thu, 10 Jul 2014 14:37:37 +
David Laight david.lai...@aculab.com wrote:
From: Olivier Sobrie
...
The function put_rxbuf_data() is called from the urb completion handler.
It puts the data
From: Olivier Sobrie Olivier Sobrie
Hi Alan and Davids,
On Thu, Jul 10, 2014 at 04:50:03PM +0100, One Thousand Gnomes wrote:
On Thu, 10 Jul 2014 14:37:37 +
David Laight david.lai...@aculab.com wrote:
From: Olivier Sobrie
...
The function put_rxbuf_data() is called from the
qcserial from master on top of v3.14 works.
I applied this patch on 3.14.5
$ git diff v3.14..ba2c0922f74a57d794c10646c3a70ee5a5e14668 --
drivers/usb/serial/qcserial.c
In total that sums up to these commits :
0ce5fb5 usb: qcserial: add additional Sierra Wireless QMI devices
ff1fcd5 usb:
Søren Holm s...@sgh.dk writes:
Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork:
The device should be handled by only one of the drivers. If it is going
to be handled by sierra driver then we should remove the entry from
the qcserial driver.
My memory is on vacation... Was it so that
Søren Holm s...@sgh.dk writes:
qcserial from master on top of v3.14 works.
Thanks for verifying. You did ensure that you can actually talk to the
serial ports?
I applied this patch on 3.14.5
$ git diff v3.14..ba2c0922f74a57d794c10646c3a70ee5a5e14668 --
drivers/usb/serial/qcserial.c
Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork:
Søren Holm s...@sgh.dk writes:
qcserial from master on top of v3.14 works.
Thanks for verifying. You did ensure that you can actually talk to the
serial ports?
I beleive so. wvdial where able to connect.
Actually, commit 51b9a752fa1c
Søren Holm s...@sgh.dk writes:
Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork:
Søren Holm s...@sgh.dk writes:
qcserial from master on top of v3.14 works.
Thanks for verifying. You did ensure that you can actually talk to the
serial ports?
I beleive so. wvdial where able to connect.
On Sat, May 24, 2014 at 07:13:12AM -0700, Dan Williams wrote:
Good Afternoon,
Let me see if I can achieve this with a debugfs interface so that
'noxhci_port_switch' does not become a permanent ABI per Greg's
concern.
I wonder if there is another non-ABI option? Couldn't the ports
be
First I notice that I don't even have qcserial on the target ... doh
lsusb gives this - so problably getting qcserial on the target will problably
solve it.
Bus 001 Device 003: ID 1199:68c0 Sierra Wireless, Inc.
Device Descriptor:
bLength18
bDescriptorType 1
Oh dear it's friday
# modinfo qcserial | grep 1199p68
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00*
alias: usb:v1199p68A9d*dc*dsc*dp*ic*isc*ip*in*
alias:
Søren Holm s...@sgh.dk writes:
Oh dear it's friday
# modinfo qcserial | grep 1199p68
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00*
alias:
On Fri, Jul 11, 2014 at 09:28:47AM +, David Laight wrote:
From: Olivier Sobrie Olivier Sobrie
Hi Alan and Davids,
On Thu, Jul 10, 2014 at 04:50:03PM +0100, One Thousand Gnomes wrote:
On Thu, 10 Jul 2014 14:37:37 +
David Laight david.lai...@aculab.com wrote:
From:
-ENODEV is interpreted by the generic driver probing function as a
non-matching driver. This leads to a missing probe failure message.
Also a missing USB PHY is more of an invalid configuration of the usb
driver because it is necessary.
This patch returns -EINVAL if devm_usb_get_phy_by_phandle()
fsl,usbphy is no optional property. This patch moves it to the list of
required properties.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
hi all:
when I trace xhci_queue_isoc_tx, I found ISO TD should look like
ISO TRB -- Normal TRB -- Normal TRB
But when I dump ep segment during Iso transfer I get below result
1. Why most of them are ISO TRBs?
2. Why there is only 1 normal TRB
appreciate your help in advance,
ep ring segment:
When the module sends bursts of data, sometimes a deadlock happens in
the hso driver when the tty buffer doesn't get the chance to be flushed
quickly enough.
Remove the endless while loop in function put_rxbuf_data() which is
called by the urb completion handler.
If there isn't enough room in the
On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote:
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.
Using udc clas is not a good idea. This may cause failures in userspace.
failures? like what?
How would you like to tell that this is
[Cc Felipe Balbi]
On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote:
Hi
Changes in v2:
- move phy handle to struct usbhs_priv
- add new default pipe type to driver
- remove pipe type from Lager board code
Ulrich Hecht (2):
usb: renesas_usbhs: add R-Car Gen. 2
On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote:
[Cc Felipe Balbi]
On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote:
Hi
Changes in v2:
- move phy handle to struct usbhs_priv
- add new default pipe type to driver
- remove pipe type from Lager
fix confirmed
uname -rm
3.15.5-1.g01d2774-desktop x86_64
journalctl -b | grep kernel | egrep -i xhci|trace
Jul 11 08:09:16 localhost kernel: ftrace: allocating 24222
entries in 95 pages
Jul 11 08:09:17 localhost kernel: xhci_hcd
On Fri, Jul 11, 2014 at 10:12:37AM -0500, Felipe Balbi wrote:
On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote:
[Cc Felipe Balbi]
On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote:
Hi
Changes in v2:
- move phy handle to struct usbhs_priv
-
On Fri, Jul 11, 2014 at 05:41:52PM +0200, Simon Horman wrote:
On Fri, Jul 11, 2014 at 10:12:37AM -0500, Felipe Balbi wrote:
On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote:
[Cc Felipe Balbi]
On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote:
Hi
Ok, then maybe it's not 3.14.5
It's a little bit unclean since the kernel is from this repo :
git://git.yoctoproject.org/linux-yocto-3.14.git commit
144595ef6215a0febfb8ee7d0c9e4eb2eaf93d61
Fact is that master supports the MC73xx, and I seem to be running a kernel
that does not.
Does it make
When posting new versions of patches, you must resubmit the entire
series, not just the patch which is changing.
Thank you.
--
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
On Fri, 11 Jul 2014, Peter Griffin wrote:
Hi Alan,
Thanks for reviewing.
On Thu, 10 Jul 2014, Alan Stern wrote:
On Thu, 10 Jul 2014, Peter Griffin wrote:
This driver adds support for the USB HCD present in STi
SoC's from STMicroelectronics. It has been tested on the
From: Hayes Wang hayesw...@realtek.com
Date: Fri, 11 Jul 2014 16:48:27 +0800
The transport offset of the IPv4 packet should be fixed and wouldn't
be out of the hw limitation, so the r8152_csum_workaround() should
be used for IPv6 packets.
Signed-off-by: Hayes Wang hayesw...@realtek.com
Hi all,
On Mon, Jun 30, 2014 at 10:38 AM, Gavin Guo gavin@canonical.com wrote:
Hi all,
Recently, I found that the AR3012 bluetooth sometimes can't work with the
00:14.0 USB controller [0c03]: Intel Corporation Lynx Point USB xHCI
Host Controller [8086:8c31] (rev 05).
The dmesg is
Hi all,
On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote:
Hi Sarah and Mathias,
As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011,
I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk
can't work in SuperSpeed after
Hi all,
On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote:
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of vichy
hi all:
when I trace xhci_queue_isoc_tx, I found ISO TD should look like
ISO TRB -- Normal TRB -- Normal TRB
But when I dump ep segment during Iso transfer I get below result
1. Why most of
On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote:
Hi all,
On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote:
Hi Sarah and Mathias,
As the discussion in
http://comments.gmane.org/gmane.linux.usb.general/107011,
I found that [AMD] FCH USB XHCI
Hi Greg,
On Sat, Jul 12, 2014 at 8:04 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote:
Hi all,
On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote:
Hi Sarah and Mathias,
As the discussion in
44 matches
Mail list logo
