1. 07 May, 2012 1 commit
  2. 04 May, 2012 6 commits
  3. 02 May, 2012 5 commits
  4. 01 May, 2012 1 commit
    • Christian Melki's avatar
      8250.c: less than 2400 baud fix. · f9a9111b
      Christian Melki authored
      We noticed that we were loosing data at speed less than 2400 baud.
      It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo
      was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr
      reg.
      The input code still fills the buffer with 64 bytes if I remember
      correctly and thus data is lost.
      Our fix was to remove whiping of the fcr content and just add the
      TRIGGER_1 which we want for latency.
      I can't see why this would not work on less than 2400 always, for all
      uarts ...
      Otherwise one would have to make sure the filling of the fifo re-checks
      the current state of available fifo size (urrk).
      Signed-off-by: default avatarChristian Melki <christian.melki@ericsson.se>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9a9111b
  5. 30 Apr, 2012 2 commits
    • Arnaud Patard's avatar
      8250_pci: fix pch uart matching · aaa10eb1
      Arnaud Patard authored
      The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids
      entries, preventing it to match and thus is breaking serial port support for
      theses systems.
      
      This has been tested on a nanoETXexpress-TT, which has a specifici uart clock.
      Tested-by: default avatarErwan Velu <Erwan.Velu@zodiacaerospace.com>
      [stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable]
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarArnaud Patard <apatard@hupstream.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aaa10eb1
    • Jiri Slaby's avatar
      TTY: n_tty, do not dereference user buffer · 3fa10cc8
      Jiri Slaby authored
      copy_from_read_buf currently copies data to a user buffer and then
      checks if the data is single EOF. But it checks it by accessing the
      user buffer. First, the buffer may be changed by other threads of the
      user program already. Second, it accesses the buffer without any
      checks. It might be write-only for example.
      
      Fix this by inspecting contents of the tty (kernel) buffer instead.
      Note that "n == 1" is necessary, but not sufficient. But we check
      later that there is nothing left by "!tty->read_cnt" condition.
      
      There is still an issue with the current code that EOF being wrapped
      to the start of the circular buffer will result in an inappropriate
      losing of the EOF character. But this is not intended to be fixed by
      this patch.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-by: default avatarEmil Goode <emilgoode@gmail.com>
      Cc: Howard Chu <hyc@symas.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fa10cc8
  6. 24 Apr, 2012 1 commit
  7. 23 Apr, 2012 1 commit
  8. 21 Apr, 2012 23 commits