linux-toradex.git/drivers/tty, branch v2.6.37.2

vt: fix issue when fbcon wants to takeover a second time.

2011-02-24T22:54:25+00:00

commit c55c63c6539499379ab4a7e8a5c0f857351fb946 upstream.

With framebuffer handover and multiple GPUs, we get into a
position where the fbcon unbinds the vesafb framebuffer for GPU 1,
but we still have a radeon framebuffer bound from GPU 0, so
we don't unregister the console driver. Then when we tried to bind
the new radeon framebuffer for GPU1 we never get to the bind
call as we fail due to the console being registered already.

This changes the return value to -EBUSY when the driver is
already registered and continues to bind for -EBUSY.

Signed-off-by: Dave Airlie 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

Input: sysrq - ensure sysrq_enabled and __sysrq_enabled are consistent

2011-02-17T23:15:07+00:00

commit 8c6a98b22b750c9eb52653ba643faa17db8d3881 upstream.

Currently sysrq_enabled and __sysrq_enabled are initialised separately
and inconsistently, leading to sysrq being actually enabled by reported
as not enabled in sysfs.  The first change to the sysfs configurable
synchronises these two:

    static int __read_mostly sysrq_enabled = 1;
    static int __sysrq_enabled;

Add a common define to carry the default for these preventing them becoming
out of sync again.  Default this to 1 to mirror previous behaviour.

Signed-off-by: Andy Whitcroft 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: sysrq - rework re-inject logic

2011-02-17T23:15:05+00:00

commit 7ab7b5adfb923978a2cab7bd3fac9ccf7d21cc3f upstream.

Internally 'disable' the filter when re-injecting Alt-SysRq instead
of relying on input core to suppress delivery of injected events
to the originating handler.

This allows to revert commit 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39
which causes problems with existing userspace programs trying to
loopback the events via evdev.

Reported-by: Kristen Carlson Accardi 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

n_gsm: copy mtu over when configuring via ioctl interface

2011-02-17T23:14:42+00:00

commit 91f78f36694b8748fda855b1f9e3614b027a744f upstream.

This field is settable but did not get copied.

Signed-off-by: Ken Mills 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

n_gsm: gsm_data_alloc buffer allocation could fail and it is not being checked

2010-12-16T21:03:13+00:00

gsm_data_alloc buffer allocation could fail and it is not being checked.

Add check for allocated buffer and return if the buffer allocation
fails.

Signed-off-by: Ken Mills 
Signed-off-by: Alan Cox 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

n_gsm: Fix message length handling when building header

2010-12-16T21:03:12+00:00

Fix message length handling when building header

When the message length is greater than 127, the length field in the header
is built incorrectly. According to the spec, when the length is less than 128
the length field is a single byte formatted as: bbbbbbb1. When it is greater
than 127 then the field is two bytes of the format: bbbbbbb0 bbbbbbbb.

Signed-off-by: Ken Mills 
Signed-off-by: Alan Cox 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

Merge branch 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6

2010-12-02T20:58:16+00:00

* 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
  serial: mfd: adjust the baud rate setting
  TTY: open/hangup race fixup
  TTY: don't allow reopen when ldisc is changing
  NET: wan/x25, fix ldisc->open retval
  TTY: ldisc, fix open flag handling
  serial8250: Mark console as CON_ANYTIME

TTY: open/hangup race fixup

2010-11-29T22:52:48+00:00

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: Jiri Slaby 
Reported-by: 
Reported-by: Kyle McMartin 
Cc: Alan Cox 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

TTY: don't allow reopen when ldisc is changing

2010-11-29T22:52:48+00:00

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:
 [] warn_slowpath_common+0x80/0x98
 [] warn_slowpath_null+0x15/0x17
 [] tty_open+0x2a2/0x49a
 [] 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: Jiri Slaby 
Reported-by: 
Cc: Kyle McMartin 
Cc: Alan Cox 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, fix open flag handling

2010-11-29T22:51:54+00:00

When a concrete ldisc open fails in tty_ldisc_open, we forget to clear
TTY_LDISC_OPEN. This causes a false warning on the next ldisc open:
WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38()
Hardware name: System Product Name
Modules linked in: ...
Pid: 5251, comm: a.out Tainted: G        W  2.6.32-5-686 #1
Call Trace:
 [] ? warn_slowpath_common+0x5e/0x8a
 [] ? warn_slowpath_null+0xa/0xc
 [] ? tty_ldisc_open+0x26/0x38
 [] ? tty_set_ldisc+0x218/0x304
...

So clear the bit when failing...

Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in
2.6.31-rc1.

Signed-off-by: Jiri Slaby 
Cc: Alan Cox 
Reported-by: Sergey Lapin 
Tested-by: Sergey Lapin 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman