Re: dma-buf and -dev refcount fun
On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie airl...@gmail.com wrote: So I've got a reproducable oops with udl sharing from i915, start X, connect UDL, randr it into position, rip out udl device, kill X, we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets called, attachment-dev is pointing to a freed structure, now the drm + udl driver points dev-dev at the USB interface device, however when the device is unplugged, the USB interface device disappears in a poof of smoke, and we just keep a fake shell of the drm device around to keep userspace happy. So I'm wondering if should be using a different device to create dma-buf objects or whether dma-buf objects need to be keeping a reference on the interface device, Don't do any mapping/attaching then since you never need to do dma anyway. And I guess if we ever need to do dma with usb devices for real we just need to teach the usb core about dma-bufs, so that the *hci can do the attaching and dma-mapping. On a quick look through udl_gem.c vmap will keep on working since it's already forwarded to i915. That leaves mmap - either your userspace doesn't need this for prime buffers or you'd need to implement that one too. Rob Clark had patches floating around for forwarding mmaping through dma-bufs between gem drivers a long time ago, Rob Bradford is working on dma-buf mmap support for i915. Besides the issue at hand though I think drivers need to make sure that the device they use for attaching does outlive the dma-buf. Which for real hotpluggin probably means that drivers need to drop all attachment on unplug (the dma mapping is useless anyway) and just keep all their imported gem objects alive with just a reference to the dma-buf object itself. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: dma-buf and -dev refcount fun
On 03/25/2014 09:01 AM, Daniel Vetter wrote: On Tue, Mar 25, 2014 at 4:53 AM, Dave Airlie airl...@gmail.com wrote: So I've got a reproducable oops with udl sharing from i915, start X, connect UDL, randr it into position, rip out udl device, kill X, we get an oops when dma_unmap_sg in i915_gem_unmap_dma_buf gets called, attachment-dev is pointing to a freed structure, now the drm + udl driver points dev-dev at the USB interface device, however when the device is unplugged, the USB interface device disappears in a poof of smoke, and we just keep a fake shell of the drm device around to keep userspace happy. So I'm wondering if should be using a different device to create dma-buf objects or whether dma-buf objects need to be keeping a reference on the interface device, Don't do any mapping/attaching then since you never need to do dma anyway. And I guess if we ever need to do dma with usb devices for real we just need to teach the usb core about dma-bufs, so that the *hci can do the attaching and dma-mapping. On a quick look through udl_gem.c vmap will keep on working since it's already forwarded to i915. That leaves mmap - either your userspace doesn't need this for prime buffers or you'd need to implement that one too. Rob Clark had patches floating around for forwarding mmaping through dma-bufs between gem drivers a long time ago, Rob Bradford is working on dma-buf mmap support for i915. Ouch, here we go! I though the idea was *not* to implement dma-buf mmap() on the major drivers :( ??? /Thomas -- 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: dma-buf and -dev refcount fun
Hi On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter dan...@ffwll.ch wrote: Besides the issue at hand though I think drivers need to make sure that the device they use for attaching does outlive the dma-buf. Which for real hotpluggin probably means that drivers need to drop all attachment on unplug (the dma mapping is useless anyway) and just keep all their imported gem objects alive with just a reference to the dma-buf object itself. Drivers should never touch other drivers or even look at them. There is no reason i915 is responsible of keeping udl alive. That gets really messy and may introduce circular dependencies. I'd like to see exported dma-bufs reference their drm-device owner. This way, the drm-device stays around until the dma-buf is removed. To avoid lazy device destruction, a driver can (during unplug) simply detach all dma-bufs if, and only if, they first made the dma-buf somehow stand-alone. For example: udl can just move the allocated pages into the dma-buf, mark it as dead and detach it. The udl-device can get destructed and whenever i915 releases the dma-buf, the udl-dma-buf ops see it's dead and just deref it / release dma-buf resources. But this is all not needed if the exported dma-bufs just reference drm_device, which is imho the easiest fix. 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] cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver
From: Michael Ulbricht michael.ulbri...@systec-electronic.com
By specifying NO_UNION_NORMAL the ACM driver does only use the first two
USB interfaces (modem data control). The AT Port, Diagnostic and NMEA
interfaces are left to the USB serial driver.
Signed-off-by: Michael Ulbricht michael.ulbri...@systec-electronic.com
Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com
---
drivers/usb/class/cdc-acm.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff..7783aca 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1652,13 +1652,27 @@ static const struct usb_device_id acm_ids[] = {
},
/* Motorola H24 HSPA module: */
{ USB_DEVICE(0x22b8, 0x2d91) }, /* modem
*/
- { USB_DEVICE(0x22b8, 0x2d92) }, /* modem + diagnostics
*/
- { USB_DEVICE(0x22b8, 0x2d93) }, /* modem + AT port
*/
- { USB_DEVICE(0x22b8, 0x2d95) }, /* modem + AT port + diagnostics
*/
- { USB_DEVICE(0x22b8, 0x2d96) }, /* modem + NMEA
*/
- { USB_DEVICE(0x22b8, 0x2d97) }, /* modem + diagnostics + NMEA
*/
- { USB_DEVICE(0x22b8, 0x2d99) }, /* modem + AT port + NMEA
*/
- { USB_DEVICE(0x22b8, 0x2d9a) }, /* modem + AT port + diagnostics + NMEA
*/
+ { USB_DEVICE(0x22b8, 0x2d92), /* modem + diagnostics
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
+ { USB_DEVICE(0x22b8, 0x2d93), /* modem + AT port
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
+ { USB_DEVICE(0x22b8, 0x2d95), /* modem + AT port + diagnostics
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
+ { USB_DEVICE(0x22b8, 0x2d96), /* modem + NMEA
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
+ { USB_DEVICE(0x22b8, 0x2d97), /* modem + diagnostics + NMEA
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
+ { USB_DEVICE(0x22b8, 0x2d99), /* modem + AT port + NMEA
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
+ { USB_DEVICE(0x22b8, 0x2d9a), /* modem + AT port + diagnostics + NMEA
*/
+ .driver_info = NO_UNION_NORMAL, /* handle only modem interface
*/
+ },
{ USB_DEVICE(0x0572, 0x1329), /* Hummingbird huc56s (Conexant) */
.driver_info = NO_UNION_NORMAL, /* union descriptor misplaced on
--
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: serial: Add USB identifier for the Motorola/Telit H24 HSPA module
As the module does not use the standard USB mechanism, the appropriate
product and vendor IDs have to be added.
Signed-off-by: Michael Ulbricht michael.ulbri...@systec-electronic.com
Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com
---
drivers/usb/serial/usb-serial-simple.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial-simple.c
b/drivers/usb/serial/usb-serial-simple.c
index fb79775..b25e552 100644
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -61,7 +61,17 @@ DEVICE(vivopay, VIVOPAY_IDS);
{ USB_DEVICE(0x0c44, 0x0022) }, /* unknown Mororola phone */\
{ USB_DEVICE(0x22b8, 0x2a64) }, /* Motorola KRZR K1m */ \
{ USB_DEVICE(0x22b8, 0x2c84) }, /* Motorola VE240 phone */ \
- { USB_DEVICE(0x22b8, 0x2c64) } /* Motorola V950 phone */
+ { USB_DEVICE(0x22b8, 0x2c64) }, /* Motorola V950 phone */ \
+ { USB_DEVICE(0x22b8, 0x2d94) }, /* Motorola H24 HSPA module (
Diagnostic ) */\
+ { USB_DEVICE(0x22b8, 0x2d9B) }, /* Motorola H24 HSPA module (
NMEA) */\
+ { USB_DEVICE(0x22b8, 0x2d93) }, /* Motorola H24 HSPA module (Modem + AT
Port) */\
+ { USB_DEVICE(0x22b8, 0x2d92) }, /* Motorola H24 HSPA module (Modem
+ Diagnostic ) */\
+ { USB_DEVICE(0x22b8, 0x2d96) }, /* Motorola H24 HSPA module (Modem
+ NMEA) */\
+ { USB_DEVICE(0x22b8, 0x2d98) }, /* Motorola H24 HSPA module (
Diagnostic + NMEA) */\
+ { USB_DEVICE(0x22b8, 0x2d95) }, /* Motorola H24 HSPA module (Modem + AT
Port + Diagnostic ) */\
+ { USB_DEVICE(0x22b8, 0x2d99) }, /* Motorola H24 HSPA module (Modem + AT
Port + NMEA) */\
+ { USB_DEVICE(0x22b8, 0x2d97) }, /* Motorola H24 HSPA module (Modem
+ Diagnostic + NMEA) */\
+ { USB_DEVICE(0x22b8, 0x2d9A) } /* Motorola H24 HSPA module (Modem + AT
Port + Diagnostic + NMEA) */
DEVICE(moto_modem, MOTO_IDS);
/* HP4x (48/49) Generic Serial driver */
--
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: dma-buf and -dev refcount fun
On Tue, Mar 25, 2014 at 7:40 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter dan...@ffwll.ch wrote: Besides the issue at hand though I think drivers need to make sure that the device they use for attaching does outlive the dma-buf. Which for real hotpluggin probably means that drivers need to drop all attachment on unplug (the dma mapping is useless anyway) and just keep all their imported gem objects alive with just a reference to the dma-buf object itself. Drivers should never touch other drivers or even look at them. There is no reason i915 is responsible of keeping udl alive. That gets really messy and may introduce circular dependencies. I'd like to see exported dma-bufs reference their drm-device owner. This way, the drm-device stays around until the dma-buf is removed. To avoid lazy device destruction, a driver can (during unplug) simply detach all dma-bufs if, and only if, they first made the dma-buf somehow stand-alone. For example: udl can just move the allocated pages into the dma-buf, mark it as dead and detach it. The udl-device can get destructed and whenever i915 releases the dma-buf, the udl-dma-buf ops see it's dead and just deref it / release dma-buf resources. But this is all not needed if the exported dma-bufs just reference drm_device, which is imho the easiest fix. I sent a patch to fix the udl case to just keep a reference on the usb_interface device it seems to work, we probably do need to do this in theory for pci devices as well in a hotplug/sysfs plug situation I suppose, Dave. -- 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 v4 00/11] Add USB OTG HNP and SRP support on Chipidea usb driver
Changes since v3: - Move out 2 patches from this patchset, as which are not directly related to otg fsm. - Add a new file chipidea.txt under Documentation/usb/ to show how to test OTG HNP and SRP. - Directly embed struct otg_fsm into ci_hdrc instead of pointer of otg_fsm. - Remove flag check in ci_otg_del_timer(). - Remove ADP related code and comments since ADP is not supported by chip. If you are implementing SoC independent code, but your chip does not support ADP, you can add ADP support in TODO list, see drivers/usb/chipidea/core.c. - Start OTG fsm before request_irq. - For B-device, do not do OTG fsm transitions when gadget driver is not registered, and start OTG fsm in register gadget driver. - Directly call ci_otg_fsm_work() in ci_hdrc_otg_fsm_start(). - Enable data pulse when a_wait_vfall timer time out. - Update a_wait_vrise time out function. - UPdate comments of OTG time macro definitions in otg_fsm.h according to OTG and EH 2.0. - Some typo correction and comments format changes. Changes since v2: - Add ABI document for sysfs input files description: Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg - Add a debug file for show some USB registers value. - Split host driver change to be 2 patches, one for otg_port number init; the other one for vbus control change. - Export interrupt enable and status read functions from udc driver. - Only enable AVV irq in otg fsm init. - Remove duplicated USBSTS bits definitions. - Add HowTo demo role switch with 2 Freescale i.MX6Q sabre SD boards in cover letter. - typo correction. Changes since v1: - Move out HNP polling patch from this series, which will be a seperated patchset followed this one - Change fsm timers global variables to be a structure embeded in ci_hdrc, to make multiple OTG instances can exist in one system - Change some otg fsm functions to be static - Re-split timer init patch to avoid a later patch changing a previous one in the same series - Change timer structure memory allocation to be devm_kzalloc - Update some format alignment and spelling errors Li Jun (11): usb: chipidea: usb OTG fsm initialization. usb: chipidea: host: vbus control change for OTG HNP. usb: chipidea: host: init otg port number. usb: chipidea: udc: driver update for OTG HNP. usb: chipidea: add OTG fsm operation functions implemenation. usb: chipidea: OTG fsm timers initialization. usb: chipidea: OTG HNP and SRP fsm implementation. usb: chipidea: add sys inputs for OTG fsm input. usb: chipidea: debug: add debug file for OTG variables Documentation: ABI: usb: chipidea USB OTG HNP sysfs Documentation: usb: add chipidea.txt for how to demo usb OTG HNP and SRP .../ABI/testing/sysfs-platform-chipidea-usb-otg| 56 ++ Documentation/usb/chipidea.txt | 69 ++ drivers/usb/chipidea/Makefile |1 + drivers/usb/chipidea/bits.h| 11 +- drivers/usb/chipidea/ci.h |3 + drivers/usb/chipidea/core.c| 10 +- drivers/usb/chipidea/debug.c | 84 ++ drivers/usb/chipidea/host.c| 13 +- drivers/usb/chipidea/host.h|9 + drivers/usb/chipidea/otg.c | 17 +- drivers/usb/chipidea/otg_fsm.c | 852 drivers/usb/chipidea/otg_fsm.h | 122 +++ drivers/usb/chipidea/udc.c | 17 +- 13 files changed, 1255 insertions(+), 9 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-chipidea- usb-otg create mode 100644 Documentation/usb/chipidea.txt create mode 100644 drivers/usb/chipidea/otg_fsm.c create mode 100644 drivers/usb/chipidea/otg_fsm.h -- 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
RE: usb 3.0 problems with NEC Controller
From: Of Sarah Sharp Cc'ing Mathias Nyman, who is taking over as xHCI driver maintainer. Do you need to repost these mails to the list just so that Mathias gets a private copy? Maybe Mathias could filter mails to linux_usb@ that are also addressed to Sarah into his 'interesting' emails folder. 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: dma-buf and -dev refcount fun
On Tue, Mar 25, 2014 at 10:40:45AM +0100, David Herrmann wrote: Hi On Tue, Mar 25, 2014 at 9:01 AM, Daniel Vetter dan...@ffwll.ch wrote: Besides the issue at hand though I think drivers need to make sure that the device they use for attaching does outlive the dma-buf. Which for real hotpluggin probably means that drivers need to drop all attachment on unplug (the dma mapping is useless anyway) and just keep all their imported gem objects alive with just a reference to the dma-buf object itself. Drivers should never touch other drivers or even look at them. There is no reason i915 is responsible of keeping udl alive. That gets really messy and may introduce circular dependencies. I'd like to see exported dma-bufs reference their drm-device owner. This way, the drm-device stays around until the dma-buf is removed. To avoid lazy device destruction, a driver can (during unplug) simply detach all dma-bufs if, and only if, they first made the dma-buf somehow stand-alone. For example: udl can just move the allocated pages into the dma-buf, mark it as dead and detach it. The udl-device can get destructed and whenever i915 releases the dma-buf, the udl-dma-buf ops see it's dead and just deref it / release dma-buf resources. But this is all not needed if the exported dma-bufs just reference drm_device, which is imho the easiest fix. The issue at hand is the other way round, i.e. i915 exporting, udl importing. The i915/dma-buf falls over because the device struct referenced in the attachment disappeared. Dave fixed it by grabbing a reference, I think the better fix would be to simply not attach (since udl doesn't need it anyway). Either works. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] staging/usbip: fix store_attach() sscanf return value check
sscanf() parses the input buffer for four input items. However, the return value check is incorrect, as it checks for one input item instead of four which is what it is expecting in the input buffer. As a result, sscanf() will always fail even when the input buffer is correct. Signed-off-by: Shuah Khan shuah...@samsung.com --- v2: Fixed changelog drivers/staging/usbip/vhci_sysfs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/usbip/vhci_sysfs.c b/drivers/staging/usbip/vhci_sysfs.c index e098032..1ff24e9 100644 --- a/drivers/staging/usbip/vhci_sysfs.c +++ b/drivers/staging/usbip/vhci_sysfs.c @@ -183,7 +183,7 @@ static ssize_t store_attach(struct device *dev, struct device_attribute *attr, * @devid: unique device identifier in a remote host * @speed: usb device speed in a remote host */ - if (sscanf(buf, %u %u %u %u, rhport, sockfd, devid, speed) != 1) + if (sscanf(buf, %u %u %u %u, rhport, sockfd, devid, speed) != 4) return -EINVAL; usbip_dbg_vhci_sysfs(rhport(%u) sockfd(%u) devid(%u) speed(%u)\n, -- 1.7.10.4 -- 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 3.0 problems with NEC Controller
On 03/25/2014 12:56 PM, David Laight wrote: From: Of Sarah Sharp Cc'ing Mathias Nyman, who is taking over as xHCI driver maintainer. Do you need to repost these mails to the list just so that Mathias gets a private copy? Maybe Mathias could filter mails to linux_usb@ that are also addressed to Sarah into his 'interesting' emails folder. David Hi David Sorry about the extra traffic I have filtering for xhci, usb3, usb 3 etc to get the xhci related mails to my interesting folder. I belive this cc Mathias is more an awareness campaign for other people on the mailing list to send xhci related issues to me in the future, and also a polite reminder for me to take a look and react to some specific issue. This should only be temporary and go away once I get my bug triage up to speed. -Mathias -- 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 v4][ 3/8] usb: chipidea: usbmisc: Add USB support for i.MX25/i.MX35 CPUs
Hi Peter, On Fri, Mar 14, 2014 at 3:51 AM, Peter Chen peter.c...@freescale.com wrote: On Thu, Mar 13, 2014 at 10:18:41AM +0100, Denis Carikli wrote: This adds the i.MX25 and the i.MX35 support in the ChipIdea usbmisc driver. The i.MX25 and i.MX35 usb controllers are similar enough to be able to use the same code. Signed-off-by: Denis Carikli de...@eukrea.com ... Applied, thanks. Where is your git tree located? I still don't see this patch applied in linux-next. Regards, Fabio Estevam -- 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] staging/usbip: fix store_attach() sscanf return value check
Hello. On 03/25/2014 02:12 AM, Shuah Khan wrote: Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7 Please also specify that commit's summary line in parens. Also, there's now an established format for such things: Fixes: 12-digit SHA ID (summary line) You can place such line before your signoff line. This commit added return value check for sscanf() that parses the input buffer for four input items. However, the return value check is incorrect, as it checks for one input item instead of four which is what it is expecting in the input buffer. As a result, sscanf() will always fail even when the input buffer is correct. Signed-off-by: Shuah Khan shuah...@samsung.com 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: problem with resume after s2ram
On Tue, 25 Mar 2014, Peter Münster wrote:
On Mon, Mar 24 2014, Alan Stern wrote:
All three files show the system hanging after the resume, even the file
with nothing in the rear ports. Also, the logs are incomplete; it
looks like a bunch of stuff is missing from the start of the suspend.
Did you use netconsole to collect the logs?
Hi,
Yes. And just before, I've made echo 8 /proc/sys/kernel/printk
Okay. I guess netconsole doesn't work very well during system suspend.
Oddly, this log is much more complete than the others. Did you collect
it the same way?
No. I've used /var/log/messages.
That explains why it is more complete.
This is very puzzling. Let's try one more combination. Can you
collect a log showing 3.14 with commit 0aa2832dd0d9d8 reverted and the
mouse keyboard both plugged into the rear ports?
Yes. Please find attached the log (kernel 3.12.14). I attach also the
hub.c that I use, because there were conflicts, that I've resolved
manually.
This looks normal.
Clearly we aren't making much progress, mainly because it's so hard to
get debugging data during system suspend. So let's try something else
-- maybe the same problem will arise during runtime suspend.
Below is a patch you should apply to normal 3.14 (nothing reverted).
It will cause the 0aa2832dd0d9d8 change to take effect during runtime
suspend as well as system suspend.
For this test, plug some device you aren't going to use (the mouse, for
example, if you will be at a VT console instead of a graphics console)
into the rear port normally used by the mouse. Plug the keyboard and
anything else into front ports -- no other devices should be attached
to a rear port.
Then you can force the test device to go into runtime suspend by typing
this:
echo auto /sys/bus/usb/devices/4-2/power/control
echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue
(I believe 4-2 is the correct path for the rear port where you like to
plug the mouse.)
After 5 seconds or so, force the device to resume by typing:
echo on /sys/bus/usb/devices/4-2/power/control
Let's see what shows up in the kernel log. With luck the resume will
hang but the rest of your system will keep on running.
Alan Stern
Index: usb-3.14/drivers/usb/core/hub.c
===
--- usb-3.14.orig/drivers/usb/core/hub.c
+++ usb-3.14/drivers/usb/core/hub.c
@@ -3015,7 +3015,7 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) 0)
+ else if (0)
status = set_port_feature(hub-hdev, port1,
USB_PORT_FEAT_SUSPEND);
else {
--
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] reset SuperSpeed, xhci_drop_endpoint called with disabled ep, Error in queuecommand_lck: task blocked
On 03/19/2014 01:37 PM, Andreas Reis wrote:
I've uploaded a dmesg with the new debugging patch to bugzilla:
https://bugzilla.kernel.org/attachment.cgi?id=130041
Andreas Reis
On 18.03.2014 15:57, Alan Stern wrote:
The debugging information didn't go far enough. Try the patch below
instead, which has some additional messages.
There are two apparently separate problems here. First, why was the
reset necessary? As far as I can tell, the only explanation seems to
be a failure of Link Power Management.
Second, why the errors in queuecommand_lck? I suspect the answer to
that lies somewhere in the SCSI subystem, not USB. The new debugging
patch should tell us for sure.
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
Hi
Alan and James solved the usb-storage side of this issue, now the LPM
part remains.
Can you try if disabling link powermanagement removes the reset?
First try this patch, it only disables LPM for intel hosts. It will send
the control messages but with values set to disable LPM.
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 04f986d..6b1dae6 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -102,7 +102,7 @@ static void xhci_pci_quirks(struct device *dev,
struct xhci_hcd *xhci)
if (pdev-vendor == PCI_VENDOR_ID_AMD
usb_amd_find_chipset_info())
xhci-quirks |= XHCI_AMD_PLL_FIX;
if (pdev-vendor == PCI_VENDOR_ID_INTEL) {
- xhci-quirks |= XHCI_LPM_SUPPORT;
+ /* xhci-quirks |= XHCI_LPM_SUPPORT; */
xhci-quirks |= XHCI_INTEL_HOST;
}
if (pdev-vendor == PCI_VENDOR_ID_INTEL
If that doesn't help, could you try the next patch. It will make sure
LPM control messages are never sent.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 64ea219..d734630 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3711,6 +3711,9 @@ int usb_disable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
+ dev_info(udev-dev, usb_disable_lpm called, do nothing\n);
+ return 0;
+
if (!udev || !udev-parent ||
udev-speed != USB_SPEED_SUPER ||
!udev-lpm_capable)
@@ -3767,6 +3770,9 @@ void usb_enable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
+ dev_info(udev-dev, usb_enable_lpm called, do nothing\n);
+ return;
+
if (!udev || !udev-parent ||
udev-speed != USB_SPEED_SUPER ||
!udev-lpm_capable)
Both testpatches are added to bug
https://bugzilla.kernel.org/show_bug.cgi?id=70781
-Mathias
--
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 3.0 problems with NEC Controller
On 03/23/2014 08:16 PM, baum...@hotmail.com wrote:
Hello,
I have problems with my USB 3.0 devices; external HDDs (HGST Touro
Mobile Pro (Simpletech-Chip), Fantec case with WDC, Asmedia Chip) and a
Sandisk card reader, with a NEC Corporation uPD720200 USB 3.0 Host
Controller (rev 03) controller.
I get the following errors; = then reset of device, then freezing of
device or many xhci_drop_endpoint called with disabled ep-messages
Suspend and Hibernate is not possible anymore.
= a detailed log is in file usb3_problems.txt
Could you try if disabling all LPM related control transfers on the
buggy NEC hosts has any impact at all.
If you can, please apply the following patch and see if it helps:
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 64ea219..d734630 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3711,6 +3711,9 @@ int usb_disable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
+ dev_info(udev-dev, usb_disable_lpm called, do nothing\n);
+ return 0;
+
if (!udev || !udev-parent ||
udev-speed != USB_SPEED_SUPER ||
!udev-lpm_capable)
@@ -3767,6 +3770,9 @@ void usb_enable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
+ dev_info(udev-dev, usb_enable_lpm called, do nothing\n);
+ return;
+
if (!udev || !udev-parent ||
udev-speed != USB_SPEED_SUPER ||
!udev-lpm_capable)
patch can also be found in bugzilla as patch to disable all lpm related
control transfers
https://bugzilla.kernel.org/show_bug.cgi?id=70781
-Mathias
--
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] reset SuperSpeed, xhci_drop_endpoint called with disabled ep, Error in queuecommand_lck: task blocked
OK, I'll try the two patches in the way you wrote. Does it matter if the
patch from James (the one also suggested to me by Alan) stays applied as
well?
The bug hasn't occurred since I applied the latter, but then again there
were days before that when it didn't happen either.
Hard to really say if something works or not with a bug like this.
Andreas Reis
On 25.03.2014 17:34, Mathias Nyman wrote:
Hi
Alan and James solved the usb-storage side of this issue, now the LPM
part remains.
Can you try if disabling link powermanagement removes the reset?
First try this patch, it only disables LPM for intel hosts. It will send
the control messages but with values set to disable LPM.
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 04f986d..6b1dae6 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -102,7 +102,7 @@ static void xhci_pci_quirks(struct device *dev,
struct xhci_hcd *xhci)
if (pdev-vendor == PCI_VENDOR_ID_AMD
usb_amd_find_chipset_info())
xhci-quirks |= XHCI_AMD_PLL_FIX;
if (pdev-vendor == PCI_VENDOR_ID_INTEL) {
- xhci-quirks |= XHCI_LPM_SUPPORT;
+ /* xhci-quirks |= XHCI_LPM_SUPPORT; */
xhci-quirks |= XHCI_INTEL_HOST;
}
if (pdev-vendor == PCI_VENDOR_ID_INTEL
If that doesn't help, could you try the next patch. It will make sure
LPM control messages are never sent.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 64ea219..d734630 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3711,6 +3711,9 @@ int usb_disable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
+ dev_info(udev-dev, usb_disable_lpm called, do nothing\n);
+ return 0;
+
if (!udev || !udev-parent ||
udev-speed != USB_SPEED_SUPER ||
!udev-lpm_capable)
@@ -3767,6 +3770,9 @@ void usb_enable_lpm(struct usb_device *udev)
{
struct usb_hcd *hcd;
+ dev_info(udev-dev, usb_enable_lpm called, do nothing\n);
+ return;
+
if (!udev || !udev-parent ||
udev-speed != USB_SPEED_SUPER ||
!udev-lpm_capable)
Both testpatches are added to bug
https://bugzilla.kernel.org/show_bug.cgi?id=70781
-Mathias
--
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: Correct last context entry calculation for Configure Endpoint
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct if you don't make assumptions about how the USB core
uses the add_endpoint/drop_endpoint interface (add_flags only contains
endpoints that are new additions in the new configuration).
Furthermore, EP0_FLAG is not consistently set in add_flags throughout
the lifetime of a device. This means that when all endpoints are
dropped, the Context Entries field can be set to 0 (which is invalid and
may cause a Parameter Error) or -1 (which is interpreted as 31 and
causes the driver to keep using the old, incorrect value).
The only surefire way to set this field right is to also take all
existing endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
This patch should be backported to kernels as old as 2.6.31 that contain
the commit f94e0186312b0fc39f41eed4e21836ed74b7efe1 USB: xhci:
Bandwidth allocation support.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 924a6cc..e7d9dfa 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1562,12 +1562,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
- struct xhci_slot_ctx *slot_ctx;
- unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
int ret;
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1614,24 +1612,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
ctrl_ctx-add_flags = cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx-add_flags);
- last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags));
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we deleted the last one */
- if ((le32_to_cpu(slot_ctx-dev_info) LAST_CTX_MASK)
- LAST_CTX(last_ctx)) {
- slot_ctx-dev_info = cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx-dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx-dev_info);
-
xhci_endpoint_zero(xhci, xhci-devs[udev-slot_id], ep);
- xhci_dbg(xhci, drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n,
+ xhci_dbg(xhci, drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n,
(unsigned int) ep-desc.bEndpointAddress,
udev-slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
return 0;
}
@@ -1654,11 +1641,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
- struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
- unsigned int last_ctx;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
@@ -1673,7 +1658,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
return -ENODEV;
added_ctxs = xhci_get_endpoint_flag(ep-desc);
- last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
* deal with ep0 max packet size changing once we get the
@@ -1739,24 +1723,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
*/
new_drop_flags = le32_to_cpu(ctrl_ctx-drop_flags);
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we just added one past */
- if ((le32_to_cpu(slot_ctx-dev_info) LAST_CTX_MASK)
- LAST_CTX(last_ctx)) {
- slot_ctx-dev_info =
Re: usb 3.0 problems with NEC Controller
Thank you for your patch, but the same problems occur with the patch applied. = log attached = xHCI xhci_drop_endpoint called with disabled ep-messages, ... Do you know why the lspci output shows different capabilities/features/flags with the same NEC Controller (exact revision), but different connection/interface? PLX Chip with NEC: not working, PCIe-card with NEC: working Here are the differences between the lspci outputs; PCIe Type | CacheLineSize | Flags; AuxCurrent | PME|DevCtl | MaxReadReq |AuxPwr | CommClk - PLX Chip, NEC, problems | 32 | AuxCurrent=375mA |D3cold+ |NoSnoop+ | 512 bytes |AuxPwr+ | CommClk- PCIe-Card NEC,working | 64 | AuxCurrent=0mA|D3cold- |NoSnoop- | 128 bytes |AuxPwr- | CommClk+ Best regards, Bernhard Log with your patch; -- Mar 25 19:11:11 stargazer kernel: [ 23.584951] usb 1-1.4.3.3: usb_disable_lpm called, do nothing Mar 25 19:11:11 stargazer kernel: [ 23.585417] usb 1-1.4.3.3: usb_enable_lpm called, do nothing Mar 25 19:11:11 stargazer kernel: [ 23.604808] usb 1-1.4.3.3: usb_disable_lpm called, do nothing Mar 25 19:11:11 stargazer kernel: [ 23.605436] usb 1-1.4.3.3: usb_enable_lpm called, do nothing Mar 25 19:11:53 stargazer kernel: [ 65.524316] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd Mar 25 19:11:53 stargazer kernel: [ 65.542614] usb 4-1: Parent hub missing LPM exit latency info. Power management will be impacted. Mar 25 19:11:56 stargazer kernel: [ 69.083510] usb 4-1: New USB device found, idVendor=174c, idProduct=5106 Mar 25 19:11:56 stargazer kernel: [ 69.083518] usb 4-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Mar 25 19:11:56 stargazer kernel: [ 69.083522] usb 4-1: Product: AS2105 Mar 25 19:11:56 stargazer kernel: [ 69.083526] usb 4-1: Manufacturer: ASMedia Mar 25 19:11:56 stargazer kernel: [ 69.083529] usb 4-1: SerialNumber: WD-WXL1E61JNVH2 Mar 25 19:11:56 stargazer kernel: [ 69.084380] usb 4-1: usb_enable_lpm called, do nothing Mar 25 19:11:56 stargazer mtp-probe: checking bus 4, device 2: /sys/devices/pci:00/:00:1c.0/:06:00.0/:07:01.0/:08:00.0/usb4/4-1 Mar 25 19:11:56 stargazer mtp-probe: bus: 4, device: 2 was not an MTP device Mar 25 19:11:56 stargazer kernel: [ 69.116726] usb 4-1: usb_disable_lpm called, do nothing Mar 25 19:11:56 stargazer kernel: [ 69.116732] usb-storage 4-1:1.0: USB Mass Storage device detected Mar 25 19:11:56 stargazer kernel: [ 69.116803] scsi12 : usb-storage 4-1:1.0 Mar 25 19:11:56 stargazer kernel: [ 69.116878] usb 4-1: usb_enable_lpm called, do nothing Mar 25 19:11:56 stargazer kernel: [ 69.116900] usbcore: registered new interface driver usb-storage Mar 25 19:11:57 stargazer kernel: [ 70.117370] scsi 12:0:0:0: Direct-Access WDC WD10 JPVT-00A1YT0 01.0 PQ: 0 ANSI: 5 Mar 25 19:11:57 stargazer kernel: [ 70.117792] sd 12:0:0:0: Attached scsi generic sg6 type 0 Mar 25 19:11:57 stargazer kernel: [ 70.117977] sd 12:0:0:0: [sde] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) Mar 25 19:11:57 stargazer kernel: [ 70.118604] sd 12:0:0:0: [sde] Write Protect is off Mar 25 19:11:57 stargazer kernel: [ 70.118612] sd 12:0:0:0: [sde] Mode Sense: 23 00 00 00 Mar 25 19:11:57 stargazer kernel: [ 70.119378] sd 12:0:0:0: [sde] No Caching mode page found Mar 25 19:11:57 stargazer kernel: [ 70.119387] sd 12:0:0:0: [sde] Assuming drive cache: write through Mar 25 19:11:57 stargazer kernel: [ 70.122476] sd 12:0:0:0: [sde] No Caching mode page found Mar 25 19:11:57 stargazer kernel: [ 70.122483] sd 12:0:0:0: [sde] Assuming drive cache: write through Mar 25 19:11:57 stargazer kernel: [ 70.149683] sde: sde1 Mar 25 19:11:57 stargazer kernel: [ 70.151870] sd 12:0:0:0: [sde] No Caching mode page found Mar 25 19:11:57 stargazer kernel: [ 70.151874] sd 12:0:0:0: [sde] Assuming drive cache: write through Mar 25 19:11:57 stargazer kernel: [ 70.151877] sd 12:0:0:0: [sde] Attached SCSI disk Mar 25 19:12:20 stargazer kernel: [ 92.930989] usb 4-1: usb_disable_lpm called, do nothing Mar 25 19:12:20 stargazer kernel: [ 93.043019] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd Mar 25 19:12:20 stargazer kernel: [ 93.060772] usb 4-1: Parent hub missing LPM exit latency info. Power management will be impacted. Mar 25 19:12:20 stargazer kernel: [ 93.062016] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 8803e635fa80 Mar 25 19:12:20 stargazer kernel: [ 93.062023] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 8803e635fac0 Mar 25 19:12:20 stargazer kernel: [ 93.062776] usb 4-1: usb_enable_lpm called, do nothing Mar 25 19:12:20 stargazer kernel: [ 93.071915] usb 4-1: usb_disable_lpm called, do nothing Mar 25 19:12:20 stargazer kernel: [ 93.183183] usb 4-1: reset
[PATCH] USB: serial: ftdi_sio: add id for Brainboxes VX-001 ExpressCard
Custom VID/PID for Brainboxes VX-001 ExpressCard RS232 as reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1071914
Signed-off-by: Michele Baldessari mich...@acksyn.org
---
drivers/usb/serial/ftdi_sio.c | 2 ++
drivers/usb/serial/ftdi_sio_ids.h | 7 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 44ab12986805..bf72063d6f48 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -909,6 +909,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_Z3X_PID) },
/* Cressi Devices */
{ USB_DEVICE(FTDI_VID, FTDI_CRESSI_PID) },
+ /* Brainbox Devices */
+ { USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_VX_001_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e599fbfcde5f..ae842a203371 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1326,3 +1326,10 @@
* Manufacturer: Cressi
*/
#define FTDI_CRESSI_PID0x87d0
+
+/*
+ * Product: ExpressCard 1 Port RS2323
+ * Manufacturer: Brainboxes
+ */
+#define BRAINBOXES_VID 0x05d1
+#define BRAINBOXES_VX_001_PID 0x1001
--
1.8.5.3
--
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: Fwd: Re: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600
On 2014-01-22 18:16 CET (UTC+1), Takashi Iwai wrote:
At Wed, 22 Jan 2014 18:12:45 +0100,
baum...@hotmail.com wrote:
On 2014-01-20 17:07, Takashi Iwai wrote:
At Mon, 20 Jan 2014 09:45:58 +0100,
Takashi Iwai wrote:
At Sun, 19 Jan 2014 21:30:58 +0100,
baum...@hotmail.com wrote:
Hello,
there must be a misunderstanding;
There is a functional change, because with the line/patch .reset_resume =
usb_audio_resume, the mixer of the usb headset was not removed during
suspend/resume and so the master channel in KDE Mixer was not changed (Headset), which is
the correct behaviour.
Without the line .reset_resume = usb_audio_resume, in /sound/usb/card.c, the
mixer was removed during suspend/resume and re-added, and so the master channel changed
in KDE Mixer to the default onboard audio.
I have tested kernel 3.13rc8, and as you mentioned, the reset_resume-messages
are gone.
But the behaviour of removing the mixer of the usb_audio_headset occurs, which
is, in my opinion, not the correct behaviour, because the chosen master
channel/mixer should stay after suspend/resume.
Could you please take a look at the issue again.
Simply adding usb_audio-resume to reset_resume ops doesn't work
properly as Clemens already suggested. It misses the recovery of the
current mixer values. This might work in some cases like S3 (where
the device is kept more or less powered on), but it'll be definitely
broken in some cases like S4.
For my USB Logitech Headset (ID 046d:0a29 Logitech, Inc. H600 [Wireless Headset]) S3 and
S4 are working (mixer resume), when using the reset_resume line/patch.
You didn't change the mixer value (e.g. mute), right? Otherwise
you'll have to notice the difference after S4.
I always let the last used mixer value stay (no mute), but I turn off the
headset (power switch) before hibernate.
... and below is a quick fix with mixer resume code.
It still doesn't handle some quirks, so it might break some devices.
Thank you for your patch/quick fix, I'll try it.
When can I expect a more complete solution for the mixer resume code, in the
next kernel releases 3.14 or 3.15?
Only after I get positive test reports. If I get them earlier, it can
be in 3.14-rc1, as it's no too intrusive change. If not, it'll be in
3.15.
Thank you for your patch, it is working fine.
It works with hibernate, the mixer value stays and the master channel headset
(kmix) is selected after hibernate as it should be.
When will the patch be in mainline = 3.14? and backported to LTS-kernels?
Do you know, what is the meaning of the following message in
/var/log/Xorg.0.log ?
(EE) [dix] Logitech Logitech Wireless Headset: unable to find touch point 0
Thanks, Bernhard
Takashi
Thanks, Bernhard
Takashi
-- 8 --
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] ALSA: usb-audio: Resume mixer values properly
Implement reset_resume callback so that the mixer values are properly
restored. Still no boot quirks are called, so it might not work well
on some devices.
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/usb/card.c | 18 --
sound/usb/mixer.c | 99
---
sound/usb/mixer.h | 7 ++--
3 files changed, 99 insertions(+), 25 deletions(-)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index d979050e6a6a..025224136129 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -691,12 +691,12 @@ static int usb_audio_suspend(struct usb_interface *intf,
pm_message_t message)
}
list_for_each_entry(mixer, chip-mixer_list, list)
- snd_usb_mixer_inactivate(mixer);
+ snd_usb_mixer_suspend(mixer);
return 0;
}
-static int usb_audio_resume(struct usb_interface *intf)
+static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
{
struct snd_usb_audio *chip = usb_get_intfdata(intf);
struct usb_mixer_interface *mixer;
@@ -711,7 +711,7 @@ static int usb_audio_resume(struct usb_interface *intf)
* we just notify and restart the mixers
*/
list_for_each_entry(mixer, chip-mixer_list, list) {
- err = snd_usb_mixer_activate(mixer);
+ err = snd_usb_mixer_resume(mixer, reset_resume);
if (err 0)
goto err_out;
}
@@ -723,9 +723,20 @@ static int usb_audio_resume(struct usb_interface *intf)
err_out:
return err;
}
+
+static int usb_audio_resume(struct usb_interface *intf)
+{
+ return __usb_audio_resume(intf, false);
+}
+
+static int usb_audio_reset_resume(struct usb_interface *intf)
+{
+ return __usb_audio_resume(intf, true);
+}
#else
#define usb_audio_suspendNULL
#define usb_audio_resume NULL
+#define usb_audio_reset_resume NULL
#endif /* CONFIG_PM */
static struct usb_device_id usb_audio_ids [] = {
@@ -747,6 +758,7 @@ static struct usb_driver usb_audio_driver = {
.disconnect =
Re: [PATCH] USB: serial: ftdi_sio: add id for Brainboxes VX-001 ExpressCard
2014-03-25 20:00 GMT+01:00 Michele Baldessari: Custom VID/PID for Brainboxes VX-001 ExpressCard RS232 as reported in + * Product: ExpressCard 1 Port RS2323 there is a stray trailing 3 -- Daniele Forsi -- 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 net-next 12/12] r8152: modify the tx timeout funcfion
On Tue, Mar 4, 2014 at 4:01 AM, Hayes Wang hayesw...@realtek.com wrote:
Reset and reinitialize the device when the tx timeout occurs.
Hayes,
I believe this patch was dropped after the series was split.
Can you please repost this patch by itself?
(and fix the function typo in the patch header)
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e04fcbd..23e03a6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1791,16 +1791,6 @@ static void rtl_drop_queued_tx(struct r8152 *tp)
}
}
-static void rtl8152_tx_timeout(struct net_device *netdev)
-{
- struct r8152 *tp = netdev_priv(netdev);
- int i;
-
- netif_warn(tp, tx_err, netdev, Tx timeout\n);
- for (i = 0; i RTL8152_MAX_TX; i++)
- usb_unlink_urb(tp-tx_info[i].urb);
-}
-
static void rtl8152_set_rx_mode(struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
@@ -3177,6 +3167,37 @@ out:
return res;
}
+static void rtl8152_tx_timeout(struct net_device *netdev)
+{
+ struct r8152 *tp = netdev_priv(netdev);
+
+ netif_warn(tp, tx_err, netdev, Tx timeout\n);
+
+ if (usb_autopm_get_interface(tp-intf) 0)
+ return;
+
+ netif_stop_queue(netdev);
+ clear_bit(WORK_ENABLE, tp-flags);
+ usb_kill_urb(tp-intr_urb);
+ cancel_delayed_work_sync(tp-schedule);
+ tp-rtl_ops.down(tp);
+
+ usb_reset_device(tp-udev);
+
+ tp-rtl_ops.init(tp);
+ tp-rtl_ops.up(tp);
+ rtl8152_set_speed(tp, AUTONEG_ENABLE,
+ tp-mii.supports_gmii ? SPEED_1000 : SPEED_100,
+ DUPLEX_FULL);
+ tp-speed = 0;
Nit: Could rtl_ops.up() set speed since it appears to be changing the
state of the link?
rtl8152_open() uses a remarkably similar code sequence. Is there an
opportunity to refactor and make sure this sequence is consistent?
(different patch, not this one)
cheers,
grant
+ netif_carrier_off(netdev);
+ netif_start_queue(netdev);
+ set_bit(WORK_ENABLE, tp-flags);
+ usb_submit_urb(tp-intr_urb, GFP_KERNEL);
+
+ usb_autopm_put_interface(tp-intf);
+}
+
static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_open = rtl8152_open,
.ndo_stop = rtl8152_close,
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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 RESEND 4/4] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
On Thu, Mar 06, 2014 at 01:56:46PM -0800, Sarah Sharp wrote: What do you mean by this sentence? Are you fixing some bug in those two functions, or just cleaning up how they look? Either way, this should really be two patches. Hi Sarah, Any feedback on v2? Thanks! Sarah Sharp -- Regards, Alexander Gordeev agord...@redhat.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
[PATCH] usb: dwc3: gadget: Iterate only over valid endpoints
Make dwc3_gadget_resize_tx_fifos() iterate only over IN
endpoints that are actually present, based on the
num_in_eps parameter. This terminates the loop so as to
prevent dereferencing a potential NULL dwc-eps[i] where
i = (num_in_eps + num_out_eps).
Change-Id: I07f711bfd380dce212e86b59cf417f84ca7eb006
Signed-off-by: Jack Pham ja...@codeaurora.org
---
Hi Felipe,
This was found when testing on a virtual simulation platform in
which the DWC3 IP was configured with only a handful of endpoints
as opposed to 32. Do you think this is worthy of cc:stable?
Thanks,
Jack
drivers/usb/dwc3/gadget.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index a740eac..258eee6 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -187,15 +187,11 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc)
* improve this algorithm so that we better use the internal
* FIFO space
*/
- for (num = 0; num DWC3_ENDPOINTS_NUM; num++) {
- struct dwc3_ep *dep = dwc-eps[num];
- int fifo_number = dep-number 1;
+ for (num = 0; num dwc-num_in_eps; num++) {
+ struct dwc3_ep *dep = dwc-eps[(num 1) | 1];
int mult = 1;
int tmp;
- if (!(dep-number 1))
- continue;
-
if (!(dep-flags DWC3_EP_ENABLED))
continue;
@@ -224,8 +220,7 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc)
dev_vdbg(dwc-dev, %s: Fifo Addr %04x Size %d\n,
dep-name, last_fifo_depth, fifo_size 0x);
- dwc3_writel(dwc-regs, DWC3_GTXFIFOSIZ(fifo_number),
- fifo_size);
+ dwc3_writel(dwc-regs, DWC3_GTXFIFOSIZ(num), fifo_size);
last_fifo_depth += (fifo_size 0x);
}
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: problem with resume after s2ram
On Tue, Mar 25 2014, Alan Stern wrote: Below is a patch you should apply to normal 3.14 (nothing reverted). Hi Alan, I've used 3.12.14, because the source-tree is already set up. I hope that this is ok. For this test, plug some device you aren't going to use (the mouse, for example, if you will be at a VT console instead of a graphics console) into the rear port normally used by the mouse. Plug the keyboard and anything else into front ports -- no other devices should be attached to a rear port. Then you can force the test device to go into runtime suspend by typing this: echo auto /sys/bus/usb/devices/4-2/power/control echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue (I believe 4-2 is the correct path for the rear port where you like to plug the mouse.) After 5 seconds or so, force the device to resume by typing: echo on /sys/bus/usb/devices/4-2/power/control Let's see what shows up in the kernel log. With luck the resume will hang but the rest of your system will keep on running. No more mouse after the test, but the rest of the system works. Please find attached the log (copied from /var/log/messages). Here my commands: echo 8 /proc/sys/kernel/printk echo auto /sys/bus/usb/devices/4-2/power/control sleep 2 echo 0 /sys/bus/usb/devices/4-2/bConfigurationValue sleep 10 echo on /sys/bus/usb/devices/4-2/power/control -- Peter kernel: [ 103.387198] usb 4-2: usb auto-suspend, wakeup 1 kernel: [ 103.387911] hub 4-0:1.0: hub_suspend kernel: [ 103.387945] usb usb4: bus auto-suspend, wakeup 1 kernel: [ 103.387955] ohci-pci :00:12.1: suspend root hub kernel: [ 105.441905] usb usb4: usb auto-resume kernel: [ 105.441923] ohci-pci :00:12.1: resume root hub kernel: [ 105.515991] hub 4-0:1.0: hub_resume kernel: [ 105.516127] hub 4-0:1.0: port 2: status 0303 change kernel: [ 105.516253] hub 4-0:1.0: state 7 ports 3 chg evt kernel: [ 105.516311] usb 4-2: finish resume kernel: [ 105.516995] ohci-pci :00:12.1: urb 88012188f8c0 path 2 ep0in 5ec2 cc 5 -- status -62 kernel: [ 105.517033] usb 4-2: retry with reset-resume kernel: [ 105.546948] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 105.550068] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 105.717102] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 105.749125] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS kernel: [ 105.805213] usb 4-2: reset low-speed USB device number 2 using ohci-pci kernel: [ 105.831072] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 105.965243] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 106.033264] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS kernel: [ 106.121391] usb 4-2: unregistering interface 4-2:1.0 kernel: [ 106.121496] ohci-pci :00:12.1: shutdown urb 8800cfa85380 ep1in-intr kernel: [ 106.149844] usb 4-2: usb_disable_device nuking non-ep0 URBs kernel: [ 108.150409] usb 4-2: usb auto-suspend, wakeup 0 kernel: [ 108.150429] hub 4-0:1.0: hub_suspend kernel: [ 108.150456] usb usb4: bus auto-suspend, wakeup 1 kernel: [ 108.150465] ohci-pci :00:12.1: suspend root hub kernel: [ 116.159228] usb usb4: usb auto-resume kernel: [ 116.159246] ohci-pci :00:12.1: resume root hub kernel: [ 116.233915] hub 4-0:1.0: hub_resume kernel: [ 116.234070] hub 4-0:1.0: port 2: status 0303 change kernel: [ 116.234179] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.234255] usb 4-2: finish resume kernel: [ 116.234880] ohci-pci :00:12.1: urb 8800ce12b2c0 path 2 ep0in 5ec2 cc 5 -- status -62 kernel: [ 116.234977] usb 4-2: retry with reset-resume kernel: [ 116.264823] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 116.268901] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.386971] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.466997] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS kernel: [ 116.523077] usb 4-2: reset low-speed USB device number 2 using ohci-pci kernel: [ 116.548990] ohci-pci :00:12.1: port[1] reset timeout, stat 0313 kernel: [ 116.635142] hub 4-0:1.0: state 7 ports 3 chg evt 0004 kernel: [ 116.751153] ohci-pci :00:12.1: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS
Re: [PATCH] usb: dwc3: gadget: Iterate only over valid endpoints
On Tue, Mar 25, 2014 at 02:11:01PM -0700, Jack Pham wrote: Make dwc3_gadget_resize_tx_fifos() iterate only over IN endpoints that are actually present, based on the num_in_eps parameter. This terminates the loop so as to prevent dereferencing a potential NULL dwc-eps[i] where i = (num_in_eps + num_out_eps). Change-Id: I07f711bfd380dce212e86b59cf417f84ca7eb006 What is that line for? Please never include it... -- 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: gadget: Iterate only over valid endpoints
On Tue, Mar 25, 2014 at 03:39:09PM -0700, Greg KH wrote: On Tue, Mar 25, 2014 at 02:11:01PM -0700, Jack Pham wrote: Make dwc3_gadget_resize_tx_fifos() iterate only over IN endpoints that are actually present, based on the num_in_eps parameter. This terminates the loop so as to prevent dereferencing a potential NULL dwc-eps[i] where i = (num_in_eps + num_out_eps). Change-Id: I07f711bfd380dce212e86b59cf417f84ca7eb006 What is that line for? Please never include it... Doh! Re-sending. -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: dwc3: gadget: Iterate only over valid endpoints
Make dwc3_gadget_resize_tx_fifos() iterate only over IN
endpoints that are actually present, based on the
num_in_eps parameter. This terminates the loop so as to
prevent dereferencing a potential NULL dwc-eps[i] where
i = (num_in_eps + num_out_eps).
Signed-off-by: Jack Pham ja...@codeaurora.org
---
v2: Removed extraneous tag
drivers/usb/dwc3/gadget.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index a740eac..258eee6 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -187,15 +187,11 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc)
* improve this algorithm so that we better use the internal
* FIFO space
*/
- for (num = 0; num DWC3_ENDPOINTS_NUM; num++) {
- struct dwc3_ep *dep = dwc-eps[num];
- int fifo_number = dep-number 1;
+ for (num = 0; num dwc-num_in_eps; num++) {
+ struct dwc3_ep *dep = dwc-eps[(num 1) | 1];
int mult = 1;
int tmp;
- if (!(dep-number 1))
- continue;
-
if (!(dep-flags DWC3_EP_ENABLED))
continue;
@@ -224,8 +220,7 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc)
dev_vdbg(dwc-dev, %s: Fifo Addr %04x Size %d\n,
dep-name, last_fifo_depth, fifo_size 0x);
- dwc3_writel(dwc-regs, DWC3_GTXFIFOSIZ(fifo_number),
- fifo_size);
+ dwc3_writel(dwc-regs, DWC3_GTXFIFOSIZ(num), fifo_size);
last_fifo_depth += (fifo_size 0x);
}
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: Kernel trace when remove usb storage without umount
Dear Greg K-H Thanks for your new kernel information. Dear Alan, Thanks for your patch's information. Here is my test environment : CPU : Bay Trail-M N2920 Bios USB setting : XHCI Kernel : 3.13.7 with scsi patch USB : 2 front usb2.0 port (electronic diagram : link to usb hub and then usb hub link to N2920 SoC) 1 rear usb2.0 port (electronic diagram : direct link to N2920 SoC) 1 rear usb3.0 port (electronic diagram : direct link to N2920 SoC) USB Storage(3.0) : SandDisk Extreme 16GB USB Storage(2.0) : Patriot 32GB result : 2 front usb2.0 port = pass 1 rear usb2.0 port = fail on USB Storage(3.0) 1 rear usb3.0 port = pass dmesg with plug-in: [ 42.517237] usb 1-2: new high-speed USB device number 5 using xhci_hcd [ 42.533963] usb 1-2: New USB device found, idVendor=0781, idProduct=5580 [ 42.533971] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 42.533976] usb 1-2: Product: Extreme [ 42.533980] usb 1-2: Manufacturer: SanDisk [ 42.533984] usb 1-2: SerialNumber: AA011102120418337893 [ 42.535009] usb 1-2: ep 0x81 - rounding interval to 16 microframes, ep desc says 20 microframes [ 42.535024] usb 1-2: ep 0x2 - rounding interval to 16 microframes, ep desc says 20 microframes [ 42.536163] usb-storage 1-2:1.0: USB Mass Storage device detected [ 42.536976] scsi0 : usb-storage 1-2:1.0 [ 43.541092] scsi 0:0:0:0: Direct-Access SanDisk Extreme 0001 PQ: 0 ANSI: 6 [ 43.545820] sd 0:0:0:0: [sda] 31277232 512-byte logical blocks: (16.0 GB/14.9 GiB) [ 43.546376] sd 0:0:0:0: [sda] Write Protect is off [ 43.546383] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08 [ 43.546912] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 73.990231] usb 1-2: reset high-speed USB device number 5 using xhci_hcd [ 74.005838] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep f5e26120 [ 74.005844] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep f5e2614c [ 74.005860] usb 1-2: ep 0x81 - rounding interval to 16 microframes, ep desc says 20 microframes [ 74.005867] usb 1-2: ep 0x2 - rounding interval to 16 microframes, ep desc says 20 microframes [ 74.007085] sda: sda1 [ 74.008360] usb 1-2: USB disconnect, device number 5 [ 74.013807] sd 0:0:0:0: [sda] READ CAPACITY failed [ 74.013815] sd 0:0:0:0: [sda] [ 74.013818] Result: hostbyte=0x01 driverbyte=0x00 [ 74.013822] sd 0:0:0:0: [sda] Sense not available. [ 74.013874] sd 0:0:0:0: [sda] Asking for cache data failed [ 74.013879] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 74.013885] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 74.294500] usb 1-2: new high-speed USB device number 6 using xhci_hcd [ 74.311936] usb 1-2: New USB device found, idVendor=0781, idProduct=5580 [ 74.311962] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.311979] usb 1-2: Product: Extreme [ 74.311994] usb 1-2: Manufacturer: SanDisk [ 74.312008] usb 1-2: SerialNumber: AA011102120418337893 [ 74.314625] usb 1-2: ep 0x81 - rounding interval to 16 microframes, ep desc says 20 microframes [ 74.314656] usb 1-2: ep 0x2 - rounding interval to 16 microframes, ep desc says 20 microframes [ 74.316668] usb-storage 1-2:1.0: USB Mass Storage device detected [ 74.317102] scsi1 : usb-storage 1-2:1.0 [ 75.319698] scsi 1:0:0:0: Direct-Access SanDisk Extreme 0001 PQ: 0 ANSI: 6 [ 75.324258] sd 1:0:0:0: [sda] 31277232 512-byte logical blocks: (16.0 GB/14.9 GiB) [ 75.324687] sd 1:0:0:0: [sda] Write Protect is off [ 75.324711] sd 1:0:0:0: [sda] Mode Sense: 53 00 00 08 [ 75.325179] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 106.015431] usb 1-2: reset high-speed USB device number 6 using xhci_hcd [ 106.030963] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep efeee540 [ 106.030972] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep efeee56c [ 106.030984] usb 1-2: ep 0x81 - rounding interval to 16 microframes, ep desc says 20 microframes [ 106.030991] usb 1-2: ep 0x2 - rounding interval to 16 microframes, ep desc says 20 microframes [ 106.032330] sda: sda1 [ 106.033611] usb 1-2: USB disconnect, device number 6 [ 106.038809] sd 1:0:0:0: [sda] Attached SCSI removable disk [ 106.315261] usb 1-2: new high-speed USB device number 7 using xhci_hcd [ 106.332795] usb 1-2: New USB device found, idVendor=0781, idProduct=5580 [ 106.332820] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 106.332838] usb 1-2: Product: Extreme [ 106.332852] usb 1-2: Manufacturer: SanDisk [ 106.332867] usb 1-2: SerialNumber: AA011102120418337893 [ 106.334929] usb 1-2: ep 0x81 - rounding interval to 16 microframes, ep desc says 20 microframes [ 106.334962] usb 1-2: ep 0x2 - rounding interval to 16 microframes, ep desc says 20 microframes [ 106.336430] usb-storage 1-2:1.0: USB Mass
Re: [PATCH v2] usb: dwc3: gadget: Iterate only over valid endpoints
Hi,
On Tue, Mar 25, 2014 at 04:11:06PM -0700, Jack Pham wrote:
Make dwc3_gadget_resize_tx_fifos() iterate only over IN
endpoints that are actually present, based on the
num_in_eps parameter. This terminates the loop so as to
prevent dereferencing a potential NULL dwc-eps[i] where
i = (num_in_eps + num_out_eps).
Signed-off-by: Jack Pham ja...@codeaurora.org
cool, this has the added benefit of making that loop execute faster
(well, we won't iterate over *all* endpoints).
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index a740eac..258eee6 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -187,15 +187,11 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc)
* improve this algorithm so that we better use the internal
* FIFO space
*/
- for (num = 0; num DWC3_ENDPOINTS_NUM; num++) {
- struct dwc3_ep *dep = dwc-eps[num];
- int fifo_number = dep-number 1;
+ for (num = 0; num dwc-num_in_eps; num++) {
+ struct dwc3_ep *dep = dwc-eps[(num 1) | 1];
Just add a comment here stating that bit0 is the direction bit, just so
we don't forget in the future.
One question, out of curiosity:
do you *really* need to enable tx-fifo-resize ? I thought OMAP5 ES1.0
was the only brainfart with FIFO setups which wouldn't even fit a single
USB3 packet :-p
Sure your patch is correct, and will be applied soonish, but if you
don't need to resize fifos, you might want to avoid it. Just curious.
cheers
ps: can you guys, please, just send your dwc3 glue layer ? :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 01/11] usb: chipidea: usb OTG fsm initialization.
On Wed, Mar 19, 2014 at 06:01:34PM +0800, Li Jun wrote:
This patch adds OTG fsm related initialization when do otg init,
add a seperate file for OTG fsm related utilities.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/Makefile |1 +
drivers/usb/chipidea/ci.h |2 ++
drivers/usb/chipidea/otg.c |7 +
drivers/usb/chipidea/otg_fsm.c | 60
drivers/usb/chipidea/otg_fsm.h | 29 +++
5 files changed, 99 insertions(+)
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 480bd4d..2f099c7 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -6,6 +6,7 @@ ci_hdrc-y := core.o otg.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST) += host.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG) += debug.o
+ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
# Glue/Bridge layers go here
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 7ae8cb6..4491c43 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -17,6 +17,7 @@
#include linux/irqreturn.h
#include linux/usb.h
#include linux/usb/gadget.h
+#include linux/usb/otg-fsm.h
/**
* DEFINE
@@ -174,6 +175,7 @@ struct ci_hdrc {
struct ci_role_driver *roles[CI_ROLE_END];
enum ci_rolerole;
boolis_otg;
+ struct otg_fsm fsm;
struct work_struct work;
struct workqueue_struct *wq;
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index c694340..3082b52 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -22,6 +22,7 @@
#include ci.h
#include bits.h
#include otg.h
+#include otg_fsm.h
/**
* hw_read_otgsc returns otgsc register bits value.
@@ -109,6 +110,12 @@ static void ci_otg_work(struct work_struct *work)
*/
int ci_hdrc_otg_init(struct ci_hdrc *ci)
{
+ int retval = 0;
+
+ retval = ci_hdrc_otg_fsm_init(ci);
You can use int retval = ci_hdrc_otg_fsm_init(ci); directly.
+ if (retval)
+ return retval;
+
INIT_WORK(ci-work, ci_otg_work);
ci-wq = create_singlethread_workqueue(ci_otg);
if (!ci-wq) {
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
new file mode 100644
index 000..fbe63f0
--- /dev/null
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -0,0 +1,60 @@
+/*
+ * otg_fsm.c - ChipIdea USB IP core OTG FSM driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Jun Li
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * This file mainly handles OTG fsm, it includes OTG fsm operations
+ * for HNP and SRP.
+ */
+
+#include linux/usb/otg.h
+#include linux/usb/gadget.h
+#include linux/usb/chipidea.h
+
+#include ci.h
+#include bits.h
+#include otg.h
+#include otg_fsm.h
+
+int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
+{
+ if (ci-platdata-dr_mode != USB_DR_MODE_OTG)
+ return 0;
+
+ ci-transceiver-otg = devm_kzalloc(ci-dev,
+ sizeof(struct usb_otg), GFP_KERNEL);
+ if (!ci-transceiver-otg) {
+ dev_err(ci-dev,
+ Failed to allocate usb_otg structure for ci hdrc otg!\n);
+ return -ENOMEM;
+ }
+
+ ci-fsm.power_up = 1;
+ ci-fsm.id = hw_read_otgsc(ci, OTGSC_ID);
+ ci-fsm.otg = ci-transceiver-otg;
+ ci-fsm.otg-phy = ci-transceiver;
+ ci-fsm.otg-gadget = ci-gadget;
+ ci-transceiver-state = OTG_STATE_UNDEFINED;
+
+ mutex_init(ci-fsm.lock);
+
+ /* Enable A vbus valid irq */
+ hw_write_otgsc(ci, OTGSC_AVVIE, OTGSC_AVVIE);
+
+ if (ci-fsm.id) {
+ ci-fsm.b_ssend_srp =
+ hw_read_otgsc(ci, OTGSC_BSV) ? 0 : 1;
+ ci-fsm.b_sess_vld =
+ hw_read_otgsc(ci, OTGSC_BSV) ? 1 : 0;
+ }
+
+ return 0;
+}
diff --git a/drivers/usb/chipidea/otg_fsm.h b/drivers/usb/chipidea/otg_fsm.h
new file mode 100644
index 000..cf27253
--- /dev/null
+++ b/drivers/usb/chipidea/otg_fsm.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Jun Li
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DRIVERS_USB_CHIPIDEA_OTG_FSM_H
+#define __DRIVERS_USB_CHIPIDEA_OTG_FSM_H
+
+#include linux/usb/otg-fsm.h
+
+#ifdef
Re: [PATCH v4 02/11] usb: chipidea: host: vbus control change for OTG HNP.
On Wed, Mar 19, 2014 at 06:01:35PM +0800, Li Jun wrote:
Leave vbus on/off hanlded by OTG fsm if in OTG mode.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/host.c |6 +++---
drivers/usb/chipidea/host.h |9 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index a8ac6c1..4b609bc 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -67,7 +67,7 @@ static int host_start(struct ci_hdrc *ci)
ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
ehci-imx28_write_fix = ci-imx28_write_fix;
- if (ci-platdata-reg_vbus) {
+ if (ci-platdata-reg_vbus !ci_host_is_otg(ci)) {
ret = regulator_enable(ci-platdata-reg_vbus);
if (ret) {
dev_err(ci-dev,
@@ -89,7 +89,7 @@ static int host_start(struct ci_hdrc *ci)
return ret;
disable_reg:
- if (ci-platdata-reg_vbus)
+ if (ci-platdata-reg_vbus !ci_host_is_otg(ci))
regulator_disable(ci-platdata-reg_vbus);
put_hcd:
@@ -105,7 +105,7 @@ static void host_stop(struct ci_hdrc *ci)
if (hcd) {
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
- if (ci-platdata-reg_vbus)
+ if (ci-platdata-reg_vbus !ci_host_is_otg(ci))
regulator_disable(ci-platdata-reg_vbus);
}
}
diff --git a/drivers/usb/chipidea/host.h b/drivers/usb/chipidea/host.h
index 5707bf3..f98d084 100644
--- a/drivers/usb/chipidea/host.h
+++ b/drivers/usb/chipidea/host.h
@@ -6,6 +6,15 @@
int ci_hdrc_host_init(struct ci_hdrc *ci);
void ci_hdrc_host_destroy(struct ci_hdrc *ci);
+static inline bool ci_host_is_otg(struct ci_hdrc *ci)
+{
+#ifdef CONFIG_USB_OTG_FSM
+ return (ci-is_otg) (ci-platdata-dr_mode == USB_DR_MODE_OTG);
+#else
+ return false;
+#endif
+}
+
#else
I talked at last round email, we need to use below condition to stand
for OTG condition:
static inline bool ci_host_is_otg(struct ci_hdrc *ci)
{
#ifdef CONFIG_USB_OTG_FSM
return ci-is_otg ci-roles[CI_ROLE_HOST]
ci-roles[CI_ROLE_GADGET];
#else
return false;
#endif
}
The user may only choose host or gadget support at configuration menu.
static inline int ci_hdrc_host_init(struct ci_hdrc *ci)
--
1.7.9.5
--
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 v4 04/11] usb: chipidea: udc: driver update for OTG HNP.
On Wed, Mar 19, 2014 at 06:01:37PM +0800, Li Jun wrote:
Add b_hnp_enable request handling and enable gadget-is_otg
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/udc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f58857d..022dd18 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -20,6 +20,7 @@
#include linux/pm_runtime.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
+#include linux/usb/otg-fsm.h
#include linux/usb/chipidea.h
#include ci.h
@@ -1052,6 +1053,14 @@ __acquires(ci-lock)
default:
break;
}
+ break;
+ case USB_DEVICE_B_HNP_ENABLE:
+ if (gadget_is_otg(ci-gadget)) {
+ ci-gadget.b_hnp_enable = 1;
+ err = isr_setup_status_phase(
+ ci);
+ }
+ break;
default:
goto delegate;
}
@@ -1759,7 +1768,7 @@ static int udc_start(struct ci_hdrc *ci)
ci-gadget.ops = usb_gadget_ops;
ci-gadget.speed= USB_SPEED_UNKNOWN;
ci-gadget.max_speed= USB_SPEED_HIGH;
- ci-gadget.is_otg = 0;
+ ci-gadget.is_otg = ci-is_otg ? 1 : 0;
ci-gadget.name = ci-platdata-name;
INIT_LIST_HEAD(ci-gadget.ep_list);
--
1.7.9.5
Acked-by: Peter Chen peter.c...@freescale.com
--
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 v4 05/11] usb: chipidea: add OTG fsm operation functions implemenation.
On Wed, Mar 19, 2014 at 06:01:38PM +0800, Li Jun wrote:
Add OTG HNP and SRP operation functions implementation:
- charge vbus
- drive vbus
- connection signaling
- drive sof
- start data pulse
- add fsm timer
- delete fsm timer
- start host
- start gadget
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/bits.h| 10 +-
drivers/usb/chipidea/ci.h |1 +
drivers/usb/chipidea/otg_fsm.c | 203
drivers/usb/chipidea/otg_fsm.h | 23 +
4 files changed, 236 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 83d06c1..9e95378 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -44,9 +44,14 @@
#define DEVICEADDR_USBADR (0x7FUL 25)
/* PORTSC */
+#define PORTSC_CCSBIT(0)
+#define PORTSC_CSCBIT(1)
+#define PORTSC_PECBIT(3)
+#define PORTSC_OCCBIT(5)
#define PORTSC_FPRBIT(6)
#define PORTSC_SUSP BIT(7)
#define PORTSC_HSPBIT(9)
+#define PORTSC_PP BIT(12)
#define PORTSC_PTC(0x0FUL 16)
#define PORTSC_PHCD(d) ((d) ? BIT(22) : BIT(23))
/* PTS and PTW for non lpm version only */
@@ -56,6 +61,9 @@
#define PORTSC_PTWBIT(28)
#define PORTSC_STSBIT(29)
+#define PORTSC_W1C_BITS \
+ (PORTSC_CSC | PORTSC_PEC | PORTSC_OCC)
+
/* DEVLC */
#define DEVLC_PFSCBIT(23)
#define DEVLC_PSPD(0x03UL 25)
@@ -69,9 +77,9 @@
#define PTS_ULPI 2
#define PTS_SERIAL3
#define PTS_HSIC 4
-
Do we really need to delete this blank line between two registers?
/* OTGSC */
#define OTGSC_IDPU BIT(5)
+#define OTGSC_HADP BIT(6)
#define OTGSC_ID BIT(8)
#define OTGSC_AVV BIT(9)
#define OTGSC_ASV BIT(10)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 4491c43..cece7e2 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -176,6 +176,7 @@ struct ci_hdrc {
enum ci_rolerole;
boolis_otg;
struct otg_fsm fsm;
+ struct ci_otg_fsm_timer_list*fsm_timer;
struct work_struct work;
struct workqueue_struct *wq;
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index fbe63f0..f0e50fd 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -18,12 +18,214 @@
#include linux/usb/otg.h
#include linux/usb/gadget.h
#include linux/usb/chipidea.h
+#include linux/regulator/consumer.h
#include ci.h
#include bits.h
#include otg.h
#include otg_fsm.h
+/*
+ * Add timer to active timer list
+ */
+static void ci_otg_add_timer(struct ci_hdrc *ci, enum ci_otg_fsm_timer_index
t)
+{
+ struct ci_otg_fsm_timer *tmp_timer;
+ struct ci_otg_fsm_timer *timer = ci-fsm_timer-timer_list[t];
+ struct list_head *active_timers = ci-fsm_timer-active_timers;
+
+ if (t = NUM_CI_OTG_FSM_TIMERS)
+ return;
+
+ /*
+ * Check if the timer is already in the active list,
+ * if so update timer count
+ */
+ list_for_each_entry(tmp_timer, active_timers, list)
+ if (tmp_timer == timer) {
+ timer-count = timer-expires;
+ return;
+ }
+
+ timer-count = timer-expires;
+ list_add_tail(timer-list, active_timers);
+
+ /* Enable 1ms irq */
+ if (!(hw_read_otgsc(ci, OTGSC_1MSIE)))
+ hw_write_otgsc(ci, OTGSC_1MSIE, OTGSC_1MSIE);
+}
+
+/*
+ * Remove timer from active timer list
+ */
+static void ci_otg_del_timer(struct ci_hdrc *ci, enum ci_otg_fsm_timer_index
t)
+{
+ struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
+ struct ci_otg_fsm_timer *timer = ci-fsm_timer-timer_list[t];
+ struct list_head *active_timers = ci-fsm_timer-active_timers;
+
+ if (t = NUM_CI_OTG_FSM_TIMERS)
+ return;
+
+ list_for_each_entry_safe(tmp_timer, del_tmp, active_timers, list)
+ if (tmp_timer == timer)
+ list_del(timer-list);
+
+ /* Disable 1ms irq if there is no any active timer */
+ if (list_empty(active_timers))
+ hw_write_otgsc(ci, OTGSC_1MSIE, 0);
+}
+
+/* -*/
+/* Operations that will be called from OTG Finite State Machine */
+/* -*/
+static void ci_otg_fsm_add_timer(struct otg_fsm *fsm, enum otg_fsm_timer t)
+{
+ struct ci_hdrc *ci = container_of(fsm, struct ci_hdrc, fsm);
+
+ if (t NUM_OTG_FSM_TIMERS)
+ ci_otg_add_timer(ci, t);
+
