1. 11 7月, 2014 1 次提交
  2. 10 7月, 2014 1 次提交
  3. 29 5月, 2014 1 次提交
    • M
      serial: uart: add hw flow control support configuration · 06aa82e4
      Murali Karicheri 提交于
      8250 uart driver currently supports only software assisted hw flow
      control. The software assisted hw flow control maintains a hw_stopped
      flag in the tty structure to stop and start transmission and use modem
      status interrupt for the event to drive the handshake signals. This is
      not needed if hw has flow control capabilities. This patch adds a
      DT attribute for enabling hw flow control for a uart port. Also skip
      stop and start if this flag is present in flag field of the port
      structure.
      Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Pawel Moll <pawel.moll@arm.com>
      CC: Mark Rutland <mark.rutland@arm.com>
      CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
      CC: Kumar Gala <galak@codeaurora.org>
      CC: Randy Dunlap <rdunlap@infradead.org>
      CC: Jiri Slaby <jslaby@suse.cz>
      CC: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06aa82e4
  4. 25 4月, 2014 2 次提交
    • D
      serial_core: Commonalize crlf when working w/ a non open console port · c7d44a02
      Doug Anderson 提交于
      In (efe2f29e kgdboc,kdb: Allow kdb to work on a non open console port)
      support was added to directly use the "write_char" functions when
      doing kdb over a non-open console port.  This is great, but it ends up
      bypassing the normal code in uart_console_write() that adds a carriage
      return before any newlines.
      
      There appears to have been a trend to add this support directly in
      some console driver's poll_put_char() functions.  This had a few side
      effects, including:
      - In this case we were doing LFCR, not CRLF.  This was fixed in
        uart_console_write() back in (d358788f [SERIAL] kernel console should
        send CRLF not LFCR)
      - Not all serial drivers had the LFCR code in their poll_put_char()
        functions.  In my case I was running serial/samsung.c which lacked
        it.
      
      I've moved the handling to uart_poll_put_char() to fix the above
      problems.  Now when I use kdb (and don't point console= to the same
      UART) I no longer get:
      
      [0]kdb>
             [0]kdb>
                    [0]kdb>
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7d44a02
    • T
      serial_core: fix uart PORT_UNKNOWN handling · 7deb39ed
      Thomas Pfaff 提交于
      While porting a RS485 driver from 2.6.29 to 3.14, i noticed that the serial tty
      driver could break it by using uart ports that it does not own :
      
      1. uart_change_pm ist called during uart_open and calls the uart pm function
         without checking for PORT_UNKNOWN.
         The fix is to move uart_change_pm from uart_open to uart_port_startup.
      2. The return code from the uart request_port call in uart_set_info is not
         handled properly, leading to the situation that the serial driver also
         thinks it owns the uart ports.
         This can triggered by doing following actions :
      
         setserial /dev/ttyS0 uart none    # release the uart ports
         modprobe lirc-serial              # or any other device that uses the uart
         setserial /dev/ttyS0 uart 16550   # gives no error and the uart tty driver
                                           # can use the ports as well
      Signed-off-by: NThomas Pfaff <tpfaff@pcs.com>
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7deb39ed
  5. 17 4月, 2014 2 次提交
    • G
      serial_core: Fix pm imbalance on unbind · bf903c0c
      Geert Uytterhoeven 提交于
      When a serial port is closed, uart_close() takes care of shutting down the
      hardware, and powering it down.
      
      When a serial port is unbound while in use, uart_close() bypasses all of
      this, as this is supposed to be done through uart_hangup() (invoked via
      tty_vhangup() in uart_remove_one_port()).
      
      However, uart_hangup() does not set the hardware's power state, leaving it
      powered up.  This may also lead to unbounded nesting counts in clock and
      power management, depending on their internal implementation.
      
      Make sure to power down the port in uart_hangup(), except when the port is
      used as a serial console.
      
      For serial consoles, this operation must be postponed until after the port
      becomes completely unused. This case is not fixed yet, as it depends on a
      (future) fix for the tty->count vs. port->count imbalance on failed
      uart_open().
      
      After this, the module clock used by the sh-sci driver is disabled on
      unbind while the serial port is in use.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf903c0c
    • S
      serial_core: Fix conditional start_tx on ring buffer not empty · 717f3bba
      Seth Bollinger 提交于
      If the serial_core ring buffer empties just as the tty layer receives
      an XOFF, then start_tx will never be called when the tty layer
      receives an XON as the serial_core ring buffer is empty.  This will
      possibly leave a few bytes trapped in the fifo for drivers that
      disable the transmitter when flow controlled.
      Signed-off-by: NSeth Bollinger <sethb@digi.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      717f3bba
  6. 18 3月, 2014 4 次提交
    • G
      serial_core: Avoid NULL pointer dereference in uart_close() · 4ed94cd4
      Geert Uytterhoeven 提交于
      When unbinding a serial driver that's being used as a serial console,
      the kernel may crash with a NULL pointer dereference in a uart_*() function
      called from uart_close () (e.g. uart_flush_buffer() or
      uart_chars_in_buffer()).
      
      To fix this, let uart_close() check for port->count == 0. If this is the
      case, bail out early. Else tty_port_close_start() will make the port
      counts inconsistent, printing out warnings like
      
          tty_port_close_start: tty->count = 1 port count = 0.
      
      and
      
          tty_port_close_start: count = -1
      
      and once uport == NULL, it will also crash.
      
      Also fix the related crash in pr_debug() by checking for a non-NULL uport
      first.
      
      Detailed description:
      
      On driver unbind, uart_remove_one_port() is called. Basically it;
        - marks the port dead,
        - calls tty_vhangup(),
        - sets state->uart_port = NULL.
      
      What will happen depends on whether the port is just in use by e.g. getty,
      or was also opened as a console.
      
      A. If the tty was not opened as a console:
      
        - tty_vhangup() will (in __tty_hangup()):
            - mark all file descriptors for this tty hung up by pointing them to
      	hung_up_tty_fops,
            - call uart_hangup(), which sets port->count to 0.
      
        - A subsequent uart_open() (this may be through /dev/ttyS*, or through
          /dev/console if this is a serial console) will fail with -ENXIO as the
          port was marked dead,
        - uart_close() after the failed uart_open() will return early, as
          tty_hung_up_p() (called from tty_port_close_start()) will notice it was
          hung up.
      
      B. If the tty was also opened as a console:
      
        - tty_vhangup() will (in __tty_hangup()):
            - mark non-console file descriptors for this tty hung up by pointing
      	them to hung_up_tty_fops,
            - NOT call uart_hangup(), but instead call uart_close() for every
              non-console file descriptor, so port->count will still have a
      	non-zero value afterwards.
      
        - A subsequent uart_open() will fail with -ENXIO as the port was
          marked dead,
        - uart_close() after the failed uart_open() starts to misbehave:
            - tty_hung_up_p() will not notice it was hung up,
            - As port->count is non-zero, tty_port_close_start() will decrease
              port->count, making the tty and port counts inconsistent. Later,
      	warnings like these will be printed:
      
      	    tty_port_close_start: tty->count = 1 port count = 0.
      
      	and
      	    tty_port_close_start: count = -1
      
            - If all of this happens after state->uart_port was set to zero, a
              NULL pointer dereference will happen.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ed94cd4
    • G
    • G
      serial_core: Grammar s/ports/port's/ · 015355b7
      Geert Uytterhoeven 提交于
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-serial@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      015355b7
    • G
      serial_core: Spelling s/contro/control/ · 02088ca6
      Geert Uytterhoeven 提交于
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-serial@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02088ca6
  7. 01 3月, 2014 1 次提交
  8. 09 12月, 2013 1 次提交
  9. 27 7月, 2013 1 次提交
  10. 21 5月, 2013 1 次提交
  11. 16 4月, 2013 1 次提交
    • F
      serial_core.c: add put_device() after device_find_child() · 5a65dcc0
      Federico Vaga 提交于
      The serial core uses device_find_child() but does not drop the reference to
      the retrieved child after using it. This patch add the missing put_device().
      
      What I have done to test this issue.
      
      I used a machine with an AMBA PL011 serial driver. I tested the patch on
      next-20120408 because the last branch [next-20120415] does not boot on this
      board.
      
      For test purpose, I added some pr_info() messages to print the refcount
      after device_find_child() (lines: 1937,2009), and after put_device()
      (lines: 1947, 2021).
      
      Boot the machine *without* put_device(). Then:
      
      echo reboot > /sys/power/disk
      echo disk > /sys/power/state
      [   87.058575] uart_suspend_port:1937 refcount 4
      [   87.058582] uart_suspend_port:1947 refcount 4
      [   87.098083] uart_resume_port:2009refcount 5
      [   87.098088] uart_resume_port:2021 refcount 5
      
      echo disk > /sys/power/state
      [  103.055574] uart_suspend_port:1937 refcount 6
      [  103.055580] uart_suspend_port:1947 refcount 6
      [  103.095322] uart_resume_port:2009 refcount 7
      [  103.095327] uart_resume_port:2021 refcount 7
      
      echo disk > /sys/power/state
      [  252.459580] uart_suspend_port:1937 refcount 8
      [  252.459586] uart_suspend_port:1947 refcount 8
      [  252.499611] uart_resume_port:2009 refcount 9
      [  252.499616] uart_resume_port:2021 refcount 9
      
      The refcount continuously increased.
      
      Boot the machine *with* this patch. Then:
      
      echo reboot > /sys/power/disk
      echo disk > /sys/power/state
      [  159.333559] uart_suspend_port:1937 refcount 4
      [  159.333566] uart_suspend_port:1947 refcount 3
      [  159.372751] uart_resume_port:2009 refcount 4
      [  159.372755] uart_resume_port:2021 refcount 3
      
      echo disk > /sys/power/state
      [  185.713614] uart_suspend_port:1937 refcount 4
      [  185.713621] uart_suspend_port:1947 refcount 3
      [  185.752935] uart_resume_port:2009 refcount 4
      [  185.752940] uart_resume_port:2021 refcount 3
      
      echo disk > /sys/power/state
      [  207.458584] uart_suspend_port:1937 refcount 4
      [  207.458591] uart_suspend_port:1947 refcount 3
      [  207.498598] uart_resume_port:2009 refcount 4
      [  207.498605] uart_resume_port:2021 refcount 3
      
      The refcount correctly handled.
      Signed-off-by: NFederico Vaga <federico.vaga@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a65dcc0
  12. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  13. 14 2月, 2013 3 次提交
  14. 16 1月, 2013 5 次提交
  15. 27 11月, 2012 1 次提交
  16. 16 11月, 2012 2 次提交
  17. 04 11月, 2012 4 次提交
  18. 31 10月, 2012 3 次提交
  19. 27 9月, 2012 1 次提交
    • A
      tty/serial/core: Introduce poll_init callback · c7f3e708
      Anton Vorontsov 提交于
      It was noticed that polling drivers (like KGDB) are not able to use
      serial ports if the ports were not previously initialized via console.
      I.e.  when booting with console=ttyAMA0 kgdboc=ttyAMA0, everything works
      fine, but with console=ttyFOO kgdboc=ttyAMA0, the kgdboc doesn't work.
      
      This is because we don't initialize the hardware. Calling ->startup() is
      not an option, because drivers request interrupts there, and drivers
      fail to handle situations when tty isn't opened with interrupts enabled.
      
      So, we have to implement a new callback (actually, tty_ops already have
      a similar callback), which does everything needed to initialize just the
      hardware.
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7f3e708
  20. 22 9月, 2012 1 次提交
  21. 07 9月, 2012 3 次提交