Hi J,
On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 11:39 Mon 20 Jan , Bo Shen wrote:
Hi J,
On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:59 Fri 17 Jan , Bo Shen wrote:
In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
is on
On Sat, 2014-01-18 at 08:59 -0500, Alan Stern wrote:
> On Fri, 17 Jan 2014, Dan Williams wrote:
>
> > > The basic idea of using runtime PM synchronization to prevent khubd and
> > > port power operations from interfering sounds good, and it is simpler
> > > than adding a new mutex. And I think we
On 21/01/2014 09:12, Bo Shen :
> Hi J,
>
> On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 11:39 Mon 20 Jan , Bo Shen wrote:
>>> Hi J,
>>>
>>> On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:59 Fri 17 Jan , Bo Shen wrote:
> In sama5d3 So
Here is kernel message:
[2.939251] usb 1-1: new high-speed USB device number 2 using ehci-pci
[ 18.490987] usb 1-1: device not accepting address 2, error -110
[ 18.595095] usb 1-1: new high-speed USB device number 3 using ehci-pci
[ 34.182233] usb 1-1: device not accepting address 3, err
> The lock hangs off the usb_device rather than the the usb_port since it
> is meant to prevent unintended disconnects. Any portstatus vs khubd
> collisions are handled by pm runtime synchronization since there is no
> expectation that khubd resumes a usb_port.
>
> Once khubd has made a determinat
Hi,
When using the USB serial gadget it regularly occurs that USB packets
arrive at the host in the wrong order. I am using kernel version 3.4
with the corresponding RT patch on an ARM Cortex-A8 platform.
The problem appears to be in file 'drivers/usb/gadget/u_serial.c'.
It seems that kernel thr
Hi,
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Marco Zamponi
>
> Hi!
> Sorry, I posted before but forgot the subject.
> I am running the test application "ffs-test.c" in user space and I
> want to
> write the descr
From: Sarah Sharp
> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
...
> > A guess...
> >
> > In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
> > of xhci_td_remainder().
>
> Why? Walt has a 0.96 xHCI host controller, and the format for how to
> calculate the TD r
From: Sarah Sharp [
> On Thu, Jan 16, 2014 at 10:21:11AM +, David Laight wrote:
> > From: David Laight
> > > From: David Laight
...
> > > Below is a possible patch, I've only compile tested it.
> > > I've minimalised the patch by not removing all the code that saves
> > > 'start_trb' and modif
Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
do not return from probe if the USB PHY library returns -ENODEV as that
indicates the platform does not have PHY.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/core.c | 34 ++
1
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to
On Tue, Jan 21, 2014 at 01:21:51PM +0800, Peter Chen wrote:
> On Mon, Jan 20, 2014 at 09:13:11AM +0800, Peter Chen wrote:
> > The idea of this message is: the non-ep0 should not use ctrl
> > transfer. But it does not cover the ep0in which uses ctrl
> > transfer too.
> >
> > This commit deletes the
Don't trace short receives if URB_SHORT_NOT_OK is set.
Short receives are normal for USB ethernet devices.
Don't trace unexpected incomplete receives if XHCI_TRUST_TX_LENGTH is set.
Ratelimit the trace.
Signed-off-by: David Laight
---
If these two traces ever happen, then they will happen for ev
On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
> Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> do not return from probe if the USB PHY library returns -ENODEV as that
> indicates the platform does not have PHY.
>
> Signed-off-by: Kishon Vijay Abraham I
Reviewed
Hi Kishon,
On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
> power_on and power_off the following APIs are used phy_init(), phy_exit(),
> phy_power_on() and phy_power_off().
>
> However using the old USB phy library wo
I'm sorry forgot kernel version: 3.13.0 .
--
Chris Cheng 鄭宇廷
Atrust Computer Corp. 冠信電腦股份有限公司
http://www.atrustcorp.com
Tel: +886-3-3288837 ext.1074
3F., No.361, Fusing 1st Rd., Gueishan Township, Taoyuan County 333, Taiwan
333 桃園縣龜山鄉復興一路361號3F
2014/1/21 Chris Cheng :
> Here is kernel message:
libusbg 0.1.0 is released. libusbg is a library that provides a C API to
the kernel USB gadget configfs API. It simplifies creation and
management of USB gadget devices from C applications.
Get it at:
git://github.com/libusbg/libusbg.git
API docs at:
http://libusbg.github.com/gr
On Thu, Nov 07, 2013 at 12:55:04PM -0500, Alan Ott wrote:
> On 11/06/2013 08:04 AM, Stanislaw Wadas wrote:
> >In reference to the message sent by Andrzej Pietrasiewicz
> >(about libusbg (formerly libgadget)) I would like to propose
> >some changes to libusbg.
> >
> >Creating directories is now perf
On Wed, Nov 06, 2013 at 02:04:40PM +0100, Stanislaw Wadas wrote:
> 256 hard coded value has been replaced by two defined
> constants MAX_LENGTH and MAX_PATH_LENGTH
In both the patch summary and commit message, please remember to use
present tense as Alan pointed out. e.g.:
"
Subject: [PATCH v4 1/
Also, there's something wrong with how you are sending your series.
This cover letter is broken and showing only a 2 part series but you've
posted a 4 part series. Please fix this for v5.
-Matt
On Wed, Nov 06, 2013 at 02:04:39PM +0100, Stanislaw Wadas wrote:
> In reference to the message sent by
On Thu, Jan 02, 2014 at 05:13:30PM +0100, Krzysztof Opasiak wrote:
> Dear Matt,
>
> Please excuse me my passivity after discussuon about libusbg some time ago.
> I had to close some other issues before taking up this one.
>
> Recently I looked into code of libusbg, build it and found some errors
On Tue, Jan 21, 2014 at 03:41:38PM +0530, Kishon Vijay Abraham I wrote:
> Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> do not return from probe if the USB PHY library returns -ENODEV as that
this isn't correct, they all have PHYs, some of them might not be
controllable
On Thu, Jan 02, 2014 at 05:13:31PM +0100, Krzysztof Opasiak wrote:
> Surround header with include guards to protect against
> multiple inclusion.
>
> Signed-off-by: Krzysztof Opasiak
> ---
> include/gadget/gadget.h |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/gadget/g
Hi,
On Tue, Jan 21, 2014 at 10:35:54AM +0100, Philip Philippe wrote:
> Hi,
>
> When using the USB serial gadget it regularly occurs that USB packets
> arrive at the host in the wrong order. I am using kernel version 3.4
> with the corresponding RT patch on an ARM Cortex-A8 platform.
>
> The prob
After about 3 iterations as an RFC, I'm elevating this to a patch. If
it works, I'll try for this merge window with a delayed backport to
stable (after the next kernel release to make sure no bugs got
introduced).
This set should fix our target problems with USB by making the target
visibility pr
In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it. In this case,
because the reap checks for STARGET_CREATED and kills the target wi
This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs. The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible. This
ensures that the t
On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote:
> On Wed, 15 Jan 2014, Dennis New wrote:
>
> > When listening to my usb-bluetooth audio headset, the usb subsystem
> > (I think) on my laptop crashes, the bluetooth/audio is lost, and my
> > mplayer program is left in an "uninterruptible
This uses the already documented devicetree booleans for this.
Signed-off-by: Hans de Goede
---
drivers/usb/host/Kconfig | 3 +++
drivers/usb/host/ehci-platform.c | 33 +++--
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/Kco
Note this commit uses the same devicetree booleans for this as the ones
already existing in the usb-ehci bindings.
Signed-off-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 3 +++
drivers/usb/host/Kconfig | 4
drivers/usb/host/ohci-pla
On Tue, 21 Jan 2014, Hans de Goede wrote:
> Note this commit uses the same devicetree booleans for this as the ones
> already existing in the usb-ehci bindings.
>
> Signed-off-by: Hans de Goede
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -512,6 +512,10 @@ config USB_C
Hello.
On 01/15/2014 10:24 PM, Hans de Goede wrote:
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should allow using ohci-platform from devicetree in various cas
Hi,
On 01/21/2014 05:40 PM, Alan Stern wrote:
On Tue, 21 Jan 2014, Hans de Goede wrote:
Note this commit uses the same devicetree booleans for this as the ones
already existing in the usb-ehci bindings.
Signed-off-by: Hans de Goede
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kco
The ring write pointer has to be left pointing at any LINK TRB
when all the TRB for a TD have been added.
This is currently acheived by advancing past a LINK in prepare_ring()
and conditonally by queue_trb() (actually inc_enq) after writing the TRB
if the caller passed 'more_trbs_coming = true'.
I
Some xhci controllers (eg ASMedia) don't like processing a LINK TRB
when they don't own the linked-to TRB.
I think this can happen due to timing races between the host cpu and the
controller even when the driver is single-threading transfers.
This happens a lot more often with the patch that pads
The 'cleanup' code at the bottom of xhci_queue_isoc_tx() can never be executed.
For 'i != 0' on an ISOC ring prepare_transfer can only fail if the endpoint
ring cannot be determined, but it was found only moments earlier (it could
be passed as a parameter).
The 'running_total' check is just check
prepare_transfer() looks up the endpoint ring structure, however
the caller already knows it.
Save code and an error test that can never fail by passing the ring
address instead of the stream_id.
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 18 +-
1 file change
Now that queue_trb() generates the correct TRB_CYCLE value for all
commands, there is no need for the callers to worry about it.
Remove all the code from xhci_queue_bulk_tx() that remembered
the location of the first TRB and its cycle bit.
Also remove related variables that used to be passed to gi
Some xhci controllers (eg ASMedia) don't like processing a LINK TRB and
then finding that they can't process the next TRB.
Instead of flipping the cycle bit on the first data TRB, remember the
real first TRB in prepare_ring() and flip that in giveback_first_trb().
In queue_trb() ignore the cycle
> This patchset brings up USB Host ports and Ethernet port on
> the OMAP5 uEVM board.
I'd keep hold of this and send it out again when the merge-window is
closed.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twi
On Mon, Jan 20, 2014 at 02:45:11PM -0600, Felipe Balbi wrote:
> If the HW reports the endpoint as Halted, there's
> no need to start any URB for that endpoint, we can
> simply return -EPIPE and this will tell upper layers
> that the endpoint is, indeed, halted.
>
> This patch fixes usbtest's set/c
Hi,
On 01/21/2014 06:59 PM, Sergei Shtylyov wrote:
Hello.
On 01/15/2014 10:24 PM, Hans de Goede wrote:
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should all
On Tue, Jan 21, 2014 at 09:39:12AM -0800, Sarah Sharp wrote:
> On Mon, Jan 20, 2014 at 02:45:11PM -0600, Felipe Balbi wrote:
> > If the HW reports the endpoint as Halted, there's
> > no need to start any URB for that endpoint, we can
> > simply return -EPIPE and this will tell upper layers
> > that
On Tue, 21 Jan 2014, Sarah Sharp wrote:
> On Mon, Jan 20, 2014 at 02:45:11PM -0600, Felipe Balbi wrote:
> > If the HW reports the endpoint as Halted, there's
> > no need to start any URB for that endpoint, we can
> > simply return -EPIPE and this will tell upper layers
> > that the endpoint is, in
On Tue, 21 Jan 2014, Hans de Goede wrote:
> Hi,
>
> On 01/21/2014 05:40 PM, Alan Stern wrote:
> > On Tue, 21 Jan 2014, Hans de Goede wrote:
> >
> >> Note this commit uses the same devicetree booleans for this as the ones
> >> already existing in the usb-ehci bindings.
> >>
> >> Signed-off-by: Han
Hi,
On Tue, Jan 21, 2014 at 01:06:19PM -0500, Alan Stern wrote:
> > You could try to differentiate between an endpoint halt that requires a
> > manual cleanup, and ones that the upper layer should handle, perhaps by
> > adding a new EP_HALTED_MANUAL flag. The driver could accept URBs for
> > the
On Tue, Jan 21, 2014 at 12:02:56PM +, David Laight wrote:
> Don't trace short receives if URB_SHORT_NOT_OK is set.
> Short receives are normal for USB ethernet devices.
>
> Don't trace unexpected incomplete receives if XHCI_TRUST_TX_LENGTH is set.
> Ratelimit the trace.
Your patch does more t
On Tue, Jan 21, 2014 at 10:00:40AM +, David Laight wrote:
> From: Sarah Sharp [
> > On Thu, Jan 16, 2014 at 10:21:11AM +, David Laight wrote:
> > > From: David Laight
> > > > From: David Laight
> ...
> > > > Below is a possible patch, I've only compile tested it.
> > > > I've minimalised t
Hi Chris,
We think the Baytrail BIOS has an issue where it doesn't set the EHCI
PCI interrupt enable bit when the computer is in "EHCI only mode".
Please try this patch:
http://marc.info/?l=linux-usb&m=138998295909608&w=2
Sarah Sharp
On Tue, Jan 21, 2014 at 10:04:41PM +0800, Chris Cheng wrote:
2014/1/14 Florian Fainelli :
> Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
> changed the ENETDMA[CS] macros such that they are no longer macros, but
> actual register offset definitions. The bcm63xx_udc driver was not
> updated, and as a result, causes the following build
On Tue, 21 Jan 2014, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jan 21, 2014 at 01:06:19PM -0500, Alan Stern wrote:
> > > You could try to differentiate between an endpoint halt that requires a
> > > manual cleanup, and ones that the upper layer should handle, perhaps by
> > > adding a new EP_HALTED_M
2014/1/21 Hans de Goede :
> This uses the already documented devicetree booleans for this.
(I would greatly appreciate if you could CC people who gave you
feedback on this before)
A more informative commit message would be welcome, along with a
reference to which Device Tree binding documentation
When vhci_hcd is enabled, the following message floods the dmesg buffer.
This message doesn't provide any useful information other than cluttering
the dmesg buffer. Fix it by removing the message. There is another debug
message in this routine that dumps detailed port status change information.
[
2014/1/21 Alan Stern :
> On Tue, 21 Jan 2014, Hans de Goede wrote:
>
>> Hi,
>>
>> On 01/21/2014 05:40 PM, Alan Stern wrote:
>> > On Tue, 21 Jan 2014, Hans de Goede wrote:
>> >
>> >> Note this commit uses the same devicetree booleans for this as the ones
>> >> already existing in the usb-ehci bindin
I have applied the patches to a0fa1dd3cdbccec9597fe53b6177a9aa6e20f2f8:
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 53c2e29..64c36fe 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3008,7 +3008,7 @@ static int prepare_ring(struct
Hi all,
After spending more time experimenting and trying to solve this
problem, we have sort-of come to a conclusion. In case anyone else
finds it interesting, I thought I should share it here.
Our findings can be summarized as follows:
- The problem is triggered by the switch from 3G to 2G. I
On Sat, Jan 18, 2014 at 10:49:17PM +0100, Arnaud Ebalard wrote:
> Hi,
>
> I have added Thomas in the recipients, because I guess he may be of some
> help debugging the issue further. Thomas, the beginning of the thread is
> here: http://thread.gmane.org/gmane.linux.usb.general/101531
...
> I sta
On Tue, Jan 21, 2014 at 12:11:39PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jan 21, 2014 at 01:06:19PM -0500, Alan Stern wrote:
> > > You could try to differentiate between an endpoint halt that requires a
> > > manual cleanup, and ones that the upper layer should handle, perhaps by
> > > addi
On Tue, 21 Jan 2014, Dan Williams wrote:
> > > We want to:
> > >
> > > 1/ prevent khubd from running while reset is in progress
> >
> > This is the open question mentioned above, if you add in the
> > requirement that we also want to prevent a reset from starting while
> > khubd is running (exce
On 01/21/2014 01:51 AM, David Laight wrote:
> From: Sarah Sharp
>> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> ...
>>> A guess...
>>>
>>> In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
>>> of xhci_td_remainder().
>>
>> Why? Walt has a 0.96 xHCI host controll
On Tue, 21 Jan 2014, Milan Svoboda wrote:
> I have applied the patches to a0fa1dd3cdbccec9597fe53b6177a9aa6e20f2f8:
> The kernel logs:
>
> [ 114.854464] usb 3-1: new high-speed USB device number 2 using xhci_hcd
> [ 114.920229] usbcore: registered new interface driver usb-storage
> [ 114.9206
On Tue, 21 Jan 2014, Sarah Sharp wrote:
> Ah, I think I see what's happening.
>
> The xHCI driver is not designed to execute transfers after a stall on a
> non-control endpoint until xhci_endpoint_reset is called and the driver
> fixes up the endpoint ring. That will happen in usb_clear_halt().
On Tue, Jan 21, 2014 at 2:05 PM, Alan Stern wrote:
> On Tue, 21 Jan 2014, Dan Williams wrote:
>
>> > > We want to:
>> > >
>> > > 1/ prevent khubd from running while reset is in progress
>> >
>> > This is the open question mentioned above, if you add in the
>> > requirement that we also want to pre
[1.] 174c:5106 1 TB External USB 3.0 Drive Fails to Automount through
USB 3.0 dock with XHCI Enabled
[2.] I have a 1 TB Western Digital drive in a USB 3.0 HDD dock that will
not automount while XHCI is enabled in the BIOS. If I disable XHCI in
the BIOS, it automounts normally. I've tried an ex
On Tue, Jan 21, 2014 at 11:20:09AM -0800, Florian Fainelli wrote:
> 2014/1/14 Florian Fainelli :
> > Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
> > changed the ENETDMA[CS] macros such that they are no longer macros, but
> > actual register offset definitions. The bcm63xx
2014/1/21 Greg KH :
> On Tue, Jan 21, 2014 at 11:20:09AM -0800, Florian Fainelli wrote:
>> 2014/1/14 Florian Fainelli :
>> > Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
>> > changed the ENETDMA[CS] macros such that they are no longer macros, but
>> > actual register offse
Hi Sarah,
The patch is useful, thanks for your help.
Thanks.
--
Chris Cheng 鄭宇廷
Atrust Computer Corp. 冠信電腦股份有限公司
http://www.atrustcorp.com
Tel: +886-3-3288837 ext.1074
3F., No.361, Fusing 1st Rd., Gueishan Township, Taoyuan County 333, Taiwan
333 桃園縣龜山鄉復興一路361號3F
2014/1/22 Sarah Sharp :
>
On 01/21/2014 04:51 PM, Jay S wrote:
> [1.] 174c:5106 1 TB External USB 3.0 Drive Fails to Automount through USB 3.0
> dock with XHCI Enabled
> [10823.816255] usb 4-5.3: Manufacturer: ASMedia
I'm interested in ASMedia usb3 bugs :)
> [4.] Linux version 3.13.0-031300-generic
You're running a ble
Hi,
On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros wrote:
> Hi Kishon,
>
> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
>> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
>> power_on and power_off the following APIs are used phy_init(), phy_exit(),
>> phy_power_on
69 matches
Mail list logo
