kernel/linux.git/drivers/tty/synclink.c, branch v4.4.171

tty: synclink, fix indentation

2015-10-18T04:14:06+00:00

The statement after if should be indenteted. So fix this. Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

tty: Remove ASYNC_CLOSING checks in open()/hangup() methods

2015-10-18T04:11:29+00:00

Since at least before 2.6.30, tty drivers that do not drop the tty lock while closing cannot observe ASYNC_CLOSING set while holding the tty lock; this includes the tty driver's open() and hangup() methods, since the tty core calls these methods holding the tty lock. For these drivers, waiting for ASYNC_CLOSING to clear while opening is not required, since this condition cannot occur. Similarly, even when the open() method drops and reacquires the tty lock after blocking, ASYNC_CLOSING cannot be set (again, for drivers that do not drop the tty lock while closing). Now that tty port drivers no longer drop the tty lock while closing (since 'tty: Remove tty_wait_until_sent_from_close()'), the same conditions apply: waiting for ASYNC_CLOSING to clear while opening is not required, nor is re-checking ASYNC_CLOSING after dropping and reacquiring the tty lock while blocking (eg., in *_block_til_ready()). Note: The ASYNC_CLOSING flag state is still maintained since several bitrotting drivers use it for (dubious) other purposes. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: synclink.c: move assignment out of if () block

2015-05-10T17:04:18+00:00

We should not be doing assignments within an if () block so fix up the code to not do this. change was created using Coccinelle. CC: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

tty: Remove tty_hung_up_p() tests from tty drivers' open()

2014-07-10T23:06:49+00:00

Since at least before 2.6.30, it has not been possible to observe a hung up file pointer in a tty driver's open() method unless/until the driver open() releases the tty_lock() (eg., before blocking). This is because tty_open() adds the file pointer while holding the tty_lock() _and_ doesn't release the lock until after calling the tty driver's open() method. [ Before tty_lock(), this was lock_kernel(). ] Since __tty_hangup() first waits on the tty_lock() before enumerating and hanging up the open file pointers, either __tty_hangup() will wait for the tty_lock() or tty_open() will not yet have added the file pointer. For example, CPU 0 | CPU 1 | tty_open | __tty_hangup .. | .. tty_lock | .. tty_reopen | tty_lock / blocks .. | tty_add_file(tty, filp) | .. | tty->ops->open(tty, filp) | tty_port_open | tty_port_block_til_ready | .. | while (1) | .. | tty_unlock | / unblocks schedule | for each filp on tty->tty_files | f_ops = tty_hung_up_fops; | .. | tty_unlock tty_lock | .. | tty_unlock | Note that since tty_port_block_til_ready() and similar drop the tty_lock while blocking, when woken, the file pointer must then be tested for having been hung up. Also, fix bit-rotted drivers that used extra_count to track the port->count bump. CC: Mikael Starvik CC: Samuel Ortiz CC: "David S. Miller" Signed-off-by: Peter Hurley Acked-by: Jesper Nilsson Signed-off-by: Greg Kroah-Hartman

synclink: fix info leak in ioctl

2014-03-17T23:13:23+00:00

The hdlcdev_ioctl() code fails to initialize the two padding bytes of struct sync_serial_settings after the ->loopback member. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Salva Peiró Signed-off-by: Greg Kroah-Hartman

tty: synclink: avoid sleep_on race

2014-01-08T01:05:21+00:00

The four variants of the synclink driver use the same code in their open() callback to wait for a port in process of being closed, using interruptible_sleep_on, which is racy and going away soon. Making things worse, these functions hold the BTM while doing so, which means that if we ever enter this code path, we cannot actually continue since the other thread that is in process of closing the port can no longer get the BTM. This addresses both issues by using wait_event_interruptible_tty() instead. Signed-off-by: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

TTY: synclink: replace bitmasks add operation with OR operation.

2013-07-29T19:47:37+00:00

Found with coccinelle, manually fixed and verified. Signed-off-by: Alexandru Juncu Signed-off-by: Greg Kroah-Hartman

TTY: synclink: fix DTR being raised on hang up

2013-04-12T21:08:17+00:00

Make sure to check ASYNC_INITIALISED before raising DTR when waking up from blocked open in block_til_ready. Currently DTR could get raised at hang up as a blocked process would raise DTR unconditionally before checking for hang up and returning. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

TTY: synclink, remove superfluous check

2013-03-18T23:17:20+00:00

info is obtained by container_of. It can never be NULL. So do not test that. Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

TTY: synclink: Convert + to | for bit operations

2013-01-30T05:09:58+00:00

Dan Carpenter noticed a missing set of parentheses around a multiple field addition. https://lkml.org/lkml/2013/1/27/166 His original commit message: There is a kind of precedence problem here, but it doesn't affect how the code works because ->serial_signals is unsigned char. We want to clear two flags here. #define SerialSignal_RTS 0x20 /* Request to Send */ #define SerialSignal_DTR 0x80 /* Data Terminal Ready */ Without the parenthesis then it does: info->serial_signals &= 0x5f; With the parenthesis it does: info->serial_signals &= 0xffffff5f; info->serial_signals is an unsigned char so the two statements are equivalent, but it's cleaner to add the parenthesis. In other dtr_rts() functions the parenthesis are there so this makes it more consistent. Other changes: Convert all + uses to | for these bit operations. Reorder the multiple fields for consistency. Update the comments too. Reported-by: Dan Carpenter Signed-off-by: Joe Perches Signed-off-by: Greg Kroah-Hartman