linux-stable.git/drivers/tty/cyclades.c, branch linux-4.6.y

tty: Use termios c_*flag macros

2016-01-28T22:13:44+00:00

Expressions of the form "tty->termios.c_*flag & FLAG"
are more clearly expressed with the termios flags macros,
I_FLAG(), C_FLAG(), O_FLAG(), and L_FLAG().

Convert treewide.

Signed-off-by: Peter Hurley 
Acked-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

tty: Remove chars_in_buffer() line discipline method

2016-01-27T23:01:44+00:00

The chars_in_buffer() line discipline method serves no functional
purpose, other than as a (dubious) debugging aid for mostly bit-rotting
drivers. Despite being documented as an optional method, every caller
is unconditionally executed (although conditionally compiled).
Furthermore, direct tty->ldisc access without an ldisc ref is unsafe.
Lastly, N_TTY's chars_in_buffer() has warned of removal since 3.12.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

cyclades: Deinline cyz_is_loaded, save 240 bytes

2015-12-14T03:59:48+00:00

This function compiles to 58 bytes of machine code.

Signed-off-by: Denys Vlasenko 
CC: Jiri Slaby 
CC: linux-serial@vger.kernel.org
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

cyclades: Deinline serial_paranoia_check, save 304 bytes

2015-12-14T03:59:48+00:00

This function compiles to 52 bytes of machine code.

Signed-off-by: Denys Vlasenko 
CC: Jiri Slaby 
CC: linux-serial@vger.kernel.org
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

cyclades: Deinline cyy_writeb, save 880 bytes

2015-12-14T03:59:48+00:00

This function compiles to 35 bytes of machine code.

Signed-off-by: Denys Vlasenko 
CC: Jiri Slaby 
CC: linux-serial@vger.kernel.org
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

cyclades: Deinline cyy_readb, save 368 bytes

2015-12-14T03:59:48+00:00

This function compiles to 32 bytes of machine code.

Signed-off-by: Denys Vlasenko 
CC: Jiri Slaby 
CC: linux-serial@vger.kernel.org
Reviewed-by: Peter Hurley 
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: remove buf parameter from tty_name()

2015-05-06T20:26:57+00:00

tty_name no longer uses the buf parameter, so remove it along with all
the 64 byte stack buffers that used to be passed in.

Mostly generated by the coccinelle script

@depends on patch@
identifier buf;
constant C;
expression tty;
@@
- char buf[C];
  <+...
- tty_name(tty, buf)
+ tty_name(tty)
  ...+>

allmodconfig compiles, so I'm fairly confident the stack buffers
weren't used for other purposes as well.

Signed-off-by: Rasmus Villemoes 
Reviewed-by: Peter Hurley 
Acked-by: Jesper Nilsson 
Acked-by: Dmitry Torokhov 
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

tty: an overflow of multiplication in drivers/tty/cyclades.c

2013-12-20T20:21:57+00:00

there is an overflow in the code :
cyz_polling_cycle = (arg * HZ) / 1000,
the multiplicator arg comes from user, so it may be an overflow if
arg is a big number. And the value of cyc_polling_cycle will be
wrong when it is used next time.

Reported-by: Qixue Xiao 
Suggested-by: Yongjian Xu 
Suggested-by: Yu Chen 
Signed-off-by: Qixue Xiao 
Signed-off-by: Greg Kroah-Hartman