<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/usb/serial, branch v3.4.2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console</title>
<updated>2012-06-01T07:18:22+00:00</updated>
<author>
<name>Darren Hart</name>
<email>dvhart@linux.intel.com</email>
</author>
<published>2012-05-11T20:56:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3c8e06de9d7d35461601d987605d091d3c817fba'/>
<id>3c8e06de9d7d35461601d987605d091d3c817fba</id>
<content type='text'>
commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.

The Kontron M2M development board, also known as the Fish River Island II,
has an optional daughter card providing access to the PCH_UART (EG20T) via
a ti_usb_3410_5052 uart to usb chip.

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
CC: Al Borchers &lt;alborchers@steinerpoint.com&gt;
CC: Peter Berger &lt;pberger@brimson.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.

The Kontron M2M development board, also known as the Fish River Island II,
has an optional daughter card providing access to the PCH_UART (EG20T) via
a ti_usb_3410_5052 uart to usb chip.

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
CC: Al Borchers &lt;alborchers@steinerpoint.com&gt;
CC: Peter Berger &lt;pberger@brimson.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb-serial: ftdi_sio: fix oops during autosuspend</title>
<updated>2012-06-01T07:18:20+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-05-07T15:20:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2aa5c3521c154db6e3bbbda1a2f0b07da4938626'/>
<id>2aa5c3521c154db6e3bbbda1a2f0b07da4938626</id>
<content type='text'>
commit 5cbe61c5aff0a8ada691eb8b07dbfb55c303f640 upstream.

This patch (as1550) fixes a bug in the usb-serial core that affects
the ftdi_sio driver and most likely others as well.  The core
implements suspend and resume routines, but it doesn't store pointers
to those routines in the usb_driver structures that it registers,
even though it does set those drivers' supports_autosuspend flag.  The
end result is that when one of these devices is autosuspended, we try
to call through a NULL pointer.

The patch fixes the problem by setting the suspend and resume method
pointers to the appropriate routines in the USB serial core, along
with the supports_autosuspend field, in each driver as it is
registered.

This should be back-ported to all the stable kernels that have the new
usb_serial_register_drivers() interface.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Frank Schäfer &lt;schaefer.frank@gmx.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5cbe61c5aff0a8ada691eb8b07dbfb55c303f640 upstream.

This patch (as1550) fixes a bug in the usb-serial core that affects
the ftdi_sio driver and most likely others as well.  The core
implements suspend and resume routines, but it doesn't store pointers
to those routines in the usb_driver structures that it registers,
even though it does set those drivers' supports_autosuspend flag.  The
end result is that when one of these devices is autosuspended, we try
to call through a NULL pointer.

The patch fixes the problem by setting the suspend and resume method
pointers to the appropriate routines in the USB serial core, along
with the supports_autosuspend field, in each driver as it is
registered.

This should be back-ported to all the stable kernels that have the new
usb_serial_register_drivers() interface.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Frank Schäfer &lt;schaefer.frank@gmx.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: ftdi-sio: add support for Physik Instrumente E-861</title>
<updated>2012-06-01T07:18:20+00:00</updated>
<author>
<name>Éric Piel</name>
<email>piel@delmic.com</email>
</author>
<published>2012-05-07T10:37:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=27234cee48f54e3f3125e44bc8b05c42b977a113'/>
<id>27234cee48f54e3f3125e44bc8b05c42b977a113</id>
<content type='text'>
commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.

This adds VID/PID for the PI E-861. Without it, I had to do:
modprobe -q ftdi-sio product=0x1008 vendor=0x1a72

http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610

Signed-off-by: Éric Piel &lt;piel@delmic.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.

This adds VID/PID for the PI E-861. Without it, I had to do:
modprobe -q ftdi-sio product=0x1008 vendor=0x1a72

http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610

Signed-off-by: Éric Piel &lt;piel@delmic.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: serial: cp210x: Fixed usb_control_msg timeout values</title>
<updated>2012-04-20T15:44:24+00:00</updated>
<author>
<name>Yuri Matylitski</name>
<email>ym@tekinsoft.com</email>
</author>
<published>2012-04-20T09:38:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2d5733fcd33dd451022d197cb6b476e970519ca7'/>
<id>2d5733fcd33dd451022d197cb6b476e970519ca7</id>
<content type='text'>
Fixed too small hardcoded timeout values for usb_control_msg
in driver for SiliconLabs cp210x-based usb-to-serial adapters.
Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT.

Signed-off-by: Yuri Matylitski &lt;ym@tekinsoft.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill@shutemov.name&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixed too small hardcoded timeout values for usb_control_msg
in driver for SiliconLabs cp210x-based usb-to-serial adapters.
Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT.

Signed-off-by: Yuri Matylitski &lt;ym@tekinsoft.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill@shutemov.name&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: sierra: avoid QMI/wwan interface on MC77xx</title>
<updated>2012-04-17T22:54:57+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2012-04-17T19:37:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=749541d19e70905e3971f2a08335a206a98e4d0c'/>
<id>749541d19e70905e3971f2a08335a206a98e4d0c</id>
<content type='text'>
These devices have a number of non serial interfaces as well.  Use
the existing "Direct IP" blacklist to prevent binding to interfaces
which are handled by other drivers.

We also extend the "Direct IP" blacklist with with interfaces only
seen in "QMI" mode, assuming that these devices use the same
interface numbers for serial interfaces both in "Direct IP" and in
"QMI" mode.

Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These devices have a number of non serial interfaces as well.  Use
the existing "Direct IP" blacklist to prevent binding to interfaces
which are handled by other drivers.

We also extend the "Direct IP" blacklist with with interfaces only
seen in "QMI" mode, assuming that these devices use the same
interface numbers for serial interfaces both in "Direct IP" and in
"QMI" mode.

Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: serial: fix race between probe and open</title>
<updated>2012-04-10T20:35:53+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2012-03-20T15:59:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a65a6f14dc24a90bde3f5d0073ba2364476200bf'/>
<id>a65a6f14dc24a90bde3f5d0073ba2364476200bf</id>
<content type='text'>
Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.

A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.

With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:

[  199.698286] IP: [&lt;f811a089&gt;] ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698297] *pde = 00000000
[  199.698303] Oops: 0000 [#1] PREEMPT SMP
[  199.698313] Modules linked in: ftdi_sio usbserial
[  199.698323]
[  199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[  199.698339] EIP: 0060:[&lt;f811a089&gt;] EFLAGS: 00010286 CPU: 0
[  199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698348] EAX: 0000003e EBX: f5067000 ECX: 00000000 EDX: 80000600
[  199.698352] ESI: f48d8800 EDI: 00000001 EBP: f515dd54 ESP: f515dcfc
[  199.698356]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  199.698361] Process ftdi_open (pid: 1146, ti=f515c000 task=f481e040 task.ti=f515c000)
[  199.698364] Stack:
[  199.698368]  f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[  199.698387]  00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[  199.698479]  22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[  199.698496] Call Trace:
[  199.698504]  [&lt;f806e68e&gt;] ? serial_activate+0x2e/0x70 [usbserial]
[  199.698511]  [&lt;f806e6ab&gt;] serial_activate+0x4b/0x70 [usbserial]
[  199.698521]  [&lt;c126380c&gt;] tty_port_open+0x7c/0xd0
[  199.698527]  [&lt;f806e660&gt;] ? serial_set_termios+0xa0/0xa0 [usbserial]
[  199.698534]  [&lt;f806e76f&gt;] serial_open+0x2f/0x70 [usbserial]
[  199.698540]  [&lt;c125d07c&gt;] tty_open+0x20c/0x510
[  199.698546]  [&lt;c10e9eb7&gt;] chrdev_open+0xe7/0x230
[  199.698553]  [&lt;c10e48f2&gt;] __dentry_open+0x1f2/0x390
[  199.698559]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698565]  [&lt;c10e4b76&gt;] nameidata_to_filp+0x66/0x80
[  199.698570]  [&lt;c10e9dd0&gt;] ? cdev_put+0x20/0x20
[  199.698576]  [&lt;c10f3e08&gt;] do_last+0x198/0x730
[  199.698581]  [&lt;c10f4440&gt;] path_openat+0xa0/0x350
[  199.698587]  [&lt;c10f47d5&gt;] do_filp_open+0x35/0x80
[  199.698593]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698599]  [&lt;c10ff110&gt;] ? alloc_fd+0xc0/0x100
[  199.698605]  [&lt;c10f0b72&gt;] ? getname_flags+0x72/0x120
[  199.698611]  [&lt;c10e4450&gt;] do_sys_open+0xf0/0x1c0
[  199.698617]  [&lt;c11fcc08&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
[  199.698623]  [&lt;c10e458e&gt;] sys_open+0x2e/0x40
[  199.698628]  [&lt;c144c990&gt;] sysenter_do_call+0x12/0x36
[  199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 &lt;0f&gt; b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[  199.698884] EIP: [&lt;f811a089&gt;] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:f515dcfc
[  199.698893] CR2: 0000000000000078
[  199.698925] ---[ end trace 77c43ec023940cff ]---

Reported-and-tested-by: Ken Huang &lt;csuhgw@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.

A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.

With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:

[  199.698286] IP: [&lt;f811a089&gt;] ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698297] *pde = 00000000
[  199.698303] Oops: 0000 [#1] PREEMPT SMP
[  199.698313] Modules linked in: ftdi_sio usbserial
[  199.698323]
[  199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[  199.698339] EIP: 0060:[&lt;f811a089&gt;] EFLAGS: 00010286 CPU: 0
[  199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[  199.698348] EAX: 0000003e EBX: f5067000 ECX: 00000000 EDX: 80000600
[  199.698352] ESI: f48d8800 EDI: 00000001 EBP: f515dd54 ESP: f515dcfc
[  199.698356]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  199.698361] Process ftdi_open (pid: 1146, ti=f515c000 task=f481e040 task.ti=f515c000)
[  199.698364] Stack:
[  199.698368]  f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[  199.698387]  00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[  199.698479]  22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[  199.698496] Call Trace:
[  199.698504]  [&lt;f806e68e&gt;] ? serial_activate+0x2e/0x70 [usbserial]
[  199.698511]  [&lt;f806e6ab&gt;] serial_activate+0x4b/0x70 [usbserial]
[  199.698521]  [&lt;c126380c&gt;] tty_port_open+0x7c/0xd0
[  199.698527]  [&lt;f806e660&gt;] ? serial_set_termios+0xa0/0xa0 [usbserial]
[  199.698534]  [&lt;f806e76f&gt;] serial_open+0x2f/0x70 [usbserial]
[  199.698540]  [&lt;c125d07c&gt;] tty_open+0x20c/0x510
[  199.698546]  [&lt;c10e9eb7&gt;] chrdev_open+0xe7/0x230
[  199.698553]  [&lt;c10e48f2&gt;] __dentry_open+0x1f2/0x390
[  199.698559]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698565]  [&lt;c10e4b76&gt;] nameidata_to_filp+0x66/0x80
[  199.698570]  [&lt;c10e9dd0&gt;] ? cdev_put+0x20/0x20
[  199.698576]  [&lt;c10f3e08&gt;] do_last+0x198/0x730
[  199.698581]  [&lt;c10f4440&gt;] path_openat+0xa0/0x350
[  199.698587]  [&lt;c10f47d5&gt;] do_filp_open+0x35/0x80
[  199.698593]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698599]  [&lt;c10ff110&gt;] ? alloc_fd+0xc0/0x100
[  199.698605]  [&lt;c10f0b72&gt;] ? getname_flags+0x72/0x120
[  199.698611]  [&lt;c10e4450&gt;] do_sys_open+0xf0/0x1c0
[  199.698617]  [&lt;c11fcc08&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
[  199.698623]  [&lt;c10e458e&gt;] sys_open+0x2e/0x40
[  199.698628]  [&lt;c144c990&gt;] sysenter_do_call+0x12/0x36
[  199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 &lt;0f&gt; b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[  199.698884] EIP: [&lt;f811a089&gt;] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:f515dcfc
[  199.698893] CR2: 0000000000000078
[  199.698925] ---[ end trace 77c43ec023940cff ]---

Reported-and-tested-by: Ken Huang &lt;csuhgw@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: sierra: add support for Sierra Wireless MC7710</title>
<updated>2012-04-09T22:42:25+00:00</updated>
<author>
<name>Anton Samokhvalov</name>
<email>pg83@yandex.ru</email>
</author>
<published>2012-04-04T18:26:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c5d703dcc776cb542b41665f2b7e2ba054efb4a7'/>
<id>c5d703dcc776cb542b41665f2b7e2ba054efb4a7</id>
<content type='text'>
Just add new device id. 3G works fine, LTE not tested.

Signed-off-by: Anton Samokhvalov &lt;pg83@yandex.ru&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Just add new device id. 3G works fine, LTE not tested.

Signed-off-by: Anton Samokhvalov &lt;pg83@yandex.ru&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort of TIOCMIWAIT when the device is removed</title>
<updated>2012-04-09T22:41:40+00:00</updated>
<author>
<name>Simon Arlott</name>
<email>simon@fire.lp0.eu</email>
</author>
<published>2012-03-26T22:27:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=876ae50d94b02f3f523aa451b45ec5fb9c25d221'/>
<id>876ae50d94b02f3f523aa451b45ec5fb9c25d221</id>
<content type='text'>
There are two issues here, one is that the device is generating
spurious very fast modem status line changes somewhere:

CTS becomes high then low 18µs later:
[121226.924373] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=6
[121226.924378] ftdi_process_packet: status=10 prev=00 diff=10
[121226.924382] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=7
(wake_up_interruptible is called)
[121226.924391] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=7
[121226.924394] ftdi_process_packet: status=00 prev=10 diff=10
[121226.924397] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=8
(wake_up_interruptible is called)

This wakes up the task in TIOCMIWAIT:
[121226.924405] ftdi_ioctl: 19451 rng=0-&gt;0 dsr=10-&gt;10 dcd=0-&gt;0 cts=6-&gt;8
(wait from 20:51:46 returns and observes both changes)

Which then calls TIOCMIWAIT again:
20:51:46.400239 ioctl(3, TIOCMIWAIT, 0x20) = 0
22:11:09.441818 ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
22:11:09.442812 ioctl(3, TIOCMIWAIT, 0x20) = -1 EIO (Input/output error)
(the second wake_up_interruptible takes effect and an I/O error occurs)

The other issue is that TIOCMIWAIT will wait forever (unless the task is
interrupted) if the device is removed.

This change removes the -EIO return that occurs if the counts don't
appear to have changed. Multiple counts may have been processed as
one or the waiting task may have started waiting after recording the
current count.

It adds a bool to indicate that the device has been removed so that
TIOCMIWAIT doesn't wait forever, and wakes up any tasks so that they can
return -EIO.

Signed-off-by: Simon Arlott &lt;simon@fire.lp0.eu&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are two issues here, one is that the device is generating
spurious very fast modem status line changes somewhere:

CTS becomes high then low 18µs later:
[121226.924373] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=6
[121226.924378] ftdi_process_packet: status=10 prev=00 diff=10
[121226.924382] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=7
(wake_up_interruptible is called)
[121226.924391] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=7
[121226.924394] ftdi_process_packet: status=00 prev=10 diff=10
[121226.924397] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=8
(wake_up_interruptible is called)

This wakes up the task in TIOCMIWAIT:
[121226.924405] ftdi_ioctl: 19451 rng=0-&gt;0 dsr=10-&gt;10 dcd=0-&gt;0 cts=6-&gt;8
(wait from 20:51:46 returns and observes both changes)

Which then calls TIOCMIWAIT again:
20:51:46.400239 ioctl(3, TIOCMIWAIT, 0x20) = 0
22:11:09.441818 ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
22:11:09.442812 ioctl(3, TIOCMIWAIT, 0x20) = -1 EIO (Input/output error)
(the second wake_up_interruptible takes effect and an I/O error occurs)

The other issue is that TIOCMIWAIT will wait forever (unless the task is
interrupted) if the device is removed.

This change removes the -EIO return that occurs if the counts don't
appear to have changed. Multiple counts may have been processed as
one or the waiting task may have started waiting after recording the
current count.

It adds a bool to indicate that the device has been removed so that
TIOCMIWAIT doesn't wait forever, and wakes up any tasks so that they can
return -EIO.

Signed-off-by: Simon Arlott &lt;simon@fire.lp0.eu&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: ftdi_sio: fix status line change handling for TIOCMIWAIT and TIOCGICOUNT</title>
<updated>2012-04-09T22:41:16+00:00</updated>
<author>
<name>Simon Arlott</name>
<email>simon@fire.lp0.eu</email>
</author>
<published>2012-03-26T20:19:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fca5430d48d53eaf103498c33fd0d1984b9f448b'/>
<id>fca5430d48d53eaf103498c33fd0d1984b9f448b</id>
<content type='text'>
Handling of TIOCMIWAIT was changed by commit 1d749f9afa657f6ee9336b2bc1fcd750a647d157
 USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers

FTDI_STATUS_B0_MASK does not indicate the changed modem status lines,
it indicates the value of the current modem status lines. An xor is
still required to determine which lines have changed.

The count was only being incremented if the line was high. The only
reason TIOCMIWAIT still worked was because the status packet is
repeated every 1ms, so the count was always changing. The wakeup
itself still ran based on the status lines changing.

This change fixes handling of updates to the modem status lines and
allows multiple processes to use TIOCMIWAIT concurrently.

Tested with two processes waiting on different status lines being
toggled independently.

Signed-off-by: Simon Arlott &lt;simon@fire.lp0.eu&gt;
Cc: Uwe Bonnes &lt;bon@elektron.ikp.physik.tu-darmstadt.de&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Handling of TIOCMIWAIT was changed by commit 1d749f9afa657f6ee9336b2bc1fcd750a647d157
 USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers

FTDI_STATUS_B0_MASK does not indicate the changed modem status lines,
it indicates the value of the current modem status lines. An xor is
still required to determine which lines have changed.

The count was only being incremented if the line was high. The only
reason TIOCMIWAIT still worked was because the status packet is
repeated every 1ms, so the count was always changing. The wakeup
itself still ran based on the status lines changing.

This change fixes handling of updates to the modem status lines and
allows multiple processes to use TIOCMIWAIT concurrently.

Tested with two processes waiting on different status lines being
toggled independently.

Signed-off-by: Simon Arlott &lt;simon@fire.lp0.eu&gt;
Cc: Uwe Bonnes &lt;bon@elektron.ikp.physik.tu-darmstadt.de&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: fix bug in serial driver unregistration</title>
<updated>2012-04-09T22:36:20+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-03-28T20:10:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=891a3b1fddb24b4b53426685bd0390bb74c9b5b3'/>
<id>891a3b1fddb24b4b53426685bd0390bb74c9b5b3</id>
<content type='text'>
This patch (as1536) fixes a bug in the USB serial core.  Unloading and
reloading a serial driver while a serial device is plugged in causes
errors because of the code in usb_serial_disconnect() that tries to
make sure the port_remove method is called.  With the new order of
driver registration introduced in the 3.4 kernel, this is definitely
not the right thing to do (if indeed it ever was).

The patch removes that whole section code, along with the mechanism
for keeping track of each port's registration state, which is no
longer needed.  The driver core can handle all that stuff for us.

Note: This has been tested only with one or two USB serial drivers.
In theory, other drivers might still run into trouble.  But if they
do, it will be the fault of the drivers, not of this patch -- that is,
the drivers will need to be fixed.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch (as1536) fixes a bug in the USB serial core.  Unloading and
reloading a serial driver while a serial device is plugged in causes
errors because of the code in usb_serial_disconnect() that tries to
make sure the port_remove method is called.  With the new order of
driver registration introduced in the 3.4 kernel, this is definitely
not the right thing to do (if indeed it ever was).

The patch removes that whole section code, along with the mechanism
for keeping track of each port's registration state, which is no
longer needed.  The driver core can handle all that stuff for us.

Note: This has been tested only with one or two USB serial drivers.
In theory, other drivers might still run into trouble.  But if they
do, it will be the fault of the drivers, not of this patch -- that is,
the drivers will need to be fixed.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
