Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sat, Jan 12, 2013 at 11:52 PM, Alan Stern wrote: > On Sat, 12 Jan 2013, Alex Riesen wrote: >> Now, who would be interested to handle this kind of misconfiguration ... > > So the whole thing was a false alarm? Yes, almost. What about khubd hanging when machine is shutdown? > Maybe you should report to the block-layer maintainers that it's > possible to mess up the system by building an elevator as a module. > That sounds like the sort of thing they'd be interested to hear. Hi Jens, may I point you at this problem report: http://thread.gmane.org/gmane.linux.kernel/1420814 It is surely a misconfiguration on my part (the used io scheduler configured as a module), but the behavior is somewhat problematic anyway: at least in this case USB storage is essentially locked up. Regards, Alex -- 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 problem
I left this problem for awhile, then finally got back to it. I upgraded the gentoo kernel to 3.6.11 and was partially successful: the 3TB drive mounted ok, but then had some serious trouble transferring files and I believe that linux force-unmounted it as a result. Then upgrading to 3.7.1 fixed the problem completely. Here is the dmesg output now: [4.787051] scsi 7:0:0:0: Direct-Access ST330006 51AS CC45 PQ: 0 ANSI: 0 [4.787176] sd 7:0:0:0: Attached scsi generic sg2 type 0 [4.787416] sd 7:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [4.787998] sd 7:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) [4.788405] sd 7:0:0:0: [sdc] Write Protect is off [4.788408] sd 7:0:0:0: [sdc] Mode Sense: 03 00 00 00 [4.76] sd 7:0:0:0: [sdc] No Caching mode page present [4.78] sd 7:0:0:0: [sdc] Assuming drive cache: write through [4.789246] sd 7:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [4.790420] sd 7:0:0:0: [sdc] No Caching mode page present [4.790424] sd 7:0:0:0: [sdc] Assuming drive cache: write through [4.841399] sdc: sdc1 [4.841883] sd 7:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [4.843331] sd 7:0:0:0: [sdc] No Caching mode page present [4.843334] sd 7:0:0:0: [sdc] Assuming drive cache: write through [4.843336] sd 7:0:0:0: [sdc] Attached SCSI disk Thanks for your help! On Wed, 2012-12-05 at 09:24 -0800, Sarah Sharp wrote: > On Tue, Dec 04, 2012 at 08:28:30PM -0500, Allan Dennis wrote: > > I hope you won't be annoyed by my question... here goes: > > It's my job to answer questions, so fire away. :) > > > I have 2TB and 3TB SATA drives, both connected to my Intense PC (Ivy > > Bridge tiny PC) on separate external drive enclosures on USB 3 cables. I > > have gentoo linux, and was running kernel 3.4.9 where both drives > > weren't recognized properly. Now I updated to 3.5.7 and the 2TB is good > > to go (yay!) but the 3TB guy is still giving me problems. Here is the > > dmesg output as I plugged in the 3TB (sdc) after the 2TB (sdb) was > > successful, with debug enabled in the kernel config. Is this a known > > issue? Can I help you figure out what's going wrong here by providing > > logs or whatnot? > > I can't see anything wrong on the xHCI side, so I suspect the problem > might be that the SCSI layer doesn't like some response the hard drive is > sending. I would suggest you take a usbmon trace, following the > directions here: > > http://lxr.linux.no/#linux/Documentation/usb/usbmon.txt > > Please hit 'reply-all' when you send the trace, since I've Cced the > linux-usb and usb-storage mailing lists. > > Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-3.7.1: kmemleak reports in comm "usb-storage"?
On Sun, 13 Jan 2013, Martin Mokrejs wrote: > > Don't worry about what kmemleak says when the drives are plugged in. > > See what it says when all the USB drives are unplugged. That's what > > matters. > > Now it is the only one drive connected. If I disconnect it kmemleak won't > change like it > did not today for many hours when all the drives were unplugged. I thought > you want > me to plug it in back and unplug several times. ;) I did want you to plug it in and unplug it several times. But pay attention only to what kmemleak says when the drive is unplugged. > So, did I answer your question now? I can't tell. I don't really understand what you are doing. 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: Re: how to disable usb hub suspend function
On Sun, 13 Jan 2013, gavin.kx wrote: > if i use suspend function, the hub may occur error, if i removed the > hub before suspend then can avoid the suspend? if it could, how can i > do ? how to remove and add ? You remove a hub the same way you remove any other USB device -- by unplugging the cable. Also, I thought you wanted to prevent the hub from going into suspend. When the hub is removed, it definitely _will_ go into suspend. 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: 回复: Re: how to disable usb hub suspend function
On Sun, 13 Jan 2013, gavin.kx wrote: > and does have a way to force to remove the usb device? my hub power > is supplied by battery, it can work while CPU sleep. You remove the USB device by unplugging its cable. 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: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sun, 13 Jan 2013, Alex Riesen wrote: > On Sat, Jan 12, 2013 at 11:52 PM, Alan Stern > wrote: > > On Sat, 12 Jan 2013, Alex Riesen wrote: > >> Now, who would be interested to handle this kind of misconfiguration ... > > > > So the whole thing was a false alarm? > > Yes, almost. What about khubd hanging when machine is shutdown? What about it? I have trouble understanding all the descriptions you have provided so far, because you talk about several different things and change your mind a lot. Can you provide a single, simple scenario that illustrates this problem? 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: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sun, Jan 13, 2013 at 5:56 PM, Alan Stern wrote: > On Sun, 13 Jan 2013, Alex Riesen wrote: >> >> Yes, almost. What about khubd hanging when machine is shutdown? > > What about it? I have trouble understanding all the descriptions you > have provided so far, because you talk about several different things > and change your mind a lot. Can you provide a single, simple scenario > that illustrates this problem? 1. Compile a kernel with deadline elevator as module 2. Boot into it, make sure the elevator is selected (I used "elevator=deadline" in the kernel command line) 3. Insert a FAT formatted mass storage device in an USB2 port Observe "io scheduler deadline registered" 4. Pull the stick out, wait a moment, and either shutdown or just and press alt-sysrq-W: [ 158.170585] usb 1-1.2: USB disconnect, device number 3 [ 158.170590] usb 1-1.2: unregistering device [ 158.170595] usb 1-1.2: unregistering interface 1-1.2:1.0 [ 166.959398] SysRq : Show Blocked State [ 166.959410] taskPC stack pid father [ 166.959432] khubd D 880213a68000 0 513 2 0x [ 166.959440] 880213affa18 0046 8802006b 0 [ 166.959448] 880213a68000 880213afffd8 880213afffd8 00013 [ 166.959454] 81a14400 880213a68000 880213aff9a8 0 [ 166.959461] Call Trace: [ 166.959475] [] ? flush_work+0x6d/0x1fe [ 166.959485] [] ? scsi_remove_host+0x24/0x10e [ 166.959490] [] ? flush_work+0x5/0x1fe [ 166.959499] [] schedule+0x65/0x67 [ 166.959506] [] schedule_preempt_disabled+0x18/0x24 [ 166.959513] [] mutex_lock_nested+0x181/0x2c1 [ 166.959518] [] ? scsi_remove_host+0x24/0x10e [ 166.959524] [] scsi_remove_host+0x24/0x10e [ 166.959531] [] usb_stor_disconnect+0x77/0xbc [ 166.959539] [] usb_unbind_interface+0x6c/0x14d [ 166.959548] [] __device_release_driver+0x88/0xdb [ 166.959554] [] device_release_driver+0x25/0x32 [ 166.959561] [] bus_remove_device+0xf5/0x10a [ 166.959567] [] device_del+0x12e/0x189 [ 166.959574] [] usb_disable_device+0xb1/0x20e [ 166.959582] [] usb_disconnect+0xab/0x113 [ 166.959589] [] hub_port_connect_change+0x1b0/0x879 [ 166.959597] [] hub_events+0x559/0x69d [ 166.959604] [] hub_thread+0x38/0x19b [ 166.959612] [] ? wake_up_bit+0x2a/0x2a [ 166.959618] [] ? hub_events+0x69d/0x69d [ 166.959625] [] kthread+0xd5/0xdd [ 166.959632] [] ? finish_task_switch+0x3f/0xf7 [ 166.959641] [] ? __init_kthread_worker+0x5a/0x5a [ 166.959648] [] ret_from_fork+0x7c/0xb0 [ 166.959655] [] ? __init_kthread_worker+0x5a/0x5a This trace if from alt-sysrq-W. I can attach an image from the shutdown case, the traces from that case are hard to save: the main storage is usually already stopped. I believe it was the same, though. -- 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 issue with kernel 3.6
Hi Alan,
Happy New Year!
I removed the previous short patch to ehci-q.c and applied
this second one.
After some extensive testing, I could not reproduce the
issue and dmesg showed the ususl "async off" and "async on"
messages, the second as soon as I started to read the HDDs.
Performance wise, it seems to me better than ever, I mean
I saw regular transfer of above 4000 KB/sec per disk.
Even with 2 processes reading the 10 HDDs, the data rate
was about 3800 KB/sec.
Next step?
Thanks,
bye,
pg
On Mon, Dec 17, 2012 at 02:59:21PM -0500, Alan Stern wrote:
> On Mon, 17 Dec 2012, Piergiorgio Sartor wrote:
>
> > Hi Alan,
> >
> > I applied the latest patch, changing the unlinking
> > behavior of EHCI.
> >
> > I tested quite extensively and I could not see the
> > issue (as expected). At a certain point I lost 3 HDDs,
> > but this is something I saw before (it happens very
> > seldom, maybe future debugging) and it was not really
> > locking the EHCI driver.
> >
> > Another thing is that the read performance was around
> > about 10% slower that the usual one.
> > I saw 3700~3800 KB/sec per HDD, while, under normal
> > conditions, I saw 4100~4200 KB/sec per HDD.
>
> The slower performance might be caused by all the idle QHs remaining on
> the async list. The controller has to look at them because they are on
> the list, even though they aren't being used, and that could slow it
> down.
>
> > I think that's all, how do you want to proceed now?
>
> Below is another patch, which is meant to replace the previous one.
> This changes the behavior to be like the driver was before the
> troublesome commit: Only one idle QH will be unlinked from the async
> schedule at a time.
>
> > Please note that shortly I'll not be anymore with
> > my PC, until January, so we can take it easy.
> >
> > In this respect, I wish you Merry Christmas and
> > Happy New Year.
>
> Enjoy your holidays too.
>
> Alan Stern
>
>
>
> Index: usb-3.7/drivers/usb/host/ehci-q.c
> ===
> --- usb-3.7.orig/drivers/usb/host/ehci-q.c
> +++ usb-3.7/drivers/usb/host/ehci-q.c
> @@ -1279,8 +1279,9 @@ static void unlink_empty_async(struct eh
>
> if (list_empty(&qh->qtd_list) &&
> qh->qh_state == QH_STATE_LINKED) {
> - if (!stopped && qh->unlink_cycle ==
> - ehci->async_unlink_cycle)
> + if (!stopped && (qh->unlink_cycle ==
> + ehci->async_unlink_cycle ||
> + ehci->async_unlink))
> check_unlinks_later = true;
> else
> single_unlink_async(ehci, qh);
--
piergiorgio
--
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: Crucible Technologies COMET Caller ID - pid added.
From: Tomasz Mloduchowski
Simple fix to add support for Crucible Technologies COMET Caller ID
USB decoder - a device containing FTDI USB/Serial converter chip,
handling 1200bps CallerID messages decoded from the phone line -
adding correct USB PID is sufficient.
Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
and 3.8.0-rc3 on both amd64 and x86 arches.
Signed-off-by: Tomasz Mloduchowski
---
diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
--- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c2013-01-13
19:41:28.0 +0100
+++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13
19:49:27.239874311 +0100
@@ -875,6 +875,8 @@
{ USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
+ /* Crucible Devices */
+ { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
{ },/* Optional parameter entry */
{ } /* Terminating entry */
};
diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h
linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h
--- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h
2013-01-13 19:41:28.0 +0100
+++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h 2013-01-13
19:48:24.819996641 +0100
@@ -1259,3 +1259,9 @@
* ATI command output: Cinterion MC55i
*/
#define FTDI_CINTERION_MC55I_PID 0xA951
+
+/*
+ * Product: Comet Caller ID decoder
+ * Manufacturer: Crucible Technologies
+ */
+#define FTDI_CT_COMET_PID 0x8e08
--
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 device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sunday 13 January 2013 18:42:49 Alex Riesen wrote: > On Sun, Jan 13, 2013 at 5:56 PM, Alan Stern wrote: > > On Sun, 13 Jan 2013, Alex Riesen wrote: > >> > >> Yes, almost. What about khubd hanging when machine is shutdown? > > > > What about it? I have trouble understanding all the descriptions you > > have provided so far, because you talk about several different things > > and change your mind a lot. Can you provide a single, simple scenario > > that illustrates this problem? > > 1. Compile a kernel with deadline elevator as module > 2. Boot into it, make sure the elevator is selected > (I used "elevator=deadline" in the kernel command line) > 3. Insert a FAT formatted mass storage device in an USB2 port >Observe "io scheduler deadline registered" > 4. Pull the stick out, wait a moment, and either shutdown or just >and press alt-sysrq-W: That makes it clear. The elevator probably has scheduled work which cannot finish waiting on a lock and scsi_remove_host() wants to flush work. This is not a USB problem. You need to involve the SCSI people. khubd just stops working because disconnects are processed in its context and the removal deadlocks. 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
close blocks, if FIFO full on gagdet serial
Hello guys,
I've found a following problems on BeagleBoard and Kernel 3.0.8 with
gadget serial driver.
Attached is a small program, which opens gadget serial tty at
/dev/ttyGS0. USB is NOT connected to host. Then it fills it's output
fifo up. Before closing, it flushes the output fifo. But despite that,
call to close function on last line blocks for 15seconds!
To me it looks like fifo flushing doesn't work. If I do this on regular
serial port on PC and if I remove output fifo flushing, close also
blocks (as I have flow control set). But if the flushing is present,
close returns immediately on PC.
On gadget serial, it always block for 15s.
So it looks to me like a bug in gadget serial driver. Or is there any
other cleanup, which I should do? Or at least some option how to lower
the timeout value?
thank you and best regards
Petr Masek
#include
#include
#include
#include
#include
#include
int main(void)
{
int fd = open("/dev/ttyGS0", O_NOCTTY | O_RDWR | O_NONBLOCK);
if (fd < 0) {
printf("Serial device open error!\n");
return -1;
}
struct termios newtio;
bzero(&newtio,sizeof(struct termios));
newtio.c_cflag = B9600 | CS8 | CRTSCTS | CLOCAL | CREAD |
NOFLSH;
newtio.c_iflag = IGNPAR;
newtio.c_oflag = 0;
newtio.c_lflag = 0;
newtio.c_cc[VMIN] = 0;
newtio.c_cc[VTIME] = 0;
tcsetattr(fd,TCSANOW,&newtio);
int ret = 0;
while (ret >= 0) {
const char buffer[32] = "Hello World!\n";
ret = write(fd, buffer, strlen(buffer));
if ((ret < 0) && (errno == EWOULDBLOCK)) printf("FIFO Full!\n");
}
tcflush(fd, TCOFLUSH);
close(fd);
--
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: Crucible Technologies COMET Caller ID - pid added.
On Sun, Jan 13, 2013 at 07:20:27PM +0100, Tomasz Mloduchowski wrote:
> From: Tomasz Mloduchowski
>
> Simple fix to add support for Crucible Technologies COMET Caller ID
> USB decoder - a device containing FTDI USB/Serial converter chip,
> handling 1200bps CallerID messages decoded from the phone line -
> adding correct USB PID is sufficient.
>
> Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
> and 3.8.0-rc3 on both amd64 and x86 arches.
>
> Signed-off-by: Tomasz Mloduchowski
> ---
> diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
> linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
> --- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c2013-01-13
> 19:41:28.0 +0100
> +++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13
> 19:49:27.239874311 +0100
> @@ -875,6 +875,8 @@
> { USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
> + /* Crucible Devices */
> + { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
> { },/* Optional parameter entry */
> { } /* Terminating entry */
> };
The patch is line-wrapped and all of the tabs are converted to spaces,
both of which are keeping this patch from being able to be applied :(
Care to fix your email client and resend this so that I can apply it?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Just as a side note, some discussion has been taking place at https://bugzilla.kernel.org/show_bug.cgi?id=43081 particularly on looking for ways to detect the 5V/5VSB setting via software, if possible at all. If this is not possible from the kernel, I'd suggest, setting the default to whatever works out of the box for most Asus-based laptops. -- Octavio. -- 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: Crucible Technologies COMET Caller ID - pid added.
On 01/13/13 20:25, Greg KH wrote:
> On Sun, Jan 13, 2013 at 07:20:27PM +0100, Tomasz Mloduchowski wrote:
>> From: Tomasz Mloduchowski
>>
>> Simple fix to add support for Crucible Technologies COMET Caller ID
>> USB decoder - a device containing FTDI USB/Serial converter chip,
>> handling 1200bps CallerID messages decoded from the phone line -
>> adding correct USB PID is sufficient.
>>
>> Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
>> and 3.8.0-rc3 on both amd64 and x86 arches.
>>
>> Signed-off-by: Tomasz Mloduchowski
>> ---
>> diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
>> linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
>> --- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c2013-01-13
>> 19:41:28.0 +0100
>> +++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13
>> 19:49:27.239874311 +0100
>> @@ -875,6 +875,8 @@
>> { USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
>> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
>> { USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
>> + /* Crucible Devices */
>> + { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
>> { },/* Optional parameter entry
>> */
>> { } /* Terminating entry */
>> };
>
> The patch is line-wrapped and all of the tabs are converted to spaces,
> both of which are keeping this patch from being able to be applied :(
>
> Care to fix your email client and resend this so that I can apply it?
>
> thanks,
>
> greg k-h
>
No problem - this should send correctly now .
Best,
Tomasz
diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
--- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c2013-01-13
19:41:28.0 +0100
+++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13 19:49:27.239874311
+0100
@@ -875,6 +875,8 @@
{ USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
+ /* Crucible Devices */
+ { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
{ },/* Optional parameter entry */
{ } /* Terminating entry */
};
diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h
linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h
--- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h2013-01-13
19:41:28.0 +0100
+++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h 2013-01-13
19:48:24.819996641 +0100
@@ -1259,3 +1259,9 @@
* ATI command output: Cinterion MC55i
*/
#define FTDI_CINTERION_MC55I_PID 0xA951
+
+/*
+ * Product: Comet Caller ID decoder
+ * Manufacturer: Crucible Technologies
+ */
+#define FTDI_CT_COMET_PID 0x8e08
--
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: Crucible Technologies COMET Caller ID - pid added.
On Sun, Jan 13, 2013 at 10:40:20PM +0100, Tomasz Mloduchowski wrote:
> On 01/13/13 20:25, Greg KH wrote:
> > On Sun, Jan 13, 2013 at 07:20:27PM +0100, Tomasz Mloduchowski wrote:
> >> From: Tomasz Mloduchowski
> >>
> >> Simple fix to add support for Crucible Technologies COMET Caller ID
> >> USB decoder - a device containing FTDI USB/Serial converter chip,
> >> handling 1200bps CallerID messages decoded from the phone line -
> >> adding correct USB PID is sufficient.
> >>
> >> Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
> >> and 3.8.0-rc3 on both amd64 and x86 arches.
> >>
> >> Signed-off-by: Tomasz Mloduchowski
> >> ---
> >> diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
> >> linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
> >> --- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c2013-01-13
> >> 19:41:28.0 +0100
> >> +++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13
> >> 19:49:27.239874311 +0100
> >> @@ -875,6 +875,8 @@
> >> { USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
> >> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> >> { USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
> >> + /* Crucible Devices */
> >> + { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
> >> { },/* Optional parameter
> >> entry */
> >> { } /* Terminating entry */
> >> };
> >
> > The patch is line-wrapped and all of the tabs are converted to spaces,
> > both of which are keeping this patch from being able to be applied :(
> >
> > Care to fix your email client and resend this so that I can apply it?
> >
> > thanks,
> >
> > greg k-h
> >
>
>
> No problem - this should send correctly now .
Yes it did. So can you resend it in the original format (correct
changelog entry and signed-off-by: line), so that I can apply it without
having to edit the patch by hand?
Also:
> diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
> linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
> --- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c 2013-01-13
> 19:41:28.0 +0100
> +++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13
> 19:49:27.239874311 +0100
> @@ -875,6 +875,8 @@
> { USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
> + /* Crucible Devices */
> + { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
> { },/* Optional parameter entry */
> { } /* Terminating entry */
> };
> diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h
> linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h
> --- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h 2013-01-13
> 19:41:28.0 +0100
> +++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h 2013-01-13
> 19:48:24.819996641 +0100
> @@ -1259,3 +1259,9 @@
> * ATI command output: Cinterion MC55i
> */
> #define FTDI_CINTERION_MC55I_PID 0xA951
> +
> +/*
> + * Product: Comet Caller ID decoder
> + * Manufacturer: Crucible Technologies
> + */
> +#define FTDI_CT_COMET_PID 0x8e08
Don't you want a tab after the FTDI_CT_COMET_PID and before the number?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: Crucible Technologies COMET Caller ID - pid added - v2
From: Tomasz Mloduchowski
Simple fix to add support for Crucible Technologies COMET Caller ID
USB decoder - a device containing FTDI USB/Serial converter chip,
handling 1200bps CallerID messages decoded from the phone line -
adding correct USB PID is sufficient.
Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
and 3.8.0-rc3 on both amd64 and x86 arches.
Signed-off-by: Tomasz Mloduchowski
---
diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c
linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c
--- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio.c2013-01-13
19:41:28.0 +0100
+++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio.c 2013-01-13 19:49:27.239874311
+0100
@@ -875,6 +875,8 @@
{ USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_LUMEL_PD12_PID) },
+ /* Crucible Devices */
+ { USB_DEVICE(FTDI_VID, FTDI_CT_COMET_PID) },
{ },/* Optional parameter entry */
{ } /* Terminating entry */
};
diff -ur linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h
linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h
--- linux-3.8-rc3.orig/drivers/usb/serial/ftdi_sio_ids.h2013-01-13
19:41:28.0 +0100
+++ linux-3.8-rc3/drivers/usb/serial/ftdi_sio_ids.h 2013-01-13
23:28:44.964087761 +0100
@@ -1259,3 +1259,9 @@
* ATI command output: Cinterion MC55i
*/
#define FTDI_CINTERION_MC55I_PID 0xA951
+
+/*
+ * Product: Comet Caller ID decoder
+ * Manufacturer: Crucible Technologies
+ */
+#define FTDI_CT_COMET_PID 0x8e08
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
On Thu, Jan 10, 2013 at 10:27:14AM +, Fangxiaozhi (Franko) wrote: > You mean that we have to write as follows? > + memset(bcbw, 0, sizeof(struct bulk_cb_wrap)); > + bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN); > + bcbw->Length = sizeof(rewind_cmd); > > Right? Excatly. > > Best Regards, > Franko Fang Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
On Fri, Jan 11, 2013 at 05:57:44PM +0800, fangxiaozhi 00110321 wrote:
> diff -uprN linux-3.8-rc3_orig/drivers/usb/storage/initializers.c
> linux-3.8-rc3/drivers/usb/storage/initializers.c
> --- linux-3.8-rc3_orig/drivers/usb/storage/initializers.c 2013-01-11
> 17:53:19.757842845 +0800
> +++ linux-3.8-rc3/drivers/usb/storage/initializers.c 2013-01-11
> 17:55:04.137841849 +0800
> @@ -104,3 +104,71 @@ int usb_stor_huawei_e220_init(struct us_
> US_DEBUGP("Huawei mode set result is %d\n", result);
> return 0;
> }
> +
> +/* It will send a scsi switch command called rewind' to huawei dongle.
> + * When the dongle receives this command at the first time,
> + * it will reboot immediately. After rebooted, it will ignore this command.
> + * So it is unnecessary to read its response. */
This multiline comment is wrong. See Documentation/CodingStyle Chapter 8:
Commenting
> +static int usb_stor_huawei_scsi_init(struct us_data *us)
> +{
> + int result = 0;
> + int act_len = 0;
> + struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
> + char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
> +
> + bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
> + bcbw->Tag = 0;
> + bcbw->DataTransferLength = 0;
> + bcbw->Flags = bcbw->Lun = 0;
> + bcbw->Length = sizeof(rewind_cmd);
> + memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
> + memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
You asked me about this, and just replied.
> + result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
> + US_BULK_CB_WRAP_LEN, &act_len);
> + US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
> + return result;
> +}
> +
> +/* It tries to find the supported Huawei USB dongles.
> + * In Huawei, they assign the following product IDs
> + * for all of their mobile broadband dongles,
> + * including the new dongles in the future.
> + * So if the product ID is not included in this list,
> + * it means it is not Huawei's mobile broadband dongles.*/
multiline comment again.
> +static int usb_stor_huawei_dongles_pid(struct us_data *us)
> +{
> + struct usb_interface_descriptor *idesc;
> + int idProduct;
> +
> + idesc = &us->pusb_intf->cur_altsetting->desc;
> + idProduct = us->pusb_dev->descriptor.idProduct;
> + /* The first port is CDROM,
> + * means the dongle in the single port mode,
> + * and a switch command is required to be sent. */
Multiline comment + means fits in the first line, doesn't it?
> + if (idesc && idesc->bInterfaceNumber == 0) {
if you do
if (!idesc || idesc-> != 0)
return 0;
then you lose one ident level.
> + if ((idProduct == 0x1001)
> + || (idProduct == 0x1003)
> + || (idProduct == 0x1004)
> + || (idProduct >= 0x1401 && idProduct <= 0x1500)
> + || (idProduct >= 0x1505 && idProduct <= 0x1600)
> + || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
> + return 1;
what about the switch case here?
> + }
> + }
> + return 0;
> +}
> +
> +int usb_stor_huawei_init(struct us_data *us)
> +{
> + int result = 0;
> +
> + if (usb_stor_huawei_dongles_pid(us)) {
> + if (us->pusb_dev->descriptor.idProduct >= 0x1446)
> + result = usb_stor_huawei_scsi_init(us);
> + else
> + result = usb_stor_huawei_feature_init(us);
> + }
> + return result;
> +}
> Binary files linux-3.8-rc3_orig/drivers/usb/storage/initializers.o and
> linux-3.8-rc3/drivers/usb/storage/initializers.o differ
^^^
Sebastian
--
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 serial driver: private data already deallocated when release function is called
Hello Greg
> Do you have a pointer to your code anywhere? That would be the easiest
> way to help you out here. Otherwise we are just guessing as to the
> issues involved.
Not really -- I hence pasted it into this posting. I hope that is OK and does
violate some etiquette of this list.
Btw. are there repositories that would be suitable to make highly experimental
code available ?
Thanks
Tilman
/* File: usbrsatest.c
* Driver for IO-Data's USB RSA serial dongle (test driver)
* Copyright (C) 2012
* Tilman Glotzner
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
*
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//#include
#include
#include
//#include
#include "usbrsa.h"
#define CONFIG_DYNAMIC_PRINTK_DEBUG 1
#define CONFIG_USB_SERIAL_DEBUG 1
#ifdef CONFIG_USB_SERIAL_DEBUG
static int debug = 1;
#else
static int debug = 0;
#endif
char buffer_tx[65];
char buffer_rx[65];
/*
* Version Information
*/
#define DRIVER_VERSION "v0.1"
#define DRIVER_AUTHOR "Tilman Gloetzner "
#define DRIVER_DESC "IO-Data USB-RSA test driver"
#define IODATA_VENDOR_ID0x4bb
#define IODATA_USBRSA_PREENUM_ID0xa01
#define IODATA_USBRSA_ID0xa03
#define IODATA_USBRSA_FW_STRING "USB-RSA Test-FW"
#define COMMAND_TIMEOUT (2*HZ) /* 2 second timeout for a command */
/*
Taken whiteheat driver as role model:
ID tables for usb-rsa are unusual, because we want to different
things for different versions of the device. Eventually, this
will be doable from a single table. But, for now, we define two
separate ID tables, and then a third table that combines them
just for the purpose of exporting the autoloading information.
*/
static const struct usb_device_id id_table_std[] = {
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_USBRSA_ID) },
{ } /* Terminating entry */
};
static const struct usb_device_id id_table_prerenumeration[] = {
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_USBRSA_PREENUM_ID) },
{ } /* Terminating entry */
};
static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_USBRSA_ID) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_USBRSA_PREENUM_ID) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, id_table_combined);
// Preenumeration device
// Function Prototypes
static int usbrsa_test_firmware_download(struct usb_serial *serial,
const struct usb_device_id *id);
static int usbrsa_test_firmware_attach(struct usb_serial *serial);
// Driver object declaration
static struct usb_serial_driver usbrsa_test_preenum_device = {
.driver = {
.owner =THIS_MODULE,
.name = "usbrsanofirm",
},
.description = "IO-DATA - USB-RSA - (test prerenumeration)",
.id_table = id_table_prerenumeration,
.num_ports =1,
.probe =usbrsa_test_firmware_download,
.attach = usbrsa_test_firmware_attach,
};
// Functions
//
// Name: usbrsa_firmware_download
// Purpose: Downloads firmware to AN2134Q
//
//
static int usbrsa_test_firmware_download(struct usb_serial *serial,
const struct usb_device_id *id)
{
int response = -ENOENT;
dev_dbg(&serial->dev->dev,"%s", __func__);
response = ezusb_fx1_ihex_firmware_download(serial->dev,
"usbrsatest.fw");
if (response < 0)
goto fwdownload_out0;
// The USB-RSA does not reenumerate without toggeling the reset bit
// one more time
// response = ezusb_fx1_set_res
Re: [PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
Balbi, On Fri, Jan 11, 2013 at 02:50:59PM +0200, Felipe Balbi wrote: > As I said before, this patch is too big for -rc and is unnecessary > considering patch I wrote above. Note that there is no problems in > checking if ULPI PHY clk is 60MHz on all arches and, for the workaround, > you already have a runtime check. > Ok, I did not have these facts on my mind. If these are true, the cpu_is_xxx() shouldn't be necessary there from the beginning, and we can simply remove them then. > Shawn, it can be broken down into smaller pieces because you can *FIX > THE COMPILE BREAKAGE* with a very small patch as above (only issue now > is usage of MX32_IO_ADDRESS()). > The MX35_IO_ADDRESS() also seems unnecessary, since as Peter's patch suggested that pdata->regs can be used instead. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
Dear Greg: > -Original Message- > From: Greg KH [mailto:g...@kroah.com] > Sent: Saturday, January 12, 2013 8:22 AM > To: Fangxiaozhi (Franko) > Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying > (Zihan); > Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); > ba...@ti.com; > mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc > Subject: Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage > devices and support new switch command > > On Fri, Jan 11, 2013 at 05:57:44PM +0800, fangxiaozhi 00110321 wrote: > > From: fangxiaozhi > > > > 1. Optimize the match rules with new macro for Huawei USB storage devices, > >to avoid to load USB storage driver for the modem interface > >with Huawei devices. > > 2. Add to support new switch command for new Huawei USB dongles. > > I don't see a 1/2 patch in this series, yet I see two different 1/1 patches. --Yes, this email includes the entire patch. --I mask the "2/2" to distinguish it from the previous email, which mask 1/1. > > Can you resend all of your outstanding patchs, in the correct order, with the > correct numbering, so I know what order to apply them in? > -This email is the whole patch, so can I resend it again? > thanks, > > greg k-h Best Regards, Franko Fang
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sun, 13 Jan 2013, Oliver Neukum wrote: > On Sunday 13 January 2013 18:42:49 Alex Riesen wrote: > > On Sun, Jan 13, 2013 at 5:56 PM, Alan Stern > > wrote: > > > On Sun, 13 Jan 2013, Alex Riesen wrote: > > >> > > >> Yes, almost. What about khubd hanging when machine is shutdown? > > > > > > What about it? I have trouble understanding all the descriptions you > > > have provided so far, because you talk about several different things > > > and change your mind a lot. Can you provide a single, simple scenario > > > that illustrates this problem? > > > > 1. Compile a kernel with deadline elevator as module > > 2. Boot into it, make sure the elevator is selected > > (I used "elevator=deadline" in the kernel command line) > > 3. Insert a FAT formatted mass storage device in an USB2 port > >Observe "io scheduler deadline registered" > > 4. Pull the stick out, wait a moment, and either shutdown or just > >and press alt-sysrq-W: Indeed. I just tried booting into a kernel that has the deadline elevator built-in, not a module. Even then, when I specified "elevator=deadline" on the boot command line, the system hung up partway through booting. Hard to tell exactly where, because it occurred shortly after the switching from VGA to the framebuffer driver, so the screen was completely blank. When I get a chance, I'll try it on another machine where I can use a serial console. > That makes it clear. The elevator probably has scheduled work > which cannot finish waiting on a lock and scsi_remove_host() > wants to flush work. What is the work and why can't it finish? Or rather, how can we figure these things out? According to what Alex wrote, the blocked task doesn't show up in the Alt-SysRq-W listing. And don't forget that the listing shows scsi_remove_host() blocks waiting to acquire the host's scan_mutex. Not waiting for work to be flushed. This casts doubt on your explanation. > This is not a USB problem. You need to involve the SCSI people. > khubd just stops working because disconnects are processed > in its context and the removal deadlocks. The why whould building the deadline elevator as a module make any difference? Or does it make a difference? Alex, if the elevator is made static instead, do you still see the same behavior when the USB drive is removed? Also, are there any mounted filesystems on the drive when you unplug it? 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
[PATCH 1/1]linux-usb:optimize the matching rules and support new switch command for Huawei USB storage devices
From: fangxiaozhi
1. Optimize the matching rules with new macro for Huawei USB storage devices,
to avoid to load USB storage driver for the modem interface
with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.
Signed-off-by: fangxiaozhi
diff -uprN linux-3.8-rc3_orig/drivers/usb/storage/initializers.c
linux-3.8-rc3/drivers/usb/storage/initializers.c
--- linux-3.8-rc3_orig/drivers/usb/storage/initializers.c 2013-01-11
17:53:19.757842845 +0800
+++ linux-3.8-rc3/drivers/usb/storage/initializers.c2013-01-14
10:53:55.738795497 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
{
int result;
@@ -104,3 +104,75 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP("Huawei mode set result is %d\n", result);
return 0;
}
+
+/*
+ * It will send a scsi switch command called rewind' to huawei dongle.
+ * When the dongle receives this command at the first time,
+ * it will reboot immediately. After rebooted, it will ignore this command.
+ * So it is unnecessary to read its response.
+ */
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+ bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw->Tag = 0;
+ bcbw->DataTransferLength = 0;
+ bcbw->Flags = bcbw->Lun = 0;
+ bcbw->Length = sizeof(rewind_cmd);
+ memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
+ memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
+ US_BULK_CB_WRAP_LEN, &act_len);
+ US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
+ return result;
+}
+
+/*
+ * It tries to find the supported Huawei USB dongles.
+ * In Huawei, they assign the following product IDs
+ * for all of their mobile broadband dongles,
+ * including the new dongles in the future.
+ * So if the product ID is not included in this list,
+ * it means it is not Huawei's mobile broadband dongles.
+ */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+
+ idesc = &us->pusb_intf->cur_altsetting->desc;
+ idProduct = us->pusb_dev->descriptor.idProduct;
+ /* The first port is CDROM,
+* means the dongle in the single port mode,
+* and a switch command is required to be sent. */
+ if (idesc && idesc->bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001)
+ || (idProduct == 0x1003)
+ || (idProduct == 0x1004)
+ || (idProduct >= 0x1401 && idProduct <= 0x1500)
+ || (idProduct >= 0x1505 && idProduct <= 0x1600)
+ || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
+ return 1;
+ }
+ }
+ return 0;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+
+ if (usb_stor_huawei_dongles_pid(us)) {
+ if (us->pusb_dev->descriptor.idProduct >= 0x1446)
+ result = usb_stor_huawei_scsi_init(us);
+ else
+ result = usb_stor_huawei_feature_init(us);
+ }
+ return result;
+}
diff -uprN linux-3.8-rc3_orig/drivers/usb/storage/initializers.h
linux-3.8-rc3/drivers/usb/storage/initializers.h
--- linux-3.8-rc3_orig/drivers/usb/storage/initializers.h 2013-01-11
17:53:19.758842845 +0800
+++ linux-3.8-rc3/drivers/usb/storage/initializers.h2013-01-11
17:55:04.767841843 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
Binary files linux-3.8-rc3_orig/drivers/usb/storage/initializers.o and
linux-3.8-rc3/drivers/usb/storage/initializers.o differ
diff -uprN linux-3.8-rc3_orig/drivers/usb/storage/unusual_devs.h
linux-3.8-rc3/drivers/usb/storage/unusual_devs.h
--- linux-3.8-rc3_orig/drivers/usb/storage/unusual_devs.h 2013-01-11
17:53:19.757842845 +0800
+++ linux-3.8-rc3/drivers/usb/storage/unusual_devs.h2013-01-11
17:55:15
Re: usb serial driver: private data already deallocated when release function is called
On Sun, Jan 13, 2013 at 10:23:59PM +, Tilman wrote: > Hello Greg > > > > Do you have a pointer to your code anywhere? That would be the easiest > > way to help you out here. Otherwise we are just guessing as to the > > issues involved. > > Not really -- I hence pasted it into this posting. I hope that is OK and does > violate some etiquette of this list. > Btw. are there repositories that would be suitable to make highly experimental > code available ? Yes, that is what drivers/staging/ is for, why not submit your driver for inclusion there? > Tilman > /* File: usbrsatest.c > * Driver for IO-Data's USB RSA serial dongle (test driver) > * Copyright (C) 2012 > * Tilman Glotzner > * > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation; either version 2 of the License, or > * (at your option) any later version. > * > * > * > */ > > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > //#include > #include > #include > //#include > #include "usbrsa.h" > > #define CONFIG_DYNAMIC_PRINTK_DEBUG 1 > #define CONFIG_USB_SERIAL_DEBUG 1 > #ifdef CONFIG_USB_SERIAL_DEBUG > static int debug = 1; > #else > static int debug = 0; > #endif > > char buffer_tx[65]; > char buffer_rx[65]; > > /* > * Version Information > */ > #define DRIVER_VERSION "v0.1" > #define DRIVER_AUTHOR "Tilman Gloetzner " > #define DRIVER_DESC "IO-Data USB-RSA test driver" > > > #define IODATA_VENDOR_ID0x4bb > #define IODATA_USBRSA_PREENUM_ID0xa01 > #define IODATA_USBRSA_ID0xa03 > #define IODATA_USBRSA_FW_STRING "USB-RSA Test-FW" > > #define COMMAND_TIMEOUT (2*HZ) /* 2 second timeout for a command */ > > /* >Taken whiteheat driver as role model: Ugh, the whitehead driver was not a good role model. You should look at the changes that have gone into that driver over the past few releases, and make the same kind of changes to your driver. That would be an easy way to bring it up to modern standards, and fix the tty port issue at the same time. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Mon, Jan 14, 2013 at 1:42 AM, Alex Riesen wrote: > > 1. Compile a kernel with deadline elevator as module > 2. Boot into it, make sure the elevator is selected > (I used "elevator=deadline" in the kernel command line) > 3. Insert a FAT formatted mass storage device in an USB2 port >Observe "io scheduler deadline registered" > 4. Pull the stick out, wait a moment, and either shutdown or just >and press alt-sysrq-W: I can reproduce the problem too on one ehci-only system(Pandaboard) with deadline elevator module case, and no such problem in the built-in case, and still on 3.8-rc3. Follows the dmesg log: [ 85.665679] usb 1-1.2.2: new high-speed USB device number 5 using ehci-omap [ 85.784423] usb 1-1.2.2: default language 0x0409 [ 85.790008] usb 1-1.2.2: udev 5, busnum 1, minor = 4 [ 85.790039] usb 1-1.2.2: New USB device found, idVendor=0951, idProduct=1624 [ 85.790039] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 85.790069] usb 1-1.2.2: Product: DataTraveler G2 [ 85.790069] usb 1-1.2.2: Manufacturer: Kingston [ 85.790100] usb 1-1.2.2: SerialNumber: 0019E06C5346EA41D071 [ 85.790100] device: '1-1.2.2': device_add [ 85.790344] bus: 'usb': add device 1-1.2.2 [ 85.790405] PM: Adding info for usb:1-1.2.2 [ 85.790740] bus: 'usb': driver_probe_device: matched device 1-1.2.2 with driver usb [ 85.790771] bus: 'usb': really_probe: probing driver usb with device 1-1.2.2 [ 85.790802] usb 1-1.2.2: usb_probe_device [ 85.790832] usb 1-1.2.2: configuration #1 chosen from 1 choice [ 85.791076] usb 1-1.2.2: adding 1-1.2.2:1.0 (config #1, interface 0) [ 85.791076] device: '1-1.2.2:1.0': device_add [ 85.791137] bus: 'usb': add device 1-1.2.2:1.0 [ 85.791168] PM: Adding info for usb:1-1.2.2:1.0 [ 85.791442] device: 'ep_81': device_add [ 85.791564] PM: Adding info for No Bus:ep_81 [ 85.791564] device: 'ep_02': device_add [ 85.791687] PM: Adding info for No Bus:ep_02 [ 85.791687] driver: '1-1.2.2': driver_bound: bound to device 'usb' [ 85.791717] bus: 'usb': really_probe: bound device 1-1.2.2 to driver usb [ 85.791748] PM: Moving platform:musb-hdrc.0.auto to end of list [ 85.791748] device: 'ep_00': device_add [ 85.791778] platform musb-hdrc.0.auto: Retrying from deferred list [ 85.791839] PM: Adding info for No Bus:ep_00 [ 85.791839] bus: 'platform': driver_probe_device: matched device musb-hdrc.0.auto with driver musb-hdrc [ 85.791839] bus: 'platform': really_probe: probing driver musb-hdrc with device musb-hdrc.0.auto [ 85.791870] hub 1-1.2:1.0: state 7 ports 4 chg evt 0004 [ 85.791900] unable to find transceiver of type USB2 PHY [ 85.797454] HS USB OTG: no transceiver configured [ 85.802703] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 85.811157] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral [ 85.811187] platform musb-hdrc.0.auto: Added to deferred list [ 85.811218] PM: Moving platform:twl6030_usb to end of list [ 85.811218] platform twl6030_usb: Retrying from deferred list [ 85.811279] bus: 'platform': driver_probe_device: matched device twl6030_usb with driver twl6030_usb [ 85.811279] bus: 'platform': really_probe: probing driver twl6030_usb with device twl6030_usb [ 85.811309] twl6030_usb twl6030_usb: phy not ready, deferring probe [ 85.811462] platform twl6030_usb: Driver twl6030_usb requests probe deferral [ 85.811462] platform twl6030_usb: Added to deferred list [ 85.883331] Initializing USB Mass Storage driver... [ 85.883361] bus: 'usb': add driver usb-storage [ 85.883453] bus: 'usb': driver_probe_device: matched device 1-1.2.2:1.0 with driver usb-storage [ 85.883483] bus: 'usb': really_probe: probing driver usb-storage with device 1-1.2.2:1.0 [ 85.883514] usb-storage 1-1.2.2:1.0: usb_probe_interface [ 85.883544] usb-storage 1-1.2.2:1.0: usb_probe_interface - got id [ 85.884094] scsi0 : usb-storage 1-1.2.2:1.0 [ 85.884155] device: 'host0': device_add [ 85.884185] bus: 'scsi': add device host0 [ 85.884246] PM: Adding info for scsi:host0 [ 85.884552] device: 'host0': device_add [ 85.884674] PM: Adding info for No Bus:host0 [ 85.884948] driver: '1-1.2.2:1.0': driver_bound: bound to device 'usb-storage' [ 85.884979] bus: 'usb': really_probe: bound device 1-1.2.2:1.0 to driver usb-storage [ 85.884979] PM: Moving platform:musb-hdrc.0.auto to end of list [ 85.885009] platform musb-hdrc.0.auto: Retrying from deferred list [ 85.885070] bus: 'platform': driver_probe_device: matched device musb-hdrc.0.auto with driver musb-hdrc [ 85.885070] bus: 'platform': really_probe: probing driver musb-hdrc with device musb-hdrc.0.auto [ 85.885131] unable to find transceiver of type USB2 PHY [ 85.886230] usbcore: registered new interface driver usb-storage [ 85.886230] USB Mass Storage support registered. [ 85.890655] HS USB OTG: no transceiver configured [ 85.895660] musb-hdrc musb-hdrc.0.auto: musb_init_co
RE: [PATCH 0/6] UVC gadget cleanup
H Laurent, > Hi Felipe, > > On Tuesday 23 October 2012 16:52:31 Felipe Balbi wrote: > > On Tue, Oct 23, 2012 at 09:50:10PM +0800, Bhupesh SHARMA wrote: > > > On Tuesday, October 23, 2012 6:31 PM Laurent Pinchart wrote: > > > > On Wednesday 01 August 2012 14:57:09 Laurent Pinchart wrote: > > > > > Hi, > > > > > > > > > > These 6 patches clean up the UVC gadget driver after Bhupesh > > > > > Sharma's "UVC webcam gadget related changes" patch series. > > > > > They're what I would have asked during patch review if the > > > > > original patches hadn't been merged before I got a change to review > them. > > > > > > > > > > Bhupesh, would you mind testing the patches, especially the ones > > > > > that touch super speed support ? I have no SS hardware I can test > them on. > > > > > > > > Ping ? Could you please test this patch set ? I've rebased it on > > > > top of the latest master branch in Linus' tree, the result is > > > > available in the > > > > uvcvideo- gadget branch of > > > > git://linuxtv.org/pinchartl/uvcvideo.git, > > > > including two of your fixes. I'll then work on your videobuf2 patch. > > > > > > Sorry for the delay. I had tested the patch-set and completely > > > forgot about updating you with the results (I could not get the UVC > > > gadget to enumerate properly with your patches). > > > > > > I was completely busy with making the UVC working on a NOMMU > > > architecture for a customer and hence the delay. I will start > > > sending you the test results and new patches I have generated > > > locally for the NOMMU architecture from the next week. > > > > > > Sorry again for the delay and thanks for your patience :) > > > > > > Regards, > > > Bhupesh > > > > > > > > Laurent Pinchart (6): > > > > > usb: gadget/uvc: Clarify comment about string descriptors > > > > > usb: gadget/uvc: Rename STATUS_BYTECOUNT to > > > > > > > > > > UVC_STATUS_MAX_PACKET_SIZE > > > > > > > > > > usb: gadget/uvc: Fix coding style issues introduced by SS support > > > > > usb: gadget/uvc: Merge the SS/HS/FS status endpoint descriptors > > > > > usb: gadget/uvc: Merge the streaming maxpacket and mult > parameters > > > > > usb: gadget/uvc: Configure the streaming endpoint based on the > > > > > speed > > > > > > > > > > drivers/usb/gadget/f_uvc.c | 220 ++-- > --- > > > > > drivers/usb/gadget/f_uvc.h | 12 +- > > > > > 2 files changed, 110 insertions(+), 122 deletions(-) > > > > I don't seem to have the patches in my inbox. I'd like to have the > > patches with proper Tested-by tags so I can queue them for v3.8 merge > > window. > > It looks like the patches broke enumeration, so a v2 will be needed. > Ok. It seems that I have finally managed to test your patches available here: http://git.linuxtv.org/pinchartl/uvcvideo.git/shortlog/refs/heads/uvc-gadget and the enumeration works fine with a USB3.0 Host (TI PCIe based USB3.0 card connected on a Fedora 17 machine) and USB2.0 Host (Fedora 17 Machine). I am still having some trouble in enumerating the same with a Windows USB2.0 Host, but this may be an issue with my board as even my patches are not working well at the moment with the Windows USB2.0 Host with my board. I tested the patches with your uvc-gadget application available here: http://git.ideasonboard.org/uvc-gadget.git So, please feel free to add my tested by to your patches: Tested-by: Bhupesh Sharma Please let me know, when can I start sending my patches and over which GIT branch of yours for the videobuf2 changes and other useful UVC gadget related patches. Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
On Fri, Jan 11, 2013 at 02:50:59PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 11, 2013 at 05:56:28PM +0800, Peter Chen wrote:
> > It changes the driver to use platform_device_id rather than cpu_is_xxx
> > to determine the SoC type, and updates the platform code accordingly.
> >
> > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable.
> > Tested at mx51 bbg board, it works ok after enable phy clock
> > (Need another patch to fix this problem)
> >
> > -
> > +static struct platform_device_id fsl_udc_devtype[] = {
>
> should be const
OK.
>
> > + {
> > + .name = "imx-udc-mx25",
> > + .driver_data = IMX25_UDC,
> > + }, {
> > + .name = "imx-udc-mx27",
> > + .driver_data = IMX27_UDC,
> > + }, {
> > + .name = "imx-udc-mx31",
> > + .driver_data = IMX31_UDC,
> > + }, {
> > + .name = "imx-udc-mx35",
> > + .driver_data = IMX35_UDC,
> > + }, {
> > + .name = "imx-udc-mx51",
> > + .driver_data = IMX51_UDC,
> > + }
> > +};
> > +MODULE_DEVICE_TABLE(platform, fsl_udc_devtype);
> > static struct platform_driver udc_driver = {
> > - .remove = __exit_p(fsl_udc_remove),
> > + .remove = __exit_p(fsl_udc_remove),
> > + /* Just for FSL i.mx SoC currently */
> > + .id_table = fsl_udc_devtype,
> > /* these suspend and resume are not usb suspend and resume */
> > - .suspend = fsl_udc_suspend,
> > - .resume = fsl_udc_resume,
> > - .driver = {
> > - .name = (char *)driver_name,
> > - .owner = THIS_MODULE,
> > - /* udc suspend/resume called from OTG driver */
> > - .suspend = fsl_udc_otg_suspend,
> > - .resume = fsl_udc_otg_resume,
> > + .suspend= fsl_udc_suspend,
> > + .resume = fsl_udc_resume,
> > + .driver = {
> > + .name = (char *)driver_name,
> > + .owner = THIS_MODULE,
> > + /* udc suspend/resume called from OTG driver */
> > + .suspend = fsl_udc_otg_suspend,
> > + .resume = fsl_udc_otg_resume,
> > },
> > };
> >
> > diff --git a/drivers/usb/gadget/fsl_usb2_udc.h
> > b/drivers/usb/gadget/fsl_usb2_udc.h
> > index f61a967..bc1f6d0 100644
> > --- a/drivers/usb/gadget/fsl_usb2_udc.h
> > +++ b/drivers/usb/gadget/fsl_usb2_udc.h
> > @@ -505,6 +505,8 @@ struct fsl_udc {
> > u32 ep0_dir;/* Endpoint zero direction: can be
> >USB_DIR_IN or USB_DIR_OUT */
> > u8 device_address; /* Device USB address */
> > + /* devtype for kinds of SoC, only i.mx uses it now */
> > + enum fsl_udc_type devtype;
>
> to me this looks wrong as it will grow forever. Are you sure you don't
> have a way to detect the revision in runtime ?
>
> BTW, it looks to me that, in order to remove cpu_is_*() from that
> driver, all you have to do is:
>
> diff --git a/drivers/usb/gadget/fsl_mxc_udc.c
> b/drivers/usb/gadget/fsl_mxc_udc.c
> index 1b0f086..f06102d 100644
> --- a/drivers/usb/gadget/fsl_mxc_udc.c
> +++ b/drivers/usb/gadget/fsl_mxc_udc.c
> @@ -18,8 +18,6 @@
> #include
> #include
>
> -#include
> -
> static struct clk *mxc_ahb_clk;
> static struct clk *mxc_per_clk;
> static struct clk *mxc_ipg_clk;
> @@ -59,14 +57,12 @@ int fsl_udc_clk_init(struct platform_device *pdev)
> clk_prepare_enable(mxc_per_clk);
>
> /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> - if (!cpu_is_mx51()) {
> - freq = clk_get_rate(mxc_per_clk);
> - if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
> - (freq < 5000 || freq > 60001000)) {
> - dev_err(&pdev->dev, "USB_CLK=%lu, should be 60MHz\n",
> freq);
> - ret = -EINVAL;
> - goto eclkrate;
> - }
> + freq = clk_get_rate(mxc_per_clk);
> + if (pdata->phy_mode != FSL_USB2_PHY_ULPI &&
> + (freq < 5000 || freq > 60001000)) {
> + dev_err(&pdev->dev, "USB_CLK=%lu, should be 60MHz\n", freq);
> + ret = -EINVAL;
> + goto eclkrate;
> }
For mx51, the otg port, the pdata->phy_mode is FSL_USB2_PHY_UTMI_WIDE,
the freq of "per_clk" is 16625. So, your patch does not work.
>
> return 0;
> @@ -82,17 +78,15 @@ eclkrate:
> void fsl_udc_clk_finalize(struct platform_device *pdev)
> {
> struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
> - if (cpu_is_mx35()) {
> - unsigned int v;
> + unsigned int v;
>
> - /* workaround ENGcm09152 for i.MX35 */
> - if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
> - v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
> + /* workaround ENGcm09152 for i.MX35 */
> + if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
> + v = readl(MX35_IO_ADDRESS(MX35_USB_BASE_ADDR +
>
[GIT PATCH] USB patches for 3.8-rc3
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.8-rc3 for you to fetch changes up to 8cf65dc386f3634a43312f436cc7a935476a40c4: usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added (2013-01-13 13:44:23 -0800) USB fixes for 3.8-rc3 Here are a bunch of USB fixes for your 3.8-rc3 tree. They all either fix problems that have been reported (like the xhci/hub changes) or add new device ids to existing drivers. Signed-off-by: Greg Kroah-Hartman Afzal Mohammed (1): usb: musb: dsps: header movement build error fix Alan Stern (1): USB: usbtest: fix test number in log message Anatolij Gustschin (3): USB: fix fsl_otg config dependency USB: fsl-mph-dr-of: fix regression on mpc5121e USB: ehci-fsl: fix regression on mpc5121e Andreas Fleig (1): USB: Add device quirk for Microsoft VX700 webcam Bjørn Mork (2): USB: option: blacklist network interface on ZTE MF880 USB: option: add Telekom Speedstick LTE II Chao Xie (3): usb: gadget: mv_udc: fix the clk APIs usb: host: ehci-mv: fix clk APIs usb: otg: mv_otg: fix the clk APIs Denis N Ladin (1): USB: cdc-acm: Add support for "PSC Scanning, Magellan 800i" Dzianis Kahanovich (1): USB: option: add Nexpring NP10T terminal id Fabio Estevam (2): usb: imx21-hcd: Include missing linux/module.h usb: chipidea: Allow disabling streaming not only in udc mode Felipe Balbi (1): usb: host: ohci-tmio: fix compile warning Greg Kroah-Hartman (2): Merge tag 'fixes-for-v3.8-rc2' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'for-usb-linus-2013-01-03' of git://git.kernel.org/.../sarah/xhci into usb-linus Haipeng YU (1): usb: gadget: u_serial: fix switch off blocked Jack Pham (1): usb: dwc3: debugfs: fix regdump offset Jan Beulich (1): USB: ehci: make debug port in-use detection functional again Kuninori Morimoto (3): usb: renesas_usbhs: gadget: remove usbhsg_uep_init() usb: renesas_usbhs: gadget: usbhsg_ep_disable() care pipe settings usb: renesas_usbhs: mod_host: fixup usbhsh_ureq_free() timing Maxime Ripard (1): USB: select USB_ARCH_HAS_EHCI for MXS Oliver Neukum (1): USB: hub: handle claim of enabled remote wakeup after reset Quentin.Li (1): USB: option: Add new MEDIATEK PID support Sarah Sharp (8): xhci: Handle HS bulk/ctrl endpoints that don't NAK. USB: Handle auto-transition from hot to warm reset. USB: Ignore xHCI Reset Device status. USB: Allow USB 3.0 ports to be disabled. USB: Increase reset timeout. USB: Ignore port state until reset completes. USB: Handle warm reset failure on empty port. xhci: Avoid "dead ports", add roothub port polling. Sebastian Andrzej Siewior (1): usb: gadget: dummy: fix enumeration with g_multi Sergei Shtylyov (1): usb: musb: core: print new line in the driver banner again Tomasz Mloduchowski (1): usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added Tushar Behera (1): usb: gadget: s3c-hsotg: Fix invalid free of devm_ allocated data Wei Yongjun (1): usb: gadget: tcm_usb_gadge: fix to return error or 0 in tcm_usbg_drop_nexus() Xi Wang (1): usb: gadget: amd5536udc: avoid NULL pointer dereference in udc_pci_probe() drivers/usb/Kconfig| 1 + drivers/usb/chipidea/host.c| 3 + drivers/usb/class/cdc-acm.c| 3 + drivers/usb/core/hub.c | 120 ++--- drivers/usb/core/quirks.c | 3 + drivers/usb/dwc3/debugfs.c | 2 +- drivers/usb/gadget/amd5536udc.c| 4 +- drivers/usb/gadget/dummy_hcd.c | 9 +-- drivers/usb/gadget/mv_udc_core.c | 4 +- drivers/usb/gadget/s3c-hsotg.c | 5 +- drivers/usb/gadget/tcm_usb_gadget.c| 3 +- drivers/usb/gadget/u_serial.c | 2 +- drivers/usb/host/ehci-fsl.c| 9 +-- drivers/usb/host/ehci-mv.c | 4 +- drivers/usb/host/ehci-pci.c| 39 +-- drivers/usb/host/fsl-mph-dr-of.c | 3 + drivers/usb/host/imx21-hcd.c | 1 + drivers/usb/host/ohci-tmio.c | 3 +- drivers/usb/host/xhci-hub.c| 38 ++- drivers/usb/host/xhci-mem.c| 2 + drivers/usb/host/xhci-ring.c | 9 +++ drivers/usb/host/xhci.c| 10 +++ drivers/usb/misc/usbtest.c | 2 +- drivers/usb/musb/musb_core.c | 5 +- drivers/usb/musb/musb_dsps.c | 5 ++ drivers/usb/otg/Kconfig| 2 +- drivers/usb/otg/mv_otg.
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Hi Doug,
On Sat, Jan 12, 2013 at 6:20 AM, Doug Anderson wrote:
> Vivek,
>
> On Fri, Jan 11, 2013 at 4:40 AM, Vivek Gautam
> wrote:
+#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
+#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 << 19)
+#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 << 19)
+#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 << 19)
+
+#define HOST_CTRL0_FSEL_MASK (0x7 << 16)
+#define HOST_CTRL0_FSEL(_x)((_x) << 16)
+#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7)
+#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5)
+#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4)
+#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3)
+#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2)
+#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1)
+#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0)
>>>
>>> Add the shifts to the #defines and remove HOST_CTRL0_FSEL(_x). That
>>> makes it match the older phy more closely.
>>>
>> Wouldn't it hamper the readability when shifts are used ??
>> I mean if we have something like this -
>>
>> phyhost |= HOST_CTRL0_FSEL(phyclk)
>>
>> so, if we are using the shifts then
>> phyhost |= (HOST_CTRL0_FSEL_CLKSEL_24M << HOST_CTRL0_FSEL_SHIFT)
>
> I was actually suggesting modifying the #defines like this:
>
> #define HOST_CTRL0_FSEL_SHIFT 16
> #define HOST_CTRL0_FSEL_MASK (0x7 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_50M (0x7 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_24M (0x5 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_20M (0x4 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_12M (0x2 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_10M (0x1 << HOST_CTRL0_FSEL_SHIFT)
> #define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 << HOST_CTRL0_FSEL_SHIFT)
>
> ...then the code doesn't need to think about shifts, right?
>
right right, sorry i din't get your point earlier. :-(
this way things will be similar in samsung_usbphy_get_refclk_freq()
across exynos 5 and older SoCs.
Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it.
Can we just do like this ..
#define HOST_CTRL0_FSEL_MASK (0x7 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_50M(0x7 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_24M(0x5 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_20M(0x4 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_12M(0x2 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_10M(0x1 << 16)
#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 << 16)
>
if (IS_ERR(ref_clk)) {
dev_err(sphy->dev, "Failed to get reference clock\n");
return PTR_ERR(ref_clk);
}
- switch (clk_get_rate(ref_clk)) {
- case 12 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_24M;
- break;
- case 48 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_48M;
- break;
- default:
- if (sphy->cpu_type == TYPE_S3C64XX)
- refclk_freq = PHYCLK_CLKSEL_48M;
- else
+ if (sphy->cpu_type == TYPE_EXYNOS5250) {
+ /* set clock frequency for PLL */
+ switch (clk_get_rate(ref_clk)) {
+ case 96 * 10:
>>>
>>> nit: change to 9600 * KHZ to match; below too.
>>>
>> sure.
>>
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_9600K;
>>>
>>> Why |= with 0?
>>>
>> kept this just to keep things look similar :-). will remove this line,
>
> My comment was about keeping things similar. Right now the 5250 code
> has the |= and the non-5250 code doesn't. I don't care which is
> picked but the two sides of the "if" should be symmetric.
>
True, it's good to maintain symmetry in the code.
I shall amend the code as suggested.
> See parts of the patch below.
>
+ break;
+ case 10 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_10M;
+ break;
+ case 12 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_12M;
+ break;
+ case 192 * 10:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_19200K;
+ break;
+ case 20 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_20M;
+ break;
+
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Mon, Jan 14, 2013 at 11:47 AM, Ming Lei wrote: > On Mon, Jan 14, 2013 at 1:42 AM, Alex Riesen wrote: > [ 86.901367] io scheduler deadline registered (default) > [ 181.168487] INFO: task modprobe:2462 blocked for more than 90 seconds. > [ 181.175323] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 181.183624] modprobeD c04f1920 0 2462 2461 0x > [ 181.183685] [] (__schedule+0x5fc/0x6d4) from [] > (async_synchronize_cookie_domain+0xdc/0x168) > [ 181.183715] [] (async_synchronize_cookie_domain+0xdc/0x168) from > [] (async_synchronize_full+0x3c/0x60) > [ 181.183776] [] (async_synchronize_full+0x3c/0x60) from > [] (load_module+0x1aac/0x1cdc) > [ 181.183807] [] (load_module+0x1aac/0x1cdc) from [] > (sys_init_module+0x104/0x110) > [ 181.183837] [] (sys_init_module+0x104/0x110) from > [] (ret_fast_syscall+0x0/0x48) The deadlock problem is caused by calling request_module() inside async function of do_scan_async(), and it was introduced by Linus's below commit: commit d6de2c80e9d758d2e36c21699117db6178c0f517 Author: Linus Torvalds Date: Fri Apr 10 12:17:41 2009 -0700 async: Fix module loading async-work regression IMO, maybe the commit isn't a proper fix, considered the below fact: - it isn't good to allow async function to be marked as __init - any user mode shouldn't expect that the device is ready just after completing of 'insmod', and drivers should make the device ready for user mode just after its async probing or other kind of async initialization(done in work or kthread) completes. - from view of driver, introducing async_synchronize_full() after do_one_initcall() inside do_init_module() is like a sync probe for drivers built as module, and cause this kind of deadlock easily. So could we revert the commit and fix the previous problems just case by case? or other better fix? Thanks, -- Ming Lei -- 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 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
It changes the driver to use platform_device_id rather than cpu_is_xxx to determine the SoC type, and updates the platform code accordingly. Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable. Tested at mx51 bbg board, it works ok after enable phy clock (Need another patch to fix this problem) Signed-off-by: Peter Chen --- Changes for v2: - Add const for fsl_udc_devtype - Do ioremap for phy address at fsl-mxc-udc arch/arm/mach-imx/clk-imx25.c |6 +- arch/arm/mach-imx/clk-imx27.c |6 +- arch/arm/mach-imx/clk-imx31.c |6 +- arch/arm/mach-imx/clk-imx35.c |6 +- arch/arm/mach-imx/clk-imx51-imx53.c |6 +- arch/arm/mach-imx/devices/devices-common.h|1 + arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++--- drivers/usb/gadget/fsl_mxc_udc.c | 23 + drivers/usb/gadget/fsl_udc_core.c | 52 +--- drivers/usb/gadget/fsl_usb2_udc.h | 13 -- include/linux/fsl_devices.h |8 +++ 11 files changed, 87 insertions(+), 55 deletions(-) diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c index b197aa7..67e353d 100644 --- a/arch/arm/mach-imx/clk-imx25.c +++ b/arch/arm/mach-imx/clk-imx25.c @@ -254,9 +254,9 @@ int __init mx25_clocks_init(void) clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2"); clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); - clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx25"); + clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx25"); + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx25"); clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0"); /* i.mx25 has the i.mx35 type cspi */ clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0"); diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 4c1d1e4..1ffe3b5 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0"); clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0"); clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0"); - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc"); + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27"); + clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27"); + clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27"); clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0"); clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0"); clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0"); diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c index 8be64e0..ef66eaf 100644 --- a/arch/arm/mach-imx/clk-imx31.c +++ b/arch/arm/mach-imx/clk-imx31.c @@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref) clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2"); clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2"); clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); - clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc"); - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); + clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx31"); + clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx31"); + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx31"); clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0"); /* i.mx31 has the i.mx21 type uart */ clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0"); diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c index 66f3d65..69fe9c8 100644 --- a/arch/arm/mach-imx/clk-imx35.c +++ b/arch/arm/mach-imx/clk-imx35.c @@ -251,9 +251,9 @@ int __init mx35_clocks_init() clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2"); - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); - clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc"); + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx35"); + clk_register_clkdev(
Re: [PATCH v2 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
Hi, On Mon, Jan 14, 2013 at 03:18:17PM +0800, Peter Chen wrote: > It changes the driver to use platform_device_id rather than cpu_is_xxx > to determine the SoC type, and updates the platform code accordingly. > > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable. > Tested at mx51 bbg board, it works ok after enable phy clock > (Need another patch to fix this problem) > > Signed-off-by: Peter Chen not good for -rc. You have to break this down as you're solving at least three different problems with this patch. Besides there are parts which are not related to the build break. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
On Mon, Jan 14, 2013 at 09:12:43AM +0800, Shawn Guo wrote: > Balbi, > > On Fri, Jan 11, 2013 at 02:50:59PM +0200, Felipe Balbi wrote: > > As I said before, this patch is too big for -rc and is unnecessary > > considering patch I wrote above. Note that there is no problems in > > checking if ULPI PHY clk is 60MHz on all arches and, for the workaround, > > you already have a runtime check. > > > Ok, I did not have these facts on my mind. If these are true, the > cpu_is_xxx() shouldn't be necessary there from the beginning, and we > can simply remove them then. > > > Shawn, it can be broken down into smaller pieces because you can *FIX > > THE COMPILE BREAKAGE* with a very small patch as above (only issue now > > is usage of MX32_IO_ADDRESS()). > > > The MX35_IO_ADDRESS() also seems unnecessary, since as Peter's patch > suggested that pdata->regs can be used instead. pdata->regs is a hack. The 'canonical' way to pass addresses to drivers is via struct resource. -- balbi signature.asc Description: Digital signature
Re: [PATCH RFC] usb: dwc3: Remove dwc3 dependency on gadget.
On Fri, Jan 11, 2013 at 07:58:23PM +0530, Vivek Gautam wrote:
> Hi,
>
>
> On Fri, Jan 11, 2013 at 7:29 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Jan 11, 2013 at 07:13:55PM +0530, Vivek Gautam wrote:
> >> On Thu, Jan 10, 2013 at 6:32 PM, Felipe Balbi wrote:
> >> > Hi,
> >> >
> >> > On Mon, Dec 24, 2012 at 07:28:33PM +0530, Vivek Gautam wrote:
> >> >> DWC3 controller curretly depends on CONFIG_USB and CONFIG_USB_GADGET.
> >> >> Some hardware may like to use only host feature on dwc3.
> >> >> So, removing the dependency of USB_DWC3 on USB_GADGET
> >> >> and further modulating the dwc3 core to enable gadget features
> >> >> only with USB_GADGET.
> >> >>
> >> >> Signed-off-by: Vivek Gautam
> >> >> CC: Doug Anderson
> >> >
> >> > right, right... Eventually we need to do it, but you're only making
> >> > gadget side optional. Host side should be optional too, but then you
> >> > need to make sure we don't build dwc3 without gadget and host.
> >> >
> >>
> >> Yes, true we need to make host side also optional, build dwc3 only when
> >> either of host or gadget are built.
> >
> > btw, make the default Dual-Role, if user/defconfig doesn't select
> > anything we want to build with all features.
> >
>
> Yes we can try something like this ?
>
> if (USB || USB_GADGET)
no need for this if, actually...
> menuconfig USB_DWC3
> tristate "DesignWare USB3 DRD Core Support"
make it a "depends on (USB || USB_GAGDGET)" here
other than that, it looks correct. Just make sure to compile test in all
options.
> if USB_DWC3
> choice
> default USB_DWC3_DUAL_ROLE_MODE
> ...
>
> config USB_DWC3_HOST_MODE
this one should depend on USB
> ...
>
> config USB_DWC3_DEVICE_MODE
this one should depend on USB_GADGET
> ...
>
> config USB_DWC3_DUAL_ROLE_MODE
should depend on USB && USB_GADGET
> >> >> int dwc3_gadget_init(struct dwc3 *dwc);
> >> >> void dwc3_gadget_exit(struct dwc3 *dwc);
> >> >> +#else
> >> >> +static inline int dwc3_gadget_init(struct dwc3 *dwc)
> >> >> +{ return -EINVAL; }
> >> >> +static inline void dwc3_gadget_exit(struct dwc3 *dwc)
> >> >> +{ }
> >> >> +#endif
> >> >>
> >> >> #endif /* __DRIVERS_USB_DWC3_CORE_H */
> >> >> diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> >> >> index d4a30f1..553bbaa 100644
> >> >> --- a/drivers/usb/dwc3/debugfs.c
> >> >> +++ b/drivers/usb/dwc3/debugfs.c
> >> >> @@ -535,7 +535,8 @@ static ssize_t dwc3_testmode_write(struct file
> >> >> *file,
> >> >> testmode = 0;
> >> >>
> >> >> spin_lock_irqsave(&dwc->lock, flags);
> >> >> - dwc3_gadget_set_test_mode(dwc, testmode);
> >> >> + if (dwc3_gadget_set_test_mode(dwc, testmode))
> >> >> + dev_dbg(dwc->dev, "host: Invalid request\n");
> >> >> spin_unlock_irqrestore(&dwc->lock, flags);
> >> >>
> >> >> return count;
> >> >
> >> > wrong, if you don't have gadget mode, you just don't create this file.
> >> >
> >>
> >> dwc3-core makes call to dwc3_debugfs_init() invariably depending on
> >> DEBUG_FS.
> >> Will this not go ahead and create this file ?
> >> I think i am missing here something. :-(
> >
> > right, you can change dwc3_debugfs_init() to take into account the fact
> > that you're a gadget/drd or host-only.
> >
> > In case of host only, you stil want regdump to be available :-)
> >
>
> So in dwc3_debugfs_init() we shall actually create just 'regdump' file
> in case of host only mode, otherwise keep the dwc3_debugfs_init() happy
> with creating other files too.
> Right ?
right.
--
balbi
signature.asc
Description: Digital signature
