06 Jan, 2012

1 commit


07 Nov, 2011

1 commit

  • Commit 2265cef2 (hwmon: (w83627ehf) Properly report PECI and AMD-SI
    sensor types) results in kernel panic if data->temp_label was not
    initialized.
    The problem was found with chip W83627DHG-P.

    Add check if data->temp->label was set before use.

    Based on incomplete patch by Alexander Beregalov.

    Reported-by: Alexander Beregalov
    Tested-by: Alexander Beregalov
    Cc: stable@kernel.org
    Signed-off-by: Guenter Roeck
    Signed-off-by: Jean Delvare

    Guenter Roeck
     

04 Nov, 2011

3 commits

  • This is essentially a stripped down version of the W83627DHG. Noticeable
    difference is that it is still powered with +5V, as older models, even
    though the ADC resolution is 8 mV as newer models have.

    Thanks to Ulf Bruman (Saab Group) for doing all the testing.

    Signed-off-by: Jean Delvare
    Acked-by: Guenter Roeck

    Jean Delvare
     
  • The probe function has grown pretty large, I think it's time for some
    cleanups, starting with these two simple ones:
    * Move temp3/in6 check for the W83667HG later in the function, where
    it is done for all other chip types.
    * Move temperature register setting to a separate function, to avoid
    code duplication.

    Signed-off-by: Jean Delvare
    Acked-by: Guenter Roeck

    Jean Delvare
     
  • When temperature sources are PECI or AMD-SI agents, it makes no sense
    to report their type as diode or thermistor. Instead we must report
    their digital nature.

    Signed-off-by: Jean Delvare
    Cc: stable@kernel.org
    Acked-by: Guenter Roeck

    Jean Delvare
     

25 Oct, 2011

5 commits


20 Oct, 2011

1 commit

  • Since 8-bit temperature values are now handled in 16-bit struct
    members, values have to be cast to s8 for negative temperatures to be
    properly handled. This is broken since kernel version 2.6.39
    (commit bce26c58df86599c9570cee83eac58bdaae760e4.)

    Signed-off-by: Jean Delvare
    Cc: Guenter Roeck
    Cc: stable@kernel.org # 2.6.39+
    Signed-off-by: Guenter Roeck

    Jean Delvare
     

14 Oct, 2011

1 commit

  • The w83627ehf driver is improperly reporting thermal diode sensors as
    type 2, instead of 3. This caused "sensors" and possibly other
    monitoring tools to report these sensors as "transistor" instead of
    "thermal diode".

    Furthermore, diode subtype selection (CPU vs. external) is only
    supported by the original W83627EHF/EHG. All later models only support
    CPU diode type, and some (NCT6776F) don't even have the register in
    question so we should avoid reading from it.

    Signed-off-by: Jean Delvare
    Cc: stable@kernel.org
    Signed-off-by: Guenter Roeck

    Jean Delvare
     

15 Mar, 2011

11 commits


09 Jan, 2011

1 commit


17 Sep, 2010

1 commit


15 Aug, 2010

2 commits


16 Dec, 2009

1 commit

  • Add control of fan minimum turn-on output levels, decoupling it from the
    fan turn-off output level. Add control of rate of change of fan output
    level. These in turn allow lower turn-off rotor speed and smoother
    transitions for better thermal and acoustic control authority. Add
    support for constant fan speed and proportional-response operations modes.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Daniel J Blueman
    Cc: Jean Delvare
    Cc: David Hubbard
    Cc: Hans de Goede
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel J Blueman
     

15 Sep, 2009

1 commit


16 Jun, 2009

1 commit

  • Add support for the new incarnation of the Winbond/Nuvoton W83627DHG
    chip known as W83627DHG-P. It is basically the same as the original
    W83627DHG with an additional automatic can speed control mode (not
    supported by the driver yet.)

    Signed-off-by: Jean Delvare
    Tested-by: Madhu

    Jean Delvare
     

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

1 commit