- 20 4月, 2011 1 次提交
-
-
The current check is uneeded, since !retval will always returns true, as retval returned from tty_add_file is checked earlier and tty_open exits if it's not zero. Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 31 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
-
- 02 3月, 2011 1 次提交
-
-
由 Arnd Bergmann 提交于
These were missed the last time I cleaned this up globally, because of code moving around or new code getting merged. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 18 2月, 2011 4 次提交
-
-
由 Kay Sievers 提交于
This is useful for system management software so that it can kick off things like gettys and everything that's started from a tty, before we reuse it from/for something else or shut it down. Without this ioctl it would have to temporarily become the owner of the tty, then call vhangup() and then give it up again. Cc: Lennart Poettering <lennart@poettering.net> Signed-off-by: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
Only oddities here are a couple of drivers that bogusly called the ldisc helpers instead of returning -ENOIOCTLCMD. Fix the bug and the rest goes away. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
Doing tiocmget was such fun we should do tiocmset as well for the same reasons Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
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: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 26 1月, 2011 1 次提交
-
-
由 Torben Hohn 提交于
The -rt patches change the console_semaphore to console_mutex. As a result, a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() This commit makes things use more neutral function names which dont make implications about the underlying lock. The only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() This patch also paves the way to switching console_sem from a semaphore to a mutex. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert] Signed-off-by: NTorben Hohn <torbenh@gmx.de> Cc: Thomas Gleixner <tglx@tglx.de> Cc: Greg KH <gregkh@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 1月, 2011 1 次提交
-
-
由 Kay Sievers 提交于
This fixes the build warnings in the tty code, and uses the proper function for iterating over the console devices. Signed-off-by: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 12月, 2010 2 次提交
-
-
由 Werner Fink 提交于
This has been in the SuSE kernels for a very long time. Signed-off-by: NWerner Fink <werner@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Kay Sievers 提交于
tty: add 'active' sysfs attribute to tty0 and console device Userspace can query the actual virtual console, and the configured console devices behind /dev/tt0 and /dev/console. The last entry in the list of devices is the active device, analog to the console= kernel command line option. The attribute supports poll(), which is raised when the virtual console is changed or /dev/console is reconfigured. Signed-off-by: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> index 0000000..b138b66
-
- 30 11月, 2010 2 次提交
-
-
由 Jiri Slaby 提交于
Like in the "TTY: don't allow reopen when ldisc is changing" patch, this one fixes a TTY WARNING as described in the option 1) there: 1) __tty_hangup from tty_ldisc_hangup to tty_ldisc_enable. During this section tty_lock is held. However tty_lock is temporarily dropped in the middle of the function by tty_ldisc_hangup. The fix is to introduce a new flag which we set during the unlocked window and check it in tty_reopen too. The flag is TTY_HUPPING and is cleared after TTY_HUPPED is set. While at it, remove duplicate TTY_HUPPED set_bit. The one after calling ops->hangup seems to be more correct. But anyway, we hold tty_lock, so there should be no difference. Also document the function it does that kind of crap. Nicely reproducible with two forked children: static void do_work(const char *tty) { if (signal(SIGHUP, SIG_IGN) == SIG_ERR) exit(1); setsid(); while (1) { int fd = open(tty, O_RDWR|O_NOCTTY); if (fd < 0) continue; if (ioctl(fd, TIOCSCTTY)) continue; if (vhangup()) continue; close(fd); } exit(0); } Signed-off-by: NJiri Slaby <jslaby@suse.cz> Reported-by: <Valdis.Kletnieks@vt.edu> Reported-by: NKyle McMartin <kyle@mcmartin.ca> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Jiri Slaby 提交于
There are many WARNINGs like the following reported nowadays: WARNING: at drivers/tty/tty_io.c:1331 tty_open+0x2a2/0x49a() Hardware name: Latitude E6500 Modules linked in: Pid: 1207, comm: plymouthd Not tainted 2.6.37-rc3-mmotm1123 #3 Call Trace: [<ffffffff8103b189>] warn_slowpath_common+0x80/0x98 [<ffffffff8103b1b6>] warn_slowpath_null+0x15/0x17 [<ffffffff8128a3ab>] tty_open+0x2a2/0x49a [<ffffffff810fd53f>] chrdev_open+0x11d/0x146 ... This means tty_reopen is called without TTY_LDISC set. For further considerations, note tty_lock is held in tty_open. TTY_LDISC is cleared in: 1) __tty_hangup from tty_ldisc_hangup to tty_ldisc_enable. During this section tty_lock is held. However tty_lock is temporarily dropped in the middle of the function by tty_ldisc_hangup. 2) tty_release via tty_ldisc_release till the end of tty existence. If tty->count <= 1, tty_lock is taken, TTY_CLOSING bit set and then tty_ldisc_release called. tty_reopen checks TTY_CLOSING before checking TTY_LDISC. 3) tty_set_ldisc from tty_ldisc_halt to tty_ldisc_enable. We: * take tty_lock, set TTY_LDISC_CHANGING, put tty_lock * call tty_ldisc_halt (clear TTY_LDISC), tty_lock is _not_ held * do some other work * take tty_lock, call tty_ldisc_enable (set TTY_LDISC), put tty_lock I cannot see how 2) can be a problem, as there I see no race. OTOH, 1) and 3) can happen without problems. This patch the case 3) by checking TTY_LDISC_CHANGING along with TTY_CLOSING in tty_reopen. 1) will be fixed in the following patch. Nicely reproducible with two processes: while (1) { fd = open("/dev/ttyS1", O_RDWR); if (fd < 0) { warn("open"); continue; } close(fd); } -------- while (1) { fd = open("/dev/ttyS1", O_RDWR); ld1 = 0; ld2 = 2; while (1) { ioctl(fd, TIOCSETD, &ld1); ioctl(fd, TIOCSETD, &ld2); } close(fd); } Signed-off-by: NJiri Slaby <jslaby@suse.cz> Reported-by: <Valdis.Kletnieks@vt.edu> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 05 11月, 2010 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
The tty code should be in its own subdirectory and not in the char driver with all of the cruft that is currently there. Based on work done by Arnd Bergmann <arnd@arndb.de> Acked-by: NArnd Bergmann <arnd@arndb.de> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 10月, 2010 4 次提交
-
-
由 Alan Cox 提交于
Dan Rosenberg noted that various drivers return the struct with uncleared fields. Instead of spending forever trying to stomp all the drivers that get it wrong (and every new driver) do the job in one place. This first patch adds the needed operations and hooks them up, including the needed USB midlayer and serial core plumbing. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Vasiliy Kulikov 提交于
Function tty_register_device may return ERR_PTR(...). Check for it. Signed-off-by: NVasiliy Kulikov <segooon@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Pekka Enberg 提交于
This patch removes __GFP_NOFAIL use from tty_add_file() and adds proper error handling to the call-sites of the function. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: NPekka Enberg <penberg@kernel.org> Acked-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Dmitry Eremin-Solenikov 提交于
Some device drivers (mostly tty line disciplines) would like to have way know a struct device instance corresponding to passed tty_struct. Add a struct device pointer to struct tty_struct and populate it during initialize_tty_struct(). Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 04 9月, 2010 1 次提交
-
-
由 Nathael Pajani 提交于
I found a bug "by chance" in drivers/char/tty_io.c I mean "by chance" because I was just reading the code of the tty_find_polling_driver() to make a new tty_find_by_name() function. In tty_find_polling_driver() the driver actually test "tty_line <= p->num" while num refers to the number of struct tty_struct pointers allocated for the p->ttys (p is a tty_driver), and tty_line is scanned in a tty name, which can be for example ttyS2. Then tty_line equals 2. And if p->num is 2, we have only p->ttys[0] and p->ttys[1], but no p->ttys[2]. This is actually unharmful, for tty_find_polling_driver() is used only in drivers/serial/kgdboc.c, and there's a test over there to find a console with a matching index, which will never happen. This is still a bug anyway. Signed-off-by: NNathael Pajani <nathael.pajani@ed3l.fr> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 18 8月, 2010 2 次提交
-
-
由 Nick Piggin 提交于
tty: fix fu_list abuse tty code abuses fu_list, which causes a bug in remount,ro handling. If a tty device node is opened on a filesystem, then the last link to the inode removed, the filesystem will be allowed to be remounted readonly. This is because fs_may_remount_ro does not find the 0 link tty inode on the file sb list (because the tty code incorrectly removed it to use for its own purpose). This can result in a filesystem with errors after it is marked "clean". Taking idea from Christoph's initial patch, allocate a tty private struct at file->private_data and put our required list fields in there, linking file and tty. This makes tty nodes behave the same way as other device nodes and avoid meddling with the vfs, and avoids this bug. The error handling is not trivial in the tty code, so for this bugfix, I take the simple approach of using __GFP_NOFAIL and don't worry about memory errors. This is not a problem because our allocator doesn't fail small allocs as a rule anyway. So proper error handling is left as an exercise for tty hackers. [ Arguably filesystem's device inode would ideally be divorced from the driver's pseudo inode when it is opened, but in practice it's not clear whether that will ever be worth implementing. ] Cc: linux-kernel@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NNick Piggin <npiggin@kernel.dk> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Nick Piggin 提交于
fs: cleanup files_lock locking Lock tty_files with a new spinlock, tty_files_lock; provide helpers to manipulate the per-sb files list; unexport the files_lock spinlock. Cc: linux-kernel@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Acked-by: NAndi Kleen <ak@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NNick Piggin <npiggin@kernel.dk> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 11 8月, 2010 5 次提交
-
-
由 Kulikov Vasiliy 提交于
Remove unnesessary casts from void*. Signed-off-by: NKulikov Vasiliy <segooon@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Arnd Bergmann 提交于
When the console has been redirected, a hangup of the tty will cause tty_release to be called under the big tty_mutex, which leads to a deadlock because hangup is also called under the BTM. This moves the BTM deeper into the tty_hangup function so we can close the redirected tty without holding the BTM. In case of pty, we now need to drop the BTM before calling tty_vhangup. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Kacur <jkacur@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Arnd Bergmann 提交于
This changes all remaining users of tty_lock_nested to be non-recursive, which lets us kill this function. As a consequence, we won't need to keep the lock count any more, which allows more simplifications later. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Arnd Bergmann 提交于
tty_mutex is never taken with the BTM held, except for two corner cases that are worked around here. We give up the BTM before calling tty_release() in the error path of tty_open(). Similarly, we reorder the locking in ptmx_open() to get tty_mutex before the BTM. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Arnd Bergmann 提交于
As a preparation for replacing the big kernel lock in the TTY layer, wrap all the callers in new macros tty_lock, tty_lock_nested and tty_unlock. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 07 8月, 2010 1 次提交
-
-
由 David Howells 提交于
Make /dev/console get initialised before any initialisation routine that invokes modprobe because if modprobe fails, it's going to want to open /dev/console, presumably to write an error message to. The problem with that is that if the /dev/console driver is not yet initialised, the chardev handler will call request_module() to invoke modprobe, which will fail, because we never compile /dev/console as a module. This will lead to a modprobe loop, showing the following in the kernel log: request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 This can happen, for example, when the built in md5 module can't find the built in cryptomgr module (because the latter fails to initialise). The md5 module comes before the call to tty_init(), presumably because 'crypto' comes before 'drivers' alphabetically. Fix this by calling tty_init() from chrdev_init(). Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 5月, 2010 1 次提交
-
-
由 Alan Cox 提交于
Arnd noted: After the "retry_open:" label, we first get the tty_mutex and then the BKL. However a the end of tty_open, we jump back to retry_open with the BKL still held. If we run into this case, the tty_open function will be left with the BKL still held. Signed-off-by: NAlan Cox <alan@linux.intel.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 03 4月, 2010 1 次提交
-
-
由 Oleg Nesterov 提交于
release_one_tty(tty) can be called when tty still has a reference to pgrp/session. In this case we leak the pid. Signed-off-by: NOleg Nesterov <oleg@redhat.com> Reported-by: NCatalin Marinas <catalin.marinas@arm.com> Reported-and-tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Acked-by: NEric W. Biederman <ebiederm@xmission.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 2月, 2010 1 次提交
-
-
由 Daniel Mack 提交于
In particular, several occurances of funny versions of 'success', 'unknown', 'therefore', 'acknowledge', 'argument', 'achieve', 'address', 'beginning', 'desirable', 'separate' and 'necessary' are fixed. Signed-off-by: NDaniel Mack <daniel@caiaq.de> Cc: Joe Perches <joe@perches.com> Cc: Junio C Hamano <gitster@pobox.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 08 2月, 2010 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 70362511 ("tty: fix race in tty_fasync") and commit b04da8bf ("fnctl: f_modown should call write_lock_irqsave/ restore") that tried to fix up some of the fallout but was incomplete. It turns out that we really cannot hold 'tty->ctrl_lock' over calling __f_setown, because not only did that cause problems with interrupt disables (which the second commit fixed), it also causes a potential ABBA deadlock due to lock ordering. Thanks to Tetsuo Handa for following up on the issue, and running lockdep to show the problem. It goes roughly like this: - f_getown gets filp->f_owner.lock for reading without interrupts disabled, so an interrupt that happens while that lock is held can cause a lockdep chain from f_owner.lock -> sighand->siglock. - at the same time, the tty->ctrl_lock -> f_owner.lock chain that commit 70362511 introduced, together with the pre-existing sighand->siglock -> tty->ctrl_lock chain means that we have a lock dependency the other way too. So instead of extending tty->ctrl_lock over the whole __f_setown() call, we now just take a reference to the 'pid' structure while holding the lock, and then release it after having done the __f_setown. That still guarantees that 'struct pid' won't go away from under us, which is all we really ever needed. Reported-and-tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Acked-by: NAmérico Wang <xiyou.wangcong@gmail.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 1月, 2010 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
We need to keep the lock held over the call to __f_setown() to prevent a PID race. Thanks to Al Viro for pointing out the problem, and to Travis for making us look here in the first place. Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Tavis Ormandy <taviso@google.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Julien Tinnes <jln@google.com> Cc: Matt Mackall <mpm@selenic.com> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 13 12月, 2009 1 次提交
-
-
由 Alan Cox 提交于
The fasync path takes the BKL (it probably doesn't need to in fact) while holding the file_list spinlock. You can't do that with the kernel lock: it causes lock inversions and deadlocks. Leave the BKL over that bit for the moment. Identified by AKPM. Signed-off-by: NAlan Cox <alan@linux.intel.com> Acked-and-Tested-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 12月, 2009 5 次提交
-
-
由 Alan Cox 提交于
The tty count sanity check may need the BKL, that isn't clear. However it is clear that the count use of the lock is internal and independant of the bigger use of the lock. Furthermore the file list locking is also separately locked already Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
There are two call points, both want to check that tty->signal->leader is set. Move the test into disassociate_ctty() as that will make locking changes easier in a bit Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
We know that the redirect field is handled via its own locking in all places Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
Start trying to untangle the remaining BKL mess Updated to fix missing unlock_kernel noted by Dan Carpenter Signed-off-by: NAlan "I must be out of my tree" Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 28 9月, 2009 1 次提交
-
-
由 Dave Young 提交于
The following commit made console open fails while booting: commit b50989dc Author: Alan Cox <alan@linux.intel.com> Date: Sat Sep 19 13:13:22 2009 -0700 tty: make the kref destructor occur asynchronously Due to tty release routines run in a workqueue now, error like the following will be reported while booting: INIT open /dev/console Input/output error It also causes hibernation regression to appear as reported at http://bugzilla.kernel.org/show_bug.cgi?id=14229 The reason is that now there's latency issue with closing, but when we open a "closing not finished" tty, -EIO will be returned. Fix it as per the following Alan's suggestion: Fun but it's actually not a bug and the fix is wrong in itself as the port may be closing but not yet being destructed, in which case it seems to do the wrong thing. Opening a tty that is closing (and could be closing for long periods) is supposed to return -EIO. I suspect a better way to deal with this and keep the old console timing is to split tty->shutdown into two functions. tty->shutdown() - called synchronously just before we dump the tty onto the waitqueue for destruction tty->cleanup() - called when the destructor runs. We would then do the shutdown part which can occur in IRQ context fine, before queueing the rest of the release (from tty->magic = 0 ... the end) to occur asynchronously The USB update in -next would then need a call like if (tty->cleanup) tty->cleanup(tty); at the top of the async function and the USB shutdown to be split between shutdown and cleanup as the USB resource cleanup and final tidy cannot occur synchronously as it needs to sleep. In other words the logic becomes final kref put make object unfindable async clean it up Signed-off-by: NDave Young <hidave.darkstar@gmail.com> [ rjw: Rebased on top of 2.6.31-git, reworked the changelog. ] Signed-off-by: N"Rafael J. Wysocki" <rjw@sisk.pl> [ Changed serial naming to match new rules, dropped tty_shutdown as per comments from Alan Stern - Linus ] Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 9月, 2009 1 次提交
-
-
由 Alan Cox 提交于
Various drivers have hacks to mangle termios structures. This stems from the fact there is no nice setup hook for configuring the termios settings when the port is created Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-