1. 14 Sep, 2007 1 commit
    • Larry Finger's avatar
      [PATCH] bcm43xx: Fix cancellation of work queue crashes · 3f708697
      Larry Finger authored
      A crash upon booting that is caused by bcm43xx has been reported [1] and
      found to be due to a work queue being reinitialized while work on that
      queue is still pending. This fix modifies the shutdown of work queues and
      prevents periodic work from being requeued during shutdown. With this patch,
      no more crashes on reboot were observed by the original reporter. I do not
      get that particular failure on my system; however, when running a large
      number of ifdown/ifup sequences, my system would kernel panic with the
      'caps lock' light blinking at roughly a 1 Hz rate. In addition, there were
      infrequent failures in the firmware that resulted in 'IRQ READY TIMEOUT'
      errors. With this patch, no more of the first type of failure occur, and
      incidence of the second type is greatly reduced.
      
      [1] http://bugzilla.kernel.org/show_bug.cgi?id=8937Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Acked-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3f708697
  2. 11 Sep, 2007 13 commits
  3. 10 Sep, 2007 24 commits
  4. 09 Sep, 2007 2 commits
    • David Brownell's avatar
      i2c-algo-bit: Read block data bugfix · 939bc494
      David Brownell authored
      This fixes a bug in the way i2c-algo-bit handles I2C_M_RECV_LEN,
      used to implement i2c_smbus_read_block_data().  Previously, in the
      absence of PEC (rarely used!) it would NAK the "length" byte:
      
      	S addr Rd [A] [length] NA
      
      That prevents the subsequent data bytes from being read:
      
      	S addr Rd [A] [length] { A [data] }* NA
      
      The primary fix just reorders two code blocks, so the length used
      in the "should I NAK now?" check incorporates the data which it
      just read from the slave device.
      
      However, that move also highlighted other fault handling glitches.
      This fixes those by abstracting the RX path ack/nak logic, so it
      can be used in more than one location.  Also, a few CodingStyle
      issues were also resolved.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      939bc494
    • Jean Delvare's avatar
      i2c-pxa: Fix adapter number · 51e5709a
      Jean Delvare authored
      It turns out that platform_device.id is a "u32" so testing it for being
      nonnegative is useless when setting up an i2c adapte.  Instead,
      do what the platform_bus code does and test it against the value "-1".
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      51e5709a