31 Mar, 2009

3 commits


18 Feb, 2009

1 commit

  • This patch fixes a number of cases where things were not properly
    cleaned up when acpi_check_resource_conflict() returned an error,
    causing oopses such as the one reported here:
    https://bugzilla.redhat.com/show_bug.cgi?id=483208

    Signed-off-by: Hans de Goede
    Signed-off-by: Jean Delvare

    Hans de Goede
     

07 Jan, 2009

2 commits

  • Signed-off-by: Jean Delvare
    Acked-by: Hans de Goede
    Acked-by: David Hubbard

    Jean Delvare
     
  • 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: Jean Delvare
    Acked-by: David Hubbard

    Jean Delvare
     

08 Feb, 2008

2 commits

  • While the W83627EHF/EHG has only 6 VID pins, the W83627DHG has 8 VID
    pins, to support VRD 11.0. Add support for this.

    Signed-off-by: Jean Delvare
    Signed-off-by: Mark M. Hoffman

    Jean Delvare
     
  • 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
    unintrusive.

    Signed-off-by: Jean Delvare
    Acked-by: Hans de Goede
    Signed-off-by: Mark M. Hoffman

    Jean Delvare
     

03 Jan, 2008

1 commit

  • The VID input level change has been reported to cause trouble. Be more
    careful in this respect:
    * Only change the level on the W83627EHF/EHG. The W83627DHG is more
    complex in this respect.
    * Don't change the level if the VID pins are in output mode.
    * Only set the level to TTL if VRM 9.x is used.

    Signed-off-by: Jean Delvare
    Signed-off-by: Mark M. Hoffman

    Jean Delvare
     

10 Oct, 2007

2 commits


13 Aug, 2007

2 commits

  • Don't assume that the default bank is 0. For one thing, we don't even
    set it to 0 when the driver is loaded, so the initial state might be
    different. For another, something (say, the BIOS) might access the chip
    and leave with the bank set to something different, so assuming that
    the bank value is 0 is not safe.

    Signed-off-by: Jean Delvare
    Signed-off-by: Mark M. Hoffman

    Jean Delvare
     
  • This patch forces the driver to read the fan divider values during early init.
    Otherwise, a call to store_fan_min() could access uninitialized variables.

    Signed-off-by: Mark M. Hoffman
    Signed-off-by: Jean Delvare

    Mark M. Hoffman
     

20 Jul, 2007

9 commits


24 Apr, 2007

1 commit


18 Apr, 2007

1 commit

  • Users have been complaining about the w83627ehf driver flooding their logs
    with debug messages like:

    w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128

    or:

    w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8

    The reason is that we failed to actually write the LSB of the encoded clock
    divider value for that fan, causing the next read to report the same old value
    again and again.

    Additionally, the fan number was improperly reported, making the bug harder to
    find.

    Signed-off-by: Jean Delvare
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

15 Feb, 2007

1 commit


13 Dec, 2006

1 commit


19 Oct, 2006

1 commit


29 Sep, 2006

3 commits

  • hwmon: Remove Yuan Mu's address

    Yuan Mu no longer works at Winbond.

    I wish to publicly thank Yuan for his help with Winbond hardware
    monitoring chips support during the past 10 months.

    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     
  • w83627ehf: Fix unchecked return status

    Fix: check return value from device_create_file()
    Fix: call device_remove_file() on error and module unload
    Fix: call hwmon_device_register() after device_create_file() to eliminate race

    Signed-off-by: David Hubbard
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    David Hubbard
     
  • This patch adds long-awaited support for automatic fan modes. Based on
    the work of Yuan Mu from Winbond, I finished the support with the great
    help of David Hubbard.

    Signed-off-by: Yuan Mu
    Signed-off-by: Rudolf Marek
    Signed-off-by: David Hubbard
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Rudolf Marek
     

27 Sep, 2006

1 commit

  • i2c-isa: Restore driver owner

    Commit 2b48716d1d2f2edb1e7cbc5ecf1cb2cb39373e33 back in January
    2006 was a bit overzealous. It removed .owner from all i2c drivers,
    including i2c-isa ones, while they still need it.

    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     

23 Jun, 2006

2 commits


24 Mar, 2006

2 commits


06 Jan, 2006

2 commits


29 Oct, 2005

2 commits

  • Use kzalloc instead of kmalloc+memset in all hardware monitoring
    drivers.

    Signed-off-by: Deepak Saxena
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Deepak Saxena
     
  • This patch changes w83627hf and w83627ehf drivers to reserve only ports
    0x295-0x296, instead of full 0x290-0x297 range. While some other
    sensors chips respond to all addresses in 0x290-0x297 range, Winbond
    chips respond to 0x295-0x296 only (this behavior is implied by
    documentation, and matches behavior observed on real systems). This is
    not problem alone, as no BIOS was found to put something at these unused
    addresses, and sensors chip itself provides nothing there as well.

    But in addition to only respond to these two addresses, also BIOS
    vendors report in their ACPI-PnP structures that there is some resource
    at I/O address 0x295 of length 2. And when later this hwmon driver
    attempts to request region with base 0x290/length 8, it fails as one
    request_region cannot span more than one device.

    Due to this we have to ask only for region this hardware really
    occupies, otherwise driver cannot be loaded on systems with ACPI-PnP
    enabled.

    Signed-off-by: Petr Vandrovec
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Petr Vandrovec
     

06 Sep, 2005

1 commit

  • We could refactor the error message 34 different i2c drivers print if
    i2c_detach_client() fails in this function itself. Saves quite a few
    lines of code. Documentation is updated to reflect that change.

    Note that this patch should be applied after Rudolf Marek's w83792d
    patches.

    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare