Re: CDC-ACM device issue

[Oliver Neukum]

On Sun, 2013-11-17 at 02:40 +, Luke-Jr wrote:

Hi,
> I *thought* 3.12 fixed this, but it seems it just gives EOF instead of EIO...

As a response to open()?

> It seems Linux is trying an interrupt in and a control out, and getting 
> ENOENT 
> and EPIPE respectively.
> 
> Windows (where this works), on the other hand, is doing a whole bunch of 
> other 
> things...
> 
> Here are USB captures of both:
> 
> http://luke.dashjr.org/tmp/code/technobit-linux-cdc.usbcap.pcapng.xz (376 B)
> http://luke.dashjr.org/tmp/code/technobit-windows-usbser.usbcap.pcap.xz (880 B

Can you please send this in a sane uncompressed format?

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

Re: CDC-ACM device issue

[Luke-Jr]

On Monday, March 24, 2014 9:05:35 AM Oliver Neukum wrote:
> On Sun, 2013-11-17 at 02:40 +, Luke-Jr wrote:
> > I *thought* 3.12 fixed this, but it seems it just gives EOF instead of
> > EIO...
> 
> As a response to open()?

IIRC, this was in response to read(). Since I was unable to make any progress, 
I did however pass the device on to a Windows developer to work with, so I 
cannot be 100% certain.

> > It seems Linux is trying an interrupt in and a control out, and getting
> > ENOENT and EPIPE respectively.
> > 
> > Windows (where this works), on the other hand, is doing a whole bunch of
> > other things...
> > 
> > Here are USB captures of both:
> > 
> > http://luke.dashjr.org/tmp/code/technobit-linux-cdc.usbcap.pcapng.xz (376
> > B)
> > http://luke.dashjr.org/tmp/code/technobit-windows-usbser.usbcap.pcap.xz
> > (880 B
> 
> Can you please send this in a sane uncompressed format?

My apologies, I had assumed that since Linux was using xz for distribution, 
everyone was able to decompress it. Or is the problem with the pcap format?
If so, what format is preferred?

I've decompressed the files on my webserver:

http://luke.dashjr.org/tmp/code/technobit-linux-cdc.usbcap.pcapng
http://luke.dashjr.org/tmp/code/technobit-windows-usbser.usbcap.pcap

Thanks,

Luke
--
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] next-20140324 drivers/staging/media/sn9c102/sn9c102_hv7131r.c fix style warnings flagged by checkpatch.pl.

[Mike Sampson]

Signed-off-by: Mike Sampson 

---
 drivers/staging/media/sn9c102/sn9c102_hv7131r.c |   23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/media/sn9c102/sn9c102_hv7131r.c 
b/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
index 26a9111..51b24e0 100644
--- a/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
+++ b/drivers/staging/media/sn9c102/sn9c102_hv7131r.c
@@ -23,7 +23,7 @@
 #include "sn9c102_devtable.h"
 
 
-static int hv7131r_init(struct sn9c102_device* cam)
+static int hv7131r_init(struct sn9c102_device *cam)
 {
int err = 0;
 
@@ -137,8 +137,8 @@ static int hv7131r_init(struct sn9c102_device* cam)
 }
 
 
-static int hv7131r_get_ctrl(struct sn9c102_device* cam,
-   struct v4l2_control* ctrl)
+static int hv7131r_get_ctrl(struct sn9c102_device *cam,
+   struct v4l2_control *ctrl)
 {
switch (ctrl->id) {
case V4L2_CID_GAIN:
@@ -176,8 +176,8 @@ static int hv7131r_get_ctrl(struct sn9c102_device* cam,
 }
 
 
-static int hv7131r_set_ctrl(struct sn9c102_device* cam,
-   const struct v4l2_control* ctrl)
+static int hv7131r_set_ctrl(struct sn9c102_device *cam,
+   const struct v4l2_control *ctrl)
 {
int err = 0;
 
@@ -197,6 +197,7 @@ static int hv7131r_set_ctrl(struct sn9c102_device* cam,
case V4L2_CID_BLACK_LEVEL:
{
int r = sn9c102_i2c_read(cam, 0x01);
+
if (r < 0)
return -EIO;
err += sn9c102_i2c_write(cam, 0x01,
@@ -211,10 +212,10 @@ static int hv7131r_set_ctrl(struct sn9c102_device* cam,
 }
 
 
-static int hv7131r_set_crop(struct sn9c102_device* cam,
-   const struct v4l2_rect* rect)
+static int hv7131r_set_crop(struct sn9c102_device *cam,
+   const struct v4l2_rect *rect)
 {
-   struct sn9c102_sensor* s = sn9c102_get_sensor(cam);
+   struct sn9c102_sensor *s = sn9c102_get_sensor(cam);
int err = 0;
u8 h_start = (u8)(rect->left - s->cropcap.bounds.left) + 1,
   v_start = (u8)(rect->top - s->cropcap.bounds.top) + 1;
@@ -226,8 +227,8 @@ static int hv7131r_set_crop(struct sn9c102_device* cam,
 }
 
 
-static int hv7131r_set_pix_format(struct sn9c102_device* cam,
- const struct v4l2_pix_format* pix)
+static int hv7131r_set_pix_format(struct sn9c102_device *cam,
+ const struct v4l2_pix_format *pix)
 {
int err = 0;
 
@@ -347,7 +348,7 @@ static const struct sn9c102_sensor hv7131r = {
 };
 
 
-int sn9c102_probe_hv7131r(struct sn9c102_device* cam)
+int sn9c102_probe_hv7131r(struct sn9c102_device *cam)
 {
int devid, err;
 
-- 
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: [PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

[Mathias Nyman]

On 03/21/2014 11:41 PM, David Cohen wrote:

Hi Mathias,



Thanks for commenting. That would be actually the v1 of my patch :)
I changed after I see the proper function has __maybe_unused flag.

But I'm fine with Sarah picking any of the patch's versions.


Guess you're handling the review of this trivial patch now :)
Comments are very welcome.

Br, David



Hi

Patch version 1 inlining the stubs looks good to me. I'll queue it for 
Greg’s usb-linus once 3.15-rc1 is out.


-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] usb: host: Add MAX3421E HCD support.

[Felipe Balbi]

Hi,

On Fri, Mar 21, 2014 at 09:55:25PM -0600, David Mosberger wrote:
> Felipe,
> 
> Thanks for your feedback, I'll take that into consideration.
> 
> On Fri, Mar 21, 2014 at 9:44 PM, Felipe Balbi  wrote:
> 
> >> + max3421_hcd->spi_thread = kthread_run(max3421_spi_thread, hcd,
> >> +   "max3421_spi_thread");
> >
> > why do you need this kthread ? For IRQ handling ? use threaded IRQs
> > instead.
> 
> Is there a clean way to wakeup a threaded IRQ handler without an
> interrupt?  Unless I'm missing something, there is not.  I started out
> with a threaded handler in fact, but there are other reasons (e.g.,
> URB enqueue) which need to wake up the thread.

Why do you need to run your IRQ handler when an URQ gets enqueued ? That
doesn't make much sense :-s

-- 
balbi


signature.asc
Description: Digital signature

Re: CDC ACM problem

[Martin Åkerberg]

thanks for the response,

I will try to reproduce the problem on the latest mainline kernel.

Regards,

Martin

2014-03-22 13:21 GMT+01:00 Johan Hovold :
> On Thu, Mar 20, 2014 at 02:31:30PM +0100, Martin Åkerberg wrote:
>> Hi Johan,
>>
>> You seem to be last contributor to cdc-acm driver in linux. I don't know if
>> you are the correct person to ask, or if you have the time to answer, but
>> if not, could you point me to the correct forum?
>
> The linux-usb list (added as CC) would be that forum.
>
>> Anyway, I am implementing a CDC-ACM device in a Atmel XMEGA processor. I am
>> interfacing this from a c-program on a Linux machine. Everything is working
>> as expected when it comes to opening the /dev/ttyACM0, configuring the
>> terminal, reading and sending data and closing the device. The problem
>> occurs when I try to open and close the device repeatedly many times.
>>
>> As a test: With a simple c-program I open and close the device in an
>> endless loop. Before every open and close I have a 100ms delay. I can see
>> on my device that setup messages with control line signals is sent on every
>> open and close, as expected.
>>
>> After about 50-500 cycles the open call fails. The message I can read in
>> dmesg is:
>>
>> [xxx] xhci_hcd :00:14.0 ERROR no room on ep ring
>> [xxx] cdc_acm 3-3:1.1: acm_submit_read_urb - usb_submit_urb failed: -12
>>
>> I read this as memory overflow regarding read urbs. I see in the kernel
>> code that 16 read urbs are allocated everytime the port is opened. But
>> these read urbs should be killed in the acm_port_shutdown function, which
>> might get called via
>>
>> tty_port_close
>>tty_port_shutdown
>> port->ops->shutdown
>>
>> I say "might" since it seems it doesn't happen in my case.
>>
>> Do you have any idea why this might be?
>
> Well, this appears to be a problem in the xhci-driver, and not directly
> related to cdc-acm. Specifically, the -ENOMEM (-12) above originates in
> the xhci-driver when it fails to enqueue the urb.
>
> [ The cdc-acm driver allocates its urbs on probe and releases them when
>   the device is unbound. ]
>
>> I don't see any of the kernel warnings from tty_port_close_start,
>>
>> The "uname -r" output is: 3.2.0.23-generic
>
> That is a fairly old kernel (and also a distro-kernel?). I'd suggest you
> try to reproduce this on a more recent mainline kernel such as v3.13.6
> (or v3.14-rc7).
>
> Thanks,
> Johan
--
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

[Alan Stern]

On Mon, 24 Mar 2014, Chris Cheng wrote:

> system kernel is 3.13.6, the origin issue is mount usb storage(3.0) on
> usb3.0 port not smooth, i found the solve method is revert xhci.c
> patch, here is the link :
> https://lkml.org/lkml/2014/3/7/295
> 
> 
> After i revert the patch, mount usb storage is fine.
> But it takes some issue, here is test case :
> 
> Here is test case :
> usb storage 2.0 remove from usb 3.0 port => kernel trace
> usb storage 2.0 remove from usb 2.0 port => kernel trace
> usb storage 3.0 remove from usb 3.0 port => kernel trace
> 
> Kernel trace message:
> 
> [224189.786719] usb 2-1: USB disconnect, device number 4
> [224189.820934] [ cut here ]
> [224189.820949] WARNING: CPU: 3 PID: 14554 at fs/sysfs/group.c:214
> sysfs_remove_group+0x37/0x69()
> [224189.820953] sysfs group c1851c34 not found for kobject 'target7:0:0'
> [224189.820956] Modules linked in: snd_hda_intel(F)
> snd_hda_codec_via(F) snd_hda_codec(F) snd_hwdep(F) snd_pcm_oss(F)
> snd_mixer_oss(F) snd_pcm(F) snd_seq_dummy(F) snd_page_alloc(F)
> snd_seq_oss(F) snd_seq_midi_event(F) snd_seq(F) snd_timer(F)
> snd_seq_device(F) snd(F) parport_pc(F) fan(F) ppdev(F) lp(F)
> parport(F)
> [224189.820985] CPU: 3 PID: 14554 Comm: umount Tainted: GF   W3.13.6 
> #1
> [224189.820988] Hardware name: LG CNS t180/t180, BIOS 1.11 03/21/2014
> [224189.820991]    da877d98 c154fb31 c175e60a da877db0
> c102e9f5 c112446b
> [224189.821001]   c1851c34 ea14f21c da877dc8 c102ea70 0009
> da877dc0 c175e60a
> [224189.821010]  da877ddc da877df0 c112446b c175e5bf 00d6 c175e60a
> c1851c34 ea28e0e0
> [224189.821019] Call Trace:
> [224189.821028]  [] dump_stack+0x41/0x52
> [224189.821036]  [] warn_slowpath_common+0x61/0x78
> [224189.821042]  [] ? sysfs_remove_group+0x37/0x69
> [224189.821047]  [] warn_slowpath_fmt+0x26/0x2a
> [224189.821053]  [] sysfs_remove_group+0x37/0x69
> [224189.821060]  [] dpm_sysfs_remove+0x2d/0x30
> [224189.821065]  [] device_del+0x2c/0x130
> [224189.821072]  [] scsi_target_reap_usercontext+0x1f/0x2a
> [224189.821078]  [] execute_in_process_context+0x16/0x45
> [224189.821083]  [] scsi_target_reap+0x81/0x87
> [224189.821090]  [] scsi_device_dev_release_usercontext+0x116/0x13b
> [224189.821095]  [] execute_in_process_context+0x16/0x45
> [224189.821101]  [] scsi_device_dev_release+0x13/0x15
> [224189.821107]  [] device_release+0x46/0x78
> [224189.821114]  [] kobject_cleanup+0x3e/0x4e
> [224189.821120]  [] kobject_put+0x3c/0x3e
> [224189.821125]  [] ? kobject_cleanup+0x49/0x4e
> [224189.821131]  [] put_device+0xf/0x11
> [224189.821137]  [] scsi_device_put+0x2f/0x33
> [224189.821143]  [] scsi_disk_put+0x23/0x31
> [224189.821148]  [] sd_release+0x40/0x44
> [224189.821154]  [] __blkdev_put+0x83/0xfa
> [224189.821159]  [] __blkdev_put+0xf2/0xfa
> [224189.821164]  [] blkdev_put+0xd8/0xde
> [224189.821170]  [] kill_block_super+0x54/0x58
> [224189.821177]  [] deactivate_locked_super+0x24/0x41
> [224189.821182]  [] deactivate_super+0x28/0x2b
> [224189.821188]  [] mntput_no_expire+0xc7/0xe3
> [224189.821194]  [] SYSC_umount+0x293/0x2b0
> [224189.821200]  [] SyS_umount+0xe/0x10
> [224189.821206]  [] sysenter_do_call+0x12/0x22
> [224189.821210] ---[ end trace 096ea20d8206361e ]--

This problem has been fixed in linux-next:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit?id=e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59

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: [REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12

[Alan Stern]

On Sun, 23 Mar 2014, Dâniel Fraga wrote:

> On Sun, 23 Mar 2014 11:56:50 -0400 (EDT)
> Alan Stern  wrote:
> 
> > > [   28.336116] usbhid 2-1.6:1.0: disconnect by usbfs
> > > [   28.336133] usb 2-1.6: unlink qh1-1c01/8802153fb480 start 0 [1/3 
> > > us]
> > > [   28.353165] usb 2-1.6: manual set_interface for iface 0, alt 0
> > > [   28.353168] usb 2-1.6: ep 81: release intr @ 0+8 (0.0+1) [1/3 us] mask 
> > > 1c01
> > > [   28.354041] usbhid 2-1.6:1.0: usb_probe_interface
> > > [   28.354044] usbhid 2-1.6:1.0: usb_probe_interface - got id
> > > [   28.356155] input: Razer Razer DeathAdder as 
> > > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input10
> > > [   28.356226] usb 2-1.6: ep 81: reserve intr @ 0+8 (0.0+1) [1/3 us] mask 
> > > 1c01
> > > [   28.356237] usb 2-1.6: link qh1-1c01/8800d55d6300 start 0 [1/3 us]
> > 
> > Is this the sort of thing you're seeing?  The "disconnect by usbfs" 
> > means that some program on your computer is causing this to happen.  
> > The program unbinds the usbhid driver from the mouse and then rebinds 
> > it.
> 
>   Hmm. The only program I use for the mouse is razerd daemon to 
> switch off the leds.
> 
> > If you want, I can post a patch that will print out the name of the 
> > process doing this.  Did this happen when you were starting up KDE?
> 
>   Yes, it just happens when starting KDE. but I'd like to test 
> with your patch, so we can be sure what process is causing this.

Okay, the patch is at the end of this email.

> > I wasn't able to learn anything from the usbmon data.  It just shows 
> > the mouse being used.  Did one of those disconnection events occur 
> > while you were collecting the usbmon trace?
> 
>   Yes! This is what I found interesting, because usbmon keeps
> reporting mouse activity while the mouse pointer is stuck. Maybe it's a
> KDE only issue, *not* kernel related? I reported here because with 3.12
> kernel it doesn't happens (only with 3.13 and above so...). But maybe
> it's a bug in KDE which only shows with 3.13 kernel.

Or a bug in the input layer.  If you load the gpm console mouse 
manager and switch to a VT console after starting KDE, does the 
console mouse pointer work?

> > Can you post an equivalent dmesg log with the f1125f81feca commit 
> > reverted?
> 
>   Forget it. I reboot 2 times without the f1125f81eca commit. Only
> in the second reboot the bug appeared. So you're right. The commit
> f1125f81eca isn't the problem.
> 
>   It seems this bug is ocasional. That explains why the bisect is
> worthless in this case, since I can't be sure what commit really 
> triggers the bug.
> 
>   What I can say for sure is that with 3.12 kernel the bug
> doesn't happen, while with 3.13 and above kernel the bug _sometimes_ 
> happens.

Then can you post an equivalent dmesg log for the 3.12 kernel?

Alan Stern



Index: usb-3.14/drivers/usb/core/devio.c
===
--- usb-3.14.orig/drivers/usb/core/devio.c
+++ usb-3.14/drivers/usb/core/devio.c
@@ -1860,6 +1860,7 @@ static int proc_ioctl(struct dev_state *
 
/* disconnect kernel driver from interface */
case USBDEVFS_DISCONNECT:
+   dev_info(&intf->dev, "DISCONNECT by %s\n", current->comm);
if (intf->dev.driver) {
driver = to_usb_driver(intf->dev.driver);
dev_dbg(&intf->dev, "disconnect by usbfs\n");
@@ -1979,6 +1980,7 @@ static int proc_disconnect_claim(struct
if (!intf)
return -EINVAL;
 
+   dev_info(&intf->dev, "DISCONNECT_CLAIM by %s\n", current->comm);
if (intf->dev.driver) {
struct usb_driver *driver = to_usb_driver(intf->dev.driver);
 

--
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: Failure to recognize device for 45 minutes and Device Disconnects

[Alan Stern]

On Sun, 23 Mar 2014, Mike Mitchell wrote:

> Then last night I caught it in the act disconnecting again:
> Here is a trap of the DISCONNECT event
> 
> cat /sys/kernel/debug/usb/usbmon/0u
> 
> f644c0c0 1122085228 C Ii:2:002:1 0:2048 2 = 0200
> f644c0c0 1122085266 S Ii:2:002:1 -115:2048 2 <
> ee4c60c0 1122085347 S Ci:2:002:0 s a3 00  0001 0004 4 <
> ee4c60c0 1122085503 C Ci:2:002:0 0 4 = 00010100
> ee4c60c0 1122085614 S Co:2:002:0 s 23 01 0010 0001  0
> ee4c60c0 1122085786 C Co:2:002:0 0 0
> ee7fb6c0 1122088626 C Ii:2:004:3 -108:32 0
> f6adec00 1122171337 S Ci:2:002:0 s a3 00  0001 0004 4 <
> f6adec00 1122171502 C Ci:2:002:0 0 4 = 0001
> f6ade180 1122202854 S Ci:2:002:0 s a3 00  0001 0004 4 <
> f6ade180 1122203042 C Ci:2:002:0 0 4 = 0001
> f3aa3000 1122234851 S Ci:2:002:0 s a3 00  0001 0004 4 <
> f3aa3000 1122235015 C Ci:2:002:0 0 4 = 0001
> f3aa3000 1122266867 S Ci:2:002:0 s a3 00  0001 0004 4 <
> f3aa3000 1122267012 C Ci:2:002:0 0 4 = 0001
> f3aa3c00 1122298811 S Ci:2:002:0 s a3 00  0001 0004 4 <
> f3aa3c00 1122298878 C Ci:2:002:0 0 4 = 0001
> f644c0c0 1122301128 C Ii:2:002:1 -2:2048 0
> f3aa3c00 1122301238 S Co:2:002:0 s 00 03 0001   0
> f3aa3c00 1122301408 C Co:2:002:0 0 0
> 
> Corresponding KERN.LOG
> Mar 22 22:58:36 enc006 kernel: [46114.215541] usb 2-1.1: USB
> disconnect, device number 3
> Mar 22 22:58:36 enc006 kernel: [46114.462978] usb 2-1.1: new
> full-speed USB device number 4 using ehci-pci
> Mar 22 22:58:36 enc006 kernel: [46114.555712] usb 2-1.1: New USB
> device found, idVendor=0d8c, idProduct=0008
> Mar 22 22:58:36 enc006 kernel: [46114.555720] usb 2-1.1: New USB
> device strings: Mfr=0, Product=1, SerialNumber=0
> Mar 22 22:58:36 enc006 kernel: [46114.555725] usb 2-1.1: Product:
> C-Media USB Audio Device
> Mar 22 22:58:36 enc006 kernel: [46114.571464] input: C-Media USB Audio
> Deviceas 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.3/input/input6
> Mar 22 22:58:36 enc006 kernel: [46114.572360] hid-generic
> 0003:0D8C:0008.0002: input,hidraw0: USB HID v1.00 Device [C-Media USB
> Audio Device   ] on usb-:00:1d.0-1.1/input3

The usbmon trace above appears to start here.

> Mar 23 00:59:30 enc006 kernel: [53367.032726] usb 2-1.1: USB
> disconnect, device number 4

That is definitely a hardware disconnect.  It's not caused by software, 
unless the mouse interprets data sent to it by some program as a 
request to disconnect itself.  (But of course, that could not explain 
the initial 45-minute delay.)  It could easily be caused by something 
like an intermittently bad USB cable connection.

Have you tried using this mouse with a different computer?

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: problem with resume after s2ram

[Alan Stern]

On Thu, 20 Mar 2014, Peter Münster wrote:

> > I'd like to see a comparable log showing what happens when you suspend
> > with only the mouse plugged in to a rear port, and one with only the
> > keyboard plugged in to the rear.  No serial ports or other stuff.
> 
> Please find attached 3 files:
> - with keyboard in rear port
> - with mouse in rear port
> - with nothing in rear port

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?

> >>  But it wakes up after pressing the power-button. The system is
> >> ok after resume. Please find attached the log. The kernel is 3.9.11 with
> >> CONFIG_USB_DEBUG turned on and with CONFIG_USB_SUSPEND turned off.
> >
> > Please post a log for the same kernel version and settings but with 
> > CONFIG_USB_SUSPEND turned back on.
> 
> This log is also attached.

Oddly, this log is much more complete than the others.  Did you collect 
it the same way?

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?

Offhand, I'd say there's something wrong with the USB controller 
hardware on the motherboard.  With incomplete information, though, it's 
hard to tell for certain.

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: [PATCH] usb: host: Add MAX3421E HCD support.

[David Mosberger]

Felipe,

On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi  wrote:

> Why do you need to run your IRQ handler when an URQ gets enqueued ? That
> doesn't make much sense :-s

Please see the comments at the start of the file: spi_sync() is
blocking and must not be called while holding spinlocks or with
interrupts disabled.  The purpose of max3421_spi_thread() is to handle
all SPI transactions (implicitly serializing them).  An interrupt is
just one of the reasons to wake up the SPI thread.  Adding URBs,
removing them, or performing a bus reset are other reasons.

You can think of max3421_spi_thread() as implementing the state
machine that would normally be implemented in silicon with a "smart"
controller such as OHCI or similar.

  --david
-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
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

Vantec NST-280S3 (external HDD enclosure on JMicron JMS539) various troubles

[lornaderek]

https://bugzilla.kernel.org/show_bug.cgi?id=72761

This enclosure (with Hitachi 1Tb HDD inside in my case) have troubles with 
Gigabyte GA-H81M-HD3 USB3.0 ports.
This MB has additional USB3.0 controller:
-
Chipset:
2 USB 3.0/2.0 ports (available through the internal USB header)
6 USB 2.0/1.1 ports (2 ports on the back panel, 4 ports available through 
the internal USB headers)

VIA® VL805 chip:
4 USB 3.0/2.0 ports on the back panel


With kernel 3.11:
1.When I'm connecting Vantec to USB (chipset) it works but very unstable. It 
hangs and then disconnects while copying files.
2.When I'm connecting it to VIA chip ports it seems to work fine.

With kernel 3.13.6 and 3.14-rc7
1.Same unstable behavior as in kernel 3.11 (with chipset USBs)
2.Do not works at all with VIA chip USBs.

Enclosure and HDD is healthy (SMART is ok and it works flawlessly on another 
PC). Other USB3.0 flash disk (Silicon Power 32GB) works flawlessly on all ports.

--
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: [REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12

[Dâniel Fraga]

On Mon, 24 Mar 2014 10:14:23 -0400 (EDT)
Alan Stern  wrote:

> Okay, the patch is at the end of this email.

[4.248244] usb 2-1.6: new full-speed USB device number 7 using ehci-pci
[5.728476] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0004/input/input9
[   28.443450] usbhid 2-1.6:1.0: DISCONNECT by razerd
[   28.468208] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0005/input/input10
[   28.469233] usbhid 2-1.6:1.0: DISCONNECT by razerd
[   29.470405] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0006/input/input11
[   29.470932] usbhid 2-1.6:1.0: DISCONNECT by razerd
[   30.472537] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0007/input/input12

If this is wrong, I can contact the razerd developer.

But I think it hasn't anything to do with razerd since I tested
3.14-rc7 without running razerd daemon and the bug was triggered too.

> Or a bug in the input layer.  If you load the gpm console mouse 
> manager and switch to a VT console after starting KDE, does the 
> console mouse pointer work?

Yes. In the console with gpm, mouse works perfectly. Even in KDM 
(before 
entering KDE), the mouse works fine.

> Then can you post an equivalent dmesg log for the 3.12 kernel?

Here it's the dmesg log using 3.12.14 kernel (works perfect):

https://bugzilla.kernel.org/attachment.cgi?id=130591

Or the extract for your convenience:

[4.237714] usb 2-1.6: new full-speed USB device number 7 using ehci-pci
[4.322762] usb 2-1.6: ep0 maxpacket = 8
[4.325949] usb 2-1.6: skipped 1 descriptor after interface
[4.326197] usb 2-1.6: default language 0x0409
[4.327575] usb 2-1.6: udev 7, busnum 2, minor = 134
[4.327580] usb 2-1.6: New USB device found, idVendor=1532, idProduct=0016
[4.327582] usb 2-1.6: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[4.327585] usb 2-1.6: Product: Razer DeathAdder
[4.327587] usb 2-1.6: Manufacturer: Razer
[4.327862] usb 2-1.6: usb_probe_device
[4.327865] usb 2-1.6: configuration #1 chosen from 1 choice
[4.328203] usb 2-1.6: adding 2-1.6:1.0 (config #1, interface 0)
[4.328374] usbhid 2-1.6:1.0: usb_probe_interface
[4.328376] usbhid 2-1.6:1.0: usb_probe_interface - got id
[4.330409] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input3
[   27.381205] usb 2-1.6: link qh1-0e01/8800d4a7e600 start 0 [1/2 us]
[   28.089618] usbhid 2-1.6:1.0: disconnect by usbfs
[   28.089635] usb 2-1.6: unlink qh1-0e01/8800d4a7e600 start 0 [1/2 us]
[   28.112632] usb 2-1.6: manual set_interface for iface 0, alt 0
[   28.113508] usbhid 2-1.6:1.0: usb_probe_interface
[   28.113512] usbhid 2-1.6:1.0: usb_probe_interface - got id
[   28.115657] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input10
[   28.115827] usb 2-1.6: link qh1-0e01/880212187280 start 0 [1/2 us]
[   28.115961] usbhid 2-1.6:1.0: disconnect by usbfs
[   28.115972] usb 2-1.6: unlink qh1-0e01/880212187280 start 0 [1/2 us]
[   28.139661] usb 2-1.6: manual set_interface for iface 0, alt 0
[   29.115748] usbhid 2-1.6:1.0: usb_probe_interface
[   29.115753] usbhid 2-1.6:1.0: usb_probe_interface - got id
[   29.117747] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input11
[   29.117929] usb 2-1.6: link qh1-0e01/8800d5c33500 start 0 [1/2 us]
[   29.118078] usbhid 2-1.6:1.0: disconnect by usbfs
[   29.118088] usb 2-1.6: unlink qh1-0e01/8800d5c33500 start 0 [1/2 us]
[   29.144956] usb 2-1.6: manual set_interface for iface 0, alt 0
[   30.118099] usbhid 2-1.6:1.0: usb_probe_interface
[   30.118104] usbhid 2-1.6:1.0: usb_probe_interface - got id
[   30.120047] input: Razer Razer DeathAdder as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input12
[   30.120149] usb 2-1.6: link qh1-0e01/8800d5c8b100 start 0 [1/2 us]

-- 
Linux 3.12.14: One Giant Leap for Frogkind
http://www.youtube.com/DanielFragaBR
http://mcxnow.com?r=danielfragabr
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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: [REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12

[Alan Stern]

On Mon, 24 Mar 2014, Dâniel Fraga wrote:

> On Mon, 24 Mar 2014 10:14:23 -0400 (EDT)
> Alan Stern  wrote:
> 
> > Okay, the patch is at the end of this email.
> 
> [4.248244] usb 2-1.6: new full-speed USB device number 7 using ehci-pci
> [5.728476] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0004/input/input9
> [   28.443450] usbhid 2-1.6:1.0: DISCONNECT by razerd
> [   28.468208] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0005/input/input10
> [   28.469233] usbhid 2-1.6:1.0: DISCONNECT by razerd
> [   29.470405] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0006/input/input11
> [   29.470932] usbhid 2-1.6:1.0: DISCONNECT by razerd
> [   30.472537] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:1532:0016.0007/input/input12
> 
>   If this is wrong, I can contact the razerd developer.

Since it works under 3.12, we can assume that it is all right.

>   But I think it hasn't anything to do with razerd since I tested
> 3.14-rc7 without running razerd daemon and the bug was triggered too.

Okay, that was a false lead.

> > Or a bug in the input layer.  If you load the gpm console mouse 
> > manager and switch to a VT console after starting KDE, does the 
> > console mouse pointer work?
> 
>   Yes. In the console with gpm, mouse works perfectly. Even in KDM 
> (before 
> entering KDE), the mouse works fine.
> 
> > Then can you post an equivalent dmesg log for the 3.12 kernel?
> 
>   Here it's the dmesg log using 3.12.14 kernel (works perfect):
> 
> https://bugzilla.kernel.org/attachment.cgi?id=130591
> 
>   Or the extract for your convenience:
> 
> [4.237714] usb 2-1.6: new full-speed USB device number 7 using ehci-pci
> [4.322762] usb 2-1.6: ep0 maxpacket = 8
> [4.325949] usb 2-1.6: skipped 1 descriptor after interface
> [4.326197] usb 2-1.6: default language 0x0409
> [4.327575] usb 2-1.6: udev 7, busnum 2, minor = 134
> [4.327580] usb 2-1.6: New USB device found, idVendor=1532, idProduct=0016
> [4.327582] usb 2-1.6: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [4.327585] usb 2-1.6: Product: Razer DeathAdder
> [4.327587] usb 2-1.6: Manufacturer: Razer
> [4.327862] usb 2-1.6: usb_probe_device
> [4.327865] usb 2-1.6: configuration #1 chosen from 1 choice
> [4.328203] usb 2-1.6: adding 2-1.6:1.0 (config #1, interface 0)
> [4.328374] usbhid 2-1.6:1.0: usb_probe_interface
> [4.328376] usbhid 2-1.6:1.0: usb_probe_interface - got id
> [4.330409] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input3
> [   27.381205] usb 2-1.6: link qh1-0e01/8800d4a7e600 start 0 [1/2 us]
> [   28.089618] usbhid 2-1.6:1.0: disconnect by usbfs
> [   28.089635] usb 2-1.6: unlink qh1-0e01/8800d4a7e600 start 0 [1/2 us]
> [   28.112632] usb 2-1.6: manual set_interface for iface 0, alt 0
> [   28.113508] usbhid 2-1.6:1.0: usb_probe_interface
> [   28.113512] usbhid 2-1.6:1.0: usb_probe_interface - got id
> [   28.115657] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input10
> [   28.115827] usb 2-1.6: link qh1-0e01/880212187280 start 0 [1/2 us]
> [   28.115961] usbhid 2-1.6:1.0: disconnect by usbfs
> [   28.115972] usb 2-1.6: unlink qh1-0e01/880212187280 start 0 [1/2 us]
> [   28.139661] usb 2-1.6: manual set_interface for iface 0, alt 0
> [   29.115748] usbhid 2-1.6:1.0: usb_probe_interface
> [   29.115753] usbhid 2-1.6:1.0: usb_probe_interface - got id
> [   29.117747] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input11
> [   29.117929] usb 2-1.6: link qh1-0e01/8800d5c33500 start 0 [1/2 us]
> [   29.118078] usbhid 2-1.6:1.0: disconnect by usbfs
> [   29.118088] usb 2-1.6: unlink qh1-0e01/8800d5c33500 start 0 [1/2 us]
> [   29.144956] usb 2-1.6: manual set_interface for iface 0, alt 0
> [   30.118099] usbhid 2-1.6:1.0: usb_probe_interface
> [   30.118104] usbhid 2-1.6:1.0: usb_probe_interface - got id
> [   30.120047] input: Razer Razer DeathAdder as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input12
> [   30.120149] usb 2-1.6: link qh1-0e01/8800d5c8b100 start 0 [1/2 us]

I think we have now established that this isn't a bug in the USB layer.  
Maybe you should try asking on the linux-input mailing list, or ask the
KDE developers.

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] reset SuperSpeed, xhci_drop_endpoint called with disabled ep, Error in queuecommand_lck: task blocked

[Mathias Nyman]

On 03/20/2014 11:16 PM, Sarah Sharp wrote:

On Wed, Mar 19, 2014 at 12:37:37PM +0100, 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.


Mathias, you might want to come up with a patch to disable link PM and
see if it helps in this case.

That could be as simple as not setting XHCI_INTEL_HOST for this PCI
device ID, or could be as complex as exposing a sysfs file similar to
usb2_hardware_lpm.  It could also have something to do with how we set
the U1/U2 timeouts for this particular device.  Exposing a file to play
with those settings may be interesting.

I'll let you handle triaging the xHCI bug reports, but please let me
know if you get stuck.


I'm on it, I'm right now digging through the USB3 LPM code and trying to 
figure out where to include useful debug messages.


Goal is to have some debugging patch by tomorrow that Andreas could try.

-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: [GIT PULL] xhci: Maintainership change for 3.15.

[Mathias Nyman]

On 03/21/2014 05:09 PM, Sarah Sharp wrote:

The following changes since commit 1d10255c1c496557a5674e651c4ebbe0f61279f2:

   USB: disable reset-resume when USB_QUIRK_RESET is set (2014-03-19 14:00:32 
-0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
tags/for-usb-next-adventure

for you to fetch changes up to 03d85053b611b6611e027a54fd5a1f188844cae0:

   xhci: Transition maintainership to Mathias Nyman. (2014-03-21 07:52:17 -0700)


xhci: Maintainership change for 3.15.

I've been working on USB for seven years at Intel, and it's time for a
change of pace.  I'm pleased to announce that I'll be joining the Intel
OTC ChromeOS team, where I'll get to learn and play with everything
across the entire Linux stack, from kernel to graphics to browser
technologies.  (I'm a secret adventure/indie/casual gamer, so I'm super
excited to start working on graphics features for ChromeOS.)

I'm leaving the xHCI driver in Mathias Nyman's capable hands.  I'll
still be around to answer any architectural questions or triage really
tough bugs, but I expect to ramp down on xHCI driver work in the coming
weeks.

I'll be available to answer xHCI questions until I start my 8-week
sabbatical on May 8th.  I'll be doing a National Parks road trip, and
it's unlikely I'll have cell coverage.  And, let's face it, people are
supposed to ignore work email on sabbaticals. :)

After my sabbatical ends on July 7th, I'll be focusing my time fully on
ChromeOS.  It's been great working with and learning from Greg, Alan,
Oliver, and Felipe, but it's time to move onto my next adventure.

So long, and thanks for all the fishes!

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb44da0b3aa0105cb38d81c5747a8feae64834be


Sarah Sharp (1):
   xhci: Transition maintainership to Mathias Nyman.



Thank you for your trust, the guidance and the opportunity.

Enjoy your sabbatical and new tasks. I'll probably continue asking 
stupid questions for a while just to ensure you don't get away too easy.


I'll do my best to keep xhci afloat.

-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: [REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12

[Dâniel Fraga]

On Mon, 24 Mar 2014 12:19:51 -0400 (EDT)
Alan Stern  wrote:

> I think we have now established that this isn't a bug in the USB layer.  
> Maybe you should try asking on the linux-input mailing list, or ask the
> KDE developers.

Ok, I'll do that. Thank you very much Alan!

-- 
Linux 3.12.14: Shuffling Zombie Juror
http://www.youtube.com/DanielFragaBR
http://mcxnow.com?r=danielfragabr
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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: Regression cause by commit f1125f81 (from Deng-Cheng Zhu)

[Deng-Cheng Zhu]

Hi Dâniel


From http://marc.info/?l=linux-usb&m=139560312908515, I'm glad to see that 
I'm not the trouble maker.


Since this bug cannot be reproduced in each boot, I suggest you stick to 
the bisect method and write a script to do valid bisecting. The script 
should be able to boot the kernel, say, 5 times, and grep the boot log or 
dmesg to determine if any of the 5 attempts triggers the bug.



Deng-Cheng

---

*From:* Alan Stern 
*Sent:* Saturday, March 22, 2014 8:07AM
*To:* Dâniel Fraga 
*Cc:* dengcheng.zhu , James Hogan 
, USB list 

*Subject:* Re: Regression cause by commit f1125f81 (from Deng-Cheng Zhu)

Messages like this should always be sent to the linux-usb mailing list.

On Sat, 22 Mar 2014, Dâniel Fraga wrote:


Hi! I posted this bug and it seems your commit caused the
regression:

https://bugzilla.kernel.org/show_bug.cgi?id=72611

Can you take a look?

Thank you!

Ps: I put James and Alan on CC just in case.


I don't see how that particular commit could cause your problem.  The
code changed by the commit is used only in debugging.  Are you certain
you found the correct commit?

To track the bug further, you should turn on CONFIG_USB_DEBUG and post
the dmesg log showing what happens when the mouse gets stuck.  You also
should post a usbmon trace (see Documentation/usb/usbmon.txt).

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: [PATCH] usb: host: Add MAX3421E HCD support.

[Felipe Balbi]

Hi,

On Mon, Mar 24, 2014 at 09:21:40AM -0600, David Mosberger wrote:
> Felipe,
> 
> On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi  wrote:
> 
> > Why do you need to run your IRQ handler when an URQ gets enqueued ? That
> > doesn't make much sense :-s
> 
> Please see the comments at the start of the file: spi_sync() is
> blocking and must not be called while holding spinlocks or with
> interrupts disabled.  The purpose of max3421_spi_thread() is to handle

sure, but this is why we have threaded IRQ support.

> all SPI transactions (implicitly serializing them).  An interrupt is
> just one of the reasons to wake up the SPI thread.  Adding URBs,
> removing them, or performing a bus reset are other reasons.

you didn't tell me why. Why do you need to run that inside the same
thread ? Why can't you do that from inside ->urb_enqueue() itself ?

> You can think of max3421_spi_thread() as implementing the state
> machine that would normally be implemented in silicon with a "smart"
> controller such as OHCI or similar.

yada, yada, yada... still didn't answer my original question.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: host: Add MAX3421E HCD support.

[Alan Stern]

On Mon, 24 Mar 2014, Felipe Balbi wrote:

> Hi,
> 
> On Mon, Mar 24, 2014 at 09:21:40AM -0600, David Mosberger wrote:
> > Felipe,
> > 
> > On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi  wrote:
> > 
> > > Why do you need to run your IRQ handler when an URQ gets enqueued ? That
> > > doesn't make much sense :-s
> > 
> > Please see the comments at the start of the file: spi_sync() is
> > blocking and must not be called while holding spinlocks or with
> > interrupts disabled.  The purpose of max3421_spi_thread() is to handle
> 
> sure, but this is why we have threaded IRQ support.
> 
> > all SPI transactions (implicitly serializing them).  An interrupt is
> > just one of the reasons to wake up the SPI thread.  Adding URBs,
> > removing them, or performing a bus reset are other reasons.
> 
> you didn't tell me why. Why do you need to run that inside the same
> thread ? Why can't you do that from inside ->urb_enqueue() itself ?
> 
> > You can think of max3421_spi_thread() as implementing the state
> > machine that would normally be implemented in silicon with a "smart"
> > controller such as OHCI or similar.
> 
> yada, yada, yada... still didn't answer my original question.

It sounds like David is saying that he needs a process context to 
communicate with the host controller over SPI, and this communication 
has to take place whenever an URB is enqueued or dequeued as well as 
whenever an interrupt occurs.

If that's correct, it seems a kernel thread would be a better solution 
than a threaded IRQ handler.

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: usbnet: driver_info->stop required to stop USB interrupts?

[Grant Grundler]

On Fri, Mar 21, 2014 at 1:33 AM, Oliver Neukum  wrote:
...
> Very well. Thorough testing is good. I'll wait for the result. Could
> you notify me of the final outcome?

Ship it. :)

The testing so far has completed over 15K iterations of unload/reload
of the asix driver on the original failing system with no failures so
far. Previously I could reproduce the problem in 2K-8K iterations.

The caveat is due to various issues with my test environment, the test
never ran more than 7K iterations continuously. The ~15k is spread out
across four invocations (2K, 3K, 7K, 4K) of the previously shared
"for" loop.

Please add my Reported-by + Tested-by to this patch.

thanks
grant
--
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: host: Add MAX3421E HCD support.

[Felipe Balbi]

On Mon, Mar 24, 2014 at 03:22:10PM -0400, Alan Stern wrote:
> On Mon, 24 Mar 2014, Felipe Balbi wrote:
> 
> > Hi,
> > 
> > On Mon, Mar 24, 2014 at 09:21:40AM -0600, David Mosberger wrote:
> > > Felipe,
> > > 
> > > On Mon, Mar 24, 2014 at 7:31 AM, Felipe Balbi  wrote:
> > > 
> > > > Why do you need to run your IRQ handler when an URQ gets enqueued ? That
> > > > doesn't make much sense :-s
> > > 
> > > Please see the comments at the start of the file: spi_sync() is
> > > blocking and must not be called while holding spinlocks or with
> > > interrupts disabled.  The purpose of max3421_spi_thread() is to handle
> > 
> > sure, but this is why we have threaded IRQ support.
> > 
> > > all SPI transactions (implicitly serializing them).  An interrupt is
> > > just one of the reasons to wake up the SPI thread.  Adding URBs,
> > > removing them, or performing a bus reset are other reasons.
> > 
> > you didn't tell me why. Why do you need to run that inside the same
> > thread ? Why can't you do that from inside ->urb_enqueue() itself ?
> > 
> > > You can think of max3421_spi_thread() as implementing the state
> > > machine that would normally be implemented in silicon with a "smart"
> > > controller such as OHCI or similar.
> > 
> > yada, yada, yada... still didn't answer my original question.
> 
> It sounds like David is saying that he needs a process context to 
> communicate with the host controller over SPI, and this communication 
> has to take place whenever an URB is enqueued or dequeued as well as 
> whenever an interrupt occurs.
> 
> If that's correct, it seems a kernel thread would be a better solution 
> than a threaded IRQ handler.

looking at the driver, there's still quite a bit of duplication between
his kthread implementation and what threaded IRQs would give for free...

I see what you're saying, from urb_enqueue the EP schedule needs to be
advanced, so he needs to run his kthread and that might be alright, code
still looks a bit fishy, though.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] staging/usbip: userspace - fix usbipd SIGSEGV from refresh_exported_devices()

[Shuah Khan]

refresh_exported_devices() doesn't check udev_device_new_from_syspath()
return value and passed in null dev to udev_device_get_driver() resulting
in a segmentation fault. Change it to check for null return value from
both udev_device_new_from_syspath() and udev_device_get_driver().

Signed-off-by: Shuah Khan 
---
 drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c 
b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
index c5bf60b..92caef7 100644
--- a/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/usbip_host_driver.c
@@ -118,6 +118,7 @@ static int refresh_exported_devices(void)
struct udev_list_entry *devices, *dev_list_entry;
struct udev_device *dev;
const char *path;
+   const char *driver;
 
enumerate = udev_enumerate_new(udev_context);
udev_enumerate_add_match_subsystem(enumerate, "usb");
@@ -128,10 +129,12 @@ static int refresh_exported_devices(void)
udev_list_entry_foreach(dev_list_entry, devices) {
path = udev_list_entry_get_name(dev_list_entry);
dev = udev_device_new_from_syspath(udev_context, path);
+   if (dev == NULL)
+   continue;
 
/* Check whether device uses usbip-host driver. */
-   if (!strcmp(udev_device_get_driver(dev),
-   USBIP_HOST_DRV_NAME)) {
+   driver = udev_device_get_driver(dev);
+   if (driver != NULL && !strcmp(driver, USBIP_HOST_DRV_NAME)) {
edev = usbip_exported_device_new(path);
if (!edev) {
dbg("usbip_exported_device_new failed");
-- 
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: [PATCH] usb: host: Add MAX3421E HCD support.

[David Mosberger]

On Mon, Mar 24, 2014 at 1:35 PM, Felipe Balbi  wrote:

> looking at the driver, there's still quite a bit of duplication between
> his kthread implementation and what threaded IRQs would give for free...

Well, let's count: hard irq handler:

static irqreturn_t
max3421_irq_handler(int irq, void *dev_id)
{
struct usb_hcd *hcd = dev_id;
struct spi_device *spi = to_spi_device(hcd->self.controller);
struct max3421_hcd *max3421_hcd = hcd_to_max3421(hcd);

if (max3421_hcd->spi_thread &&
max3421_hcd->spi_thread->state != TASK_RUNNING)
wake_up_process(max3421_hcd->spi_thread);
if (!max3421_hcd->do_enable_irq) {
max3421_hcd->do_enable_irq = 1;
disable_irq_nosync(spi->irq);
}
return IRQ_HANDLED;
}

irq-specific part of spi_thread:

   set_current_state(TASK_INTERRUPTIBLE);
   if (max3421_hcd->do_enable_irq) {
max3421_hcd->do_enable_irq = 0;
enable_irq(spi->irq);
   }
   schedule();
   __set_current_state(TASK_RUNNING);

so we're talking about ~22 lines of code.  As I told you before, I did
start out using a threaded irq handler but it had the distinct
disadvantage of not working.

If you have better solution in mind that actually works, please show
us the code.  As the old saying goes: put up or shut up.

  --david
-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
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] staging/usbip: fix store_attach() sscanf return value check

[Shuah Khan]

Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7
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 
---
 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: USB3.0 is not getting detected sometimes

[Sarah Sharp]

On Mon, Mar 24, 2014 at 02:17:37PM -0700, Abhay kumar wrote:
> Thanks Sarah..
> 
> I did further investigation on this figured out that When the host tries to
> disable the LPM U1 and U2 state of USB 3 device by sending
> command "usb_control_msg" it is getting timed out as the device is not
> responding and after that we get timeout error --110 and then followed by
> usb 2-1: Disable of device-initiated U1 failed.
> 
> I am trying now to plug an external powered USB hard disk to see if this is
> power/signal problem. Any suggestion?

Please send the output of `sudo lspci -vvv` and `sudo lspci -vvv -n`.
I'm seeing a disturbing pattern where specific Ivy Bridge systems (C210
systems) have Link PM failures.  Not sure if that's because we aren't
programming the U1/U2 timeouts correctly, or if those systems simply
don't support Link PM at all.

Can you blacklist the usb-storage driver, and then send the output of
`sudo lsusb -v` with the USB 3.0 device plugged in?

Sarah Sharp

> 
> Regards,
> Abhay Kumar
> 
> 
> 
> On Sun, Mar 23, 2014 at 9:48 AM, Sarah Sharp
> wrote:
> 
> > Cc-ing Mathias Nyman, who is taking over as xHCI maintainer.
> >
> > On Sat, Mar 22, 2014 at 01:46:00AM +, Abhay Kumar wrote:
> > >
> > > Hi,
> > >
> > >  In my linux kernel USB 3.0 pendrive is not getting detected some
> > time.For
> > > the same usb port usb2.0 works perfectly.
> > >
> > > Here is the error message i am getting
> > > [  161.808889] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd
> > > [  161.87] usb 2-1: New USB device found, idVendor=0951,
> > idProduct=168f
> > > [  161.822288] usb 2-1: New USB device strings: Mfr=4, Product=5,
> > > SerialNumber=6
> > > [  161.822340] usb 2-1: Product: DT Workspace
> > > [  161.822387] usb 2-1: Manufacturer: Kingston
> > > [  161.822436] usb 2-1: SerialNumber: 0018F30C9F55010E0022
> > > [  161.825196] usb-storage 2-1:1.0: USB Mass Storage device detected
> > > [  161.825493] scsi2 : usb-storage 2-1:1.0
> > > [  161.827469] find_i2c_adapter_num: i2c adapter i2c-designware-pci-0 not
> > > found on system.
> > > [  161.827537] find_i2c_adapter_num: i2c adapter i2c-designware-pci-0 not
> > > found on system.
> > > [  161.827596] find_i2c_adapter_num: i2c adapter i2c-designware-pci-5 not
> > > found on system.
> > > [  161.827653] find_i2c_adapter_num: i2c adapter i2c-designware-pci-1 not
> > > found on system.
> > > [  188.955719] usb 2-1: Disable of device-initiated U1 failed.
> > > [  193.959530] usb 2-1: Disable of device-initiated U2 failed.
> > > [  199.065489] xhci_hcd :00:14.0: Timeout while waiting for Address
> > > Device
> > > [  204.271133] xhci_hcd :00:14.0: Timeout while waiting for Address
> > > Device
> > > [  204.471822] usb 2-1: device not accepting address 4, error -62
> > > [  204.626803] usb 2-1: reset SuperSpeed USB device number 4 using
> > xhci_hcd
> > > [  204.638364] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
> > > disabled ep 88006dfd4500
> > > [  204.638401] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
> > > disabled ep 88006dfd4540
> > > [  219.652519] usb 2-1: Disable of device-initiated U1 failed.
> > > [  224.656871] usb 2-1: Disable of device-initiated U2 failed.
> > > [  229.762425] xhci_hcd :00:14.0: Timeout while waiting for Address
> > > Device
> > > [  234.967629] xhci_hcd :00:14.0: Timeout while waiting for Address
> > > Device
> > > [  235.169041] usb 2-1: device not accepting address 4, error -62
> > > [  235.323588] usb 2-1: reset SuperSpeed USB device number 4 using
> > xhci_hcd
> > > [  235.335404] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
> > > disabled ep 88006dfd4500
> > > [  235.335441] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
> > > disabled ep 88006dfd4540
> > > [  256.353129] usb 2-1: Disable of device-initiated U1 failed.
> > > [  261.357636] usb 2-1: Disable of device-initiated U2 failed.
> > > [  266.463482] xhci_hcd :00:14.0: Timeout while waiting for Address
> > > Device
> > >
> > > 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
> >
> 
> 
> 
> -- 
> Abhay kumar
> +1-408-663-8262
--
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

[Sarah Sharp]

Cc'ing Mathias Nyman, who is taking over as xHCI driver maintainer.

On Sun, Mar 23, 2014 at 07:16:03PM +0100, 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
> 
> [18853.074081] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with 
> disabled ep 8803e2119c80
> [18853.074088] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with 
> disabled ep 8803e2119cc0
> [18890.189088] xhci_hcd :08:00.0: xHCI host not responding to stop 
> endpoint command.
> [18890.189096] xhci_hcd :08:00.0: Assuming host is dying, halting host.
> [18890.232182] xhci_hcd :08:00.0: Host not halted after 16000 
> microseconds.
> [18890.232193] xhci_hcd :08:00.0: Non-responsive xHCI host is not halting.
> [18890.232197] xhci_hcd :08:00.0: Completing active URBs anyway.
> [18890.232209] xhci_hcd :08:00.0: HC died; cleaning up
> 
> Furthermore I have tried kernel 3.14rc6 but the same issues.
> 
> ** My configuration:
> Home PC: ASUS P7P55D-E PRO with Intel Chipset P55 with PLX PEX PCI Bridges 
> attached to NEC Controller
> => detailed information: pc_lspci_PLX_PEX_Chip_problems.txt
> **
> 
> For my office PC I have bought a PCIe-Card with the same NEC-Controller (it 
> is exactly the same revision reported by lspci, 
> pc_lspci_PCIe_Card_noproblems.txt) and all the usb3-devices are working fine 
> there => no errors !?
> 
> It is the same USB3-NEC-controller in both PCs, but only with a different 
> connection (PLX PEX PCI Bridge vs. PCIe-Card).
> 
> Please help me to get my Usb3-devices working!
> 
> Thank you for your support!
> 
> Best regards, Bernhard
> 
> ** Chipset P55 with PLX PEX PCI Bridges vs Sandybridge Mainboard with 
> PCIe-Card(PCIe 2.0 x1, 5Gbps):
> 
> Here are the differences between the lspci outputs;
> 
> PCIe Type | CacheLineSize | Flags; AuxCurrent | PME|DevCtl   | 
> MaxReadReq |AuxPwr  | CommClk
> -
> PLX Chip, NEC |   32  | AuxCurrent=375mA  |D3cold+ |NoSnoop+ | 512 
> bytes  |AuxPwr+ | CommClk-
> PCIe-Card NEC |   64  | AuxCurrent=0mA|D3cold- |NoSnoop- | 128 
> bytes  |AuxPwr- | CommClk+
> 
> lsusb diffs;
> PLX Chip, NEC; bmAttributes 0x02 (no LTM support)
> PCIe-Card: bmAttributes 0x00  Latency Tolerance Messages (LTM) Supported
> 
> PLX Chip with NEC: problems; pc_lspci_PLX_PEX_Chip_problems.txt and 
> pc_lsusb_PLX_PEX_Chip_problems.txt
> ---
> Cache Line Size: 32 bytes
> 
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> 
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ 
> TransPend-
> 
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
> 
> 
> PCIe-Card; no problems; pc_lspci_PCIe_Card_noproblems.txt and 
> pc_lsusb_PCIe_Card_noproblems.txt
> 
> Cache Line Size: 64 bytes
> 
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
> 
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- 
> TransPend-
> 
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 

> Mar 16 21:29:27 stargazer kernel: [ 8364.261248] usb 4-1: reset SuperSpeed 
> USB device number 4 using xhci_hcd
> Mar 16 21:29:27 stargazer kernel: [ 8364.280610] usb 4-1: Parent hub missing 
> LPM exit latency info.  Power management will be impacted.
> Mar 16 21:29:27 stargazer kernel: [ 8364.289092] xhci_hcd :08:00.0: xHCI 
> xhci_drop_endpoint called with disabled ep 8804087c8200
> Mar 16 21:29:27 stargazer kernel: [ 8364.289095] xhci_hcd :08:00.0: xHCI 
> xhci_drop_endpoint called with disabled ep 8804087c8240
> Mar 16 21:29:34 stargazer kernel: [ 8370.985086] usb 4-1: reset SuperSpeed 
> USB device number 4 using xhci_hcd
> Mar 16 21:29:34 stargazer kernel: [ 8371.004475] usb 4-1: Parent hub missing 
> LPM exit latency info.  Power management will be impacted.
> Mar 16 21:29:34 stargazer kernel: [ 8371.013046] xhci_hcd :08:00.0: xH

Re: [PATCH] staging/usbip: fix store_attach() sscanf return value check

[Greg KH]

On Mon, Mar 24, 2014 at 05:12:09PM -0600, Shuah Khan wrote:
> Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7

What do you mean by this 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 
> ---
>  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
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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

[Shuah Khan]

On 03/24/2014 06:38 PM, Greg KH wrote:

On Mon, Mar 24, 2014 at 05:12:09PM -0600, Shuah Khan wrote:

Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7


What do you mean by this line?



Nothing really. Sloppiness on my part. I was keeping notes as I was 
chasing the problem and those ended up in the change log. Sorry about. 
Will fix the change log and resend the patch.


-- Shuah


--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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] chipidea: usbmisc_imx: Allow USB OTG to work on mx51

[Fabio Estevam]

From: Fabio Estevam 

The field PLLDIVVALUE of register PHY_CTRL_1 selects the reference clock source
for the PHY:
00 = sysclock uses 19.2 MHz
01 = sysclock uses 24 MHz
10 = sysclock uses 26 MHz
11 = sysclock uses 27 MHz

The reset value for this field is 01 according to the reference manual, but
inspecting the register on mx51 showed that this does not happen.

So instead of relying on the reset value for the PLLDIVVALUE field, explicitly
set it to 01, so that both mx51 and mx53 can have USB OTG functional.

Succesfully tested 'g_ether' on a imx51-babbage and on a imx53-qsb boards.

Signed-off-by: Fabio Estevam 
---
 drivers/usb/chipidea/usbmisc_imx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index cd061ab..f6c4f3c 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -26,11 +26,14 @@
 #define MX27_OTG_PM_BITBIT(24)
 
 #define MX53_USB_OTG_PHY_CTRL_0_OFFSET 0x08
+#define MX53_USB_OTG_PHY_CTRL_1_OFFSET 0x0c
 #define MX53_USB_UH2_CTRL_OFFSET   0x14
 #define MX53_USB_UH3_CTRL_OFFSET   0x18
 #define MX53_BM_OVER_CUR_DIS_H1BIT(5)
 #define MX53_BM_OVER_CUR_DIS_OTG   BIT(8)
 #define MX53_BM_OVER_CUR_DIS_UHx   BIT(30)
+#define MX53_USB_PHYCTRL1_PLLDIV_MASK  0x3
+#define MX53_USB_PLL_DIV_24_MHZ0x01
 
 #define MX6_BM_OVER_CUR_DISBIT(7)
 
@@ -111,6 +114,13 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data 
*data)
if (data->index > 3)
return -EINVAL;
 
+   /* Select a 24 MHz reference clock for the PHY  */
+   reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET;
+   val = readl(reg);
+   val &= ~MX53_USB_PHYCTRL1_PLLDIV_MASK;
+   val |= MX53_USB_PLL_DIV_24_MHZ;
+   writel(val, usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
+
if (data->disable_oc) {
spin_lock_irqsave(&usbmisc->lock, flags);
switch (data->index) {
-- 
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] chipidea: usbmisc_imx: Allow USB OTG to work on mx51

[Fabio Estevam]

From: Fabio Estevam 

The field PLLDIVVALUE of register PHY_CTRL_1 selects the reference clock source
for the PHY:
00 = sysclock uses 19.2 MHz
01 = sysclock uses 24 MHz
10 = sysclock uses 26 MHz
11 = sysclock uses 27 MHz

The reset value for this field is 10 according to the reference manual, and
even though this reset value works for mx53, it does not work for mx51.

So instead of relying on the reset value for the PLLDIVVALUE field, explicitly
set it to 01 so that a 24MHz clock can be selected for the PHY and allowing both
mx51 and mx53 to have USB OTG port functional.

Succesfully tested 'g_ether' on a imx51-babbage and on a imx53-qsb boards.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- The reset value for PLLDIVVALUE is 10, not 01.

 drivers/usb/chipidea/usbmisc_imx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index cd061ab..f6c4f3c 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -26,11 +26,14 @@
 #define MX27_OTG_PM_BITBIT(24)
 
 #define MX53_USB_OTG_PHY_CTRL_0_OFFSET 0x08
+#define MX53_USB_OTG_PHY_CTRL_1_OFFSET 0x0c
 #define MX53_USB_UH2_CTRL_OFFSET   0x14
 #define MX53_USB_UH3_CTRL_OFFSET   0x18
 #define MX53_BM_OVER_CUR_DIS_H1BIT(5)
 #define MX53_BM_OVER_CUR_DIS_OTG   BIT(8)
 #define MX53_BM_OVER_CUR_DIS_UHx   BIT(30)
+#define MX53_USB_PHYCTRL1_PLLDIV_MASK  0x3
+#define MX53_USB_PLL_DIV_24_MHZ0x01
 
 #define MX6_BM_OVER_CUR_DISBIT(7)
 
@@ -111,6 +114,13 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data 
*data)
if (data->index > 3)
return -EINVAL;
 
+   /* Select a 24 MHz reference clock for the PHY  */
+   reg = usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET;
+   val = readl(reg);
+   val &= ~MX53_USB_PHYCTRL1_PLLDIV_MASK;
+   val |= MX53_USB_PLL_DIV_24_MHZ;
+   writel(val, usbmisc->base + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
+
if (data->disable_oc) {
spin_lock_irqsave(&usbmisc->lock, flags);
switch (data->index) {
-- 
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

dma-buf and ->dev refcount fun

[Dave Airlie]

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,

Dave.

[  147.162846] [drm:i915_gem_unmap_dma_buf] *ERROR* attachment is
88002a9f2ab8 880030b1e238 88002a90cf00
[  147.164228] [drm:i915_gem_unmap_dma_buf] *ERROR* obj is 88002a90cf00
[  147.165641] [drm:i915_gem_unmap_dma_buf] *ERROR* sg is
88002a9ef2d0 88002da0ca40 33
[  147.167089] [drm:i915_gem_unmap_dma_buf] *ERROR* ops is
880030829c08 6b6b6b6b6b6b6b6b
[  147.168988] general protection fault:  [#1] SMP
[  147.169379] Modules linked in: udl syscopyarea sysfillrect
sysimgblt drm_usb rfcomm fuse ip6table_filter ip6_tables
iptable_mangle bnep arc4 iwldvm mac80211 btusb iwlwifi bluetooth
snd_hda_codec_conexant snd_hda_codec_generic cfg80211 snd_hda_intel
snd_hda_codec snd_hwdep snd_seq e1000e snd_seq_device sdhci_pci sdhci
coretemp kvm_intel mmc_core snd_pcm kvm microcode 6lowpan_iphc
i2c_i801 thinkpad_acpi snd_timer snd lpc_ich mfd_core rfkill soundcore
ptp pps_core wmi firewire_ohci firewire_core crc_itu_t yenta_socket
i915 i2c_algo_bit drm_kms_helper drm i2c_core video
[  147.169379] CPU: 0 PID: 481 Comm: Xorg Not tainted 3.14.0-rc7+ #28
[  147.169379] Hardware name: LENOVO 406334M/406334M, BIOS 6FET79WW
(3.09 ) 10/02/2009
[  147.169379] task: 880070ba29d0 ti: 88005df74000 task.ti:
88005df74000
[  147.169379] RIP: 0010:[]  []
i915_gem_unmap_dma_buf+0x10e/0x1a0 [i915]
[  147.169379] RSP: 0018:88005df75c58  EFLAGS: 00010246
[  147.169379] RAX:  RBX: 88002a9ef2d0 RCX: 831a8319
[  147.169379] RDX: 00a0 RSI: 0001 RDI: 88002da0cf40
[  147.169379] RBP: 88005df75c90 R08:  R09: 
[  147.169379] R10:  R11:  R12: 880030829c08
[  147.169379] R13: 88002a90cf00 R14:  R15: 6b6b6b6b6b6b6b6b
[  147.169379] FS:  7f5e18ef89c0() GS:880078c0()
knlGS:
[  147.169379] CS:  0010 DS:  ES:  CR0: 8005003b
[  147.169379] CR2: 0042fa60 CR3: 3f5e7000 CR4: 07f0
[  147.169379] Stack:
[  147.169379]  00212a9f2ab8 88002da0ca40 88002a9f2ab8
88002a9ef2d0
[  147.169379]   88003fd413b0 88005df75d70
88005df75cb8
[  147.169379]  81487851 88002a9f2ab8 88004446e818
88004446e7b0
[  147.169379] Call Trace:
[  147.169379]  [] dma_buf_unmap_attachment+0x51/0x80
[  147.169379]  [] drm_prime_gem_destroy+0x22/0x40 [drm]
[  147.169379]  [] udl_gem_free_object+0x35/0x60 [udl]
[  147.169379]  [] drm_gem_object_free+0x2a/0x30 [drm]
[  147.169379]  []
drm_gem_object_handle_unreference_unlocked+0xe4/0x120 [drm]
[  147.169379]  []
drm_gem_object_release_handle+0x5c/0x80 [drm]
[  147.169379]  [] idr_for_each+0x104/0x1a0
[  147.169379]  [] ? drm_gem_dumb_destroy+0x20/0x20 [drm]
[  147.169379]  [] ? mutex_unlock+0xe/0x10
[  147.169379]  [] drm_gem_release+0x20/0x30 [drm]
[  147.169379]  [] drm_release+0x533/0x5c0 [drm]
[  147.169379]  [] __fput+0xf5/0x2c0
[  147.169379]  [] fput+0xe/0x10
[  147.169379]  [] task_work_run+0xb4/0xe0
[  147.169379]  [] do_exit+0x2ec/0xcd0
--
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