1. 13 6月, 2012 8 次提交
  2. 03 6月, 2012 1 次提交
    • L
      tty: Revert the tty locking series, it needs more work · f309532b
      Linus Torvalds 提交于
      This reverts the tty layer change to use per-tty locking, because it's
      not correct yet, and fixing it will require some more deep surgery.
      
      The main revert is d29f3ef3 ("tty_lock: Localise the lock"), but
      there are several smaller commits that built upon it, they also get
      reverted here. The list of reverted commits is:
      
        fde86d31 - tty: add lockdep annotations
        8f6576ad - tty: fix ldisc lock inversion trace
        d3ca8b64 - pty: Fix lock inversion
        b1d679af - tty: drop the pty lock during hangup
        abcefe5f - tty/amiserial: Add missing argument for tty_unlock()
        fd11b42e - cris: fix missing tty arg in wait_event_interruptible_tty call
        d29f3ef3 - tty_lock: Localise the lock
      
      The revert had a trivial conflict in the 68360serial.c staging driver
      that got removed in the meantime.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f309532b
  3. 21 5月, 2012 1 次提交
  4. 18 5月, 2012 6 次提交
  5. 16 5月, 2012 1 次提交
  6. 15 5月, 2012 3 次提交
  7. 12 5月, 2012 2 次提交
  8. 11 5月, 2012 2 次提交
  9. 10 5月, 2012 3 次提交
  10. 08 5月, 2012 1 次提交
  11. 05 5月, 2012 3 次提交
  12. 03 5月, 2012 5 次提交
  13. 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
  14. 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
    • L
      tty/serial/pmac_zilog: Fix "nobody cared" IRQ message · 810b4de2
      Larry Finger 提交于
      Following commit a79dd5ae titled "tty/serial/pmac_zilog: Fix suspend & resume",
      my Powerbook G4 Titanium showed the following stack dump:
      
      [   36.878225] irq 23: nobody cared (try booting with the "irqpoll" option)
      [   36.878251] Call Trace:
      [   36.878291] [dfff3f00] [c000984c] show_stack+0x7c/0x194 (unreliable)
      [   36.878322] [dfff3f40] [c00a6868] __report_bad_irq+0x44/0xf4
      [   36.878339] [dfff3f60] [c00a6b04] note_interrupt+0x1ec/0x2ac
      [   36.878356] [dfff3f80] [c00a48d0] handle_irq_event_percpu+0x250/0x2b8
      [   36.878372] [dfff3fd0] [c00a496c] handle_irq_event+0x34/0x54
      [   36.878389] [dfff3fe0] [c00a753c] handle_fasteoi_irq+0xb4/0x124
      [   36.878412] [dfff3ff0] [c000f5bc] call_handle_irq+0x18/0x28
      [   36.878428] [deef1f10] [c000719c] do_IRQ+0x114/0x1cc
      [   36.878446] [deef1f40] [c0015868] ret_from_except+0x0/0x1c
      [   36.878484] --- Exception: 501 at 0xf497610
      [   36.878489]     LR = 0xfdc3dd0
      [   36.878497] handlers:
      [   36.878510] [<c02b7424>] pmz_interrupt
      [   36.878520] Disabling IRQ #23
      
      From an E-mail exchange about this problem, Andreas Schwab noticed a typo
      that resulted in the wrong condition being tested.
      
      The patch also corrects 2 typos that incorrectly report why an error branch
      is being taken.
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      810b4de2
  15. 25 4月, 2012 1 次提交
    • S
      serial i.MX: do not depend on grouped clocks · 3a9465fa
      Sascha Hauer 提交于
      the current i.MX clock support groups together unrelated clocks
      to a single clock which is then used by the driver. This can't
      be accomplished with the generic clock framework so we instead
      request the individual clocks in the driver. For i.MX there are
      generally three different clocks:
      
      ipg: bus clock (needed to access registers)
      ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
      per: bit clock, pixel clock
      
      This patch changes the driver to request the individual clocks.
      Currently all clk_get will get the same clock until the SoCs
      are converted to the generic clock framework
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      3a9465fa