Commit Graph

11 Commits

Author SHA1 Message Date
Johan Hovold b0a9aa6da8 USB: usb_wwan: do not resume I/O on closing ports
Use tty-port initialised flag rather than private flag to determine when
port is closing down.

Since the tty-port flag is set prior to dropping DTR/RTS (when HUPCL is
set) this avoid submitting the read urbs when resuming the interface in
dtr_rts() only to immediately kill them again in shutdown().

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-27 15:04:08 -07:00
Johan Hovold 89da4a49b9 USB: usb_wwan: remove bogus function prototype
The usb_wwan_send_setup() function has never existed.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-27 15:04:08 -07:00
Johan Hovold a427c179de USB: usb_wwan: remove unimplemented set_termios
The driver does not implement set_termios so the operation can be left
unset (tty will do the tty_termios_copy_hw for us).

Note that the send_setup call is bogus as it really only sets DTR/RTS
to their current values.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-27 15:04:07 -07:00
Johan Hovold c1c0180340 USB: usb_wwan: fix remote wakeup
Make sure that needs_remote_wake up is always set when there are open
ports.

Currently close() would unconditionally set needs_remote_wakeup to 0
even though there might still be open ports. This could lead to blocked
input and possibly dropped data on devices that do not support remote
wakeup (and which must therefore not be runtime suspended while open).

Add an open_ports counter (protected by the susp_lock) and only clear
needs_remote_wakeup when the last port is closed.

Note that there are currently no multi-port drivers using the usb_wwan
implementation.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-27 15:04:06 -07:00
Johan Hovold b8f0e82044 USB: usb-wwan: fix multiple memory leaks in error paths
Fix port-data memory leak in usb-serial probe error path by moving port
data allocation to port_probe.

Since commit a1028f0abf ("usb: usb_wwan: replace release and disconnect
with a port_remove hook") port data is deallocated in port_remove. This
leaves a possibility for memory leaks if usb-serial probe fails after
attach but before the port in question has been successfully registered.

Note that this patch also fixes two additional memory leaks in the error
path of attach should port initialisation fail for any port as the urbs
were never freed and neither was the data of any of the successfully
initialised ports.

Compile-only tested.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-25 09:37:13 -07:00
Bjørn Mork a1028f0abf usb: usb_wwan: replace release and disconnect with a port_remove hook
Doing port specific cleanup in the .port_remove hook is a
lot simpler and safer than doing it in the USB driver
.release or .disconnect methods. The removal of the port
from the usb-serial bus will happen before the USB driver
cleanup, so we must be careful about accessing port specific
driver data from any USB driver functions.

This problem surfaced after the commit

 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound

which turned the previous unsafe access into a reliable NULL
pointer dereference.

Fixes the following Oops:

[  243.148471] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  243.148508] IP: [<ffffffffa0468527>] stop_read_write_urbs+0x37/0x80 [usb_wwan]
[  243.148556] PGD 79d60067 PUD 79d61067 PMD 0
[  243.148590] Oops: 0000 [#1] SMP
[  243.148617] Modules linked in: sr_mod cdrom qmi_wwan usbnet option cdc_wdm usb_wwan usbserial usb_storage uas fuse af_packet ip6table_filter ip6_tables iptable_filter ip_tables x_tables tun edd
cpufreq_conservative cpufreq_userspace cpufreq_powersave snd_pcm_oss snd_mixer_oss acpi_cpufreq snd_seq mperf snd_seq_device coretemp arc4 sg hp_wmi sparse_keymap uvcvideo videobuf2_core
videodev videobuf2_vmalloc videobuf2_memops rtl8192ce rtl8192c_common rtlwifi joydev pcspkr microcode mac80211 i2c_i801 lpc_ich r8169 snd_hda_codec_idt cfg80211 snd_hda_intel snd_hda_codec rfkill
snd_hwdep snd_pcm wmi snd_timer ac snd soundcore snd_page_alloc battery uhci_hcd i915 drm_kms_helper drm i2c_algo_bit ehci_hcd thermal usbcore video usb_common button processor thermal_sys
[  243.149007] CPU 1
[  243.149027] Pid: 135, comm: khubd Not tainted 3.5.0-rc7-next-20120720-1-vanilla #1 Hewlett-Packard HP Mini 110-3700                /1584
[  243.149072] RIP: 0010:[<ffffffffa0468527>]  [<ffffffffa0468527>] stop_read_write_urbs+0x37/0x80 [usb_wwan]
[  243.149118] RSP: 0018:ffff880037e75b30  EFLAGS: 00010286
[  243.149133] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88005912aa28
[  243.149150] RDX: ffff88005e95f028 RSI: 0000000000000000 RDI: ffff88005f7c1a10
[  243.149166] RBP: ffff880037e75b60 R08: 0000000000000000 R09: ffffffff812cea90
[  243.149182] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88006539b440
[  243.149198] R13: ffff88006539b440 R14: 0000000000000000 R15: 0000000000000000
[  243.149216] FS:  0000000000000000(0000) GS:ffff88007ee80000(0000) knlGS:0000000000000000
[  243.149233] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  243.149248] CR2: 0000000000000000 CR3: 0000000079fe0000 CR4: 00000000000007e0
[  243.149264] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  243.149280] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  243.149298] Process khubd (pid: 135, threadinfo ffff880037e74000, task ffff880037d40600)
[  243.149313] Stack:
[  243.149323]  ffff880037e75b40 ffff88006539b440 ffff8800799bc830 ffff88005f7c1800
[  243.149348]  0000000000000001 ffff88006539b448 ffff880037e75b70 ffffffffa04685e9
[  243.149371]  ffff880037e75bc0 ffffffffa0473765 ffff880037354988 ffff88007b594800
[  243.149395] Call Trace:
[  243.149419]  [<ffffffffa04685e9>] usb_wwan_disconnect+0x9/0x10 [usb_wwan]
[  243.149447]  [<ffffffffa0473765>] usb_serial_disconnect+0xd5/0x120 [usbserial]
[  243.149511]  [<ffffffffa0046b48>] usb_unbind_interface+0x58/0x1a0 [usbcore]
[  243.149545]  [<ffffffff8139ebd7>] __device_release_driver+0x77/0xe0
[  243.149567]  [<ffffffff8139ec67>] device_release_driver+0x27/0x40
[  243.149587]  [<ffffffff8139e5cf>] bus_remove_device+0xdf/0x150
[  243.149608]  [<ffffffff8139bc78>] device_del+0x118/0x1a0
[  243.149661]  [<ffffffffa0044590>] usb_disable_device+0xb0/0x280 [usbcore]
[  243.149718]  [<ffffffffa003c6fd>] usb_disconnect+0x9d/0x140 [usbcore]
[  243.149770]  [<ffffffffa003da7d>] hub_port_connect_change+0xad/0x8a0 [usbcore]
[  243.149825]  [<ffffffffa0043bf5>] ? usb_control_msg+0xe5/0x110 [usbcore]
[  243.149878]  [<ffffffffa003e6e3>] hub_events+0x473/0x760 [usbcore]
[  243.149931]  [<ffffffffa003ea05>] hub_thread+0x35/0x1d0 [usbcore]
[  243.149955]  [<ffffffff81061960>] ? add_wait_queue+0x60/0x60
[  243.150004]  [<ffffffffa003e9d0>] ? hub_events+0x760/0x760 [usbcore]
[  243.150026]  [<ffffffff8106133e>] kthread+0x8e/0xa0
[  243.150047]  [<ffffffff8157ec04>] kernel_thread_helper+0x4/0x10
[  243.150068]  [<ffffffff810612b0>] ? flush_kthread_work+0x120/0x120
[  243.150088]  [<ffffffff8157ec00>] ? gs_change+0xb/0xb
[  243.150101] Code: fd 41 54 53 48 83 ec 08 80 7f 1a 00 74 57 49 89 fc 31 db 90 49 8b 7c 24 20 45 31 f6 48 81 c7 10 02 00 00 e8 bc 64 f3 e0 49 89 c7 <4b> 8b 3c 37 49 83 c6 08 e8 4c a5 bd ff 49 83 fe 20
75 ed 45 30
[  243.150257] RIP  [<ffffffffa0468527>] stop_read_write_urbs+0x37/0x80 [usb_wwan]
[  243.150282]  RSP <ffff880037e75b30>
[  243.150294] CR2: 0000000000000000
[  243.177170] ---[ end trace fba433d9015ffb8c ]---

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-10 11:51:43 -07:00
Alan Cox 00a0d0d65b tty: remove filp from the USB tty ioctls
We don't use it so we can trim it from here as we try and stamp the file
object dependencies out of the serial code.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17 11:59:14 -08:00
Alan Cox 20b9d17715 tiocmset: kill the file pointer argument
Doing tiocmget was such fun we should do tiocmset as well for the same
reasons

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17 11:52:43 -08:00
Alan Cox 60b33c133c tiocmget: kill off the passing of the struct file
We don't actually need this and it causes problems for internal use of
this functionality. Currently there is a single use of the FILE * pointer.
That is the serial core which uses it to check tty_hung_up_p. However if
that is true then IO_ERROR is also already set so the check may be removed.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17 11:47:33 -08:00
Dan Williams 02303f7337 usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking close(2)
Some devices (ex ZTE 2726) simply don't respond at all when data is sent
to some of their USB interfaces.  The data gets stuck in the TTYs queue
and sits there until close(2), which them blocks because closing_wait
defaults to 30 seconds (even though the fd is O_NONBLOCK).  This is
rarely desired.  Implement the standard mechanism to adjust closing_wait
and let applications handle it how they want to.

Signed-off-by: Dan Williams <dcbw@redhat.com>
2010-11-30 16:44:57 -08:00
Matthew Garrett 0d4561947b usb serial: Add generic USB wwan support
The generic USB serial code is ill-suited for high-speed USB wwan devices,
resulting in the option driver. However, other non-option devices may also
gain similar benefits from not using the generic code. Factorise out the
non-option specific code from the option driver and make it available to
other users.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-05-20 13:21:37 -07:00