1. 10 7月, 2006 4 次提交
    • A
      [SERIAL] 8250: sysrq deadlock fix · 68aa2c0d
      Andrew Morton 提交于
      Fix http://bugzilla.kernel.org/show_bug.cgi?id=6716
      
      Doing a sysrq over a serial line into an SMP machine presently deadlocks.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      68aa2c0d
    • Z
      [SERIAL] 8250: add tsi108 serial support · 3be91ec7
      Zang Roy-r61911 提交于
      The following patch gets rid of CONFIG_TSI108_BRIDGE.  I add UPIO_TSI to
      handle IIR and IER register in serial_in and serial_out.
      
      (1) the reason to rewrite serial_in:
      
          TSI108 rev Z1 version ERRATA.  Reading the UART's Interrupt
          Identification Register (IIR) clears the Transmit Holding Register
          Empty (THRE) and Transmit buffer Empty (TEMP) interrupts even if they
          are not enabled in the Interrupt Enable Register (IER).  This leads to
          loss of the interrupts.  Interrupts are not cleared when reading UART
          registers as 32-bit word.
      
      (2) the reason to rewrite serial_out:
      
          Check for UART_IER_UUE bit in the autoconfig routine.  This section
          of autoconfig is excluded for Tsi108/109 because bits 7 and 6 are
          reserved for internal use.  They are R/W bits.  In addition to
          incorrect identification, changing these bits (from 00) will make
          Tsi108/109 UART non-functional.
      Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3be91ec7
    • J
      [SERIAL] IP22: fix serial console hangs · c65b15cf
      Julien BLACHE 提交于
      The patch below fixes serial console hangs as seen on IP22
      machines. Typically, while booting, the machine hangs for ~1 minute
      displaying "INIT: ", then the same thing happens again when init
      enters in the designated runlevel and finally the getty process on
      ttyS0 hangs indefinitely (though strace'ing it helps).
      
      strace (-e raw=ioctl, otherwise the ioctl() translation is utterly
      bogus) reveals that getty hangs on ioctl() 0x540f which happens to be
      TCSETSW (I saw it hang on another console ioctl() but couldn't
      reproduce that one).
      
      A diff between ip22zilog and sunzilog revealed the following
      differences:
       1. the channel A flag being set on up.port.flags instead of up.flags
       2. the channel A flag being set on what is marked as being channel B
       3. sunzilog has a call to uart_update_timeout(port, termios->c_cflag, baud);
          at the end of sunzilog_set_termios(), which ip22zilog lacks (on
          purpose ?)
      
      The patch below addresses point 1 and fixes the serial console hangs
      just fine. However point 2 should be investigated by someone familiar
      with the IP22 Zilog; it's probably OK as is but even if it is, a
      comment in ip22zilog.c is badly needed.
      
      Point 3 is left as an exercise for whoever feels like digging into
      ip22zilog :)
      
      These are the main obvious differences between ip22zilog and
      sunzilog. Newer versions of sunzilog (Linus's git tree as of today)
      are more close to ip22zilog as the sbus_{write,read}b have been
      changed into simple {write,read}b, which shrinks the diff by a fair
      amount. Resyncing both drivers should be doable in a few hours time
      now for someone familiar with the IP22 Zilog hardware.
      Signed-off-by: NJulien BLACHE <jb@jblache.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c65b15cf
    • M
      [SERIAL] dz: Fix compilation error · d608ab99
      Martin Michlmayr 提交于
      Fix the following compilation error in the dz serial driver that got
      introduced with the "kernel console should send CRLF not LFCR" change.
      
        CC      drivers/serial/dz.o
      drivers/serial/dz.c: In function 'dz_console_putchar':
      drivers/serial/dz.c:679: error: 'uport' undeclared (first use in this function)
      drivers/serial/dz.c:679: error: (Each undeclared identifier is reported only once
      drivers/serial/dz.c:679: error: for each function it appears in.)
      Signed-off-by: NMartin Michlmayr <tbm@cyrius.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d608ab99
  2. 09 7月, 2006 2 次提交
  3. 08 7月, 2006 1 次提交
    • D
      [PATCH] Fix cpufreq vs hotplug lockdep recursion. · a496e25d
      Dave Jones 提交于
      [ There's some not quite baked bits in cpufreq-git right now
        so sending this on as a patch instead ]
      
      On Thu, 2006-07-06 at 07:58 -0700, Tom London wrote:
      
      > After installing .2356 I get this each time I boot:
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > -------------------------------------------------------
      > S06cpuspeed/1620 is trying to acquire lock:
      >  (dbs_mutex){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
      >
      > but task is already holding lock:
      >  (cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
      >
      > which lock already depends on the new lock.
      >
      
      make sure the cpu hotplug recursive mutex (yuck) is taken early in the
      cpufreq codepaths to avoid a AB-BA deadlock.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a496e25d
  4. 06 7月, 2006 33 次提交