1. 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
  2. 30 4月, 2012 2 次提交
    • A
      8250_pci: fix pch uart matching · aaa10eb1
      Arnaud Patard 提交于
      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: NErwan 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: NArnaud Patard <apatard@hupstream.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aaa10eb1
    • J
      TTY: n_tty, do not dereference user buffer · 3fa10cc8
      Jiri Slaby 提交于
      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: NJiri Slaby <jslaby@suse.cz>
      Reported-by: NEmil Goode <emilgoode@gmail.com>
      Cc: Howard Chu <hyc@symas.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fa10cc8
  3. 25 4月, 2012 1 次提交
  4. 20 4月, 2012 1 次提交
  5. 19 4月, 2012 7 次提交
    • D
      serial/8250_pci: fix suspend/resume vs init/exit quirks · 5f1a3895
      Dan Williams 提交于
      Commit e86ff4a6 "serial/8250_pci: init-quirk msi support for kt serial
      controller" introduced a regression in suspend/resume by causing msi's
      to be enabled twice without an intervening disable.
      
      00:16.3 Serial controller: Intel Corporation Patsburg KT Controller (rev 05) (prog-if 02 [16550])
             Subsystem: Intel Corporation Device 7270
             Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 72
             I/O ports at 4080 [size=8]
             Memory at d1c30000 (32-bit, non-prefetchable) [size=4K]
             Capabilities: [c8] Power Management version 3
             Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
             Kernel driver in use: serial
      
      [  365.250523] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:16.3/msi_irqs'
      [  365.250525] Modules linked in: nls_utf8 ipv6 uinput sg iTCO_wdt
        iTCO_vendor_support ioatdma dca i2c_i801 i2c_core wmi sd_mod ahci libahci isci
        libsas libata scsi_transport_sas [last unloaded: scsi_wait_scan]
      [  365.250540] Pid: 9030, comm: kworker/u:1 Tainted: G        W    3.3.0-isci-3.0.213+ #1
      [  365.250542] Call Trace:
      [  365.250545]  [<ffffffff8115e955>] ? sysfs_add_one+0x99/0xad
      [  365.250548]  [<ffffffff8102db8b>] warn_slowpath_common+0x85/0x9e
      [  365.250551]  [<ffffffff8102dc96>] warn_slowpath_fmt+0x6e/0x70
      [  365.250555]  [<ffffffff8115e8fa>] ? sysfs_add_one+0x3e/0xad
      [  365.250558]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
      [  365.250561]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
      [  365.250564]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
      [  365.250567]  [<ffffffff8115e8b4>] ? sysfs_pathname+0x3c/0x44
      [  365.250570]  [<ffffffff8115e955>] sysfs_add_one+0x99/0xad
      [  365.250573]  [<ffffffff8115f031>] create_dir+0x72/0xa5
      [  365.250577]  [<ffffffff8115f194>] sysfs_create_dir+0xa2/0xbe
      [  365.250581]  [<ffffffff81262463>] kobject_add_internal+0x126/0x1f8
      [  365.250585]  [<ffffffff8126255b>] kset_register+0x26/0x3f
      [  365.250588]  [<ffffffff8126275a>] kset_create_and_add+0x62/0x7c
      [  365.250592]  [<ffffffff81293619>] populate_msi_sysfs+0x34/0x103
      [  365.250595]  [<ffffffff81293e1c>] pci_enable_msi_block+0x1b3/0x216
      [  365.250599]  [<ffffffff81303f7c>] try_enable_msi+0x13/0x17
      [  365.250603]  [<ffffffff81303fb3>] pciserial_resume_ports+0x21/0x42
      [  365.250607]  [<ffffffff81304041>] pciserial_resume_one+0x50/0x57
      [  365.250610]  [<ffffffff81283e1a>] pci_legacy_resume+0x38/0x47
      [  365.250613]  [<ffffffff81283e7d>] pci_pm_restore+0x54/0x87
      [  365.250616]  [<ffffffff81283e29>] ? pci_legacy_resume+0x47/0x47
      [  365.250619]  [<ffffffff8131e9e8>] dpm_run_callback+0x48/0x7b
      [  365.250623]  [<ffffffff8131f39a>] device_resume+0x342/0x394
      [  365.250626]  [<ffffffff8131f5b7>] async_resume+0x21/0x49
      
      That patch has since been reverted, but by inspection it seems that
      pciserial_suspend_ports() should be invoking .exit() quirks to release
      resources acquired during .init().
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f1a3895
    • S
      serial/8250_pci: Clear FIFOs for Intel ME Serial Over Lan device on BI · 0ad372b9
      Sudhakar Mamillapalli 提交于
      When using Serial Over Lan (SOL) over the virtual serial port in a Intel
      management engine (ME) device, on device reset the serial FIFOs need to
      be cleared to keep the FIFO indexes in-sync between the host and the
      engine.
      
      On a reset the serial device assertes BI, so using that as a cue FIFOs
      are cleared.  So for this purpose a new handle_break callback has been
      added.  One other problem is that the serial registers might temporarily
      go to 0 on reset of this device.  So instead of using the IER register
      read, if 0 returned use the ier value in uart_8250_port. This is hidden
      under a custom serial_in.
      
      Cc: Nhan H Mai <nhan.h.mai@intel.com>
      Signed-off-by: NSudhakar Mamillapalli <sudhakar@fb.com>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ad372b9
    • T
      pch_uart: Fix dma channel unallocated issue · af6d17cd
      Tomoya MORINAGA 提交于
      This driver anticipates pch_uart_verify_port() is not called
      during installation.
      However, actually pch_uart_verify_port() is called during
      installation.
      As a result, memory access violation occurs like below.
      
      0. initial value: use_dma=0
      1. starup()
          - dma channel is not allocated because use_dma=0
      2. pch_uart_verify_port()
          - Set use_dma=1
      3. UART processing acts DMA mode because use_dma=1
           - memory access violation occurs!
      
      This patch fixes the issue.
      
      Solution:
      Whenever pch_uart_verify_port() is called and then
      dma channel is not allocated, the channel should be allocated.
      Signed-off-by: NTomoya MORINAGA <tomoya.rohm@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af6d17cd
    • A
      ARM: clps711x: serial driver hungs are a result of call disable_irq within ISR · 7a6fbc9a
      Alexander Shiyan 提交于
      Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result
      of call disable_irq from ISR. synchronize_irq waits for end of interrupt
      and goes to infinite loop. This patch fix this problem.
      Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a6fbc9a
    • D
      tegra, serial8250: add ->handle_break() uart_port op · bf03f65b
      Dan Williams 提交于
      The "KT" serial port has another use case for a "received break" quirk,
      so before adding another special case to the 8250 core take this
      opportunity to push such quirks out of the core and into a uart_port op.
      
      Stephen says:
      "If the callback function is to no longer live in 8250.c itself,
       arch/arm/mach-tegra/devices.c isn't logically a good place to put it,
       and that file will be going away once we get rid of all the board files
       and move solely to device tree."
      
      ...so since 8250_pci.c houses all the quirks for pci serial devices this
      quirk is similarly housed in of_serial.c.  Once the open firmware
      conversion completes the infrastructure details
      (include/linux/of_serial.h, and the export) can all be removed to make
      this self contained to of_serial.c.
      
      Cc: Nhan H Mai <nhan.h.mai@intel.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: Olof Johansson <olof@lixom.net>
      [stephen: kill CONFIG_SERIAL_TEGRA in favor just using CONFIG_ARCH_TEGRA]
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSudhakar Mamillapalli <sudhakar@fb.com>
      Reported-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NStephen Warren <swarren@wwwdotorg.org>
      Tested-by: NStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf03f65b
    • G
      OMAP2+: UART: Remove cpu checks for populating errata flags · 7c77c8de
      Govindraj.R 提交于
      Currently the errata is populated based on cpu checks this can
      be removed and replaced with module version check of uart ip block.
      MVR reg is provided within the uart reg map use the same
      to populate the errata and thus now errata population and handling
      can be managed within the driver itself.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c77c8de
    • R
      serial: pl011: implement workaround for CTS clear event issue · 4fd0690b
      Rajanikanth H.V 提交于
      Problem Observed:
      - interrupt status is set by rising or falling edge on CTS line
      - interrupt status is cleared on a .0. to .1. transition of the
        interrupt-clear register bit 1.
      - interrupt-clear register is reset by hardware once the interrupt
        status is .0..
        Remark: It seems not possible to read this register back by the
        CPU though, but internally this register exists.
      - when simultaneous set and reset event on the interrupt status
        happens, then the set-event has priority and the status remains
        .1.. As a result the interrupt-clear register is not reset to
        .0., and no new .0. to .1. transition can be detected on it when
        writing a .1. to it.
        This implies race condition, the clear must be performed at least
        one UARTCLK the riding edge of CTS RIS interrupt.
      
      Fix:
        Instead of resetting UART as done in commit
        c16d51a3
        "amba pl011: workaround for uart registers lockup" do the
        following:
      
        write .0. and then  .1. to the interrupt-clear register to make
        sure that this transition is detected. According to the datasheet
        writing a .0. does not have any effect, but actually it allows to
        reset the internal interrupt-clear register.
      
        Take into account:
        The .0. needs to last at least for one clk_uart clock period
        (~ 38 MHz, 26.08ns)
      
      This way we can do away with the tasklet and keep only a tiny
      fix triggered by the variant flag introduced in this patch.
      Signed-off-by: NGuillaume Jaunet <guillaume.jaunet@stericsson.com>
      Signed-off-by: NChristophe Arnal <christophe.arnal@stericsson.com>
      Signed-off-by: NMatthias Locher  <Matthias.Locher@stericsson.com>
      Signed-off-by: NRajanikanth H.V <rajanikanth.hv@stericsson.com>
      Reviewed-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fd0690b
  6. 14 4月, 2012 1 次提交
    • J
      TTY: hvc, fix TTY refcounting · a2f89206
      Jiri Slaby 提交于
      A -next commit "TTY: HVC, use tty from tty_port" switched the driver
      to use tty_port helper for tty refcounting. But it omitted to remove
      manual tty refcounting from open, close and hangup. So now we are
      getting random crashes caused by use-after-free:
      Unable to handle kernel paging request for data at address 0xc0000003f9d550
      Faulting instruction address: 0xc0000000001b7f40
      Oops: Kernel access of bad area, sig: 11 [#1]
      ...
      NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
      ...
      NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
      LR [c0000000001b7f14] .__kmalloc+0x44/0x230
      Call Trace:
      [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
      [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
      [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
      [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
      [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
      [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
      [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
      [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
      
      Fix that by complete removal of tty_kref_get/put in open/close/hangup
      paths.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reported-and-tested-by: NMichael Neuling <mikey@neuling.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2f89206
  7. 10 4月, 2012 27 次提交