1. 12 Aug, 2013 14 commits
    • Jingoo Han's avatar
      serial: icom: fix casting warning · 5a7daed8
      Jingoo Han authored
      icom_port->uart_port.membase is (unsigned char __iomem *); thus,
      casting (unsigned char __iomem *) is necessary to fix the
      following warning. Also, local symbols are staticized.
      
      drivers/tty/serial/icom.c:108:26: warning: symbol 'start_proc' was not declared. Should it be static?
      drivers/tty/serial/icom.c:116:26: warning: symbol 'stop_proc' was not declared. Should it be static?
      drivers/tty/serial/icom.c:123:25: warning: symbol 'int_mask_tbl' was not declared. Should it be static?
      drivers/tty/serial/icom.c:1569:54: warning: incorrect type in assignment (different address spaces)
      drivers/tty/serial/icom.c:1569:54:    expected unsigned char [noderef] <asn:2>*membase
      drivers/tty/serial/icom.c:1569:54:    got char *<noident>
      drivers/tty/serial/icom.c:1090:9: warning: cast truncates bits from constant value (ffffff7f becomes 7f)
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a7daed8
    • Jingoo Han's avatar
      serial: timbuart: Staticize local symbols · edd173da
      Jingoo Han authored
      These local symbols are used only in this file.
      Fix the following sparse warnings:
      
      drivers/tty/serial/timbuart.c:165:6: warning: symbol 'timbuart_handle_rx_port' was not declared. Should it be static?
      drivers/tty/serial/timbuart.c:187:6: warning: symbol 'timbuart_tasklet' was not declared. Should it be static?
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edd173da
    • Jingoo Han's avatar
      serial: mrst_max3110: fix casting warning · 6602769b
      Jingoo Han authored
      max->port.membase is (unsigned char __iomem *); thus,
      casting (unsigned char __iomem *) is necessary to fix
      the following warning. Also, serial_m3110_ops() is staticized.
      
      drivers/tty/serial/mrst_max3110.c:716:17: warning: symbol 'serial_m3110_ops' was not declared. Should it be static?
      drivers/tty/serial/mrst_max3110.c:847:27: warning: incorrect type in assignment (different address spaces)
      drivers/tty/serial/mrst_max3110.c:847:27:    expected unsigned char [noderef] <asn:2>*membase
      drivers/tty/serial/mrst_max3110.c:847:27:    got void *<noident>
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6602769b
    • Jingoo Han's avatar
      serial: 8250_early: fix comparison of different types · 75474b6f
      Jingoo Han authored
      Fix the following sparse warning:
      
      drivers/tty/serial/8250/8250_early.c:196:26: error: incompatible types in comparison expression (different type sizes)
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75474b6f
    • Jingoo Han's avatar
      serial: samsung: fix casting warning · 9fdedf5d
      Jingoo Han authored
      port->membase is (unsigned char __iomem *), not (unsigned long *)
      __set_bit() uses (unsigned long *) as the second argument.
      Thus, casting (unsigned long *)(unsigned long) is necessary
      to fix the following sparse warnings.
      
      drivers/tty/serial/samsung.c:142:33: warning: cast removes address space of expression
      drivers/tty/serial/samsung.c:161:33: warning: cast removes address space of expression
      drivers/tty/serial/samsung.c:176:33: warning: cast removes address space of expression
      drivers/tty/serial/samsung.c:526:40: warning: cast removes address space of expression
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9fdedf5d
    • Jingoo Han's avatar
      serial: sirf: Staticize local symbols · ada1f443
      Jingoo Han authored
      These local symbols are used only in this file.
      Fix the following sparse warnings:
      
      drivers/tty/serial/sirfsoc_uart.c:147:6: warning: symbol 'sirfsoc_uart_start_tx' was not declared. Should it be static?
      drivers/tty/serial/sirfsoc_uart.c:636:5: warning: symbol 'sirfsoc_uart_probe' was not declared. Should it be static?
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Acked-by: default avatarBarry Song <Baohua.Song@csr.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ada1f443
    • Qipan Li's avatar
      serial: sirf: make the driver also support USP-based UART · 5df83111
      Qipan Li authored
      Universal Serial Ports (USP) can be used as PCM, UART, SPI,
      I2S etc. this makes the USP work as UART. the basic work
      flow is same with UART controller, the main difference will
      be offset of registers and bits.
      
      this patch makes the old sirfsoc uart driver support both
      sirf UART and USP-based UART by making their differences
      become private data.
      Signed-off-by: default avatarQipan Li <Qipan.Li@csr.com>
      Signed-off-by: default avatarBarry Song <Baohua.Song@csr.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5df83111
    • Barry Song's avatar
      serial: sirf: add support for Marco chip · 909102db
      Barry Song authored
      the marco and coming new CSR multiple SoCs have SET/CLR pair for
      INTEN registers to avoid some read-modify-write.
      
      this patch adds support for this and make the driver support current
      up and coming mp SoCs.
      Signed-off-by: default avatarBarry Song <Baohua.Song@csr.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      909102db
    • Sascha Hauer's avatar
      serial: i.MX: evaluate linux,stdout-path property · f7d2c0bb
      Sascha Hauer authored
      devicetrees may have the linux,stdout-path property to specify the
      console. This patch adds support to the i.MX serial driver for this.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7d2c0bb
    • Sascha Hauer's avatar
      OF: Add helper for matching against linux,stdout-path · 5c19e952
      Sascha Hauer authored
      devicetrees may have a linux,stdout-path property in the chosen
      node describing the console device. This adds a helper function
      to match a device against this property so a driver can call
      add_preferred_console for a matching device.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: default avatarRob Herring <rob.herring@calxeda.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c19e952
    • Gabor Juhos's avatar
      tty: ar933x_uart: convert to use devm_* functions · a324e4de
      Gabor Juhos authored
      Use devm_* functions in order to simplify cleanup
      paths.
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a324e4de
    • Peter Hurley's avatar
      n_tty: Fix termios_rwsem lockdep false positive · aefceaf4
      Peter Hurley authored
      Lockdep reports a circular lock dependency between
      atomic_read_lock and termios_rwsem [1]. However, a lock
      order deadlock is not possible since CPU1 only holds a
      read lock which cannot prevent CPU0 from also acquiring
      a read lock on the same r/w semaphore.
      
      Unfortunately, lockdep cannot currently distinguish whether
      the locks are read or write for any particular lock graph,
      merely that the locks _were_ previously read and/or write.
      
      Until lockdep is fixed, re-order atomic_read_lock so
      termios_rwsem can be dropped and reacquired without
      triggering lockdep.
      
      Patch based on original posted here https://lkml.org/lkml/2013/8/1/510
      by Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      
      [1] Initial lockdep report from Artem Savkov <artem.savkov@gmail.com>
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.11.0-rc3-next-20130730+ #140 Tainted: G        W
       -------------------------------------------------------
       bash/1198 is trying to acquire lock:
        (&tty->termios_rwsem){++++..}, at: [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660
      
       but task is already holding lock:
        (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&ldata->atomic_read_lock){+.+...}:
              [<ffffffff811111cc>] validate_chain+0x73c/0x850
              [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0
              [<ffffffff81111a29>] lock_acquire+0x179/0x1d0
              [<ffffffff81d34b9c>] mutex_lock_interruptible_nested+0x7c/0x540
              [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660
              [<ffffffff816a3bb6>] tty_read+0x86/0xf0
              [<ffffffff811f21d3>] vfs_read+0xc3/0x130
              [<ffffffff811f2702>] SyS_read+0x62/0xa0
              [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b
      
       -> #0 (&tty->termios_rwsem){++++..}:
              [<ffffffff8111064f>] check_prev_add+0x14f/0x590
              [<ffffffff811111cc>] validate_chain+0x73c/0x850
              [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0
              [<ffffffff81111a29>] lock_acquire+0x179/0x1d0
              [<ffffffff81d372c1>] down_read+0x51/0xa0
              [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660
              [<ffffffff816a3bb6>] tty_read+0x86/0xf0
              [<ffffffff811f21d3>] vfs_read+0xc3/0x130
              [<ffffffff811f2702>] SyS_read+0x62/0xa0
              [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&ldata->atomic_read_lock);
                                      lock(&tty->termios_rwsem);
                                      lock(&ldata->atomic_read_lock);
         lock(&tty->termios_rwsem);
      
        *** DEADLOCK ***
      
       2 locks held by bash/1198:
        #0:  (&tty->ldisc_sem){.+.+.+}, at: [<ffffffff816ade04>] tty_ldisc_ref_wait+0x24/0x60
        #1:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff816aa0f0>] n_tty_read+0x1d0/0x660
      
       stack backtrace:
       CPU: 1 PID: 1198 Comm: bash Tainted: G        W    3.11.0-rc3-next-20130730+ #140
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
        0000000000000000 ffff880019acdb28 ffffffff81d34074 0000000000000002
        0000000000000000 ffff880019acdb78 ffffffff8110ed75 ffff880019acdb98
        ffff880019fd0000 ffff880019acdb78 ffff880019fd0638 ffff880019fd0670
       Call Trace:
        [<ffffffff81d34074>] dump_stack+0x59/0x7d
        [<ffffffff8110ed75>] print_circular_bug+0x105/0x120
        [<ffffffff8111064f>] check_prev_add+0x14f/0x590
        [<ffffffff81d3ab5f>] ? _raw_spin_unlock_irq+0x4f/0x70
        [<ffffffff811111cc>] validate_chain+0x73c/0x850
        [<ffffffff8110ae0f>] ? trace_hardirqs_off_caller+0x1f/0x190
        [<ffffffff811117e0>] __lock_acquire+0x500/0x5d0
        [<ffffffff81111a29>] lock_acquire+0x179/0x1d0
        [<ffffffff816aa3bb>] ? n_tty_read+0x49b/0x660
        [<ffffffff81d372c1>] down_read+0x51/0xa0
        [<ffffffff816aa3bb>] ? n_tty_read+0x49b/0x660
        [<ffffffff816aa3bb>] n_tty_read+0x49b/0x660
        [<ffffffff810e4130>] ? try_to_wake_up+0x210/0x210
        [<ffffffff816a3bb6>] tty_read+0x86/0xf0
        [<ffffffff811f21d3>] vfs_read+0xc3/0x130
        [<ffffffff811f2702>] SyS_read+0x62/0xa0
        [<ffffffff815e24ee>] ? trace_hardirqs_on_thunk+0x3a/0x3f
        [<ffffffff81d45259>] system_call_fastpath+0x16/0x1b
      Reported-by: default avatarArtem Savkov <artem.savkov@gmail.com>
      Reported-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aefceaf4
    • Jingoo Han's avatar
      serial: pxa: Staticize local symbols · 6c62cc0d
      Jingoo Han authored
      These local symbols are used only in this file.
      Fix the following sparse warnings:
      
      drivers/tty/serial/pxa.c:793:17: warning: symbol 'serial_pxa_pops' was not declared. Should it be static?
      drivers/tty/serial/pxa.c:971:12: warning: symbol 'serial_pxa_init' was not declared. Should it be static?
      drivers/tty/serial/pxa.c:986:13: warning: symbol 'serial_pxa_exit' was not declared. Should it be static?
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c62cc0d
    • Daniel Mack's avatar
      tty: serial: pxa: remove old cruft · 331b3734
      Daniel Mack authored
      This #if-0'd block wouldn't compile, so let's dispose it.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      331b3734
  2. 05 Aug, 2013 5 commits
  3. 04 Aug, 2013 7 commits
  4. 03 Aug, 2013 14 commits