Skip to content
  1. Aug 27, 2006
    • Daniel Ritz's avatar
      [PATCH] PCI: use PCBIOS as last fallback · 954c0b7c
      Daniel Ritz authored
      
      
      there was a change in 2.6.17 which affected the order in which the PCI
      access methods are probed.  this gives regressions on some machines with
      broken BIOS.  the problem is that PCBIOS sometimes reports last bus wrong,
      leaving cardbus non-funcational.  previously those system worked fine with
      direct access.
      
      The patch changes the PCI init code to have PCBIOS as last fallback, yet
      the PCBIOS code still has to run first to set pcibios_last_bus to the value
      reported by the BIOS.  this is needed in case legacy PCI probing
      (arch/i386/pci/legacy.c) is used to detect peer busses.  using direct
      access if available fixes the cardbus problems.
      
      Signed-off-by: default avatarDaniel Ritz <daniel.ritz@gmx.ch>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      954c0b7c
    • Hans de Goede's avatar
      [PATCH] hwmon: abituguru timeout fixes · faf9b616
      Hans de Goede authored
      
      
      This patch contains 2 sets of fixes for the abituguru:
       1) Much improved timeout handling, drasticly reducing the amount of
          timeout errors on some motherboards
       2) Fix the exit paths in the bank1 sensor type detect code to always
          restore the original settings even on an error. Without this our
          special test settings could remain seriously confusing the system
          BIOS's setup menu.
      
      Both are very much related and are must haves, to avoid messing up the
      uguru CMOS settings.
      
      Detailed changes:
      - Much improved timeout / wait for status handling. Many thanks to Sunil
        Kumar, for all his testing, ideas and patches! The code now first busy
        waits, polling the uguru for the expected status as this usually
        succeeds pretty quickly (within 90 reads). To avoid unnecessary CPU burn
        in timeout conditions, the amount of busy waiting has been halved from
        previous versions (120 tries instead of 250). This is not a problem,
        because this version goes to sleep after 120 attemps for 1 jiffy and
        then tries again, it does this sleep and try again 5 times before
        finally giving up. This (almost?) completly removes the timeout errors
        some people have seen regulary. Apparently some older uguru versions
        sometimes are distracted for a (relatively) long time. This solves this.
      - These timeout errors not only occur in the sending address part of
        reading the uguru but also in the wait for read state, so errors in
        this state are now handled as retryable just like send address state
        errors and are only logged and reported to userspace if 3 executive
        tries fail.
      - Fix a very nasty bug in the bank1 sensor type detection code, where it
        would not restore the original settings in any of the error paths!
      - Since not successfully restoring the original settings can seriously
        confuse the system BIOS (hang when entering the relevant setup menu),
        we now try restoring them 3 times before giving up.
      
      Signed-off-by: default avatarHans de Goede <j.w.r.degoede@hhs.nl>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      faf9b616
    • David Brownell's avatar
      [PATCH] i2c: tps65010 build fixes · 4801bc25
      David Brownell authored
      
      
      The tps65010.c driver in the main tree never got updated with
      build fixes since the last batch of I2C driver changes; and the
      genirq trigger flags were updated wierdly too.
      
      This also includes a minor tweak to reduce the frequency used to
      poll for unplug-the-AC-power on the TPS chips that don't provide
      relevant IRQs.  It _would_ be nice to sense whether there's even
      a battery, but that'd normally be an HDQ/1-wire interface to a
      smart battery, and such APIs aren't standardized.
      
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4801bc25
    • Greg Kroah-Hartman's avatar
  2. Aug 26, 2006
  3. Aug 25, 2006
  4. Aug 24, 2006