Skip to content

L
linux
Switch branch/tag
  1. 08 May, 2012 1 commit
  3. 07 May, 2012 1 commit
  5. 04 May, 2012 6 commits
  7. 02 May, 2012 5 commits
  9. 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
  11. 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
  13. 24 Apr, 2012 1 commit
  15. 23 Apr, 2012 1 commit
  17. 21 Apr, 2012 22 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7