Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 3月, 2013 2 次提交
    • J
      TTY: 8250, deprecated 8250_core.* options · 9326b047
      由 Jiri Slaby 提交于 
      They were introduced by mistake in 3.7. Let's deprecate them now. For
the reasons, see the text in Kconfig below.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9326b047
    • J
      TTY: 8250, revert module name change · 9196d8ac
      由 Jiri Slaby 提交于 
      In 3.7 the 8250 module name was changed unintentionally from 8250 to
8250_core by commit 835d844d
(8250_pnp: do pnp probe before legacy probe). We then had to
re-introduce the old module options to ensure the old good
8250.nr_uart & co. still work. This can be done only by a very dirty
hack and we did it in f2b8dfd9
(serial: 8250: Keep 8250.<xxxx> module options functional after driver
rename).

That is so damn ugly so that I decided to revert to the old module
name and deprecate the new 8250_core options present in 3.7 and 3.8
only. The deprecation will happen in the following patch.

Note that this patch changes the hack above to support "8250_core.*",
because we now have "8250.*" natively.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9196d8ac
  3. 12 3月, 2013 2 次提交
  5. 30 1月, 2013 1 次提交
  7. 18 1月, 2013 1 次提交
  9. 16 1月, 2013 4 次提交
  11. 22 11月, 2012 7 次提交
  13. 25 10月, 2012 1 次提交
  15. 27 9月, 2012 2 次提交
  17. 22 9月, 2012 1 次提交
  19. 12 9月, 2012 1 次提交
  21. 27 7月, 2012 1 次提交
  23. 13 7月, 2012 3 次提交
  25. 13 6月, 2012 2 次提交
  27. 03 5月, 2012 5 次提交
  29. 02 5月, 2012 1 次提交
    • C
      8250.c: less than 2400 baud fix. · f9a9111b
      由 Christian Melki 提交于 
      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: NChristian Melki <christian.melki@ericsson.se>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9a9111b
  31. 19 4月, 2012 2 次提交
  33. 10 4月, 2012 2 次提交
  35. 10 3月, 2012 2 次提交
    • P
      serial: remove back and forth conversions in serial_out_sync · 55e4016d
      由 Paul Gortmaker 提交于 
      The two callers to serial_out_sync() have a struct port right
there in scope, but then pass in a struct 8250_port which then
is locally resolved back to a struct port.

Delete the needless back and forth and just pass in the struct
port directly.  Rename the function to have "_port" in its
name, so the name <--> args relationship is consistent with the
other serial_in/out vs serial_port_in/out function classes.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55e4016d
    • P
      serial: use serial_port_in/out vs serial_in/out in 8250 · 4fd996a1
      由 Paul Gortmaker 提交于 
      The serial_in and serial_out helpers are expecting to operate
on an 8250_port struct.  These in turn go after the contained
normal port struct which actually has the actual in/out accessors.

But what is happening in some cases, is that a function is passed
in a port struct, and it runs container_of to get the 8250_port
struct, and then it uses serial_in/out helpers on that.  But when
you do, it goes full circle, since it jumps back inside the 8250_port
to find the contained port struct (which we already knew!).

So, if we are operating in a scope where we know the struct port,
then use the serial_port_in/out helpers and avoid the bouncing
around.  If we don't have the struct port handy, and it isn't
worth making a local for it, then just leave things as-is which
uses the serial_in/out helpers that will resolve the 8250_port
onto the struct port.

Mostly, gcc figures this out on its own -- so this doesn't bring to
the table any revolutionary runtime delta.  However, it is somewhat
misleading to always hammer away on 8250 structs, when the actual
underlying property isn't at all 8250 specific -- and this change
makes that clear.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fd996a1