1. 27 1月, 2017 1 次提交
    • B
      tty: serial: constify uart_ops structures · 2331e068
      Bhumika Goyal 提交于
      Declare uart_ops structures as const as they are only stored in the ops
      field of an uart_port structure. This field is of type const, so
      uart_ops structures having this property can be made const too.
      
      File size details before and after patching.
      First line of every .o file shows the file size before patching
      and second line shows the size after patching.
      
         text	   data	    bss	    dec	    hex	filename
      
         2977	    456	     64	   3497	    da9	drivers/tty/serial/amba-pl010.o
         3169	    272	     64	   3505	    db1	drivers/tty/serial/amba-pl010.o
      
         3109	    456	      0	   3565	    ded	drivers/tty/serial/efm32-uart.o
         3301	    272	      0	   3573	    df5	drivers/tty/serial/efm32-uart.o
      
        10668	    753	      1	  11422	   2c9e	drivers/tty/serial/icom.o
        10860	    561	      1	  11422	   2c9e	drivers/tty/serial/icom.o
      
        23904	    408	      8	  24320	   5f00	drivers/tty/serial/ioc3_serial.o
        24088	    224	      8	  24320	   5f00	drivers/tty/serial/ioc3_serial.o
      
        10516	    560	      4	  11080	   2b48	drivers/tty/serial/ioc4_serial.o
        10709	    368	      4	  11081	   2b49	drivers/tty/serial/ioc4_serial.o
      
         7853	    648	   1216	   9717	   25f5	drivers/tty/serial/mpsc.o
         8037	    456	   1216	   9709	   25ed	drivers/tty/serial/mpsc.o
      
        10248	    456	      0	  10704	   29d0	drivers/tty/serial/omap-serial.o
        10440	    272	      0	  10712	   29d8	drivers/tty/serial/omap-serial.o
      
         8122	    532	   1984	  10638	   298e	drivers/tty/serial/pmac_zilog.o
         8306	    340	   1984	  10630	   2986	drivers/tty/serial/pmac_zilog.o
      
         3808	    456	      0	   4264	   10a8	drivers/tty/serial/pxa.o
         4000	    264	      0	   4264	   10a8	drivers/tty/serial/pxa.o
      
        21781	   3864	      0	  25645	   642d	drivers/tty/serial/serial-tegra.o
        22037	   3608	      0	  25645	   642d	drivers/tty/serial/serial-tegra.o
      
         2481	    456	     96	   3033	    bd9	drivers/tty/serial/sprd_serial.o
         2673	    272	     96	   3041	    be1	drivers/tty/serial/sprd_serial.o
      
         5534	    300	    512	   6346	   18ca	drivers/tty/serial/vr41xx_siu.o
         5630	    204	    512	   6346	   18ca	drivers/tty/serial/vr41xx_siu.o
      
         6730	   1576	    128	   8434	   20f2	drivers/tty/serial/vt8500_serial.o
         6986	   1320	    128	   8434	   20f2	drivers/tty/serial/vt8500_serial.o
      
      Cross compiled for mips architecture.
      
         3005	    488	      0	   3493	    da5	drivers/tty/serial/pnx8xxx_uart.o
         3189	    304	      0	   3493	    da5	drivers/tty/serial/pnx8xxx_uart.o
      
         4272	    196	   1056	   5524	   1594	drivers/tty/serial/dz.o
         4368	    100	   1056	   5524	   1594	drivers/tty/serial/dz.o
      
         6551	    144	     16	   6711	   1a37	drivers/tty/serial/ip22zilog.o
         6647	     48	     16	   6711	   1a37	drivers/tty/serial/ip22zilog.o
      
         9612	    428	   1520	  11560	   2d28	drivers/tty/serial/serial_txx9.o
         9708	    332	   1520	  11560	   2d28	drivers/tty/serial/serial_txx9.o
      
         4156	    296	     16	   4468	   1174	drivers/tty/serial/ar933x_uart.o
         4252	    200	     16	   4468	   1174	drivers/tty/serial/ar933x_uart.o
      
      Cross compiled for arm archiecture.
      
        11716	   1780	     44	  13540	   34e4	drivers/tty/serial/sirfsoc_uart.o
        11808	   1688	     44	  13540	   34e4	drivers/tty/serial/sirfsoc_uart.o
      
        13352	    596	     56	  14004	   36b4	drivers/tty/serial/amba-pl011.o
        13444	    504	     56	  14004	   36b4	drivers/tty/serial/amba-pl011.o
      
      Cross compiled for sparc architecture.
      
         4664	    528	     32	   5224	   1468	drivers/tty/serial/sunhv.o
         4848	    344	     32	   5224	   1468	drivers/tty/serial/sunhv.o
      
         8080	    332	     28	   8440	   20f8	drivers/tty/serial/sunzilog.o
         8184	    228	     28	   8440	   20f8	drivers/tty/serial/sunzilog.o
      
      Cross compiled for ia64 architecture.
      
        10226	    549	    472	  11247	   2bef	drivers/tty/serial/sn_console.o
        10414	    365	    472	  11251	   2bf3	drivers/tty/serial/sn_console.o
      
      The files drivers/tty/serial/zs.o, drivers/tty/serial/lpc32xx_hs.o and
      drivers/tty/serial/lantiq.o did not compile.
      Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2331e068
  2. 19 1月, 2017 1 次提交
  3. 07 2月, 2016 3 次提交
  4. 14 12月, 2015 1 次提交
  5. 05 10月, 2015 1 次提交
  6. 10 6月, 2015 1 次提交
  7. 08 5月, 2015 1 次提交
    • S
      serial: omap: Fix error handling in probe · 66cf1d84
      Semen Protsenko 提交于
      There is pm_qos_add_request() being executed on serial_omap_probe(),
      which stores "&up->pm_qos_request" from omap-serial driver to
      "pm_qos_array[PM_QOS_CPU_DMA_LATENCY]->constraints". If
      serial_omap_probe() fails after pm_qos_add_request() (e.g. on
      uart_add_one_port() call), pm_qos_array still keeping pm_qos_request
      struct from omap-serial driver, which is not valid anymore (since driver
      failed). This leads further to kernel crash on pm_qos_update_target(),
      executing from some completely different driver.
      
      We were observing this while trying to run audio playback while having
      one of omap-serial driver instances failed on uart_add_one_port() call:
          Unable to handle kernel paging request at virtual address fffffffc
          Backtrace:
          (plist_add) from (pm_qos_update_target)
          (pm_qos_update_target) from (pm_qos_add_request)
          (pm_qos_add_request) from (snd_pcm_hw_params)
          (snd_pcm_hw_params) from (snd_pcm_common_ioctl1)
          (snd_pcm_common_ioctl1) from (snd_pcm_playback_ioctl1)
          (snd_pcm_playback_ioctl1) from (snd_pcm_playback_ioctl)
          (snd_pcm_playback_ioctl) from (do_vfs_ioctl)
          (do_vfs_ioctl) from (SyS_ioctl)
          (SyS_ioctl) from (ret_fast_syscall)
      
      This patch adds pm_qos_remove_request() on fail path in
      serial_omap_probe() in order to fix this issue. While at it, free the
      wakeup settings on fail path as well, just like it's done in
      serial_omap_remove().
      Signed-off-by: NSemen Protsenko <semen.protsenko@globallogic.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66cf1d84
  8. 27 3月, 2015 1 次提交
    • D
      tty/serial: omap: fix !wakeirq message · 1cf94d3a
      Doug Kehn 提交于
      When wakeirq is not used/enabled, "no wakeirq for uart0" is output for
      all TTY as the log message is generated before the port line is
      initialized.
      [    0.802656] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
      [    0.811700] omap_uart 44e09000.serial: no wakeirq for uart0
      [    0.812379] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88, base_baud = 3000000) is a OMAP UART0
      [    1.503622] console [ttyO0] enabled
      [    1.509836] omap_uart 48022000.serial: no wakeirq for uart0
      [    1.516118] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89, base_baud = 3000000) is a OMAP UART1
      [    1.527711] omap_uart 48024000.serial: no wakeirq for uart0
      [    1.533881] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90, base_baud = 3000000) is a OMAP UART2
      [    1.545324] omap_uart 481a6000.serial: no wakeirq for uart0
      [    1.551410] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60, base_baud = 3000000) is a OMAP UART3
      [    1.562946] omap_uart 481a8000.serial: no wakeirq for uart0
      [    1.569036] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61, base_baud = 3000000) is a OMAP UART4
      
      Fix by moving wakeirq initialization, check, and dev_info() call to
      after port line initialization and validation.
      Signed-off-by: NDoug Kehn <rdkehn@yahoo.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cf94d3a
  9. 03 2月, 2015 2 次提交
    • P
      serial: omap: Fix RTS handling · 348f9bb3
      Peter Hurley 提交于
      The OMAP UART ignores MCR[1] (ie., RTS) when in autoRTS mode. This
      makes it impossible for either the serial core or userspace to
      manually flow control the sender.
      
      Disable autoRTS mode when RTS is lowered and restore the previous
      mode when RTS is raised.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      348f9bb3
    • P
      serial: core: Rework hw-assisted flow control support · 391f93f2
      Peter Hurley 提交于
      hw-assisted flow control support was added to the serial core
      in v3.8 with commits,
      dba05832 ("SERIAL: core: add hardware assisted h/w flow control support")
      2cbacafd ("SERIAL: core: add hardware assisted s/w flow control support")
      9aba8d5b ("SERIAL: core: add throttle/unthrottle callbacks for hardware
                      assisted flow control")
      Since then, additional requirements for serial core support have arisen.
      Specifically,
      1. Separate tx and rx flow control settings for UARTs which only support
         tx flow control (ie., autoCTS).
      2. Disable sw-assisted CTS flow control in autoCTS mode
      3. Support for RTS flow control by serial core and userspace in autoRTS mode
      
      Distinguish mode from capability; introduce UPSTAT_AUTORTS, UPSTAT_AUTOCTS
      and UPSTAT_AUTOXOFF which, when set by the uart driver, enable serial core
      support for hw-assisted rx, hw-assisted tx and hw-assisted in-band/IXOFF
      rx flow control, respectively. [Note: hw-assisted in-band/IXON tx flow
      control does not require serial core support/intervention and can be
      enabled by the uart driver when required.]
      
      These modes must be set/reset in the driver's set_termios() method, based
      on termios settings, and thus can be safely queried in any context in which
      one of the port lock, port mutex or termios rwsem are held. Set these modes
      in the 2 in-tree drivers, omap-serial and 8250_omap, which currently
      use UPF_HARD_FLOW/UPF_SOFT_FLOW support.
      
      Retain UPF_HARD_FLOW and UPF_SOFT_FLOW as capabilities; re-define
      UPF_HARD_FLOW as both UPF_AUTO_RTS and UPF_AUTO_CTS to allow for distinct
      and separate rx and tx flow control capabilities.
      
      Disable sw-assisted CTS flow control when UPSTAT_AUTOCTS is enabled.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      391f93f2
  10. 10 1月, 2015 1 次提交
  11. 13 12月, 2014 1 次提交
  12. 26 11月, 2014 1 次提交
  13. 07 11月, 2014 3 次提交
    • R
      tty/serial_core: Introduce lock mechanism for RS485 · bd737f87
      Ricardo Ribalda Delgado 提交于
      Introduce an homogeneous lock system between setting and using the rs485
      data of the uart_port.
      
      This patch should not be split into multiple ones in order to avoid
      leaving the tree in an unstable state.
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Suggested-by: NAlan Cox <alan@linux.intel.com>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd737f87
    • R
      serial/omap: Use the rs485 functions on serial_core · dadd7ecb
      Ricardo Ribalda Delgado 提交于
      In order to unify all the rs485 ioctl handling
      Use the implementation of TIOC[GS]RS485 ioctl handling on serial_core.
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dadd7ecb
    • N
      tty: serial: omap: Increase max consoles and add check to prevent crash · 7af0ea5d
      Nishanth Menon 提交于
      Increase the maximum number of consoles possible to 10 since DRA7 now
      has the maximum number of consoles possible. without doing this, for
      example, enabling DRA7 UART10 results in internal data structures and
      console cannot match up and we endup with a crash as follows:
      
      [    1.903503] omap_uart 48424000.serial: [UART-1]: failure [serial_omap_probe]: -22
      [    1.911437] omap_uart: probe of 48424000.serial failed with error -22
      [    1.920379] Unable to handle kernel NULL pointer dereference at virtual address 00000004
      [    1.928894] pgd = c0004000
      [    1.931732] [00000004] *pgd=00000000
      [    1.935485] Internal error: Oops: 5 [#1] SMP ARM
      [    1.940338] Modules linked in:
      [    1.943542] CPU: 1 PID: 12 Comm: kworker/1:0 Tainted: G        W      3.18.0-rc1-00001-g8821bc4-dirty #6
      [    1.953521] task: ed8a2d00 ti: ed8a4000 task.ti: ed8a4000
      [    1.959197] PC is at process_one_work+0x38/0x4a4
      [    1.964050] LR is at 0x0
      [    1.966705] pc : [<c00548e0>]    lr : [<00000000>]    psr: 40000093
      [    1.966705] sp : ed8a5ea8  ip : ed8a5ec8  fp : eeb9abc0
      [    1.978759] r10: ed8a4000  r9 : 00000008  r8 : ed842458
      [    1.984252] r7 : 00000000  r6 : eeb9abc0  r5 : ed842440  r4 : edbf26a8
      [    1.991119] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000
      [    1.997985] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [    2.005767] Control: 10c5387d  Table: 8000406a  DAC: 00000015
      [    2.011810] Process kworker/1:0 (pid: 12, stack limit = 0xed8a4248)
      [    2.018371] Stack: (0xed8a5ea8 to 0xed8a6000)
      [    2.022949] 5ea0:                   00000001 00000000 60000093 c008346c 00000001 ed8a5ec8
      [    2.031555] 5ec0: c0054de4 eeb9abc0 ed8a4000 ed842458 00000008 ed8a4000 eeb9abc0 ed842440
      [    2.040161] 5ee0: eeb9abc0 eeb9abf0 ed8a4000 ed842458 00000008 ed8a4000 eeb9abc0 c0054ec4
      [    2.048767] 5f00: ed8a4000 eeb9ac4c a0000053 00000000 ed845bc0 ed842440 c0054d80 00000000
      [    2.057342] 5f20: 00000000 00000000 00000000 c005999c 00000001 00000000 c05eaa64 ed842440
      [    2.065948] 5f40: 00000000 00000000 dead4ead ffffffff ffffffff c097c680 00000000 00000000
      [    2.074554] 5f60: c078acd4 ed8a5f64 ed8a5f64 00000000 00000000 dead4ead ffffffff ffffffff
      [    2.083160] 5f80: c097c680 00000000 00000000 c078acd4 ed8a5f90 ed8a5f90 600000d3 ed845bc0
      [    2.091766] 5fa0: c00598d4 00000000 00000000 c000e668 00000000 00000000 00000000 00000000
      [    2.100341] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    2.108947] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 90005148 11010482
      [    2.117553] [<c00548e0>] (process_one_work) from [<c0054ec4>] (worker_thread+0x144/0x498)
      [    2.126159] [<c0054ec4>] (worker_thread) from [<c005999c>] (kthread+0xc8/0xe4)
      [    2.133758] [<c005999c>] (kthread) from [<c000e668>] (ret_from_fork+0x14/0x2c)
      [    2.141357] Code: e1a04001 e1a05000 e893000f e31e0004 (e5978004)
      [    2.147766] ---[ end trace 5798e2803311b69f ]---
      <snip>
      
      The final solution is to transition off to use 8250 driver and no
      dependency on console structures and move away from omap-serial
      driver, hence no major cleanups are done for this driver, so add a
      simple check to prevent future crashes in a similar manner in case of
      platform with additional ports.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7af0ea5d
  14. 06 11月, 2014 1 次提交
  15. 29 9月, 2014 2 次提交
    • F
      tty: omap-serial: pull out calculation from baud_is_mode16 · 13d6ceb4
      Frans Klaver 提交于
      To determine the correct divisor, we need to know the difference between
      the desired baud rate and the actual baud rate. The calculation for this
      difference is implemented twice within omap_serial_baud_is_mode16().
      Pull out the calculation for easier maintenance.
      
      While at it, remove the CamelCasing from the variable names.
      Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13d6ceb4
    • F
      tty: omap-serial: fix division by zero · dc318756
      Frans Klaver 提交于
      If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
      calculated n values in serial_omap_is_baud_mode16() may become 0. This
      causes a division by zero when calculating the difference between
      calculated and desired baud rates. To prevent this, cap the n13 and n16
      values on 1.
      
      Division by zero in kernel.
      [<c00132e0>] (unwind_backtrace) from [<c00112ec>] (show_stack+0x10/0x14)
      [<c00112ec>] (show_stack) from [<c01ed7bc>] (Ldiv0+0x8/0x10)
      [<c01ed7bc>] (Ldiv0) from [<c023805c>] (serial_omap_baud_is_mode16+0x4c/0x68)
      [<c023805c>] (serial_omap_baud_is_mode16) from [<c02396b4>] (serial_omap_set_termios+0x90/0x8d8)
      [<c02396b4>] (serial_omap_set_termios) from [<c0230a0c>] (uart_change_speed+0xa4/0xa8)
      [<c0230a0c>] (uart_change_speed) from [<c0231798>] (uart_set_termios+0xa0/0x1fc)
      [<c0231798>] (uart_set_termios) from [<c022bb44>] (tty_set_termios+0x248/0x2c0)
      [<c022bb44>] (tty_set_termios) from [<c022c17c>] (set_termios+0x248/0x29c)
      [<c022c17c>] (set_termios) from [<c022c3e4>] (tty_mode_ioctl+0x1c8/0x4e8)
      [<c022c3e4>] (tty_mode_ioctl) from [<c0227e70>] (tty_ioctl+0xa94/0xb18)
      [<c0227e70>] (tty_ioctl) from [<c00cf45c>] (do_vfs_ioctl+0x4a0/0x560)
      [<c00cf45c>] (do_vfs_ioctl) from [<c00cf568>] (SyS_ioctl+0x4c/0x74)
      [<c00cf568>] (SyS_ioctl) from [<c000e480>] (ret_fast_syscall+0x0/0x30)
      Signed-off-by: NFrans Klaver <frans.klaver@xsens.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc318756
  16. 25 4月, 2014 9 次提交
  17. 17 4月, 2014 2 次提交
    • T
      serial: omap: Fix missing pm_runtime_resume handling by simplifying code · d758c9c1
      Tony Lindgren 提交于
      The lack of pm_runtime_resume handling for the device state leads into
      device wake-up interrupts not working after a while for runtime PM.
      
      Also, serial-omap is confused about the use of device_may_wakeup.
      The checks for device_may_wakeup should only be done for suspend and
      resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
      events for PM runtime should always be enabled.
      
      The lack of pm_runtime_resume handling leads into device wake-up
      interrupts not working after a while for runtime PM.
      
      Rather than try to patch over the issue of adding complex tests to
      the pm_runtime_resume, let's fix the issues properly:
      
      1. Make serial_omap_enable_wakeup deal with all internal PM state
         handling so we don't need to test for up->wakeups_enabled elsewhere.
      
         Later on once omap3 boots in device tree only mode we can also
         remove the up->wakeups_enabled flag and rely on the wake-up
         interrupt enable/disable state alone.
      
      2. Do the device_may_wakeup checks in suspend and resume only,
         for runtime PM the wake-up events need to be always enabled.
      
      3. Finally just call serial_omap_enable_wakeup and make sure we
         call it also in pm_runtime_resume.
      
      4. Note that we also have to use disable_irq_nosync as serial_omap_irq
         calls pm_runtime_get_sync.
      
      Fixes: 2a0b965c (serial: omap: Add support for optional wake-up)
      Cc: stable@vger.kernel.org # v3.13+
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d758c9c1
    • S
  18. 18 3月, 2014 2 次提交
  19. 14 2月, 2014 3 次提交
  20. 01 11月, 2013 1 次提交
  21. 30 10月, 2013 2 次提交