1. 07 Jan, 2009 1 commit
    • Jean Delvare's avatar
      hwmon: Check for ACPI resource conflicts · b9acb64a
      Jean Delvare authored
      Check for ACPI resource conflicts in hwmon drivers. I've included
      all Super-I/O and PCI drivers.
      I've voluntarily left out:
      * Vendor-specific drivers: if they conflicted on any system, this would
        pretty much mean that they conflict on all systems, and we would know
        by now.
      * Legacy ISA drivers (lm78 and w83781d): they only support chips found
        on old designs were ACPI either wasn't supported or didn't deal with
        thermal management.
      * Drivers accessing the I/O resources indirectly (e.g. through SMBus):
        the checks are already done where they belong, i.e. in the bus drivers.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Acked-by: default avatarDavid Hubbard <david.c.hubbard@gmail.com>
  2. 07 Feb, 2008 1 commit
    • Jean Delvare's avatar
      hwmon: Let the user override the detected Super-I/O device ID · 67b671bc
      Jean Delvare authored
      While it is possible to force SMBus-based hardware monitoring chip
      drivers to drive a not officially supported device, we do not have this
      possibility for Super-I/O-based drivers. That's unfortunate because
      sometimes newer chips are fully compatible and just forcing the driver
      to load would work. Instead of that we have to tell the users to
      recompile the kernel driver, which isn't an easy task for everyone.
      So, I propose that we add a module parameter to all Super-I/O based
      hardware monitoring drivers, letting advanced users force the driver
      to load on their machine. The user has to provide the device ID of a
      supposedly compatible device. This requires looking at the source code or
      a datasheet, so I am confident that users can't randomly force a driver
      without knowing what they are doing. Thus this should be relatively safe.
      As you can see from the code, the implementation is pretty simple and
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Acked-by: default avatarHans de Goede <j.w.r.degoede@hhs.nl>
      Signed-off-by: default avatarMark M. Hoffman <mhoffman@lightlink.com>
  3. 09 Oct, 2007 2 commits
  4. 19 Jul, 2007 3 commits
  5. 08 May, 2007 1 commit
    • Jean Delvare's avatar
      hwmon: Request the I/O regions in platform drivers · ce7ee4e8
      Jean Delvare authored
      My understanding of the resource management in the Linux 2.6 device
      driver model is that the devices should declare their resources, and
      then when a driver attaches to a device, it should request the
      resources it will be using, so as to mark them busy. This is how the
      PCI and PNP subsystems work, you can clearly see the two levels of
      resources (declaration and request) in /proc/ioports for these
      So I believe that our platform hardware monitoring drivers should
      follow the same logic. At the moment, we only declare the resources
      but we do not request them. This patch adds the I/O region request
      and release calls.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Acked-by: default avatarJuerg Haefliger <juergh@gmail.com>
  6. 14 Feb, 2007 2 commits
    • Jean Delvare's avatar
      hwmon/f71805f: Fix a race condition · a117dddf
      Jean Delvare authored
      I think I introduced a potential race condition bug with commit
      . I didn't realize it
      back then, but platform_device_put and platform_device_release
      both appear to free the platform data associated with the device.
      This makes an explicit kfree redundant at best, and maybe even
      racy, as it might occur while someone still holds a reference
      to the platform device.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
    • Jean Delvare's avatar
      hwmon: Simplify the locking model of two drivers · 7f999aa7
      Jean Delvare authored
      Many hardware monitoring drivers use two different mutexes, one to
      protect their per-device data structure, and one to protect the
      access to the device registers. These mutexes are essentially
      redundant, as the drivers are transfering values between the device
      registers and the data cache, so they almost always end up holding
      both mutexes at the same time. Using a single mutex will make the
      code more simple and faster.
      I am changing only two of the affected drivers here, the authors
      of the other affected drivers are welcome to submit similar patches
      if they want.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
  7. 12 Dec, 2006 8 commits
  8. 28 Sep, 2006 2 commits
  9. 22 Jun, 2006 1 commit
  10. 23 Mar, 2006 2 commits
  11. 06 Feb, 2006 1 commit
    • Jean Delvare's avatar
      [PATCH] hwmon: New f71805f driver · e53004e2
      Jean Delvare authored
      This is my f71805f hardware monitoring driver ported from lm_sensors
      to Linux 2.6. This new driver differs from the other hardware monitoring
      drivers in that it is implemented as a platform driver. This might not
      be optimal yet (we would probably need a generic infrastructure and bus
      type for Super-I/O logical devices) but it is certainly much better than
      the i2c-isa solution.
      Note that this driver requires lm_sensors CVS. I hope to get it
      released as 2.10.0 soon.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>