Re: USB sound auto-suspend not working
On Tue, 2013-12-17 at 14:55 -0800, Sarah Sharp wrote: Hi Oliver and Takashi, I've noticed that in the last couple kernel releases or so, I can't get USB webcams to suspend. It turns out that the USB sound interface is keeping the device active, even when the device is not playing sound. This goes back as far as 3.10, but I haven't tried older kernels. This is testing on Ubuntu 13.10. Commit 88a8516a2128a6d078a106ead48092240e8a138f ALSA: usbaudio: implement USB autosuspend went into kernel 2.6.39. The commit message says the device is prevented from suspending if the pcm or midi channel files are open. I plugged in a USB speaker, and ran lsof to see which files were open (output is attached). AFAICT, only the USB sound device's control files are open, and I don't have any midi files. Is that sensible? In case of a webcam the problem is input, not output. Regards Oliver -- 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
XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
Greetings, I have an HP EliteBook 8560p, I am running Linux kernel 3.12.3, and I am trying to connect a WDC MyBook 1230 3TB SuperSpeed USB hard drive to the notebook. I am often (though not consistently) having problems with the access to the drive stalling for several seconds, and the kernel resetting the device afterwards: usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd xhci_hcd :26:00.0: xHCI xhci_drop_endpoint called with disabled ep 880412adf480 xhci_hcd :26:00.0: xHCI xhci_drop_endpoint called with disabled ep 880412adf4c0 Sometimes a single kernel-issued reset is enough to allow the disk to be accessed without problems until physically disconnected, in another instances, this problem simply repeats itself as the drive is accessed. When the drive decides to cooperate, the transmission speeds are stable and solid - in excess of 120 MB/s. So far, I have not been able to pinpoint the exact circumstances under which the problem remains persistent even across kernel-issued USB resets. I am attaching a series of outputs: - dmesg output after the drive was connected and a gdisk -l /dev/sdb command was issued to print out the partition table of the disk, prompting the problem to appear - lspci and lspci -v outputs - lsusb and lsusb -v outputs - usbmon capture, logging the entire session with the drive being connected to the notebook, and issuing gdisk -l /dev/sdb command as noted above Any and all help is greatly appreciated! I will gladly perform whatever experiments are necessary to track down the cause of this problem. Best regards, Peter files.tar.bz2 Description: application/bzip
About SRP and HNP features at OTG descriptor
Hi Felipe, According to the newest OTG EH spec (On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification July 27, 2012 Revision 2.0 version 1.1a), the OTG descriptor is needed for B device, even for peripheral-only B device (see chapter 6.1 OTG Descriptor). At current code, otg_descriptor is only included at descriptors when CONFIG_USB_OTG is defined, and .bmAttributes is assigned as (USB_OTG_SRP | USB_OTG_HNP) at otg descriptor, so for EH B-ports, OTG B-devices, and Peripheral-only B-devices, we have to enable CONFIG_USB_OTG, and declare us as SRP and HNP capable. My question is: do we need to support SRP and HNP at current dual-role switch udc driver as well as enable CONFIG_USB_OTG or we include otg_descriptor unconditionally, and only add CONFIG_USB_OTG for .bmAttributes = USB_OTG_SRP | USB_OTG_HNP at code? Thanks. -- Best Regards, Peter Chen -- 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] xhci: fix array index out of the bounds in function last_trb() and last_trb_on_last_seg()
Then the inc_deq() code could just be:
ring-deq_updates++;
ring-num_trbs_free++;
if (last_trb(xhci, ring, ring-deq_seg, ++ring-dequeue)) {
ring-deq_seg = ring-deq_seg-next;
ring-dequeue = ring-deq_seg-trbs;
if (ring-deq_seg == ring-first_seg) /* not sure of name */
ring-cycle_state ^= 1;
}
The cycle state is only changed when the enqueue pointer makes it past
the segment with the toggle bit. It shouldn't be modified for the
dequeue pointer.
Except for the event ring.
I did think that was a quick rewrite of the existing functionality.
Really the code for the event and command rings needs separating completely.
It would all then be clearer.
And yes, inc_deq() could do with some simplification. David, are you
interested in creating a patch to simplify this code? I haven't gotten
v2 revisions from a couple of patches you previously sent, so I wasn't
sure if you're still interested in creating xHCI patches.
I will sort out my existing patches hopefully today.
git managed to trash my source tree and I've been busy fixing some
of my own code.
I was waiting for the patches I'd posted to get processed before
adding many more. Otherwise it all gets completely out of hand.
Also I've dropped you (Sarah) from the mail address list, our work email
server is getting very strange bounces for linux.intel.com and I think
the list carefully avoids delivering mails to addresses in the mail itself.
David
--
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] usb: dwc3: ep0: Handle variable-length Data Stage
Hi Anton, On Wed, Dec 18, 2013 at 12:11:33PM +0800, Felipe Balbi wrote: Hi, On Tue, Dec 17, 2013 at 03:59:31PM +0900, Anton Tikhomirov wrote: In accordance with specification, when sent data length is please mention section of specification. an exact multiple of wMaxPacketSize for the pipe and less than requested by host, the function shall return a zero-length packet (ZLP) to indicate the end of the Data stage to a USB host. hmm... so in USB3 mode that would be host requesting 513 bytes and us sending only 512. Curious, what was the use case when you encountered above situation? Wouldn't something simple as follows be able to resolve it? diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 95f7649..8b419aa 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -924,6 +924,10 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc, ret = dwc3_ep0_start_trans(dwc, dep-number, req-request.dma, req-request.length, DWC3_TRBCTL_CONTROL_DATA); + if (req-zero !ret) + ret = dwc3_ep0_start_trans(dwc, dep-number, + dwc-ctrl_req_addr, 0, + DWC3_TRBCTL_CONTROL_DATA); } WARN_ON(ret 0); Regards Pratyush -- 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] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.9+
---
drivers/mfd/omap-usb-tll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0d946ae1..248004c 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -346,7 +346,9 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
for (i = 0; i tll-nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
if (needs_tll) {
void __iomem *base = tll-base;
@@ -398,9 +400,8 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
@@ -420,7 +421,9 @@ int omap_tll_enable(struct usbhs_omap_platform_data *pdata)
tll = dev_get_drvdata(tll_dev);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
@@ -438,7 +441,6 @@ int omap_tll_enable(struct usbhs_omap_platform_data *pdata)
}
spin_unlock(tll_lock);
-
return 0;
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
@@ -464,9 +466,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data *pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
--
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 1/2] usb: usbtest: Add timetout to simple_io()
Without a timetout some tests e.g. test_halt() can remain stuck forever.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/misc/usbtest.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index b415282..6294e1b 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -10,6 +10,7 @@
#include linux/usb.h
+#define SIMPLE_IO_TIMEOUT 1 /* in milliseconds */
/*-*/
@@ -366,6 +367,7 @@ static int simple_io(
int max = urb-transfer_buffer_length;
struct completion completion;
int retval = 0;
+ unsigned long expire;
urb-context = completion;
while (retval == 0 iterations-- 0) {
@@ -378,9 +380,15 @@ static int simple_io(
if (retval != 0)
break;
- /* NOTE: no timeouts; can't be broken out of by interrupt */
- wait_for_completion(completion);
- retval = urb-status;
+ expire = msecs_to_jiffies(SIMPLE_IO_TIMEOUT);
+ if (!wait_for_completion_timeout(completion, expire)) {
+ usb_kill_urb(urb);
+ retval = (urb-status == -ENOENT ?
+ -ETIMEDOUT : urb-status);
+ } else {
+ retval = urb-status;
+ }
+
urb-dev = udev;
if (retval == 0 usb_pipein(urb-pipe))
retval = simple_check_buf(tdev, urb);
--
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] usb: usbtest: Always clear halt else further tests will fail
In test_halt() we set an endpoint halt condition and return on halt verification
failure, then the enpoint will remain halted and all further tests related
to that enpoint will fail. This is because we don't tackle endpoint halt error
condition
in any of the tests. To avoid that situation, make sure to clear the
halt condition before exiting test_halt().
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/misc/usbtest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 6294e1b..300b726 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int ep,
struct urb *urb)
return retval;
}
retval = verify_halted(tdev, ep, urb);
- if (retval 0)
+ if (retval 0) {
+ int ret;
+
+ /* clear halt anyways, else further tests will fail */
+ ret = usb_clear_halt(urb-dev, urb-pipe);
+ if (ret)
+ ERROR(tdev, ep %02x couldn't clear halt, %d\n,
+ ep, ret);
+
return retval;
+ }
/* clear halt (tests API + protocol), verify it worked */
retval = usb_clear_halt(urb-dev, urb-pipe);
--
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] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.9+
---
drivers/mfd/omap-usb-tll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0d946ae1..248004c 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -346,7 +346,9 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
for (i = 0; i tll-nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
This is pretty ugly. Can't you move it above the spin_lock() instead?
snip
tll = dev_get_drvdata(tll_dev);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
Same here?
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
@@ -438,7 +441,6 @@ int omap_tll_enable(struct usbhs_omap_platform_data
*pdata)
}
spin_unlock(tll_lock);
-
This doesn't belong in this patch and is now inconsistent with the
other functions in the driver.
return 0;
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
@@ -464,9 +466,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data
*pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
[RFC 5/5] usb: dwc3: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3 device (the parent of xhci-plat) in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3 driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/core.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 59bb8d2..9c8a273 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -586,6 +586,8 @@ static int dwc3_probe(struct platform_device *pdev) pm_runtime_allow(dev); + device_enable_async_suspend(dev); + return 0; err3: -- 1.7.9.5 -- 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
[RFC 3/5] usb: xhci-plat: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the XHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to suspend and resume asynchronously. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/host/xhci-plat.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 8abda5c..1bc1565 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -162,6 +162,8 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + device_enable_async_suspend(pdev-dev); + return 0; put_usb3_hcd: -- 1.7.9.5 -- 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
[RFC 4/5] usb: dwc3-exynos: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3-exynos platform device in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3-exynos driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/dwc3-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 8b20c70..57431b7 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -155,6 +155,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev) goto err2; } + device_enable_async_suspend(dev); + return 0; err2: -- 1.7.9.5 -- 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
[RFC 1/5] usb: ohci-exynos: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the Exynos OHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to suspend and resume asynchronously. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/host/ohci-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index 68588d8..faad2bdc 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -137,6 +137,8 @@ skip_phy: if (exynos_ohci-otg) exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self); + device_enable_async_suspend(pdev-dev); + platform_set_drvdata(pdev, hcd); exynos_ohci_phy_enable(pdev); -- 1.7.9.5 -- 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
[RFC 2/5] usb: ehci-s5p: enable async suspend/resume
From: Andrew Bresticker abres...@chromium.org USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the Exynos EHCI controller has no outside dependencies (other than clocks, which are suspended late/resumed early), allow it to suspend and resume asynchronously. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/host/ehci-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index f7ce8e2..e5125cd 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -165,6 +165,8 @@ skip_phy: } device_wakeup_enable(hcd-self.controller); + device_enable_async_suspend(pdev-dev); + platform_set_drvdata(pdev, hcd); return 0; -- 1.7.9.5 -- 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 v3] usb: xhci Use TRB_CYCLE instead of the constant 0x1.
Using TRB_CYCLE makes it clearer that the ring-cycle_state value is used when
writing to the actual ring itself.
Always use ^= TRB_CYCLE to invert the bit.
Revert the part of 186a7ef13a8f (xHCI: set cycle state when allocate rings)
that passed the cycle state to xhci_ring_alloc() and xhci_initialize_ring_info()
as these are only called for new rings and always passed 1 (TRB_CYCLE).
Signed-off-by: David Laight david.lai...@aculab.com
---
Changes for v2:
1: Adjusted so that is applies to HEAD
2: Added signed-off
Changes for v3:
1: Changed for additional lines (assignd to new_cycle_state).
2: Removed the cycle_state parameter - also shortens some overlong lines.
drivers/usb/host/xhci-mem.c | 37 ++---
drivers/usb/host/xhci-ring.c | 22 +++---
drivers/usb/host/xhci.c | 2 +-
3 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 49b8bd0..706b530 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -161,8 +161,7 @@ void xhci_ring_free(struct xhci_hcd *xhci, struct xhci_ring
*ring)
kfree(ring);
}
-static void xhci_initialize_ring_info(struct xhci_ring *ring,
- unsigned int cycle_state)
+static void xhci_initialize_ring_info(struct xhci_ring *ring)
{
/* The ring is empty, so the enqueue pointer == dequeue pointer */
ring-enqueue = ring-first_seg-trbs;
@@ -173,10 +172,9 @@ static void xhci_initialize_ring_info(struct xhci_ring
*ring,
* bit to handover ownership of the TRB, so PCS = 1. The consumer must
* compare CCS to the cycle bit to check ownership, so CCS = 1.
*
-* New rings are initialized with cycle state equal to 1; if we are
-* handling ring expansion, set the cycle state equal to the old ring.
+* New rings are initialized with cycle state equal to 1.
*/
- ring-cycle_state = cycle_state;
+ ring-cycle_state = TRB_CYCLE;
/* Not necessary for new rings, but needed for re-initialized rings */
ring-enq_updates = 0;
ring-deq_updates = 0;
@@ -234,8 +232,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd
*xhci,
* See section 4.9.1 and figures 15 and 16.
*/
static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
- unsigned int num_segs, unsigned int cycle_state,
- enum xhci_ring_type type, gfp_t flags)
+ unsigned int num_segs, enum xhci_ring_type type, gfp_t flags)
{
struct xhci_ring*ring;
int ret;
@@ -251,7 +248,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd
*xhci,
return ring;
ret = xhci_alloc_segments_for_ring(xhci, ring-first_seg,
- ring-last_seg, num_segs, cycle_state, type, flags);
+ ring-last_seg, num_segs, TRB_CYCLE, type, flags);
if (ret)
goto fail;
@@ -261,7 +258,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd
*xhci,
ring-last_seg-trbs[TRBS_PER_SEGMENT - 1].link.control |=
cpu_to_le32(LINK_TOGGLE);
}
- xhci_initialize_ring_info(ring, cycle_state);
+ xhci_initialize_ring_info(ring);
return ring;
fail:
@@ -297,25 +294,19 @@ void xhci_free_or_cache_endpoint_ring(struct xhci_hcd
*xhci,
* pointers to the beginning of the ring.
*/
static void xhci_reinit_cached_ring(struct xhci_hcd *xhci,
- struct xhci_ring *ring, unsigned int cycle_state,
- enum xhci_ring_type type)
+ struct xhci_ring *ring, enum xhci_ring_type type)
{
struct xhci_segment *seg = ring-first_seg;
- int i;
do {
memset(seg-trbs, 0,
sizeof(union xhci_trb)*TRBS_PER_SEGMENT);
- if (cycle_state == 0) {
- for (i = 0; i TRBS_PER_SEGMENT; i++)
- seg-trbs[i].link.control |= TRB_CYCLE;
- }
/* All endpoint rings have link TRBs */
xhci_link_segments(xhci, seg, seg-next, type);
seg = seg-next;
} while (seg != ring-first_seg);
ring-type = type;
- xhci_initialize_ring_info(ring, cycle_state);
+ xhci_initialize_ring_info(ring);
/* td list should be empty since all URBs have been cancelled,
* but just in case...
*/
@@ -597,7 +588,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct
xhci_hcd *xhci,
*/
for (cur_stream = 1; cur_stream num_streams; cur_stream++) {
stream_info-stream_rings[cur_stream] =
- xhci_ring_alloc(xhci, 2, 1, TYPE_STREAM, mem_flags);
+ xhci_ring_alloc(xhci, 2, TYPE_STREAM, mem_flags);
cur_ring =
RE: [PATCH v3] usb: xhci Use TRB_CYCLE instead of the constant 0x1.
From: Of David Laight
Using TRB_CYCLE makes it clearer that the ring-cycle_state value is used when
writing to the actual ring itself.
FWIW this patch is against Linus's tree.
This hunk probably fails to apply to some trees because the patch
to force TRB_CYCLE to be little endian hasn't got there yet.
@@ -297,25 +294,19 @@ void xhci_free_or_cache_endpoint_ring(struct xhci_hcd
*xhci,
* pointers to the beginning of the ring.
*/
static void xhci_reinit_cached_ring(struct xhci_hcd *xhci,
- struct xhci_ring *ring, unsigned int cycle_state,
- enum xhci_ring_type type)
+ struct xhci_ring *ring, enum xhci_ring_type type)
{
struct xhci_segment *seg = ring-first_seg;
- int i;
do {
memset(seg-trbs, 0,
sizeof(union xhci_trb)*TRBS_PER_SEGMENT);
- if (cycle_state == 0) {
- for (i = 0; i TRBS_PER_SEGMENT; i++)
- seg-trbs[i].link.control |= TRB_CYCLE;
- }
/* All endpoint rings have link TRBs */
xhci_link_segments(xhci, seg, seg-next, type);
seg = seg-next;
} while (seg != ring-first_seg);
ring-type = type;
- xhci_initialize_ring_info(ring, cycle_state);
+ xhci_initialize_ring_info(ring);
/* td list should be empty since all URBs have been cancelled,
* but just in case...
*/
David
--
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] xhci: Allocate the td array and urb_priv together.
This saves a kzalloc() call on every transfer and some memory
indirections.
The only possible downside is for isochronous tranfers with 64 td
when the allocate is 8+4096 bytes (on 64bit systems) so requires
an additional page.
Signed-off-by: David Laight david.lai...@aculab.com
---
v2: Added signed-off-by line
drivers/usb/host/xhci-mem.c | 4 +---
drivers/usb/host/xhci-ring.c | 22 ++
drivers/usb/host/xhci.c | 24 ++--
drivers/usb/host/xhci.h | 2 +-
4 files changed, 18 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 79cdcc2..9b5d1c3 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1675,10 +1675,8 @@ struct xhci_command *xhci_alloc_command(struct xhci_hcd
*xhci,
void xhci_urb_free_priv(struct xhci_hcd *xhci, struct urb_priv *urb_priv)
{
- if (urb_priv) {
- kfree(urb_priv-td[0]);
+ if (urb_priv)
kfree(urb_priv);
- }
}
void xhci_free_command(struct xhci_hcd *xhci,
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e38abc2..d3f4a9a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3007,7 +3007,7 @@ static int prepare_transfer(struct xhci_hcd *xhci,
return ret;
urb_priv = urb-hcpriv;
- td = urb_priv-td[td_index];
+ td = urb_priv-td[td_index];
INIT_LIST_HEAD(td-td_list);
INIT_LIST_HEAD(td-cancelled_td_list);
@@ -3024,8 +3024,6 @@ static int prepare_transfer(struct xhci_hcd *xhci,
td-start_seg = ep_ring-enq_seg;
td-first_trb = ep_ring-enqueue;
- urb_priv-td[td_index] = td;
-
return 0;
}
@@ -3216,7 +3214,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
return trb_buff_len;
urb_priv = urb-hcpriv;
- td = urb_priv-td[0];
+ td = urb_priv-td[0];
/*
* Don't give the first TRB to the hardware (by toggling the cycle bit)
@@ -3387,7 +3385,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
return ret;
urb_priv = urb-hcpriv;
- td = urb_priv-td[0];
+ td = urb_priv-td[0];
/*
* Don't give the first TRB to the hardware (by toggling the cycle bit)
@@ -3517,7 +3515,7 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
return ret;
urb_priv = urb-hcpriv;
- td = urb_priv-td[0];
+ td = urb_priv-td[0];
/*
* Don't give the first TRB to the hardware (by toggling the cycle bit)
@@ -3729,7 +3727,7 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci,
gfp_t mem_flags,
goto cleanup;
}
- td = urb_priv-td[i];
+ td = urb_priv-td[i];
for (j = 0; j trbs_per_td; j++) {
u32 remainder = 0;
field = 0;
@@ -3829,20 +3827,20 @@ cleanup:
/* Clean up a partially enqueued isoc transfer. */
for (i--; i = 0; i--)
- list_del_init(urb_priv-td[i]-td_list);
+ list_del_init(urb_priv-td[i].td_list);
/* Use the first TD as a temporary variable to turn the TDs we've queued
* into No-ops with a software-owned cycle bit. That way the hardware
* won't accidentally start executing bogus TDs when we partially
* overwrite them. td-first_trb and td-start_seg are already set.
*/
- urb_priv-td[0]-last_trb = ep_ring-enqueue;
+ urb_priv-td[0].last_trb = ep_ring-enqueue;
/* Every TRB except the first last will have its cycle bit flipped. */
- td_to_noop(xhci, ep_ring, urb_priv-td[0], true);
+ td_to_noop(xhci, ep_ring, urb_priv-td[0], true);
/* Reset the ring enqueue back to the first TRB and its cycle bit. */
- ep_ring-enqueue = urb_priv-td[0]-first_trb;
- ep_ring-enq_seg = urb_priv-td[0]-start_seg;
+ ep_ring-enqueue = urb_priv-td[0].first_trb;
+ ep_ring-enq_seg = urb_priv-td[0].start_seg;
ep_ring-cycle_state = start_cycle;
ep_ring-num_trbs_free = ep_ring-num_trbs_free_temp;
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus), urb);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6e0d886..0969f74 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1248,12 +1248,11 @@ static int xhci_check_maxpacket(struct xhci_hcd *xhci,
unsigned int slot_id,
int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flags)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- struct xhci_td *buffer;
unsigned long flags;
int ret = 0;
unsigned int slot_id, ep_index;
struct urb_priv *urb_priv;
- int size, i;
+ int size;
if (!urb || xhci_check_args(hcd, urb-dev, urb-ep,
Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
On Wed, Dec 18, 2013 at 9:41 AM, Andreas Naumann d...@andin.de wrote:
Am 17.12.2013 18:22, schrieb David Cohen:
On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:
From: Andreas Naumann anaum...@ultratronik.de
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it has not been
initialized yet.
Signed-off-by: Andreas Naumann anaum...@ultratronik.de
---
Even though I find the implementation a bit awkward this should fix
the issue without breaking anything else. Hope everyone is happy
with this.
drivers/usb/musb/omap2430.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..fbe2c08 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -48,6 +48,7 @@ struct omap2430_glue {
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
struct device *control_otghs;
+ u8 initialized;
};
#define glue_to_musb(g) platform_get_drvdata(g-musb)
@@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
}
musb_writel(musb-mregs, OTG_INTERFSEL, l);
+ glue-initialized = 1;
pr_debug(HS USB OTG: revision 0x%x, sysconfig 0x%02x,
sysstatus 0x%x, intrfsel 0x%x, simenable
0x%x\n,
@@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device
*pdev)
glue-dev = pdev-dev;
glue-musb = musb;
glue-status= OMAP_MUSB_UNKNOWN;
+ glue-initialized = 0;
You don't need to do this. 'glue' was already allocated with kzalloc().
ok
if (np) {
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata),
GFP_KERNEL);
@@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device
*dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb-mregs, OTG_INTERFSEL,
+ if(glue-initialized)
Are you sure this is thread safe?
If you're sending this patch it means runtime_resume can be called
before omap2430_must_init(), but how about at the same time?
No, the problem is that omap2430_runtime_resume() is called _during_
omap2430_must_init(), when pm_runtime_get_sync() is called. We can't
read the initial register value before pm_runtime_get_sync() returns
because the hardware is not powered up, and from pm_runtime_get_sync()
omap2430_runtime_resume() is called, where the cached register value
is needed.
You defined 'initialized' as u8 type, then read/write operations won't
be atomic in ARM.
We would only have problems if runtime_suspend() and runtime_resume()
are called at the same time, can this really happed?
Grazvydas
--
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: xhci: Add a 2nd memory barrier to giveback_first_trb()
Add a wmb() barrier between the write to the cycle bit in the first TRB and the write to the doorbell register. Without this the hardware might read the ring entry before the write completes and not action the transfer until the next time a request is added. Since it isn't needed in the other places the doobell is rung (because the ring contents haven't been changed) add it to giveback_first_trb() rather than somewhere later. Signed-off-by: David Laight david.lai...@aculab.com --- Changes for v2: - Comment why the wmb() is needed. drivers/usb/host/xhci-ring.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index ebc2961..6d8b119 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3182,6 +3182,12 @@ static void giveback_first_trb(struct xhci_hcd *xhci, int slot_id, */ wmb(); start_trb-field[3] ^= cpu_to_le32(TRB_CYCLE); + /* +* Ensure that the write above happens before the xhci hardware reads +* the ring following the write to the doorbell register below. +* This is the only critical write to the doorbell. +*/ + wmb(); xhci_ring_ep_doorbell(xhci, slot_id, ep_index, stream_id); } -- 1.8.1.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 v2] usb: xhci: Rename xhci_queue_xxx_tx() to xhci_queue_xxx_urb()
The xhci_queue_bulk_tx() function is used for both OUT and IN
transactions, but the name implies that it is only used for transmits.
Rename it to xhci_queue_bulk_urb() to avoid any confusion.
Similarly rename the functions for ctrl, intr and isoc URB.
Rename the existing xhci_queue_isoc_tx() to write_isoc_trbs() to allow
consistent naming.
Signed-off-by: David Laight david.lai...@aculab.com
---
Changes for v2:
- Modified so that it applies before one of my other patches.
(which also needs a v2 now)
drivers/usb/host/xhci-ring.c | 16
drivers/usb/host/xhci.c | 8
drivers/usb/host/xhci.h | 8
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6d8b119..b98031b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3197,7 +3197,7 @@ static void giveback_first_trb(struct xhci_hcd *xhci, int
slot_id,
* (comprised of sg list entries) can take several service intervals to
* transmit.
*/
-int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
+int xhci_queue_intr_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
{
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci,
@@ -3225,7 +3225,7 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
urb-dev-speed == USB_SPEED_FULL)
urb-interval /= 8;
}
- return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
+ return xhci_queue_bulk_urb(xhci, mem_flags, urb, slot_id, ep_index);
}
/*
@@ -3429,7 +3429,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
}
/* This is very similar to what ehci-q.c qtd_fill() does */
-int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
+int xhci_queue_bulk_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
{
struct xhci_ring *ep_ring;
@@ -3562,7 +3562,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
}
/* Caller must have locked xhci-lock */
-int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
+int xhci_queue_ctrl_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
{
struct xhci_ring *ep_ring;
@@ -3749,7 +3749,7 @@ static unsigned int
xhci_get_last_burst_packet_count(struct xhci_hcd *xhci,
}
/* This is for isoc transfer */
-static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
+static int write_isoc_trbs(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
{
struct xhci_ring *ep_ring;
@@ -3930,11 +3930,11 @@ cleanup:
/*
* Check transfer ring to guarantee there is enough room for the urb.
* Update ISO URB start_frame and interval.
- * Update interval as xhci_queue_intr_tx does. Just use xhci frame_index to
+ * Update interval as xhci_queue_intr_urb does. Just use xhci frame_index to
* update the urb-start_frame by now.
* Always assume URB_ISO_ASAP set, and NEVER use urb-start_frame as input.
*/
-int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
+int xhci_queue_isoc_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
{
struct xhci_virt_device *xdev;
@@ -3993,7 +3993,7 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci,
gfp_t mem_flags,
}
ep_ring-num_trbs_free_temp = ep_ring-num_trbs_free;
- return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
+ return write_isoc_trbs(xhci, mem_flags, urb, slot_id, ep_index);
}
/ Command Ring Operations /
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4f378f3..076292f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1302,7 +1302,7 @@ int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb
*urb, gfp_t mem_flags)
spin_lock_irqsave(xhci-lock, flags);
if (xhci-xhc_state XHCI_STATE_DYING)
goto dying;
- ret = xhci_queue_ctrl_tx(xhci, GFP_ATOMIC, urb,
+ ret = xhci_queue_ctrl_urb(xhci, GFP_ATOMIC, urb,
slot_id, ep_index);
if (ret)
goto free_priv;
@@ -1323,7 +1323,7 @@ int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb
*urb, gfp_t mem_flags)
not having streams.\n);
ret = -EINVAL;
} else {
- ret = xhci_queue_bulk_tx(xhci, GFP_ATOMIC, urb,
+ ret = xhci_queue_bulk_urb(xhci, GFP_ATOMIC, urb,
slot_id, ep_index);
}
if (ret)
@@
[PATCH] usb: dwc3: dwc3-omap: Fix the crash in module removal
In the wrapper driver the child nodes are populated using
of_platform_populate(), which does a device_add. So while
removing the module if platform_device_unregister is called
it leads to following crash.
[ 57.676757] Unable to handle kernel NULL pointer dereference at virtual
address 0018
[ 57.685241] pgd = edf7c000
[ 57.687988] [0018] *pgd=add17831, *pte=, *ppte=
[ 57.694488] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 57.699920] Modules linked in: g_mass_storage usb_f_mass_storage
libcomposite configfs wlcore_sdio dwc3_omap(-) pixcir_i2c_ts [last unloaded:
dwc3]
[ 57.713317] CPU: 0 PID: 1580 Comm: rmmod Not tainted
3.12.4-02001-gb1278cc-dirty #21
[ 57.721099] task: ed9f8bc0 ti: edfb task.ti: edfb
[ 57.726562] PC is at release_resource+0x14/0x7c
[ 57.731109] LR is at release_resource+0x10/0x7c
[ 57.735687] pc : [c004e278]lr : [c004e274]psr: 600f0013
[ 57.735687] sp : edfb1eb0 ip : 600f0013 fp : 00021008
[ 57.747192] r10: r9 : edfb r8 : c00142e8
[ 57.752441] r7 : edfb r6 : bf005198 r5 : edd18000 r4 : edfa3e80
[ 57.759002] r3 : r2 : r1 : 0010 r0 : c09bf394
[ 57.765563] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 57.772735] Control: 10c53c7d Table: adf7c059 DAC: 0015
[ 57.778503] Process rmmod (pid: 1580, stack limit = 0xedfb0248)
[ 57.784454] Stack: (0xedfb1eb0 to 0xedfb2000)
[ 57.788848] 1ea0: 0001
edd18000 c03a1870
[ 57.797088] 1ec0: edd18010 edd18000 c03a1b70 bf0051a4
edd18010 c039c86c
[ 57.805297] 1ee0: ed927a40 edd9d9f0 edcc0990 ed97e410 ed97e444 bf00518c
bf005120 ed97e410
[ 57.813507] 1f00: bf005d54 c03a1594 c03a157c c039fe94 bf005d54 ed97e410
bf005d54 c03a0698
[ 57.821746] 1f20: bf005d54 c09e4f90 c039fcbc bf005d98
0800 c00abd2c
[ 57.829956] 1f40: c09c9920 bf005d98 0800 edfb1f44 33637764
616d6f5f 0070
[ 57.838165] 1f60: ed9f8bc0 c0014190 0001 edfb bee6ee08
00021008 c00a36e0
[ 57.846405] 1f80: 00021088 0800 00021088 0081 8010 00021088
0800 00021088
[ 57.854614] 1fa0: 0081 c0014100 00021088 0800 000210b8 0800
c0514b00 c0514b00
[ 57.862823] 1fc0: 00021088 0800 00021088 0081 0001 bee6ebf8
bee6ee08 00021008
[ 57.871032] 1fe0: 43098880 bee6ebb4 b6fd59bc 4309888c 8010 000210b8
0002130c
[ 57.879302] [c004e278] (release_resource+0x14/0x7c) from [c03a1870]
(platform_device_del+0x6c/0x9c)
[ 57.888732] [c03a1870] (platform_device_del+0x6c/0x9c) from [c03a1b70]
(platform_device_unregister+0xc/0x18)
[ 57.898986] [c03a1b70] (platform_device_unregister+0xc/0x18) from
[bf0051a4] (dwc3_omap_remove_core+0xc/0x14 [dwc3_omap])
[ 57.910400] [bf0051a4] (dwc3_omap_remove_core+0xc/0x14 [dwc3_omap]) from
[c039c86c] (device_for_each_child+0x34/0x74)
[ 57.921417] [c039c86c] (device_for_each_child+0x34/0x74) from [bf00518c]
(dwc3_omap_remove+0x6c/0x78 [dwc3_omap])
[ 57.932067] [bf00518c] (dwc3_omap_remove+0x6c/0x78 [dwc3_omap]) from
[c03a1594] (platform_drv_remove+0x18/0x1c)
[ 57.942565] [c03a1594] (platform_drv_remove+0x18/0x1c) from [c039fe94]
(__device_release_driver+0x70/0xc8)
[ 57.952606] [c039fe94] (__device_release_driver+0x70/0xc8) from
[c03a0698] (driver_detach+0xb4/0xb8)
[ 57.962127] [c03a0698] (driver_detach+0xb4/0xb8) from [c039fcbc]
(bus_remove_driver+0x8c/0xd0)
[ 57.971160] [c039fcbc] (bus_remove_driver+0x8c/0xd0) from [c00abd2c]
(SyS_delete_module+0x118/0x22c)
[ 57.980712] [c00abd2c] (SyS_delete_module+0x118/0x22c) from [c0014100]
(ret_fast_syscall+0x0/0x48)
[ 57.990051] Code: e1a04000 e59f0068 eb175e43 e5943010 (e5932018)
[ 57.996368] ---[ end trace 2af5f15c0b475a3d ]---
Replace platform_device_unregister with of_device_unregister.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b269dbd..d241ff3 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -323,7 +323,7 @@ static int dwc3_omap_remove_core(struct device *dev, void
*c)
{
struct platform_device *pdev = to_platform_device(dev);
- platform_device_unregister(pdev);
+ of_device_unregister(pdev);
return 0;
}
--
1.8.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
Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
Hi Dan,
Am 17.12.2013 um 23:27 schrieb Dan Williams:
On Tue, 2013-12-17 at 20:56 +0100, Dr. H. Nikolaus Schaller wrote:
Hi Dan,
Am 16.12.2013 um 20:40 schrieb Dan Williams:
On Fri, 2013-12-13 at 15:43 +0100, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 02.10.2013 um 09:00 schrieb Dr. H. Nikolaus Schaller:
Hi Jan,
we are using a GTM601 modem (Firmware 1.7) for a while and have spotted an
issue that under some conditions the modem sends a packed wIndex over USB
that is rejected by the hso driver making troubles afterwards. Not
rejecting makes
it work fine.
BR,
Nikolaus Schaller
---
From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
From: H. Nikolaus Schaller h...@goldelico.com
Date: Thu, 15 Nov 2012 14:40:57 +0100
Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by
OPTION
GTM601 during RING indication
It has been observed that the GTM601 with 1.7 firmware sometimes sends a
value
wIndex that has bit 0x04 set instead of being reset as the code expects.
So we
mask it for the error check.
See
http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
Signed-off-by: NeilBrown ne...@suse.de
Signed-off-by: H. Nikolaus Schaller h...@goldelico.de
---
drivers/net/usb/hso.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..d146e26 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb *urb)
if (serial_state_notification-bmRequestType != BM_REQUEST_TYPE ||
serial_state_notification-bNotification != B_NOTIFICATION ||
le16_to_cpu(serial_state_notification-wValue) != W_VALUE ||
- le16_to_cpu(serial_state_notification-wIndex) != W_INDEX ||
+ (le16_to_cpu(serial_state_notification-wIndex) ~0x4) !=
+ W_INDEX ||
le16_to_cpu(serial_state_notification-wLength) != W_LENGTH) {
dev_warn(usb-dev,
hso received invalid serial state notification\n);
--
1.7.7.4
I have found this (better) proposal by OPTION, but wonder what did happen
to it.
It neither shows in mainline 3.13-rc nor linux-next:
https://lkml.org/lkml/2013/10/9/263
Likely because nobody formally submitted the patch with a signed-off-by,
which indicates their intent that the patch is tested, correct, and can
be merged to the kernel.
Ok, I see. I just wasn't aware of the proposal at all since I missed the
discussion
and wasn't on CC.
Therefore I have added Eric to the CC.
I looked at this today, and I'm left wondering how any port other than
HSO_PORT_MODEM can get the notification via tiocmget_intr_callback().
serial-tiocmget is only created for HSO_PORT_MODEM serial ports (see
hso_create_bulk_serial_device()):
if ((port HSO_PORT_MASK) == HSO_PORT_MODEM) {
num_urbs = 2;
serial-tiocmget = kzalloc(sizeof(struct hso_tiocmget),
GFP_KERNEL);
and the code in tiocmget_intr_callback() does this:
tiocmget = serial-tiocmget;
if (!tiocmget)
return;
which should mean that only a HSO_PORT_MODEM will ever process the
notification. Further, the tiocmget interrupt URB is only created and
submitted if serial-tiocmget != NULL, so only HSO_PORT_MODEM should
ever be calling into tiocmget_intr_callback().
Ok, that looks plausible.
So I think Eric's patch is actually wrong because it will *always* pass
the new check.
The original code had the correct intention, but the original code was
obviously wrong for newer devices where the port layout is read from
firmware and not from static tables, and thus for recent devices where
the modem interface is not USB interface #2.
This explains why we did run into the problem with the GTM601.
Can you confirm/deny that the 'modem' interface for your GTM601 is USB
interface #6? For example, my Icon 452 has the following USB interface
layout:
0: Diag
1: GPS
2: GPS control
3: Application
4: Control
5: Network
6: Modem
So like the GTM601, I would expect any RING notifications to appear for
wIndex=0x06.
Interestingly I see:
0: Diagnostic
1: GPS
2: GPS Control
3: Application
4: Control
5: Modem
I.e. there is no Network interface. Originally we did focus on /dev/ttyHS3
How are you determining the number here? Are you using:
cat /sys/class/tty/ttyHS_Modem/device/bInterfaceNumber
to determine the actual USB interface number associated with the Modem
port? Or are you going off the pre-udev-rename ttyHSx numbers?
Ah, I did use
root@gta04:~# ls -d /sys/class/tty/ttyHS*; cat /sys/class/tty/ttyHS*/hsotype
/sys/class/tty/ttyHS0 /sys/class/tty/ttyHS1 /sys/class/tty/ttyHS2
/sys/class/tty/ttyHS3 /sys/class/tty/ttyHS4 /sys/class/tty/ttyHS5
Diagnostic
GPS
GPS Control
Application
Control
Modem
With bInterfaceNumber I
[PATCH] usb: phy: am335x: Enable USB remote wakeup using PHY wakeup
USB remote wakeup using PHY wakeup is supported only in standby mode.
Enabling the PHY_WKUP will break DS0 mode of system suspend.
If the same is enabled while entering DS0, AM33xx never stays in DS0,
it returns immediately from DS0. By default make the PHY wakeup
disabled, using sysfs entry enable the same manually to get
the remote wakeup working from standby.
echo enabled /sys/bus/platform/device/usb phy id/power/wakeup
This will enable the PHY wakeup while going to standby.
PHY wakeup feature is required to wakeup the system from standby
state. Since AM33xx has a bug in which PHY wakeup should not
be enabled while entering DS0, disable the same by default.
A user wishing to use USB wakeup from standby mode need to enable
the same using the sysfs entries.
Also remove am335x_phy_runtime_(suspend/resume) this driver doesnot really
enable/disable the clocks to the PHY.
Add am335x_phy_(suspend/resume) and use the same for enabling the PHY_WKUP.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/phy/phy-am335x.c | 46 +---
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index 6370e50..3f78eaf 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -64,6 +64,19 @@ static int am335x_phy_probe(struct platform_device *pdev)
am_phy-usb_phy_gen.phy.shutdown = am335x_shutdown;
platform_set_drvdata(pdev, am_phy);
+ device_init_wakeup(dev, true);
+
+ /*
+* If we leave PHY wakeup enabled then AM33XX wakes up
+* immediately from DS0. To avoid this we mark dev-power.can_wakeup
+* to false. The same is checked in suspend routine to decide
+* on whether to enable PHY wakeup or not.
+* PHY wakeup works fine in standby mode, there by allowing us to
+* handle remote wakeup, wakeup on disconnect and connect.
+*/
+
+ device_set_wakeup_enable(dev, false);
+ phy_ctrl_power(am_phy-phy_ctrl, am_phy-id, false);
return 0;
@@ -78,40 +91,51 @@ static int am335x_phy_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_RUNTIME
-
-static int am335x_phy_runtime_suspend(struct device *dev)
+#ifdef CONFIG_PM_SLEEP
+static int am335x_phy_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct am335x_phy *am_phy = platform_get_drvdata(pdev);
+ /*
+* Enable phy wakeup only if dev-power.can_wakeup is true.
+* Make sure to enable wakeup to support remote wakeup in
+* standby mode ( same is not supported in OFF(DS0) mode).
+* Enable it by doing
+* echo enabled /sys/bus/platform/devices/usb-phy-id/power/wakeup
+*/
+
if (device_may_wakeup(dev))
phy_ctrl_wkup(am_phy-phy_ctrl, am_phy-id, true);
+
phy_ctrl_power(am_phy-phy_ctrl, am_phy-id, false);
+
return 0;
}
-static int am335x_phy_runtime_resume(struct device *dev)
+static int am335x_phy_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct am335x_phy *am_phy = platform_get_drvdata(pdev);
phy_ctrl_power(am_phy-phy_ctrl, am_phy-id, true);
+
if (device_may_wakeup(dev))
phy_ctrl_wkup(am_phy-phy_ctrl, am_phy-id, false);
+
return 0;
}
+#define DEV_PM_OPS (am335x_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif
+
static const struct dev_pm_ops am335x_pm_ops = {
- SET_RUNTIME_PM_OPS(am335x_phy_runtime_suspend,
- am335x_phy_runtime_resume, NULL)
+ .suspend = am335x_phy_suspend,
+ .resume = am335x_phy_resume,
};
-#define DEV_PM_OPS (am335x_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif
-
static const struct of_device_id am335x_phy_ids[] = {
{ .compatible = ti,am335x-usb-phy },
{ }
--
1.8.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
[RESEND PATCH] usb: dwc3: fix the glue drivers using the nop phy
The reset_gpio member of the usb_phy_gen_xceiv_platform_data structure needs the have negative value or phy-generic's probe will fail unless DT is used. 0 is a valid gpio number. This fixes an issue where phy-generic fails to probe with message: usb_phy_gen_xceiv.0: Error requesting RESET GPIO 0. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com --- drivers/usb/dwc3/dwc3-exynos.c | 1 + drivers/usb/dwc3/dwc3-pci.c| 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 8b20c70..28c8ad7 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -50,6 +50,7 @@ static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos) exynos-usb2_phy = pdev; pdata.type = USB_PHY_TYPE_USB2; + pdata.gpio_reset = -1; ret = platform_device_add_data(exynos-usb2_phy, pdata, sizeof(pdata)); if (ret) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 665686e..f393c18 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -52,6 +52,7 @@ static int dwc3_pci_register_phys(struct dwc3_pci *glue) glue-usb2_phy = pdev; pdata.type = USB_PHY_TYPE_USB2; + pdata.gpio_reset = -1; ret = platform_device_add_data(glue-usb2_phy, pdata, sizeof(pdata)); if (ret) -- 1.8.5.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
RE: [PATCH] usb: xhci: Rename xhci_queue_xxx_tx() to xhci_queue_xxx_urb()
From: Sarah Sharp Hi David, This patch is fine in general, however I can't seem to get it to apply. I tried 3.12, 3.13-rc4, and my for-usb-next-queue branch, and `git am` failed on all three kernels. Can you rebase this against either 3.13-rc4 or my for-usb-next-queue branch? I've resent it based on Linus's tree. I think I wrote it after one of my other patches. I've also spotted another one: handle_tx_event() - handle_data_event() That was included in one of my other patches which I'm about to resend having split it into two patches (and without that rename). I'll send a separate patch for it. David -- 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 1/3] mips: qi_lb60: add defconfig for Ben NanoNote
Hello. On 18-12-2013 3:55, Apelete Seketeli wrote: Add defconfig for the Ben NanoNote handheld computer which is built around QI_LB60 board and Ingenic JZ4740 MIPS SoC. Signed-off-by: Apelete Seketeli apel...@seketeli.net --- arch/mips/configs/qi_lb60_defconfig | 188 +++ 1 file changed, 188 insertions(+) create mode 100644 arch/mips/configs/qi_lb60_defconfig This should be sent to linux-m...@linux-mips.org and pushed thru the MIPS tree. No need to send this patch to linux-usb. 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 1/2] usb: usbtest: Add timetout to simple_io()
Hi Roger,
On Wed, Dec 18, 2013 at 03:40:10PM +0530, Roger Quadros wrote:
Without a timetout some tests e.g. test_halt() can remain stuck forever.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/usb/misc/usbtest.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index b415282..6294e1b 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -10,6 +10,7 @@
#include linux/usb.h
+#define SIMPLE_IO_TIMEOUT1 /* in milliseconds */
Only one question, how do you confirm the timeout value?
Thanks,
Rui
/*-*/
@@ -366,6 +367,7 @@ static int simple_io(
int max = urb-transfer_buffer_length;
struct completion completion;
int retval = 0;
+ unsigned long expire;
urb-context = completion;
while (retval == 0 iterations-- 0) {
@@ -378,9 +380,15 @@ static int simple_io(
if (retval != 0)
break;
- /* NOTE: no timeouts; can't be broken out of by interrupt */
- wait_for_completion(completion);
- retval = urb-status;
+ expire = msecs_to_jiffies(SIMPLE_IO_TIMEOUT);
+ if (!wait_for_completion_timeout(completion, expire)) {
+ usb_kill_urb(urb);
+ retval = (urb-status == -ENOENT ?
+ -ETIMEDOUT : urb-status);
+ } else {
+ retval = urb-status;
+ }
+
urb-dev = udev;
if (retval == 0 usb_pipein(urb-pipe))
retval = simple_check_buf(tdev, urb);
--
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] usb: xhci: Rename constants for truncated bulk transfers.
Rename the constants XHCI_TRUST_TX_LENGTH to XHCI_TRUST_RX_LENGTH
and COMP_SHORT_TX to COMP_SHORT_RX to avoid any confusion that
they might apply to transmit transfers.
Signed-off-by: David Laight david.lai...@aculab.com
---
I can't actually see any driver that requires this quirk!
Note that this replaces part of the earlier patch from me:
[PATCH] usb: xhci: Less verbose tracing of short receives
drivers/usb/host/xhci-pci.c | 4 ++--
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.h | 4 ++--
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index b8dffd5..97b3edc 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -89,7 +89,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
QUIRK: Fresco Logic revision %u
has broken MSI implementation,
pdev-revision);
- xhci-quirks |= XHCI_TRUST_TX_LENGTH;
+ xhci-quirks |= XHCI_TRUST_RX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_NEC)
@@ -135,7 +135,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci-quirks |= XHCI_RESET_ON_RESUME;
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
QUIRK: Resetting on resume);
- xhci-quirks |= XHCI_TRUST_TX_LENGTH;
+ xhci-quirks |= XHCI_TRUST_RX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6bf8a37..2031dc3 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2115,7 +2115,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
*status = 0;
}
break;
- case COMP_SHORT_TX:
+ case COMP_SHORT_RX:
if (td-urb-transfer_flags URB_SHORT_NOT_OK)
*status = -EREMOTEIO;
else
@@ -2210,9 +2210,9 @@ static int process_isoc_td(struct xhci_hcd *xhci, struct
xhci_td *td,
frame-status = 0;
break;
}
- if ((xhci-quirks XHCI_TRUST_TX_LENGTH))
- trb_comp_code = COMP_SHORT_TX;
- case COMP_SHORT_TX:
+ if ((xhci-quirks XHCI_TRUST_RX_LENGTH))
+ trb_comp_code = COMP_SHORT_RX;
+ case COMP_SHORT_RX:
frame-status = td-urb-transfer_flags URB_SHORT_NOT_OK ?
-EREMOTEIO : 0;
break;
@@ -2316,13 +2316,13 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci,
struct xhci_td *td,
*status = -EREMOTEIO;
else
*status = 0;
- if ((xhci-quirks XHCI_TRUST_TX_LENGTH))
- trb_comp_code = COMP_SHORT_TX;
+ if ((xhci-quirks XHCI_TRUST_RX_LENGTH))
+ trb_comp_code = COMP_SHORT_RX;
} else {
*status = 0;
}
break;
- case COMP_SHORT_TX:
+ case COMP_SHORT_RX:
if (td-urb-transfer_flags URB_SHORT_NOT_OK)
*status = -EREMOTEIO;
else
@@ -2332,7 +2332,7 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci,
struct xhci_td *td,
/* Others already handled above */
break;
}
- if (trb_comp_code == COMP_SHORT_TX)
+ if (trb_comp_code == COMP_SHORT_RX)
xhci_dbg(xhci, ep %#x - asked for %d bytes,
%d bytes untransferred\n,
td-urb-ep-desc.bEndpointAddress,
@@ -2480,12 +2480,12 @@ static int handle_tx_event(struct xhci_hcd *xhci,
case COMP_SUCCESS:
if (EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) == 0)
break;
- if (xhci-quirks XHCI_TRUST_TX_LENGTH)
- trb_comp_code = COMP_SHORT_TX;
+ if (xhci-quirks XHCI_TRUST_RX_LENGTH)
+ trb_comp_code = COMP_SHORT_RX;
else
xhci_warn_ratelimited(xhci,
- WARN Successful completion on short
TX: needs XHCI_TRUST_TX_LENGTH quirk?\n);
- case COMP_SHORT_TX:
+ WARN Successful completion on short
RX: needs XHCI_TRUST_RX_LENGTH quirk?\n);
+ case COMP_SHORT_RX:
break;
case COMP_STOP:
xhci_dbg(xhci, Stopped on Transfer TRB\n);
@@ -2652,7 +2652,7 @@ static int handle_tx_event(struct
[PATCH] usb: xhci: Don't trace all short/incomplete receives.
Don't trace unexpected incomplete receives if the XHCI_TRUST_RX_LENGTH is set.
Don't trace short receives if URB_SHORT_NOT_OK is set. Short receives
are normal for USB ethernet devices.
Ratelimit both traces.
Signed-off-by: David Laight david.lai...@aculab.com
---
This is dependent on my previous patch to rename XHCI_TRUST_TX_LENGTH
to XHCI_TRUST_RX_LENGTH.
This replaces most of the rest of my earlier patch:
[PATCH] usb: xhci: Less verbose tracing of short receives
drivers/usb/host/xhci-ring.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 2031dc3..2315be1 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2308,36 +2308,34 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci,
struct xhci_td *td,
switch (trb_comp_code) {
case COMP_SUCCESS:
/* Double check that the HW transferred everything. */
- if (event_trb != td-last_trb ||
- EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) != 0) {
- xhci_warn(xhci, WARN Successful completion
- on short TX\n);
- if (td-urb-transfer_flags URB_SHORT_NOT_OK)
- *status = -EREMOTEIO;
- else
- *status = 0;
- if ((xhci-quirks XHCI_TRUST_RX_LENGTH))
- trb_comp_code = COMP_SHORT_RX;
- } else {
+ if (event_trb == td-last_trb
+ EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) == 0) {
*status = 0;
+ break;
}
- break;
+ if (xhci-quirks XHCI_TRUST_RX_LENGTH)
+ trb_comp_code = COMP_SHORT_RX;
+ else
+ xhci_warn_ratelimited(xhci,
+ WARN Successful completion on short
RX: needs XHCI_TRUST_RX_LENGTH quirk?\n);
+ /* FALLTHROUGH */
case COMP_SHORT_RX:
- if (td-urb-transfer_flags URB_SHORT_NOT_OK)
+ if (td-urb-transfer_flags URB_SHORT_NOT_OK) {
+ xhci_dbg(xhci, ep %#x - asked for %d bytes,
+ %d bytes not received\n,
+ td-urb-ep-desc.bEndpointAddress,
+ td-urb-transfer_buffer_length,
+
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)));
*status = -EREMOTEIO;
- else
+ } else {
*status = 0;
+ }
break;
default:
/* Others already handled above */
break;
}
- if (trb_comp_code == COMP_SHORT_RX)
- xhci_dbg(xhci, ep %#x - asked for %d bytes,
- %d bytes untransferred\n,
- td-urb-ep-desc.bEndpointAddress,
- td-urb-transfer_buffer_length,
-
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)));
+
/* Fast path - was this the last TRB in the TD for this URB? */
if (event_trb == td-last_trb) {
if (EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) != 0) {
--
1.8.1.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 V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
Hi, On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote: From: Andreas Naumann anaum...@ultratronik.de This is a hard to reproduce problem which leads to non-functional USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore of OTG_INTERFSEL over suspend. Since the resume function is also called early in driver init, it uses a non-initialized value (which is 0 and a non-supported setting in DM37xx for INTERFSEL). Shortly after the correct value is set. Apparently this works most time, but not always. yeah, but the problem is not on the glue layer. The bug is omap_device and pm_runtime not agreeing on device's state. I suppose there was a fix for that recently in linux-omap@vger mailing list. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] usb: dwc3: pm_runtime implementation
Hi, On Tue, Dec 17, 2013 at 03:35:54PM -0800, David Cohen wrote: On Tue, Dec 17, 2013 at 03:31:40PM -0800, David Cohen wrote: On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote: hi all, these patches add pm_runtime support for all glue layers. I plan to add pm_runtime support for dwc3 after these patches are merged upstream. Please test. At first time I failed to notice you were removing #ifdef's around pm callback functions. Instead of saying DWC3 will start to have warnings when CONFIG_PM is not selected, I'd say your patch set is now a dependence of my RFC :) I guess I said it in wrong order :P Your patch set depends on my RFC. Or I just modify my patchset a little bit for now ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] usb: dwc3: pm_runtime implementation
On Wed, Dec 18, 2013 at 09:36:14AM -0600, Felipe Balbi wrote: Hi, On Tue, Dec 17, 2013 at 03:35:54PM -0800, David Cohen wrote: On Tue, Dec 17, 2013 at 03:31:40PM -0800, David Cohen wrote: On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote: hi all, these patches add pm_runtime support for all glue layers. I plan to add pm_runtime support for dwc3 after these patches are merged upstream. Please test. At first time I failed to notice you were removing #ifdef's around pm callback functions. Instead of saying DWC3 will start to have warnings when CONFIG_PM is not selected, I'd say your patch set is now a dependence of my RFC :) I guess I said it in wrong order :P Your patch set depends on my RFC. Or I just modify my patchset a little bit for now ;-) nah, it looks horrible with all those ifdefs around. I'll delay my patch series. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: fix driver dependencies
Hi, On Wed, Dec 18, 2013 at 05:33:52PM +1100, Stephen Rothwell wrote: both isp1301-omap and fsl_usb2_otg drivers depend on usb_bus_start_enum() which is only defined if CONFIG_USB != n. There is a problem, however, where both those drivers could be statically linked, while CONFIG_USB=m. Fix the problem by fixing driver dependency. Signed-off-by: Felipe Balbi ba...@ti.com --- Greg, I'll send this to you in a pull request tomorrow. I can take this as-is right now if you want me to, no need for a full pull request, I still do take patches :) Just let me know, please go ahead, I don't think I'll have any other important fixes for this -rc. (famous last words). Gentle ping on this patch, we still have build errors on randconfig due to lack of this patch in mainline. Ick, sorry, it got lost in my travels, I'll go get to this right now... Thanks Greg. I am still getting this error despite your patch being in the tree ... are you sure that patch is included ? I have just checked on greg/usb-linus that it's impossible to make CONFIG_USB=m and CONFIG_ISP1301_OMAP=y (same for the other phy driver from Freescale). I can also build omap1_defconfig with all possibilities for CONFIG_USB + CONFIG_ISP1301_OMAP, that is: N-N, M-M, Y-M. If you can still see the problem, then send me your .config and error messages. You could be seeing another problem. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: ep0: Handle variable-length Data Stage
Hi, On Wed, Dec 18, 2013 at 03:22:07PM +0530, Pratyush Anand wrote: In accordance with specification, when sent data length is please mention section of specification. an exact multiple of wMaxPacketSize for the pipe and less than requested by host, the function shall return a zero-length packet (ZLP) to indicate the end of the Data stage to a USB host. hmm... so in USB3 mode that would be host requesting 513 bytes and us sending only 512. Curious, what was the use case when you encountered above situation? Wouldn't something simple as follows be able to resolve it? diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 95f7649..8b419aa 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -924,6 +924,10 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc, ret = dwc3_ep0_start_trans(dwc, dep-number, req-request.dma, req-request.length, DWC3_TRBCTL_CONTROL_DATA); + if (req-zero !ret) + ret = dwc3_ep0_start_trans(dwc, dep-number, + dwc-ctrl_req_addr, 0, + DWC3_TRBCTL_CONTROL_DATA); at this time you don't know if the previous transfer has completed ;-) But true, a use-case scenario would be great. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/3] mips: qi_lb60: add defconfig for Ben NanoNote
Hello, On 18-Dec-13, Sergei Shtylyov wrote: Hello. On 18-12-2013 3:55, Apelete Seketeli wrote: Add defconfig for the Ben NanoNote handheld computer which is built around QI_LB60 board and Ingenic JZ4740 MIPS SoC. Signed-off-by: Apelete Seketeli apel...@seketeli.net --- arch/mips/configs/qi_lb60_defconfig | 188 +++ 1 file changed, 188 insertions(+) create mode 100644 arch/mips/configs/qi_lb60_defconfig This should be sent to linux-m...@linux-mips.org and pushed thru the MIPS tree. No need to send this patch to linux-usb. Understood, will send it to linux-m...@linux-mips.org. Please ignore this patch for USB tree. Cheers. -- Apelete -- 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: [RFC 5/5] usb: dwc3: enable async suspend/resume
On Wed, Dec 18, 2013 at 04:09:34PM +0530, Yuvaraj Kumar C D wrote: From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3 device (the parent of xhci-plat) in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3 driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/core.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 59bb8d2..9c8a273 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -586,6 +586,8 @@ static int dwc3_probe(struct platform_device *pdev) pm_runtime_allow(dev); + device_enable_async_suspend(dev); how has this series been tested ? Let me rephrase this: was this series tested at all ? Note that if we are in gadget mode, we will disable physical endpoints 0 and 1, which will break USB communication requiring a new enumeration later. On top of that, for versions of the core which are configured without hibernation support - in fact for all cores currently, since we don't have hibernation support implemented in this driver -, we will loose communication with the far end (be it a host or a device). You mention there are no external dependencies to make async suspend work on this driver, but that's far from the truth. As it is today, this driver needs a lot of work to learn about all the details about all different versions of this IP when it comes to supporting async PM. I suppose this was tested with 500 other out-of-tree patches and you simply cherry-picked this patch to send upstream ? Am I right ? It certainly looks like it. Please let us know how has this been tested ? Did you run USB30CV ? Did you make sure to run through USB Certification interoperability tests ? Did you leave some stress test running for weeks before sending this patch out ? Is Exynos 5 working fine out of mainline ? cheers -- balbi signature.asc Description: Digital signature
Re: [RFC 4/5] usb: dwc3-exynos: enable async suspend/resume
On Wed, Dec 18, 2013 at 04:09:33PM +0530, Yuvaraj Kumar C D wrote: From: Andrew Bresticker abres...@chromium.org In addition to enabling async suspend/resume on the xhci-plat device, we must enable it for the dwc3-exynos platform device in order to make the full USB stack resume asynchronously. Like the xhci-plat, ehci-s5p, and ohci-exynos drivers, there are no outside dependencies which would make resuming the dwc3-exynos driver asynchronously unsafe. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Julius Werner jwer...@chromium.org Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/usb/dwc3/dwc3-exynos.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 8b20c70..57431b7 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -155,6 +155,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev) goto err2; } + device_enable_async_suspend(dev); sure that clk_disable() in your -suspend() callback will cause no issues at all ? -- balbi signature.asc Description: Digital signature
[PATCH] Change nop_cmd to __le32 to fix sparse warnings.
Code is correct since the value and final target are both little-endian. Signed-off-by: David Laight david.lai...@aculab.com --- drivers/usb/host/xhci-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 2315be1..0420daf 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2979,7 +2979,7 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring, union xhci_trb *trb = ep_ring-enqueue; unsigned int usable = ep_ring-enq_seg-trbs + TRBS_PER_SEGMENT - 1 - trb; - u32 nop_cmd; + __le32 nop_cmd; /* * Section 4.11.7.1 TD Fragments states that a link -- 1.8.1.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] usb: dwc3: dwc3-omap: Fix the crash in module removal
Hi,
On Wed, Dec 18, 2013 at 06:35:09PM +0530, George Cherian wrote:
In the wrapper driver the child nodes are populated using
of_platform_populate(), which does a device_add. So while
removing the module if platform_device_unregister is called
it leads to following crash.
[ 57.676757] Unable to handle kernel NULL pointer dereference at virtual
address 0018
[ 57.685241] pgd = edf7c000
[ 57.687988] [0018] *pgd=add17831, *pte=, *ppte=
[ 57.694488] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 57.699920] Modules linked in: g_mass_storage usb_f_mass_storage
libcomposite configfs wlcore_sdio dwc3_omap(-) pixcir_i2c_ts [last unloaded:
dwc3]
[ 57.713317] CPU: 0 PID: 1580 Comm: rmmod Not tainted
3.12.4-02001-gb1278cc-dirty #21
[ 57.721099] task: ed9f8bc0 ti: edfb task.ti: edfb
[ 57.726562] PC is at release_resource+0x14/0x7c
[ 57.731109] LR is at release_resource+0x10/0x7c
[ 57.735687] pc : [c004e278]lr : [c004e274]psr: 600f0013
[ 57.735687] sp : edfb1eb0 ip : 600f0013 fp : 00021008
[ 57.747192] r10: r9 : edfb r8 : c00142e8
[ 57.752441] r7 : edfb r6 : bf005198 r5 : edd18000 r4 : edfa3e80
[ 57.759002] r3 : r2 : r1 : 0010 r0 : c09bf394
[ 57.765563] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
user
[ 57.772735] Control: 10c53c7d Table: adf7c059 DAC: 0015
[ 57.778503] Process rmmod (pid: 1580, stack limit = 0xedfb0248)
[ 57.784454] Stack: (0xedfb1eb0 to 0xedfb2000)
[ 57.788848] 1ea0: 0001
edd18000 c03a1870
[ 57.797088] 1ec0: edd18010 edd18000 c03a1b70 bf0051a4
edd18010 c039c86c
[ 57.805297] 1ee0: ed927a40 edd9d9f0 edcc0990 ed97e410 ed97e444 bf00518c
bf005120 ed97e410
[ 57.813507] 1f00: bf005d54 c03a1594 c03a157c c039fe94 bf005d54 ed97e410
bf005d54 c03a0698
[ 57.821746] 1f20: bf005d54 c09e4f90 c039fcbc bf005d98
0800 c00abd2c
[ 57.829956] 1f40: c09c9920 bf005d98 0800 edfb1f44 33637764
616d6f5f 0070
[ 57.838165] 1f60: ed9f8bc0 c0014190 0001 edfb bee6ee08
00021008 c00a36e0
[ 57.846405] 1f80: 00021088 0800 00021088 0081 8010 00021088
0800 00021088
[ 57.854614] 1fa0: 0081 c0014100 00021088 0800 000210b8 0800
c0514b00 c0514b00
[ 57.862823] 1fc0: 00021088 0800 00021088 0081 0001 bee6ebf8
bee6ee08 00021008
[ 57.871032] 1fe0: 43098880 bee6ebb4 b6fd59bc 4309888c 8010 000210b8
0002130c
[ 57.879302] [c004e278] (release_resource+0x14/0x7c) from [c03a1870]
(platform_device_del+0x6c/0x9c)
[ 57.888732] [c03a1870] (platform_device_del+0x6c/0x9c) from [c03a1b70]
(platform_device_unregister+0xc/0x18)
[ 57.898986] [c03a1b70] (platform_device_unregister+0xc/0x18) from
[bf0051a4] (dwc3_omap_remove_core+0xc/0x14 [dwc3_omap])
[ 57.910400] [bf0051a4] (dwc3_omap_remove_core+0xc/0x14 [dwc3_omap]) from
[c039c86c] (device_for_each_child+0x34/0x74)
[ 57.921417] [c039c86c] (device_for_each_child+0x34/0x74) from
[bf00518c] (dwc3_omap_remove+0x6c/0x78 [dwc3_omap])
[ 57.932067] [bf00518c] (dwc3_omap_remove+0x6c/0x78 [dwc3_omap]) from
[c03a1594] (platform_drv_remove+0x18/0x1c)
[ 57.942565] [c03a1594] (platform_drv_remove+0x18/0x1c) from [c039fe94]
(__device_release_driver+0x70/0xc8)
[ 57.952606] [c039fe94] (__device_release_driver+0x70/0xc8) from
[c03a0698] (driver_detach+0xb4/0xb8)
[ 57.962127] [c03a0698] (driver_detach+0xb4/0xb8) from [c039fcbc]
(bus_remove_driver+0x8c/0xd0)
[ 57.971160] [c039fcbc] (bus_remove_driver+0x8c/0xd0) from [c00abd2c]
(SyS_delete_module+0x118/0x22c)
[ 57.980712] [c00abd2c] (SyS_delete_module+0x118/0x22c) from [c0014100]
(ret_fast_syscall+0x0/0x48)
[ 57.990051] Code: e1a04000 e59f0068 eb175e43 e5943010 (e5932018)
[ 57.996368] ---[ end trace 2af5f15c0b475a3d ]---
Replace platform_device_unregister with of_device_unregister.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b269dbd..d241ff3 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -323,7 +323,7 @@ static int dwc3_omap_remove_core(struct device *dev, void
*c)
{
struct platform_device *pdev = to_platform_device(dev);
- platform_device_unregister(pdev);
+ of_device_unregister(pdev);
causes a build break on x86. Who on earth is handling the OF bus ?
Nobody build tests anymore ? There are quite a few problems with this
one liner (and not all of them are related to your patch, George).
a) of_device_unregister() is *not* analogous to of_platform_populate()
b) of_device_unregister() does *not* provide a no-op in case of
!CONFIG_OF
c) it's insane that of_device_* receives a
Suspend issues with a LaCie USB hard disk connected
Hi, I'm facing an issue putting an embedded system to sleep while a Lacie external USB hard disk is connected. Relevant kernel messages that occur at the attempt are: [ 13.834731] PM: Sending message for entering DeepSleep mode [ 13.846575] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 13.858818] sd 0:0:0:0: [sda] [ 13.862432] Result: hostbyte=0x00 driverbyte=0x08 [ 13.867349] sd 0:0:0:0: [sda] [ 13.870626] Sense Key : 0x5 [current] [ 13.874602] sd 0:0:0:0: [sda] [ 13.877879] ASC=0x20 ASCQ=0x0 [ 13.885053] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns -5 [ 13.901130] PM: Device 0:0:0:0 failed to suspend async: error -5 [ 13.907507] PM: Some devices failed to suspend, or early wake event detected What happens is that in sd_sync_cache(), scsi_execute_req_flags() returns 0x0802, so driver_byte(res) evaluates to DRIVER_SENSE and host_byte(res) is DID_OK, which is an unhandled case that leads to -EIO eventually. I have admittedly not much clue about the SCSI layer, so I wonder what would be the best way to fix this. Should DID_OK just be handled as non-error condition in the switch? Should the suspend call chain ignore such errors from sd_sync_cache()? I'm open to suggestions and happy to test patches. Thanks, Daniel -- 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 v7 8/9] phy: add Broadcom Kona USB2 PHY driver
On Tue, Dec 17, 2013 at 02:42:35PM -0500, Matt Porter wrote:
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter mpor...@linaro.org
Kishon, are you ok with this driver ?
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct bcm_kona_usb *phy;
+ struct resource *res;
+ struct phy *gphy;
+ struct phy_provider *phy_provider;
+
+ phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ phy-regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(phy-regs))
+ return PTR_ERR(phy-regs);
+
+ platform_set_drvdata(pdev, phy);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+ of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ gphy = devm_phy_create(dev, ops, NULL);
+ if (IS_ERR(gphy))
+ return PTR_ERR(gphy);
+
+ /* The Kona PHY supports an 8-bit wide UTMI interface */
+ phy_set_bus_width(gphy, 8);
+
+ phy_set_drvdata(gphy, phy);
I think this set_drvdata() should be done before registering the
provider, no ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: phy: am335x: Enable USB remote wakeup using PHY wakeup
Hi,
On Wed, Dec 18, 2013 at 06:52:09PM +0530, George Cherian wrote:
USB remote wakeup using PHY wakeup is supported only in standby mode.
Enabling the PHY_WKUP will break DS0 mode of system suspend.
If the same is enabled while entering DS0, AM33xx never stays in DS0,
it returns immediately from DS0. By default make the PHY wakeup
disabled, using sysfs entry enable the same manually to get
the remote wakeup working from standby.
echo enabled /sys/bus/platform/device/usb phy id/power/wakeup
This will enable the PHY wakeup while going to standby.
PHY wakeup feature is required to wakeup the system from standby
state. Since AM33xx has a bug in which PHY wakeup should not
be enabled while entering DS0, disable the same by default.
A user wishing to use USB wakeup from standby mode need to enable
the same using the sysfs entries.
Also remove am335x_phy_runtime_(suspend/resume) this driver doesnot really
enable/disable the clocks to the PHY.
Add am335x_phy_(suspend/resume) and use the same for enabling the PHY_WKUP.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/phy/phy-am335x.c | 46
+---
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index 6370e50..3f78eaf 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -64,6 +64,19 @@ static int am335x_phy_probe(struct platform_device *pdev)
am_phy-usb_phy_gen.phy.shutdown = am335x_shutdown;
platform_set_drvdata(pdev, am_phy);
+ device_init_wakeup(dev, true);
+
+ /*
+ * If we leave PHY wakeup enabled then AM33XX wakes up
+ * immediately from DS0. To avoid this we mark dev-power.can_wakeup
+ * to false. The same is checked in suspend routine to decide
+ * on whether to enable PHY wakeup or not.
+ * PHY wakeup works fine in standby mode, there by allowing us to
+ * handle remote wakeup, wakeup on disconnect and connect.
+ */
+
+ device_set_wakeup_enable(dev, false);
+ phy_ctrl_power(am_phy-phy_ctrl, am_phy-id, false);
return 0;
@@ -78,40 +91,51 @@ static int am335x_phy_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_RUNTIME
-
-static int am335x_phy_runtime_suspend(struct device *dev)
+#ifdef CONFIG_PM_SLEEP
+static int am335x_phy_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct am335x_phy *am_phy = platform_get_drvdata(pdev);
+ /*
+ * Enable phy wakeup only if dev-power.can_wakeup is true.
+ * Make sure to enable wakeup to support remote wakeup in
+ * standby mode ( same is not supported in OFF(DS0) mode).
+ * Enable it by doing
+ * echo enabled /sys/bus/platform/devices/usb-phy-id/power/wakeup
+ */
Alan, any suggestions on how to handle wakeup correctly ? I mean, it
should be enabled by default during runtime PM and disabled during
system sleep. But when it comes to default state of can_wakeup field,
what should we do ? Should the driver be fiddling with that ? Leave it
to the bus driver ? Any tips ?
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] usb: usbtest: Add timetout to simple_io()
On Wed, Dec 18, 2013 at 10:46:03PM +0800, Huang Rui wrote: Hi Roger, On Wed, Dec 18, 2013 at 03:40:10PM +0530, Roger Quadros wrote: Without a timetout some tests e.g. test_halt() can remain stuck forever. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com --- drivers/usb/misc/usbtest.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index b415282..6294e1b 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -10,6 +10,7 @@ #include linux/usb.h +#define SIMPLE_IO_TIMEOUT 1 /* in milliseconds */ Only one question, how do you confirm the timeout value? dude, it's just a timeout. It could be anything, really. 10 seconds is just large enough value that would allow even the slowest scenarios (host + device) to complete, while not being so slow that you would wanna kill yourself after waiting for such a long time ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v7 8/9] phy: add Broadcom Kona USB2 PHY driver
On Wed, Dec 18, 2013 at 10:25:54AM -0600, Felipe Balbi wrote:
On Tue, Dec 17, 2013 at 02:42:35PM -0500, Matt Porter wrote:
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter mpor...@linaro.org
Kishon, are you ok with this driver ?
Kishon did mention he was fine with this if I addressed a couple
comments a couple versions ago, I neglected solicit his ack though.
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct bcm_kona_usb *phy;
+ struct resource *res;
+ struct phy *gphy;
+ struct phy_provider *phy_provider;
+
+ phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ phy-regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(phy-regs))
+ return PTR_ERR(phy-regs);
+
+ platform_set_drvdata(pdev, phy);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+ of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ gphy = devm_phy_create(dev, ops, NULL);
+ if (IS_ERR(gphy))
+ return PTR_ERR(gphy);
+
+ /* The Kona PHY supports an 8-bit wide UTMI interface */
+ phy_set_bus_width(gphy, 8);
+
+ phy_set_drvdata(gphy, phy);
I think this set_drvdata() should be done before registering the
provider, no ?
It seems so, given that we wouldn't want the provider on on the
provider list until the phy has been allocated and configured.
Interestingly, this also needs to be addressed in the four phy
drivers already upstream...they all do the same thing before the
generic phy is created.
-Matt
--
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: USB sound auto-suspend not working
At Tue, 17 Dec 2013 14:55:48 -0800, Sarah Sharp wrote: Hi Oliver and Takashi, I've noticed that in the last couple kernel releases or so, I can't get USB webcams to suspend. It turns out that the USB sound interface is keeping the device active, even when the device is not playing sound. This goes back as far as 3.10, but I haven't tried older kernels. This is testing on Ubuntu 13.10. Commit 88a8516a2128a6d078a106ead48092240e8a138f ALSA: usbaudio: implement USB autosuspend went into kernel 2.6.39. The commit message says the device is prevented from suspending if the pcm or midi channel files are open. I plugged in a USB speaker, and ran lsof to see which files were open (output is attached). AFAICT, only the USB sound device's control files are open, and I don't have any midi files. Any ideas as to why USB sound auto-suspend isn't working? I don't know of any intentional changes regarding autosuspend in usb-audio since years. The central points are snd_usb_autosuspend() and snd_usb_autoresume() in sound/usb/card.c, so you can try to add some debug prints there for tracking more deeply what's going wrong. Takashi -- 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 1/3] mips: qi_lb60: add defconfig for Ben NanoNote
Hello. On 12/18/2013 07:00 PM, Apelete Seketeli wrote: Add defconfig for the Ben NanoNote handheld computer which is built around QI_LB60 board and Ingenic JZ4740 MIPS SoC. Signed-off-by: Apelete Seketeli apel...@seketeli.net --- arch/mips/configs/qi_lb60_defconfig | 188 +++ 1 file changed, 188 insertions(+) create mode 100644 arch/mips/configs/qi_lb60_defconfig This should be sent to linux-m...@linux-mips.org and pushed thru the MIPS tree. No need to send this patch to linux-usb. Understood, will send it to linux-m...@linux-mips.org. Please ignore this patch for USB tree. Generally, please use scripts/get_maintainer.pl to determine where a patch should be mailed to. Cheers. 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
[GIT PULL] USB fixes for 3.13-rc5
The following changes since commit 2d51f3cd11f414c56a87dc018196b85fd50b04a4: usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED (2013-12-04 17:00:43 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.13-rc5 for you to fetch changes up to fb5f1834c3221e459324c6885eaad75429f722a5: usb: ohci-at91: fix irq and iomem resource retrieval (2013-12-17 13:22:36 -0800) USB: fixes for 3.13-rc5 Here are a few USB fixes for things that have people have reported issues with recently. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Bj??rn Mork (1): usb: cdc-wdm: manage_power should always set needs_remote_wakeup Boris BREZILLON (1): usb: ohci-at91: fix irq and iomem resource retrieval Chris Ruehl (1): usb: phy-tegra-usb.c: wrong pointer check for remap UTMI Dan Carpenter (2): usb: phy: twl6030-usb: signedness bug in twl6030_readb() drivers: phy: tweaks to phy_create() Dmitry Kunilov (1): usb: serial: zte_ev: move support for ZTE AC2726 from zte_ev back to option Fabio Estevam (1): usb: chipidea: host: Only disable the vbus regulator if it is not NULL Felipe Balbi (1): usb: phy: fix driver dependencies Greg Kroah-Hartman (2): Merge tag 'fixes-for-v3.13-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'for-usb-linus-2013-12-10' of git://git.kernel.org/.../sarah/xhci into usb-linus Kishon Vijay Abraham I (3): usb: dwc3: invoke phy_resume after phy_init usb: dwc3: power off usb phy in error path phy: kconfig: add depends on USB_PHY to OMAP_USB2 and TWL4030_USB Peter Chen (1): usb: chipidea: fix nobody cared IRQ when booting with host role Sachin Kamat (1): drivers: phy: Fix memory leak Takashi Iwai (1): xhci: Limit the spurious wakeup fix only to HP machines drivers/phy/Kconfig | 4 ++-- drivers/phy/phy-core.c| 26 ++ drivers/usb/chipidea/core.c | 4 drivers/usb/chipidea/host.c | 3 ++- drivers/usb/chipidea/udc.c| 3 --- drivers/usb/class/cdc-wdm.c | 8 +++- drivers/usb/dwc3/core.c | 8 +--- drivers/usb/host/ohci-at91.c | 26 +++--- drivers/usb/host/xhci-pci.c | 7 ++- drivers/usb/phy/Kconfig | 4 +++- drivers/usb/phy/phy-tegra-usb.c | 2 +- drivers/usb/phy/phy-twl6030-usb.c | 3 ++- drivers/usb/serial/option.c | 2 ++ drivers/usb/serial/zte_ev.c | 3 +-- 14 files changed, 56 insertions(+), 47 deletions(-) -- 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/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
On Wed, 2013-12-18 at 14:16 +0100, Dr. H. Nikolaus Schaller wrote:
Hi Dan,
Am 17.12.2013 um 23:27 schrieb Dan Williams:
On Tue, 2013-12-17 at 20:56 +0100, Dr. H. Nikolaus Schaller wrote:
Hi Dan,
Am 16.12.2013 um 20:40 schrieb Dan Williams:
On Fri, 2013-12-13 at 15:43 +0100, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 02.10.2013 um 09:00 schrieb Dr. H. Nikolaus Schaller:
Hi Jan,
we are using a GTM601 modem (Firmware 1.7) for a while and have spotted
an
issue that under some conditions the modem sends a packed wIndex over
USB
that is rejected by the hso driver making troubles afterwards. Not
rejecting makes
it work fine.
BR,
Nikolaus Schaller
---
From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
From: H. Nikolaus Schaller h...@goldelico.com
Date: Thu, 15 Nov 2012 14:40:57 +0100
Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by
OPTION
GTM601 during RING indication
It has been observed that the GTM601 with 1.7 firmware sometimes sends
a value
wIndex that has bit 0x04 set instead of being reset as the code
expects. So we
mask it for the error check.
See
http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
Signed-off-by: NeilBrown ne...@suse.de
Signed-off-by: H. Nikolaus Schaller h...@goldelico.de
---
drivers/net/usb/hso.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..d146e26 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb
*urb)
if (serial_state_notification-bmRequestType != BM_REQUEST_TYPE
||
serial_state_notification-bNotification != B_NOTIFICATION
||
le16_to_cpu(serial_state_notification-wValue) != W_VALUE ||
- le16_to_cpu(serial_state_notification-wIndex) != W_INDEX ||
+ (le16_to_cpu(serial_state_notification-wIndex) ~0x4) !=
+ W_INDEX ||
le16_to_cpu(serial_state_notification-wLength) !=
W_LENGTH) {
dev_warn(usb-dev,
hso received invalid serial state
notification\n);
--
1.7.7.4
I have found this (better) proposal by OPTION, but wonder what did
happen to it.
It neither shows in mainline 3.13-rc nor linux-next:
https://lkml.org/lkml/2013/10/9/263
Likely because nobody formally submitted the patch with a signed-off-by,
which indicates their intent that the patch is tested, correct, and can
be merged to the kernel.
Ok, I see. I just wasn't aware of the proposal at all since I missed the
discussion
and wasn't on CC.
Therefore I have added Eric to the CC.
I looked at this today, and I'm left wondering how any port other than
HSO_PORT_MODEM can get the notification via tiocmget_intr_callback().
serial-tiocmget is only created for HSO_PORT_MODEM serial ports (see
hso_create_bulk_serial_device()):
if ((port HSO_PORT_MASK) == HSO_PORT_MODEM) {
num_urbs = 2;
serial-tiocmget = kzalloc(sizeof(struct hso_tiocmget),
GFP_KERNEL);
and the code in tiocmget_intr_callback() does this:
tiocmget = serial-tiocmget;
if (!tiocmget)
return;
which should mean that only a HSO_PORT_MODEM will ever process the
notification. Further, the tiocmget interrupt URB is only created and
submitted if serial-tiocmget != NULL, so only HSO_PORT_MODEM should
ever be calling into tiocmget_intr_callback().
Ok, that looks plausible.
So I think Eric's patch is actually wrong because it will *always* pass
the new check.
The original code had the correct intention, but the original code was
obviously wrong for newer devices where the port layout is read from
firmware and not from static tables, and thus for recent devices where
the modem interface is not USB interface #2.
This explains why we did run into the problem with the GTM601.
Can you confirm/deny that the 'modem' interface for your GTM601 is USB
interface #6? For example, my Icon 452 has the following USB interface
layout:
0: Diag
1: GPS
2: GPS control
3: Application
4: Control
5: Network
6: Modem
So like the GTM601, I would expect any RING notifications to appear for
wIndex=0x06.
Interestingly I see:
0: Diagnostic
1: GPS
2: GPS Control
3: Application
4: Control
5: Modem
I.e. there is no Network interface. Originally we did focus on /dev/ttyHS3
How are you determining the number here? Are you using:
cat /sys/class/tty/ttyHS_Modem/device/bInterfaceNumber
to determine the actual USB interface number associated with the Modem
port? Or are you going off the pre-udev-rename ttyHSx numbers?
Ah, I did use
Re: [PATCH] usb: phy: am335x: Enable USB remote wakeup using PHY wakeup
On Wed, 18 Dec 2013, Felipe Balbi wrote: Alan, any suggestions on how to handle wakeup correctly ? I mean, it should be enabled by default during runtime PM and disabled during system sleep. During system sleep, it should be set according to the value of device_may_wakeup(). But when it comes to default state of can_wakeup field, what should we do ? Should the driver be fiddling with that ? Leave it to the bus driver ? Any tips ? If the bus driver knows whether the hardware is capable of issuing a wakeup request, it should set can_wakeup appropriately. In most cases the device driver doesn't need to worry about it. There are a few exceptions, though. If the bus code doesn't know enough about the hardware, or if some hardware has a quirk that the driver knows about but the bus code doesn't, for example. Alan Stern -- 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: XHCI: Ring expansion failure
On Wed, Nov 06, 2013 at 11:09:50PM -, hema...@codeaurora.org wrote: On Wed, Nov 6, 2013 at 12:33 PM, hema...@codeaurora.org wrote: On Wed, Nov 6, 2013 at 12:53 AM, hema...@codeaurora.org wrote: Hi Hi Hemant, By performing iterative port suspend and resume (which results in function suspend and resume), ring expansion failure is observed. Attached device has multiple interfaces for which interface host drivers are unlinking the urbs during function suspend and submitting urbs during resume. For the cases when dequeue ptr is close to the end of deq segment, value of num_trbs_in_deq_seg (= ring-dequeue - ring-deq_seg-trbs) becomes high when function suspend is over. At the time of resume this high value is causing to trigger ring expansion in the middle of submitting urbs(ring-num_trbs_free num_trbs + num_trbs_in_deq_seg). All the interface host drivers only request one TRB per urb (num_trb =1). Ring expansion logic is doubling the num of previously allocated segments every time. This is causing the num of segments to grow at fast pace (at the time of failure, one of the ep rings num_seg was 128), even though it is also increasing num_trbs_free. Sorry for taking so long to respond to this. It's definitely something we need to look into. Which type of USB device caused this out-of-control ring expansion? Can you provide us a link for where to buy it, if it's a specific device? It would make it easier for us to test this. Sounds like a bug. Why num_trbs_in_deq_seg becomes high? How many urbs are submitted during resume? Normally only isoc transfer triggers ring expansion with multiple trbs per urb. Let me explain it little further what is being observed in terms of enq , deq ptr:- For example 1) Let's say First seg of the ring starts with 0xed0d3000 which means enq ptr and deq ptr are pointing to this address. 2) Interface driver queuing 10 urbs (one urb represents one trb) enq ptr goes to ed0d30a0. 3) Interface suspend happened. All 10 urbs are going to get unlinked. For the first urb to be unlinked, it is added to ep-cancelled_td_list and Stop ep cmd was called (rest of the urbs added to ep-cancelled_td_list before stop ep cmd completed). 4) When stop ep cmd is completed, for 9 urbs td_to_noop() is called. For the first urb (for which stop ep cmd was called), xhci_find_new_dequeue_state() gets called which updates deq ptr to next trb (0x ed0d3010) so set tr deq ptr cmd is issued to xhci to set its deq ptr to next trb(0xed0d3010). 5) In set tr deq cmd completion handler update_ring_for_set_deq_completion() gets called which will just increments num_trbs_free to only one, but we unlinked all the urbs. So when interface suspend finished we have enq ptr pointing to 0x ed0d30a0 and dep ptr pointing to 0x ed0d3010. With num_trbs_free only incremented by one. 6) At the time of interface resume we re-queue 10 urbs back with num_trbs_free (just incremented 1 during suspend). This means num_trbs_free is incrementing very slowly every time interface suspend happens. And it is very easy to get into a situation where room_on_ring() returning 0 as deq ptr will be reaching to the end of the seg and causing num_trbs_in_deq_seg to go high enough that ring-num_trbs_free num_trbs + num_trbs_in_deq_seg condition becomes true. So it's because the suspend/resume loops and urbs are enqueued and unlinked, deq_ptr does not follow enq_ptr. This is expected since deq_ptr and num_trbs_free increase in inc_deq(), which is called by irq handler. As there is no transfer on this ring, deq_ptr will not get updated. Yep, I think this is the root cause. If we're just queuing and then canceling URBs, the no-op TRBs get executed, but we don't get an event back for them, so the dequeue pointer remains on the first canceled TRB. Considering the suspend resume scenario, with this behavior don't you think ring expansion will be triggered very often and for no reason (as we are just doing suspend and resume). In handle_stopped_endpoint() when traversing to ep-cancelled_td_list is it better to call xhci_find_new_dequeue_state() for last td and call td_to_noop() for all previous tds. Doing that we will update deq ptr to set to enq ptr with correct value of num_trbs_free when interface suspends finishes. There's no guarantee that the last URB queued for cancellation is the last TD physically in the ring. The URBs could be queued for cancellation in any order, and thus go on to cancelled_td_list in any order. We would also have issues using this solution for endpoints with streams enabled, where there are multiple stream rings associated with one endpoint. The current code assumes that the host controller has stopped on one particular endpoint ring, which may need a Set TR dequeue command, and other rings will only have TDs turned into no-op TRBs. Otherwise
[PATCH] usb: musb: finish suspend/reset work independently from musb_hub_control()
Currently, resume and reset is completed when the USB core calls back
the root hub, asking for the port's state. This results in
unpredictable timing of state assertion, which in turn renders some
USB devices unusable after resume.
Fix this by moving the logic to end the reset and suspend state out of
musb_hub_control() into separate functions called from delayed workers.
GetPortStatus only reports the current state now, without taking any
real action.
The rh_timeout variable is kept in order to define a minimum time gap
between reset and resume only.
FWIW, in my case, a Verbatim STORE N GO mass storage device won't
resume cleanly without this patch.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c| 25 ++--
drivers/usb/musb/musb_core.h| 3 ++
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 65 +
4 files changed, 61 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2d2c503..202456b 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -478,8 +478,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
musb-port1_status |=
(USB_PORT_STAT_C_SUSPEND 16)
| MUSB_PORT_STAT_RESUME;
- musb-rh_timer = jiffies
- + msecs_to_jiffies(20);
+ schedule_delayed_work(
+ musb-finish_resume_work, 20);
musb-xceiv-state = OTG_STATE_A_HOST;
musb-is_active = 1;
@@ -1813,6 +1813,21 @@ static void musb_free(struct musb *musb)
musb_host_free(musb);
}
+static void musb_deassert_reset(struct work_struct *work)
+{
+ struct musb *musb;
+ unsigned long flags;
+
+ musb = container_of(work, struct musb, deassert_reset_work.work);
+
+ spin_lock_irqsave(musb-lock, flags);
+
+ if (musb-port1_status USB_PORT_STAT_RESET)
+ musb_port_reset(musb, false);
+
+ spin_unlock_irqrestore(musb-lock, flags);
+}
+
/*
* Perform generic per-controller initialization.
*
@@ -1897,6 +1912,8 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
+ INIT_DELAYED_WORK(musb-deassert_reset_work, musb_deassert_reset);
+ INIT_DELAYED_WORK(musb-finish_resume_work, musb_host_finish_resume);
/* setup musb parts of the core (especially endpoints) */
status = musb_core_init(plat-config-multipoint
@@ -1981,6 +1998,8 @@ fail4:
fail3:
cancel_work_sync(musb-irq_work);
+ cancel_delayed_work_sync(musb-finish_resume_work);
+ cancel_delayed_work_sync(musb-deassert_reset_work);
if (musb-dma_controller)
dma_controller_destroy(musb-dma_controller);
fail2_5:
@@ -2044,6 +2063,8 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb-dma_controller);
cancel_work_sync(musb-irq_work);
+ cancel_delayed_work_sync(musb-finish_resume_work);
+ cancel_delayed_work_sync(musb-deassert_reset_work);
musb_free(musb);
device_init_wakeup(dev, 0);
return 0;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 29f7cd7..7083e82 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -47,6 +47,7 @@
#include linux/usb/otg.h
#include linux/usb/musb.h
#include linux/phy/phy.h
+#include linux/workqueue.h
struct musb;
struct musb_hw_ep;
@@ -295,6 +296,8 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
+ struct delayed_work deassert_reset_work;
+ struct delayed_work finish_resume_work;
u16 hwvers;
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 7436c24..909ba49 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -94,6 +94,7 @@ extern void musb_host_resume_root_hub(struct musb *musb);
extern void musb_host_poke_root_hub(struct musb *musb);
extern void musb_port_suspend(struct musb *musb, bool do_suspend);
extern void musb_port_reset(struct musb *musb, bool do_reset);
+extern void musb_host_finish_resume(struct work_struct *work);
#else
static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
{
@@ -125,6 +126,7 @@ static inline void musb_host_poll_rh_status(struct musb
*musb) {}
static inline void musb_host_poke_root_hub(struct musb *musb) {}
static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
static
Re: [RFC 0/2] target refcounting infrastructure fixes for usb
On Mon, Dec 16, 2013 at 07:10:19AM -0800, James Bottomley wrote: This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. James I tried these patches, and they cause an oops when a USB mass storage device is plugged in. Note that this device uses the usb-storage driver, not the uas driver. [14248.340064] scsi6 : usb-storage 2-2:1.0 [14248.341083] usbcore: registered new interface driver usb-storage [14248.346211] usbcore: registered new interface driver uas [14249.339937] scsi 6:0:0:0: Direct-Access LexarJumpDrive1.00 PQ: 0 ANSI: 6 [14249.340988] [ cut here ] [14249.340999] WARNING: CPU: 3 PID: 5578 at lib/kobject.c:227 kobject_add_internal+0x13f/0x350() [14249.341003] kobject_add_internal failed for 6:0:0:0 (error: -2 parent: target6:0:0) [14249.341005] Modules linked in: uas usb_storage ctr ccm cuse dm_crypt uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev btusb x86_pkg_temp_thermal coretemp ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd arc4 iwldvm mac80211 microcode snd_hda_codec_hdmi iwlwifi psmouse snd_hda_codec_realtek serio_raw snd_hda_intel snd_usb_audio snd_hda_codec thinkpad_acpi cfg80211 joydev snd_usbmidi_lib nvram snd_hwdep snd_seq_midi snd_pcm snd_seq_midi_event snd_rawmidi lpc_ich rfcomm bnep snd_seq bluetooth snd_seq_device snd_page_alloc ehci_pci snd_timer ehci_hcd snd soundcore tpm_tis binfmt_misc btrfs libcrc32c xor raid6_pq hid_generic usbhid hid i915 ahci libahci e1000e sdhci_pci sdhci i2c_algo_bit drm_kms_helper ptp pps_core drm xhci_hcd video [14249.341095] CPU: 3 PID: 5578 Comm: kworker/u16:0 Not tainted 3.13.0-rc1+ #142 [14249.341098] Hardware name: LENOVO 2325AP7/2325AP7, BIOS G2ET82WW (2.02 ) 09/11/2012 [14249.341105] Workqueue: events_unbound async_run_entry_fn [14249.341108] 0009 88003aa9db60 81658a4e 88003aa9dba8 [14249.341115] 88003aa9db98 81048c3d 88006bc551b0 fffe [14249.341121] 8800bec22838 0200 88003aa9dbf8 [14249.341127] Call Trace: [14249.341135] [81658a4e] dump_stack+0x4d/0x66 [14249.341142] [81048c3d] warn_slowpath_common+0x7d/0xa0 [14249.341148] [81048cac] warn_slowpath_fmt+0x4c/0x50 [14249.341154] [81660f17] ? _raw_spin_unlock+0x27/0x40 [14249.341159] [8133748f] kobject_add_internal+0x13f/0x350 [14249.341163] [813379b5] kobject_add+0x65/0xb0 [14249.341170] [81425b40] ? get_device+0x30/0x30 [14249.341175] [81649781] ? klist_init+0x31/0x40 [14249.341181] [81427208] device_add+0x128/0x660 [14249.341186] [814369cc] ? __pm_runtime_resume+0x5c/0x90 [14249.341193] [8145bcdc] scsi_sysfs_add_sdev+0xac/0x340 [14249.341199] [8145a443] do_scan_async+0x83/0x180 [14249.341204] [81074247] async_run_entry_fn+0x37/0x130 [14249.341210] [81066524] process_one_work+0x1f4/0x550 [14249.341215] [810664c2] ? process_one_work+0x192/0x550 [14249.341220] [81067261] worker_thread+0x121/0x3a0 [14249.341225] [81067140] ? manage_workers.isra.22+0x2a0/0x2a0 [14249.341231] [8106dc8c] kthread+0xfc/0x120 [14249.341238] [8106db90] ? kthread_create_on_node+0x230/0x230 [14249.341243] [81669cac] ret_from_fork+0x7c/0xb0 [14249.341249] [8106db90] ? kthread_create_on_node+0x230/0x230 [14249.341253] ---[ end trace 7f1d8a449e6af5aa ]--- [14249.341259] scsi 6:0:0:0: failed to add device: -2 Sarah Sharp -- 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: Suspend issues with a LaCie USB hard disk connected
On Wed, 18 Dec 2013, Daniel Mack wrote: Hi, I'm facing an issue putting an embedded system to sleep while a Lacie external USB hard disk is connected. Relevant kernel messages that occur at the attempt are: [ 13.834731] PM: Sending message for entering DeepSleep mode [ 13.846575] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 13.858818] sd 0:0:0:0: [sda] [ 13.862432] Result: hostbyte=0x00 driverbyte=0x08 [ 13.867349] sd 0:0:0:0: [sda] [ 13.870626] Sense Key : 0x5 [current] [ 13.874602] sd 0:0:0:0: [sda] [ 13.877879] ASC=0x20 ASCQ=0x0 [ 13.885053] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns -5 [ 13.901130] PM: Device 0:0:0:0 failed to suspend async: error -5 [ 13.907507] PM: Some devices failed to suspend, or early wake event detected What happens is that in sd_sync_cache(), scsi_execute_req_flags() returns 0x0802, so driver_byte(res) evaluates to DRIVER_SENSE and host_byte(res) is DID_OK, which is an unhandled case that leads to -EIO eventually. I have admittedly not much clue about the SCSI layer, so I wonder what would be the best way to fix this. Should DID_OK just be handled as non-error condition in the switch? Should the suspend call chain ignore such errors from sd_sync_cache()? I'm open to suggestions and happy to test patches. The Sense Key and ASC values indicate that the drive did not understand the SYNCHRONIZE CACHE command. A usbmon trace would verify this; see the instructions in Documentation/usb/usbmon.txt. Assuming that really is what happened, we have to decide how to handle the situation. Alan Stern -- 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: XHCI: Ring expansion failure
On Wed, 18 Dec 2013, Sarah Sharp wrote: I think there's a couple of ways we could fix this. One would be to set the IOC flag on the last no-op TRBs in a TD we're trying to cancel. I think that will make the event handling code increment the dequeue pointer and update the number of free TRBs on the ring (or the code could be changed to do so). That would take care of the num_trbs_free counting issue for URB cancellation that isn't part of device suspend. Why not just keep the existing IOC flag setting when you convert a TRB into a no-op? Then the number of events generated by the hardware will be the same as it would have been. Alan Stern -- 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: xhci_hcd and Canon Lide 110 not playing well together
Hey all, On Fr, 2013-12-13 at 17:53 +0100, Holger Hans Peter Freyther wrote: On Tue, May 28, 2013 at 07:40:57PM +0200, Holger Hans Peter Freyther wrote: Is there a timeline when you think this could be fixed? I tried with 3.10.x and 3.12.5 and the symptoms remain the same. The first time it is working, the second time the scanning does not start. The scanner is still working fine on other machines (with the identical cable). as I'm facing a similar problem (Canon Lide, though 25 instead of 110), I would also like to know if there are news about this. See http://thread.gmane.org/gmane.linux.usb.general/99815 for details about the hardware. If something is missing I'll try to provide it. Its strange, that the same hardware (notebook and scanner) works on one port, but not on the other). I tried again today and all physical ports I can access are either connected to Bus 03 (I suspect, that Bus 04 and Bus 03 are the same, only differing in their speed) or Bus 02. Bus 02 (Driver=ehci-pci/2p, 480M) works, Bus 03 (Driver=xhci_hcd/4p, 480M) fails. Any ideas? Greetings Matthias PS: I removed my subscription of linux-usb as I got flooded with mails, please keep me CCed. -- 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: [RFC 0/2] target refcounting infrastructure fixes for usb
On Wed, 18 Dec 2013, Sarah Sharp wrote: On Mon, Dec 16, 2013 at 07:10:19AM -0800, James Bottomley wrote: This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. James I tried these patches, and they cause an oops when a USB mass storage device is plugged in. Note that this device uses the usb-storage driver, not the uas driver. [14248.340064] scsi6 : usb-storage 2-2:1.0 [14248.341083] usbcore: registered new interface driver usb-storage [14248.346211] usbcore: registered new interface driver uas [14249.339937] scsi 6:0:0:0: Direct-Access LexarJumpDrive1.00 PQ: 0 ANSI: 6 [14249.340988] [ cut here ] [14249.340999] WARNING: CPU: 3 PID: 5578 at lib/kobject.c:227 kobject_add_internal+0x13f/0x350() [14249.341003] kobject_add_internal failed for 6:0:0:0 (error: -2 parent: target6:0:0) [14249.341005] Modules linked in: uas usb_storage ctr ccm cuse dm_crypt uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev btusb x86_pkg_temp_thermal coretemp ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd arc4 iwldvm mac80211 microcode snd_hda_codec_hdmi iwlwifi psmouse snd_hda_codec_realtek serio_raw snd_hda_intel snd_usb_audio snd_hda_codec thinkpad_acpi cfg80211 joydev snd_usbmidi_lib nvram snd_hwdep snd_seq_midi snd_pcm snd_seq_midi_event snd_rawmidi lpc_ich rfcomm bnep snd_seq bluetooth snd_seq_device snd_page_alloc ehci_pci snd_timer ehci_hcd snd soundcore tpm_tis binfmt_misc btrfs libcrc32c xor raid6_pq hid_generic usbhid hid i915 ahci libahci e1000e sdhci_pci sdhci i2c_algo_bit drm_kms_helper ptp pps_core drm xhci_hcd video [14249.341095] CPU: 3 PID: 5578 Comm: kworker/u16:0 Not tainted 3.13.0-rc1+ #142 [14249.341098] Hardware name: LENOVO 2325AP7/2325AP7, BIOS G2ET82WW (2.02 ) 09/11/2012 [14249.341105] Workqueue: events_unbound async_run_entry_fn [14249.341108] 0009 88003aa9db60 81658a4e 88003aa9dba8 [14249.341115] 88003aa9db98 81048c3d 88006bc551b0 fffe [14249.341121] 8800bec22838 0200 88003aa9dbf8 [14249.341127] Call Trace: [14249.341135] [81658a4e] dump_stack+0x4d/0x66 [14249.341142] [81048c3d] warn_slowpath_common+0x7d/0xa0 [14249.341148] [81048cac] warn_slowpath_fmt+0x4c/0x50 [14249.341154] [81660f17] ? _raw_spin_unlock+0x27/0x40 [14249.341159] [8133748f] kobject_add_internal+0x13f/0x350 [14249.341163] [813379b5] kobject_add+0x65/0xb0 [14249.341170] [81425b40] ? get_device+0x30/0x30 [14249.341175] [81649781] ? klist_init+0x31/0x40 [14249.341181] [81427208] device_add+0x128/0x660 [14249.341186] [814369cc] ? __pm_runtime_resume+0x5c/0x90 [14249.341193] [8145bcdc] scsi_sysfs_add_sdev+0xac/0x340 [14249.341199] [8145a443] do_scan_async+0x83/0x180 [14249.341204] [81074247] async_run_entry_fn+0x37/0x130 [14249.341210] [81066524] process_one_work+0x1f4/0x550 [14249.341215] [810664c2] ? process_one_work+0x192/0x550 [14249.341220] [81067261] worker_thread+0x121/0x3a0 [14249.341225] [81067140] ? manage_workers.isra.22+0x2a0/0x2a0 [14249.341231] [8106dc8c] kthread+0xfc/0x120 [14249.341238] [8106db90] ? kthread_create_on_node+0x230/0x230 [14249.341243] [81669cac] ret_from_fork+0x7c/0xb0 [14249.341249] [8106db90] ? kthread_create_on_node+0x230/0x230 [14249.341253] ---[ end trace 7f1d8a449e6af5aa ]--- [14249.341259] scsi 6:0:0:0: failed to add device: -2 James: The problem occurs when scsi_finish_async_scan() calls scsi_sysfs_add_devices(). During an async scan, the devices get stored up and not made visible as they are found (see the end of scsi_add_lun()). At the end, the target gets removed because it has no visible children, of course. Then when the children do get added all at once, when the scan is over, it's too late. How should this be fixed? Forget about the en-masse registration and do each device as it is found? Alan Stern -- 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
Debugging XHCI hardware issues?
Hello again, we've made some progress getting large SuperSpeed ISO transfers for the new Kinect to work. As it turns out, the central issue here was which XHCI controller the device is connected to. I have two different HCs, one from Intel and one from NEC. According to lspci, these are: 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)) 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) The exact same code works when the device is attached to the NEC controller (transferring 33792 bytes per ISO packet as requested), but fails on the Intel controller (transferring only 11264 bytes, exactly 1/3 of the requested size). I don't have enough background knowledge to decide if this is some sort of hardware issue, missing hardware feature or rather related to the XHCI driver. Can somebody suggest a direction for further investigation? Thanks best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] usb: phy: fix driver dependencies
On Wed, 18 Dec 2013 09:58:33 -0600 Felipe Balbi ba...@ti.com wrote: are you sure that patch is included ? I have just checked on greg/usb-linus that it's impossible to make CONFIG_USB=m and CONFIG_ISP1301_OMAP=y (same for the other phy driver from Freescale). I can also build omap1_defconfig with all possibilities for CONFIG_USB + CONFIG_ISP1301_OMAP, that is: N-N, M-M, Y-M. If you can still see the problem, then send me your .config and error messages. You could be seeing another problem. OK, I took Linus' tree of today, merged Greg's usb.current tree (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-linus) and then your tree (git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#next) fixed the merge conflict in drivers/usb/phy/Kconfig as per the email I sent yesterday, added the merge fix patch I reported a few days ago (for the usb_phy_gen_create_phy() API change). I then did an x86_64 allmodconfig build and got: drivers/built-in.o: In function `otg_set_state': drivers/usb/phy/phy-fsm-usb.c:170: undefined reference to `usb_bus_start_enum' .config attached. Greg's tree contains commit 7cd0c298f6e0 (usb: phy: fix driver dependencies). -- Cheers, Stephen Rothwells...@canb.auug.org.au config.bz2 Description: Binary data pgpUN7FIXPf7Q.pgp Description: PGP signature
RE: Debugging XHCI hardware issues?
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Florian Echtler Sent: Wednesday, December 18, 2013 2:04 PM we've made some progress getting large SuperSpeed ISO transfers for the new Kinect to work. As it turns out, the central issue here was which XHCI controller the device is connected to. I have two different HCs, one from Intel and one from NEC. According to lspci, these are: 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)) 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) The exact same code works when the device is attached to the NEC controller (transferring 33792 bytes per ISO packet as requested), but fails on the Intel controller (transferring only 11264 bytes, exactly 1/3 of the requested size). I don't have enough background knowledge to decide if this is some sort of hardware issue, missing hardware feature or rather related to the XHCI driver. Can somebody suggest a direction for further investigation? What are the values from the ISO endpoint's Endpoint descriptor and SuperSpeed Endpoint Companion descriptor? If the Mult value is 2 (bits 1:0 of the Companion descriptor's bmAttributes field) and the Intel controller is treating it as 0 for some reason, that would give you 1/3 of the requested size. Or perhaps it is a throughput issue; if the bInterval is 1, then 33792 bytes every 128us is a pretty high data rate. Perhaps the Intel controller can't keep up. Do you have USB debugging enabled (CONFIG_USB_DEBUG=y) in the kernel config? With the latest kernels that should cause the xHCI driver to print debug messages to the dmesg log. In earlier kernels you also have to enable CONFIG_USB_XHCI_HCD_DEBUGGING. Do you have a USB bus analyzer? That should show you exactly what is going on. If not, maybe you can capture a usbmon trace. I don't know anything about usbmon, but Alan Stern might be able to help with that. -- Paul Thanks best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL -- 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 V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
On Wed, Dec 18, 2013 at 5:35 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote: From: Andreas Naumann anaum...@ultratronik.de This is a hard to reproduce problem which leads to non-functional USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore of OTG_INTERFSEL over suspend. Since the resume function is also called early in driver init, it uses a non-initialized value (which is 0 and a non-supported setting in DM37xx for INTERFSEL). Shortly after the correct value is set. Apparently this works most time, but not always. yeah, but the problem is not on the glue layer. The bug is omap_device and pm_runtime not agreeing on device's state. I suppose there was a fix for that recently in linux-omap@vger mailing list. You mean this: http://marc.info/?t=13844488263r=1w=2 ? This looks like a different issue during suspend, this problem is at startup. Both musb_core and omap2430.c expect hardware to be disabled on startup, and that works as expected. The problem is on first pm_runtime_get_sync(), which results in first runtime_resume() call, musb_core checks for first resume and doesn't load yet-unset context in that case, however glue does and breaks things. We have this problem since 3.2. Gražvydas -- 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 09/12] USB: ohci-octeon: Use devm_ioremap_resource()
On 12/10/2013 11:27 PM, Jingoo Han wrote:
Use devm_ioremap_resource() to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
Tested and...
Acked-by: David Daney david.da...@cavium.com
---
drivers/usb/host/ohci-octeon.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ohci-octeon.c b/drivers/usb/host/ohci-octeon.c
index 49b220d..15af895 100644
--- a/drivers/usb/host/ohci-octeon.c
+++ b/drivers/usb/host/ohci-octeon.c
@@ -138,20 +138,12 @@ static int ohci_octeon_drv_probe(struct platform_device
*pdev)
hcd-rsrc_start = res_mem-start;
hcd-rsrc_len = resource_size(res_mem);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len,
- OCTEON_OHCI_HCD_NAME)) {
- dev_err(pdev-dev, request_mem_region failed\n);
- ret = -EBUSY;
+ reg_base = devm_ioremap_resource(pdev-dev, res_mem);
+ if (IS_ERR(reg_base)) {
+ ret = PTR_ERR(reg_base);
goto err1;
}
- reg_base = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!reg_base) {
- dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err2;
- }
-
ohci_octeon_hw_start();
hcd-regs = reg_base;
@@ -168,7 +160,7 @@ static int ohci_octeon_drv_probe(struct platform_device
*pdev)
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret) {
dev_dbg(pdev-dev, failed to add hcd with err %d\n, ret);
- goto err3;
+ goto err2;
}
device_wakeup_enable(hcd-self.controller);
@@ -177,12 +169,9 @@ static int ohci_octeon_drv_probe(struct platform_device
*pdev)
return 0;
-err3:
+err2:
ohci_octeon_hw_stop();
- iounmap(hcd-regs);
-err2:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
err1:
usb_put_hcd(hcd);
return ret;
@@ -195,8 +184,6 @@ static int ohci_octeon_drv_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
ohci_octeon_hw_stop();
- iounmap(hcd-regs);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
return 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: [PATCH 03/12] USB: ehci-octeon: Use devm_ioremap_resource()
On 12/10/2013 11:20 PM, Jingoo Han wrote:
Use devm_ioremap_resource() to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
This patch doesn't apply cleanly against Linus' branch. However, I was
able to successfully test it after manually applying the changes.
After you rebase the patch, you can add ...
Acked-by: David Daney david.da...@cavium.com
---
drivers/usb/host/ehci-octeon.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ehci-octeon.c b/drivers/usb/host/ehci-octeon.c
index c4ad7ed..9051439 100644
--- a/drivers/usb/host/ehci-octeon.c
+++ b/drivers/usb/host/ehci-octeon.c
@@ -128,20 +128,12 @@ static int ehci_octeon_drv_probe(struct platform_device
*pdev)
hcd-rsrc_start = res_mem-start;
hcd-rsrc_len = resource_size(res_mem);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len,
- OCTEON_EHCI_HCD_NAME)) {
- dev_err(pdev-dev, request_mem_region failed\n);
- ret = -EBUSY;
+ hcd-regs = devm_ioremap_resource(pdev-dev, res_mem);
+ if (IS_ERR(hcd-regs)) {
+ ret = PTR_ERR(hcd-regs);
goto err1;
}
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!hcd-regs) {
- dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err2;
- }
-
ehci_octeon_start();
ehci = hcd_to_ehci(hcd);
@@ -156,19 +148,16 @@ static int ehci_octeon_drv_probe(struct platform_device
*pdev)
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret) {
dev_dbg(pdev-dev, failed to add hcd with err %d\n, ret);
- goto err3;
+ goto err2;
}
device_wakeup_enable(hcd-self.controller);
platform_set_drvdata(pdev, hcd);
return 0;
-err3:
+err2:
ehci_octeon_stop();
- iounmap(hcd-regs);
-err2:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
err1:
usb_put_hcd(hcd);
return ret;
@@ -181,8 +170,6 @@ static int ehci_octeon_drv_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
ehci_octeon_stop();
- iounmap(hcd-regs);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
return 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: [RFC 0/2] target refcounting infrastructure fixes for usb
On Wed, 2013-12-18 at 16:50 -0500, Alan Stern wrote: On Wed, 18 Dec 2013, Sarah Sharp wrote: On Mon, Dec 16, 2013 at 07:10:19AM -0800, James Bottomley wrote: This set should fix our target problems with USB by making the target visibility properly reference counted. Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. James I tried these patches, and they cause an oops when a USB mass storage device is plugged in. Note that this device uses the usb-storage driver, not the uas driver. [14248.340064] scsi6 : usb-storage 2-2:1.0 [14248.341083] usbcore: registered new interface driver usb-storage [14248.346211] usbcore: registered new interface driver uas [14249.339937] scsi 6:0:0:0: Direct-Access LexarJumpDrive 1.00 PQ: 0 ANSI: 6 [14249.340988] [ cut here ] [14249.340999] WARNING: CPU: 3 PID: 5578 at lib/kobject.c:227 kobject_add_internal+0x13f/0x350() [14249.341003] kobject_add_internal failed for 6:0:0:0 (error: -2 parent: target6:0:0) [14249.341005] Modules linked in: uas usb_storage ctr ccm cuse dm_crypt uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev btusb x86_pkg_temp_thermal coretemp ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd arc4 iwldvm mac80211 microcode snd_hda_codec_hdmi iwlwifi psmouse snd_hda_codec_realtek serio_raw snd_hda_intel snd_usb_audio snd_hda_codec thinkpad_acpi cfg80211 joydev snd_usbmidi_lib nvram snd_hwdep snd_seq_midi snd_pcm snd_seq_midi_event snd_rawmidi lpc_ich rfcomm bnep snd_seq bluetooth snd_seq_device snd_page_alloc ehci_pci snd_timer ehci_hcd snd soundcore tpm_tis binfmt_misc btrfs libcrc32c xor raid6_pq hid_generic usbhid hid i915 ahci libahci e1000e sdhci_pci sdhci i2c_algo_bit drm_kms_helper ptp pps_core drm xhci_hcd video [14249.341095] CPU: 3 PID: 5578 Comm: kworker/u16:0 Not tainted 3.13.0-rc1+ #142 [14249.341098] Hardware name: LENOVO 2325AP7/2325AP7, BIOS G2ET82WW (2.02 ) 09/11/2012 [14249.341105] Workqueue: events_unbound async_run_entry_fn [14249.341108] 0009 88003aa9db60 81658a4e 88003aa9dba8 [14249.341115] 88003aa9db98 81048c3d 88006bc551b0 fffe [14249.341121] 8800bec22838 0200 88003aa9dbf8 [14249.341127] Call Trace: [14249.341135] [81658a4e] dump_stack+0x4d/0x66 [14249.341142] [81048c3d] warn_slowpath_common+0x7d/0xa0 [14249.341148] [81048cac] warn_slowpath_fmt+0x4c/0x50 [14249.341154] [81660f17] ? _raw_spin_unlock+0x27/0x40 [14249.341159] [8133748f] kobject_add_internal+0x13f/0x350 [14249.341163] [813379b5] kobject_add+0x65/0xb0 [14249.341170] [81425b40] ? get_device+0x30/0x30 [14249.341175] [81649781] ? klist_init+0x31/0x40 [14249.341181] [81427208] device_add+0x128/0x660 [14249.341186] [814369cc] ? __pm_runtime_resume+0x5c/0x90 [14249.341193] [8145bcdc] scsi_sysfs_add_sdev+0xac/0x340 [14249.341199] [8145a443] do_scan_async+0x83/0x180 [14249.341204] [81074247] async_run_entry_fn+0x37/0x130 [14249.341210] [81066524] process_one_work+0x1f4/0x550 [14249.341215] [810664c2] ? process_one_work+0x192/0x550 [14249.341220] [81067261] worker_thread+0x121/0x3a0 [14249.341225] [81067140] ? manage_workers.isra.22+0x2a0/0x2a0 [14249.341231] [8106dc8c] kthread+0xfc/0x120 [14249.341238] [8106db90] ? kthread_create_on_node+0x230/0x230 [14249.341243] [81669cac] ret_from_fork+0x7c/0xb0 [14249.341249] [8106db90] ? kthread_create_on_node+0x230/0x230 [14249.341253] ---[ end trace 7f1d8a449e6af5aa ]--- [14249.341259] scsi 6:0:0:0: failed to add device: -2 James: The problem occurs when scsi_finish_async_scan() calls scsi_sysfs_add_devices(). During an async scan, the devices get stored up and not made visible as they are found (see the end of scsi_add_lun()). At the end, the target gets removed because it has no visible children, of course. Then when the children do get added all at once, when the scan is over, it's too late. How should this be fixed? Forget about the en-masse registration and do each device as it is found? Great, I knew I'd find a reason to hate the async scanning code eventually. However, the solution is just to make the kref work for us. We already properly refcount everything, so we just take the reap_ref on the target at the point the disk has to go through the remove device path, then just rely on refcounting ... a bit like this. James --- diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index 34eab7b..cc6e5bd 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -996,7 +996,6 @@ int
Support for Empia 2980 video/audio capture chip set
Hello, I'm trying to get a Dazzle Video Capture USB V1.0 video capture card working on a Linux device but it doesn't look like the chip set is supported yet. I believe this card is the next version of the Pinnacle VC100 capture card that worked with the em28xx kernel module. The hardware vendor that sold the card says that this device has an Empia 2980 chip set in it so I'm inquiring about support for that chip set. I'm just wondering about the best approach for getting the new chip supported in the kernel. Is this something the em28xx maintainers would naturally address in time or can I assist in getting this into the kernel? Here's dmesg from the Debian box I'm working on: [ 3198.920619] usb 3-1: new high-speed USB device number 5 using xhci_hcd [ 3198.939394] usb 3-1: New USB device found, idVendor=1b80, idProduct=e60a [ 3198.939399] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 3198.939403] usb 3-1: Product: Dazzle Video Capture USB Audio Device [ 3198.939405] usb 3-1: SerialNumber: 0 l440:~$ uname -a Linux l440 3.10-3-amd64 #1 SMP Debian 3.10.11-1 (2013-09-10) x86_64 GNU/Linux If this isn't the appropriate list to ask this question please point me in the right direction. I'm subscribed so no need to CC. Thanks, Keith. -- 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] usb: dwc3: ep0: Handle variable-length Data Stage
Hi,
Hi,
On Tue, Dec 17, 2013 at 03:59:31PM +0900, Anton Tikhomirov wrote:
In accordance with specification, when sent data length is
please mention section of specification.
USB2.0 spec., 8.5.3.2 Variable-length Data Stage
an exact multiple of wMaxPacketSize for the pipe and less
than requested by host, the function shall return a zero-length
packet (ZLP) to indicate the end of the Data stage to a USB host.
hmm... so in USB3 mode that would be host requesting 513 bytes and us
sending only 512.
Our customer reported this issue. In their case, Windows USB2.0 host
requests Configuration descriptor with wLength = 255. Device replies
with two 64 bytes IN transactions, and stalls EP0 on 3rd IN transaction,
where it has to reply with ZLP. Unfortunately, we don’t have full
picture of what's happening on their side and why host requests
more bytes than actual length of Configuration descriptor.
@@ -619,6 +619,7 @@ struct dwc3_scratchpad_array {
* @three_stage_setup: set if we perform a three phase setup
* @ep0_bounced: true when we used bounce buffer
* @ep0_expect_in: true when we expect a DATA IN transfer
+ * @ep0_zlp_sent: true when ZLP was sent
I would rather have a ep0_needs_zlp flag.
ok
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 21a3520..cf72561 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -782,6 +782,9 @@ static void dwc3_ep0_complete_data(struct dwc3
*dwc,
return;
}
+ if (dwc-ep0_zlp_sent)
+ goto finish_zlp;
+
length = trb-size DWC3_TRB_SIZE_MASK;
if (dwc-ep0_bounced) {
@@ -802,14 +805,24 @@ static void dwc3_ep0_complete_data(struct dwc3
*dwc,
/* for some reason we did not get everything out */
dwc3_ep0_stall_and_restart(dwc);
- } else {
- /*
-* handle the case where we have to send a zero packet.
This
-* seems to be case when req.length maxpacket. Could it
be?
-*/
- if (r)
By the way, why do we need this check? If r is NULL, we will have
panic above in this function, where ur is dereferenced.
- dwc3_gadget_giveback(ep0, r, 0);
+ return;
}
+
+ /* handle the case where we have to send a zero packet */
+ if ((epnum 1) ur-zero
+ (ur-length % ep0-endpoint.maxpacket == 0)) {
+ int ret;
+
+ ret = dwc3_ep0_start_trans(dwc, epnum, dwc-ctrl_req_addr,
0,
+ DWC3_TRBCTL_CONTROL_DATA);
+ WARN_ON(ret 0);
+ dwc-ep0_zlp_sent = 1;
+ return;
+ }
note that this causes a slight bug. Code expects to receive a
NRDY_STATUS, but we're sending another CONTROL_DATA which means we will
receive XFER_COMPLETE_DATA.
It's only working because Control(Data) lost its XferNotReady handling
due to a silicon bug we found. If someone ever patches that handler,
this will be a hard-to-track problem.
My bad, will fix this.
how have you tested this ? Any changes to ep0 handling must come with a
libusb-based testcase so I can make sure nothing else gets broken (yes,
new requirement :-)
Also make sure to run testusb for control endpoints and leave it
running
for weeks. You should be able to survive 4 weeks of stress test without
any issues.
Don't forget to run through USB30CV ch9 on USB3 and USB2 modes.
Sorry dude, but I can't accept regressions and this code has been
exercised pretty well.
Thank you for review. I will rework the patch and test carefully.
--
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 03/12] USB: ehci-octeon: Use devm_ioremap_resource()
On Wed, Dec 18, 2013 at 03:44:21PM -0800, David Daney wrote: On 12/10/2013 11:20 PM, Jingoo Han wrote: Use devm_ioremap_resource() to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com This patch doesn't apply cleanly against Linus' branch. However, I was able to successfully test it after manually applying the changes. After you rebase the patch, you can add ... Acked-by: David Daney david.da...@cavium.com No rebase needed, it was against my tree, and I've now applied it, thanks. greg k-h -- 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 03/12] USB: ehci-octeon: Use devm_ioremap_resource()
On Thursday, December 19, 2013 8:44 AM, Jingoo Han wrote: On 12/10/2013 11:20 PM, Jingoo Han wrote: Use devm_ioremap_resource() to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com This patch doesn't apply cleanly against Linus' branch. However, I was able to successfully test it after manually applying the changes. As Greg said, this patch was based on Greg's USB tree. Anyway, I really appreciate your test. :-) Best regards, Jingoo Han After you rebase the patch, you can add ... Acked-by: David Daney david.da...@cavium.com -- 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: Support for Empia 2980 video/audio capture chip set
On Wed, Dec 18, 2013 at 08:26:47PM -0500, Keith Lawson wrote: Hello, I'm trying to get a Dazzle Video Capture USB V1.0 video capture card working on a Linux device but it doesn't look like the chip set is supported yet. I believe this card is the next version of the Pinnacle VC100 capture card that worked with the em28xx kernel module. The hardware vendor that sold the card says that this device has an Empia 2980 chip set in it so I'm inquiring about support for that chip set. I'm just wondering about the best approach for getting the new chip supported in the kernel. Is this something the em28xx maintainers would naturally address in time or can I assist in getting this into the kernel? Here's dmesg from the Debian box I'm working on: [ 3198.920619] usb 3-1: new high-speed USB device number 5 using xhci_hcd [ 3198.939394] usb 3-1: New USB device found, idVendor=1b80, idProduct=e60a [ 3198.939399] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 3198.939403] usb 3-1: Product: Dazzle Video Capture USB Audio Device [ 3198.939405] usb 3-1: SerialNumber: 0 l440:~$ uname -a Linux l440 3.10-3-amd64 #1 SMP Debian 3.10.11-1 (2013-09-10) x86_64 GNU/Linux If this isn't the appropriate list to ask this question please point me in the right direction. I'm subscribed so no need to CC. Try the linux-media developers, they would know this chipset and drivers much better than we do. thanks, greg k-h -- 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/1] AX88179_178A: Add FLAG_HW_IPALIGN to determine whether reserving NET_IP_ALIGN bytes for an SKB.
On 2013年12月16日 18:09, David Laight wrote: I was thinking of something like: skb = netdev_alloc_skb(dev, length + dev-skb_align, gfp); if (NET_IP_ALIGN skb !(ev-driver_flags FLAG_HW_IPALIGN)) skb_reserve(skb, NET_IP_ALIGN); It might even be reasonable to remove the length adjustment - provided that all the later code uses the skb length. David Thanks for your advice. In the way you advised, does the dev-skb_align equal to NET_IP_ALIGN in the case that HW doesn't supoort IP alignment? In other words, dev-skb_align should be initialized to NET_IP_ALIGN in USBNET, and I can change its value to 0 in AX88179_178A driver, right? Freddy -- 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] usb: usbtest: Add timetout to simple_io()
On Wed, Dec 18, 2013 at 10:37:44AM -0600, Felipe Balbi wrote: On Wed, Dec 18, 2013 at 10:46:03PM +0800, Huang Rui wrote: Hi Roger, On Wed, Dec 18, 2013 at 03:40:10PM +0530, Roger Quadros wrote: Without a timetout some tests e.g. test_halt() can remain stuck forever. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com --- drivers/usb/misc/usbtest.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index b415282..6294e1b 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -10,6 +10,7 @@ #include linux/usb.h +#define SIMPLE_IO_TIMEOUT1 /* in milliseconds */ Only one question, how do you confirm the timeout value? dude, it's just a timeout. It could be anything, really. 10 seconds is just large enough value that would allow even the slowest scenarios (host + device) to complete, while not being so slow that you would wanna kill yourself after waiting for such a long time ;-) OK. I've tested in my side. Acked-by: Huang Rui ray.hu...@amd.com -- 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 2/2] usb: usbtest: Always clear halt else further tests will fail
On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote:
In test_halt() we set an endpoint halt condition and return on halt
verification
failure, then the enpoint will remain halted and all further tests related
to that enpoint will fail. This is because we don't tackle endpoint halt
error condition
in any of the tests. To avoid that situation, make sure to clear the
halt condition before exiting test_halt().
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 6294e1b..300b726 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int ep,
struct urb *urb)
return retval;
}
retval = verify_halted(tdev, ep, urb);
- if (retval 0)
+ if (retval 0) {
+ int ret;
+
+ /* clear halt anyways, else further tests will fail */
+ ret = usb_clear_halt(urb-dev, urb-pipe);
+ if (ret)
+ ERROR(tdev, ep %02x couldn't clear halt, %d\n,
+ ep, ret);
+
return retval;
+ }
/* clear halt (tests API + protocol), verify it worked */
retval = usb_clear_halt(urb-dev, urb-pipe);
--
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: [RFC/PATCH 0/3] pm: Make SET_*_PM_OPS() macros more smart
On Thu, Dec 12, 2013 at 09:18:22PM -0800, David Cohen wrote: Hi, These patches are proposal to extend the lack of #ifdef checks on PM callback to its implementation too. Currently SET_*_PM_OPS() macros make #ifdefs checks not necessary when setting the callback to PM ops, but the callbacks implementation don't see same benefit. This RFC Solves a problem reported by Santosh on xhci-plat.c driver due to wrong #ifdef checks: drivers/usb/host/xhci-plat.c:201:12: warning: ‘xhci_plat_suspend’ defined but not used [-Wunused-function] drivers/usb/host/xhci-plat.c:209:12: warning: ‘xhci_plat_resume’ defined but not used [-Wunused-function] But instead of fixing the #ifdefs, we remove the need for it :) Ping. Comments here? :) Br, David Br, David Cohen --- David Cohen (2): pm: make PM macros more smart usb/xhci: implement proper static inline stubs when !CONFIG_PM Santosh Shilimkar (1): usb/xhci-plat: remove unnecessary #ifdef checks for CONFIG_PM_SLEEP drivers/usb/host/xhci-plat.c | 7 +-- drivers/usb/host/xhci.h | 6 -- include/linux/pm.h | 11 +-- 3 files changed, 14 insertions(+), 10 deletions(-) -- 1.8.4.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: XHCI: Ring expansion failure
On Wed, Nov 06, 2013 at 11:09:50PM -, hema...@codeaurora.org wrote: On Wed, Nov 6, 2013 at 12:33 PM, hema...@codeaurora.org wrote: On Wed, Nov 6, 2013 at 12:53 AM, hema...@codeaurora.org wrote: Hi Hi Hemant, By performing iterative port suspend and resume (which results in function suspend and resume), ring expansion failure is observed. Attached device has multiple interfaces for which interface host drivers are unlinking the urbs during function suspend and submitting urbs during resume. For the cases when dequeue ptr is close to the end of deq segment, value of num_trbs_in_deq_seg (= ring-dequeue - ring-deq_seg-trbs) becomes high when function suspend is over. At the time of resume this high value is causing to trigger ring expansion in the middle of submitting urbs(ring-num_trbs_free num_trbs + num_trbs_in_deq_seg). All the interface host drivers only request one TRB per urb (num_trb =1). Ring expansion logic is doubling the num of previously allocated segments every time. This is causing the num of segments to grow at fast pace (at the time of failure, one of the ep rings num_seg was 128), even though it is also increasing num_trbs_free. Sorry for taking so long to respond to this. It's definitely something we need to look into. Which type of USB device caused this out-of-control ring expansion? Can you provide us a link for where to buy it, if it's a specific device? It would make it easier for us to test this. No it is not device specific issue. I continued debugging this issue further after writing to linux-usb. I am hitting the issue easily on interrupt IN ep ring. I was able to get to the point due to which issue is happening. I have a driver which is queuing 17 urb on interrupt IN ep and when suspend happens it kills one urb at a time which means this results into 17 stop ep cmds which gets finished one after the other. I added some dmesg logs for this ep to print SW deq ptr and also the deq ptr xHC is on in handle_tx_event which will be called as a result of issuing stop ep command. For good cases i see that xHC was able to skip though the No-OP TRBs when stop ep cmd was issued for urbs :- 21.700565] handle_tx_event: Stopped on No-op or Link TRB [ 21.705895] handle_tx_event NO OP EVT TRB: ed0da4c0 ep_ring-enq = ed0da5a0 ep_ring-deq = ed0da4c0 ep_ring-num_trbs_free 111 [ 21.717272] handle_stopped_endpoint: MARKED NO-OP TRB: ed0da4d0 curr td = e9dbd080 ep-stopped_td = (null) ep_ring-enq = ed0da5a0 ep_ring-deq = ed0da4c0 ep_ring-num_trbs_free 111 [ 21.733648] handle_tx_event: Stopped on No-op or Link TRB [ 21.738968] handle_tx_event NO OP EVT TRB: ed0da4d0 ep_ring-enq = ed0da5a0 ep_ring-deq = ed0da4c0 ep_ring-num_trbs_free 111 Here you can see that TRB @ 0xed0da4c0 was marked as NO-OP and xHC deq ptr is on that NO-OP TRB. For the next stop ep cmd which marked the TRB 0xed0da4d0 as No-OP when door bell was rung handle_tx_event happened for 0xed0da4d0 which means controller is skipping though the No-OP TRBs on the way. Also, with controller skipping TRBs there could be a situation when TD that we are trying to cancel, xHC deq ptr is on corresponding TRB which will cause set TR deq cmd to get executed. In bad case i am observing that xHC deq ptr is stuck to a No-OP TRB (0xed0da420) and for all the subsequent stop ep cmd it is generating handle_tx_event for same No-OP TRB like this (pasting few of the logs) :- [ 23.126453] handle_tx_event: Stopped on No-op or Link TRB [ 23.130811] handle_tx_event NO OP EVT TRB: ed0da420 ep_ring-enq = ed0da550 ep_ring-deq = ed0da420 ep_ring-num_trbs_free 106 [ 23.142185] handle_stopped_endpoint: MARKED NO-OP TRB: ed0da440 curr td = e9d9d400 ep-stopped_td = (null) ep_ring-enq = ed0da550 ep_ring-deq = ed0da420 ep_ring-num_trbs_free 106 [ 23.158569] handle_tx_event: Stopped on No-op or Link TRB [ 23.163883] handle_tx_event NO OP EVT TRB: ed0da420 ep_ring-enq = ed0da550 ep_ring-deq = ed0da420 ep_ring-num_trbs_free 106 [ 23.175255] handle_stopped_endpoint: MARKED NO-OP TRB: ed0da450 curr td = e9d9d300 ep-stopped_td = (null) ep_ring-enq = ed0da550 ep_ring-deq = ed0da420 ep_ring-num_trbs_free 106 [ 23.191698] handle_tx_event: Stopped on No-op or Link TRB [ 23.196955] handle_tx_event NO OP EVT TRB: ed0da420 ep_ring-enq = ed0da550 ep_ring-deq = ed0da420 ep_ring-num_trbs_free 106 [ 23.208329] handle_stopped_endpoint: MARKED NO-OP TRB: ed0da460 curr td = e9d9d200 ep-stopped_td = (null) ep_ring-enq = ed0da550 ep_ring-deq = ed0da420 ep_ring-num_trbs_free 106 Here you can see that all the times handle_tx_event is generated for same NO-OP TRB. So controller is not skipping through the NO-OP TRBs which are getting marked here (ed0da440, ed0da450, ed0da460) even after door bell was rung. This causes all the TRBs to become No-OP TRBs when all the URBs are cancelled. Now there is no way set tr deq ptr cmd will be called and controller remains stuck to the same No-OP TRB.
Re: [PATCH v7 8/9] phy: add Broadcom Kona USB2 PHY driver
Hi Felipe,
On Wednesday 18 December 2013 09:55 PM, Felipe Balbi wrote:
On Tue, Dec 17, 2013 at 02:42:35PM -0500, Matt Porter wrote:
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter mpor...@linaro.org
Kishon, are you ok with this driver ?
yeah. Since this patch touches phy/Kconfig (and Makefile) and there is one more
PHY driver to be merged that also modifies Kconfig there might be conflicts. So
thought I should be taking this patch?
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+struct device *dev = pdev-dev;
+struct bcm_kona_usb *phy;
+struct resource *res;
+struct phy *gphy;
+struct phy_provider *phy_provider;
+
+phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+if (!phy)
+return -ENOMEM;
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+phy-regs = devm_ioremap_resource(pdev-dev, res);
+if (IS_ERR(phy-regs))
+return PTR_ERR(phy-regs);
+
+platform_set_drvdata(pdev, phy);
+
+phy_provider = devm_of_phy_provider_register(dev,
+of_phy_simple_xlate);
+if (IS_ERR(phy_provider))
+return PTR_ERR(phy_provider);
+
+gphy = devm_phy_create(dev, ops, NULL);
+if (IS_ERR(gphy))
+return PTR_ERR(gphy);
+
+/* The Kona PHY supports an 8-bit wide UTMI interface */
+phy_set_bus_width(gphy, 8);
+
+phy_set_drvdata(gphy, phy);
I think this set_drvdata() should be done before registering the
provider, no ?
hmm, right.
Thanks
Kishon
--
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] usb: dwc3: ep0: Handle variable-length Data Stage
Hi, On Thu, Dec 19, 2013 at 02:54:31PM +0900, Anton Tikhomirov wrote: WARN_ON(ret 0); Regards Pratyush By the way, chaining additional (auxiliary) TRB would allow complying with Buffer Size Rule on _UDC_driver_level_ for any type of OUT endpoints, when total size of a Buffer Descriptor must be a multiple of MaxPacketSize: rem = request_length % MaxPacketSize general TRB size = request_length (CHN = 1) should be request_length - rem aux TRB size = MaxPacketSize - rem(CHN = 0) should be rem Buffer for aux TRBs can be allocated at initialization time and used when necessary. send a patch and test it for weeks ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: ep0: Handle variable-length Data Stage
On Thu, Dec 19, 2013 at 11:32:08AM +0900, Anton Tikhomirov wrote:
Hi,
Hi,
On Tue, Dec 17, 2013 at 03:59:31PM +0900, Anton Tikhomirov wrote:
In accordance with specification, when sent data length is
please mention section of specification.
USB2.0 spec., 8.5.3.2 Variable-length Data Stage
an exact multiple of wMaxPacketSize for the pipe and less
than requested by host, the function shall return a zero-length
packet (ZLP) to indicate the end of the Data stage to a USB host.
hmm... so in USB3 mode that would be host requesting 513 bytes and us
sending only 512.
Our customer reported this issue. In their case, Windows USB2.0 host
requests Configuration descriptor with wLength = 255. Device replies
with two 64 bytes IN transactions, and stalls EP0 on 3rd IN transaction,
where it has to reply with ZLP. Unfortunately, we don’t have full
picture of what's happening on their side and why host requests
more bytes than actual length of Configuration descriptor.
that's a bug on the host side.
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 21a3520..cf72561 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -782,6 +782,9 @@ static void dwc3_ep0_complete_data(struct dwc3
*dwc,
return;
}
+ if (dwc-ep0_zlp_sent)
+ goto finish_zlp;
+
length = trb-size DWC3_TRB_SIZE_MASK;
if (dwc-ep0_bounced) {
@@ -802,14 +805,24 @@ static void dwc3_ep0_complete_data(struct dwc3
*dwc,
/* for some reason we did not get everything out */
dwc3_ep0_stall_and_restart(dwc);
- } else {
- /*
- * handle the case where we have to send a zero packet.
This
- * seems to be case when req.length maxpacket. Could it
be?
- */
- if (r)
By the way, why do we need this check? If r is NULL, we will have
panic above in this function, where ur is dereferenced.
probably comes from earlier code.
how have you tested this ? Any changes to ep0 handling must come with a
libusb-based testcase so I can make sure nothing else gets broken (yes,
new requirement :-)
Also make sure to run testusb for control endpoints and leave it
running
for weeks. You should be able to survive 4 weeks of stress test without
any issues.
Don't forget to run through USB30CV ch9 on USB3 and USB2 modes.
Sorry dude, but I can't accept regressions and this code has been
exercised pretty well.
Thank you for review. I will rework the patch and test carefully.
Thanks for that, I appreciate it :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail
On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote:
On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote:
In test_halt() we set an endpoint halt condition and return on halt
verification
failure, then the enpoint will remain halted and all further tests related
^^^
to that enpoint will fail. This is because we don't tackle endpoint halt
error condition
^^^
BTW, please fix these typo.
Thanks,
Rui
in any of the tests. To avoid that situation, make sure to clear the
halt condition before exiting test_halt().
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 6294e1b..300b726 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int
ep, struct urb *urb)
return retval;
}
retval = verify_halted(tdev, ep, urb);
- if (retval 0)
+ if (retval 0) {
+ int ret;
+
+ /* clear halt anyways, else further tests will fail */
+ ret = usb_clear_halt(urb-dev, urb-pipe);
+ if (ret)
+ ERROR(tdev, ep %02x couldn't clear halt, %d\n,
+ ep, ret);
+
return retval;
+ }
/* clear halt (tests API + protocol), verify it worked */
retval = usb_clear_halt(urb-dev, urb-pipe);
--
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
--
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 2/2] usb: usbtest: Always clear halt else further tests will fail
On 12/19/2013 11:16 AM, Huang Rui wrote:
On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote:
On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote:
In test_halt() we set an endpoint halt condition and return on halt
verification
failure, then the enpoint will remain halted and all further tests related
^^^
to that enpoint will fail. This is because we don't tackle endpoint halt
error condition
^^^
BTW, please fix these typo.
Hi Rui,
These patches have been already applied to Greg's usb tree without your Ack's
or the typo fix.
Greg,
do you want me to resend the patches?
cheers,
-roger
Thanks,
Rui
in any of the tests. To avoid that situation, make sure to clear the
halt condition before exiting test_halt().
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/misc/usbtest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 6294e1b..300b726 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int
ep, struct urb *urb)
return retval;
}
retval = verify_halted(tdev, ep, urb);
- if (retval 0)
+ if (retval 0) {
+ int ret;
+
+ /* clear halt anyways, else further tests will fail */
+ ret = usb_clear_halt(urb-dev, urb-pipe);
+ if (ret)
+ ERROR(tdev, ep %02x couldn't clear halt, %d\n,
+ ep, ret);
+
return retval;
+ }
/* clear halt (tests API + protocol), verify it worked */
retval = usb_clear_halt(urb-dev, urb-pipe);
--
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
--
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 2/2] usb: usbtest: Always clear halt else further tests will fail
On Thu, Dec 19, 2013 at 11:51:45AM +0530, Roger Quadros wrote: On 12/19/2013 11:16 AM, Huang Rui wrote: On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote: On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote: In test_halt() we set an endpoint halt condition and return on halt verification failure, then the enpoint will remain halted and all further tests related ^^^ to that enpoint will fail. This is because we don't tackle endpoint halt error condition ^^^ BTW, please fix these typo. Hi Rui, These patches have been already applied to Greg's usb tree without your Ack's or the typo fix. Greg, do you want me to resend the patches? Nope, it's not a big deal, typo's in changelog comments isn't a worry. greg k-h -- 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] usb: dwc3: ep0: Handle variable-length Data Stage
Hi, Hi, On Thu, Dec 19, 2013 at 02:54:31PM +0900, Anton Tikhomirov wrote: WARN_ON(ret 0); Regards Pratyush By the way, chaining additional (auxiliary) TRB would allow complying with Buffer Size Rule on _UDC_driver_level_ for any type of OUT endpoints, when total size of a Buffer Descriptor must be a multiple of MaxPacketSize: rem = request_length % MaxPacketSize general TRB size = request_length (CHN = 1) should be request_length - rem aux TRB size = MaxPacketSize - rem (CHN = 0) should be rem In this case: Buffer_Descriptor_size = general_TRB_size + aux_TRB_size = (request_lenth - rem) + rem = request_length , which is not multiple of MaxPacketSize. The idea is to build Buffer Descriptor, whose total size is multiple of MaxPacketSize, using additional TRB. Buffer for aux TRBs can be allocated at initialization time and used when necessary. send a patch and test it for weeks ;-) -- Balbi Thanks -- 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] usb: dwc3: ep0: Handle variable-length Data Stage
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Wednesday, December 18, 2013 10:03 PM On Thu, Dec 19, 2013 at 11:32:08AM +0900, Anton Tikhomirov wrote: Hi, Hi, On Tue, Dec 17, 2013 at 03:59:31PM +0900, Anton Tikhomirov wrote: In accordance with specification, when sent data length is please mention section of specification. USB2.0 spec., 8.5.3.2 Variable-length Data Stage an exact multiple of wMaxPacketSize for the pipe and less than requested by host, the function shall return a zero-length packet (ZLP) to indicate the end of the Data stage to a USB host. hmm... so in USB3 mode that would be host requesting 513 bytes and us sending only 512. Our customer reported this issue. In their case, Windows USB2.0 host requests Configuration descriptor with wLength = 255. Device replies with two 64 bytes IN transactions, and stalls EP0 on 3rd IN transaction, where it has to reply with ZLP. Unfortunately, we don’t have full picture of what's happening on their side and why host requests more bytes than actual length of Configuration descriptor. that's a bug on the host side. Certainly not. The host doesn't know how big the Configuration descriptor is, so it always asks for 255 bytes (on Windows that is, I'm not sure about Linux). The problem here sounds like the Configuration descriptor for this particular device is exactly 128 bytes (two packets at HS), so a 0-length packet is needed to terminate the transfer. -- Paul
RE: [PATCH] usb: dwc3: ep0: Handle variable-length Data Stage
Hi, On Thu, Dec 19, 2013 at 11:32:08AM +0900, Anton Tikhomirov wrote: Hi, Hi, On Tue, Dec 17, 2013 at 03:59:31PM +0900, Anton Tikhomirov wrote: In accordance with specification, when sent data length is please mention section of specification. USB2.0 spec., 8.5.3.2 Variable-length Data Stage an exact multiple of wMaxPacketSize for the pipe and less than requested by host, the function shall return a zero-length packet (ZLP) to indicate the end of the Data stage to a USB host. hmm... so in USB3 mode that would be host requesting 513 bytes and us sending only 512. Our customer reported this issue. In their case, Windows USB2.0 host requests Configuration descriptor with wLength = 255. Device replies with two 64 bytes IN transactions, and stalls EP0 on 3rd IN transaction, where it has to reply with ZLP. Unfortunately, we don’t have full picture of what's happening on their side and why host requests more bytes than actual length of Configuration descriptor. that's a bug on the host side. Certainly not. The host doesn't know how big the Configuration descriptor is, so it always asks for 255 bytes (on Windows that is, I'm not sure about Linux). As far as I know, first time Windows host requests only 9 bytes of Configuration descriptor, which include total size of Configuration descriptor and its subordinates. Then, second time it requests Configuration descriptor again and uses total length obtained in first step. Am I wrong? The problem here sounds like the Configuration descriptor for this particular device is exactly 128 bytes (two packets at HS), so a 0- Exactly! length packet is needed to terminate the transfer. -- 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/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
Hi Dan,
Am 18.12.2013 um 18:49 schrieb Dan Williams:
On Wed, 2013-12-18 at 14:16 +0100, Dr. H. Nikolaus Schaller wrote:
Hi Dan,
Am 17.12.2013 um 23:27 schrieb Dan Williams:
On Tue, 2013-12-17 at 20:56 +0100, Dr. H. Nikolaus Schaller wrote:
Hi Dan,
Am 16.12.2013 um 20:40 schrieb Dan Williams:
On Fri, 2013-12-13 at 15:43 +0100, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 02.10.2013 um 09:00 schrieb Dr. H. Nikolaus Schaller:
Hi Jan,
we are using a GTM601 modem (Firmware 1.7) for a while and have spotted
an
issue that under some conditions the modem sends a packed wIndex over
USB
that is rejected by the hso driver making troubles afterwards. Not
rejecting makes
it work fine.
BR,
Nikolaus Schaller
---
From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
From: H. Nikolaus Schaller h...@goldelico.com
Date: Thu, 15 Nov 2012 14:40:57 +0100
Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by
OPTION
GTM601 during RING indication
It has been observed that the GTM601 with 1.7 firmware sometimes sends
a value
wIndex that has bit 0x04 set instead of being reset as the code
expects. So we
mask it for the error check.
See
http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
Signed-off-by: NeilBrown ne...@suse.de
Signed-off-by: H. Nikolaus Schaller h...@goldelico.de
---
drivers/net/usb/hso.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..d146e26 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb
*urb)
if (serial_state_notification-bmRequestType != BM_REQUEST_TYPE
||
serial_state_notification-bNotification != B_NOTIFICATION
||
le16_to_cpu(serial_state_notification-wValue) != W_VALUE ||
- le16_to_cpu(serial_state_notification-wIndex) != W_INDEX ||
+ (le16_to_cpu(serial_state_notification-wIndex) ~0x4) !=
+ W_INDEX ||
le16_to_cpu(serial_state_notification-wLength) !=
W_LENGTH) {
dev_warn(usb-dev,
hso received invalid serial state
notification\n);
--
1.7.7.4
I have found this (better) proposal by OPTION, but wonder what did
happen to it.
It neither shows in mainline 3.13-rc nor linux-next:
https://lkml.org/lkml/2013/10/9/263
Likely because nobody formally submitted the patch with a signed-off-by,
which indicates their intent that the patch is tested, correct, and can
be merged to the kernel.
Ok, I see. I just wasn't aware of the proposal at all since I missed the
discussion
and wasn't on CC.
Therefore I have added Eric to the CC.
I looked at this today, and I'm left wondering how any port other than
HSO_PORT_MODEM can get the notification via tiocmget_intr_callback().
serial-tiocmget is only created for HSO_PORT_MODEM serial ports (see
hso_create_bulk_serial_device()):
if ((port HSO_PORT_MASK) == HSO_PORT_MODEM) {
num_urbs = 2;
serial-tiocmget = kzalloc(sizeof(struct hso_tiocmget),
GFP_KERNEL);
and the code in tiocmget_intr_callback() does this:
tiocmget = serial-tiocmget;
if (!tiocmget)
return;
which should mean that only a HSO_PORT_MODEM will ever process the
notification. Further, the tiocmget interrupt URB is only created and
submitted if serial-tiocmget != NULL, so only HSO_PORT_MODEM should
ever be calling into tiocmget_intr_callback().
Ok, that looks plausible.
So I think Eric's patch is actually wrong because it will *always* pass
the new check.
The original code had the correct intention, but the original code was
obviously wrong for newer devices where the port layout is read from
firmware and not from static tables, and thus for recent devices where
the modem interface is not USB interface #2.
This explains why we did run into the problem with the GTM601.
Can you confirm/deny that the 'modem' interface for your GTM601 is USB
interface #6? For example, my Icon 452 has the following USB interface
layout:
0: Diag
1: GPS
2: GPS control
3: Application
4: Control
5: Network
6: Modem
So like the GTM601, I would expect any RING notifications to appear for
wIndex=0x06.
Interestingly I see:
0: Diagnostic
1: GPS
2: GPS Control
3: Application
4: Control
5: Modem
I.e. there is no Network interface. Originally we did focus on /dev/ttyHS3
How are you determining the number here? Are you using:
cat /sys/class/tty/ttyHS_Modem/device/bInterfaceNumber
to determine the actual USB interface number associated with the Modem
port? Or are you going off the pre-udev-rename ttyHSx numbers?
Ah, I did use
root@gta04:~# ls -d /sys/class/tty/ttyHS*; cat /sys/class/tty/ttyHS*/hsotype
/sys/class/tty/ttyHS0
