gmane.linux.drivers.sensors

Re: lm-sensors help question

Bruce Kettle — 2013-05-25T01:19:54

Thanks again for the useful information.  Looking through dmesg you are 
probably right since I am getting an ACPI error shortly after the it87 
driver loads, as shown below:

[   13.891413] it87: Found IT8718F chip at 0xe80, revision 5
[   13.891423] it87: VID is disabled (pins used for GPIO)
[   13.891459] ACPI Warning: 0x0000000000000e85-0x0000000000000e86 
SystemIO conflicts with Region \SENP 1 (20120320/utaddress-251)
[   13.891464] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver
[   13.891507] fglrx: module license 'Proprietary. (C) 2002 - ATI 
Technologies, Starnberg, GERMANY' taints kernel.
[   13.891513] Disabling lock debugging due to kernel taint
[   13.892406] ACPI Warning: 0x0000000000000b00-0x0000000000000b07 
SystemIO conflicts with Region \SOR1 1 (20120320/utaddress-251)
[   13.892416] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

I updated to Ubuntu 12.04 64 bit versus 32 bit but this issue did not 
appear to change, the output from sensors is the same:

bruce< at >bruce-A780L3G:~$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +60.0°C  (crit = +127.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +48.6°C  (high = +70.0°C)
                        (crit = +90.0°C, hyst = +88.0°C)

But as long as the k10temp above is representative of the CPU core temp 
I am good, this represents the system at 100% for several hours.

Thanks


On 05/24/2013 09:26 AM, Jean Delvare wrote:


_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: ITE IT8518E supported in coreboot, helpful?

Guenter Roeck — 2013-05-24T17:34:40

I may be missing something, but my understanding is that the chip
has an embedded microcontroller (EC) which handles the actual fan
control. While the chip data sheet describes the hardware accessible
to the EC, and the API between CPU and EC, it does not describe
the logical interface between the two. Problem is that this
interface is not well defined and depends on the microcode
running on the EC.

The file referenced above seems to provide that information for the
specific board and for the microcode running on the EC in that board
(which appears to be the referenced 'quanta' firmware). That does
not mean, however, that it would be the same for other boards,
including yours.

A second potential problem is that the ACPI data provided above suggests
that the EC may be controlled through ACPI, which means that ACPI most
likely reserves the memory space needed to access the controller.
If this is the case in your system, which is quite likely, your best
option would be an ACPI driver.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: W83L786G not detected on vx800

rh — 2013-05-24T15:28:40

On Fri, 24 May 2013 08:59:27 +0200
Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw< at >public.gmane.org> wrote:


I only know that my fans are  running all the time and lmsensors was
mentioned everywhere I looked.


sensors-detect


That returns cpu temp and data from the w83l786! (don't have it
to cut-n-paste)


They do look close enough after reading the datasheet for each. 


I tried this and sensors-detect produces the same output.
It seems I don't need to rely on sensors-detect though and
need to find out why pwmconfig cannot control the fans.

But it's another guess. I did see that in the 3.9.2 kernel there's
a separate flag for PWM that I had never noticed before. I think
it's new. I checked the box for that.

I just want to have fan control and it seems all the pieces are there
but something's missing.  It could be PEBKAC but I've looked at a
lot of stuff....the vx800 spec, the W83l786NG,NR,G,R datasheets,
linux/Documentation/hwmon, thermal, etc., etc.

Thanks for lm-sensors! And thanks for taking the time to reply.


_______________________________________________
lm-sensors mailing list
lm-sensors-GZX6beZjE8VD60Wz+7aTrA< at >public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: lm-sensors help question

Jean Delvare — 2013-05-24T15:26:41

And? PCI is a system bus. The value is retrieved over the PCI bus.
That's all it means, really.


Did you actually try loading the it87 driver? Did it work? If not, you
may be another victim of ACPI:
http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31

Re: [PATCH v3] hwmon (ds1621): Remove detectionfunction

Guenter Roeck — 2013-05-24T14:56:40

Applied to -next.

Thanks a lot to both of you!

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: sensord systemd unit

Jean Delvare — 2013-05-24T12:57:42

Hi Nikola,

Sorry for the late reply :(

On Mon, 13 Feb 2012 14:37:22 +0100, Nikola Pajkovsky wrote:

I added:
After=syslog.target


I removed the "-", as the environment file is mandatory, otherwise the
ExecStart below will fail, right?


Applied, thanks!

Re: lm-sensors help question

Bruce Kettle — 2013-05-24T12:36:28

Thank you for responding.  So this reading is actually the CPU temp?  
It's the only k10temp reading returned but it's labelled for pci.

k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +23.5°C  (high = +70.0°C)
                         (crit = +90.0°C, hyst = +88.0°C)

Here is output from sensors-detect.


bruce< at >bruce-A780L3G:~$ sudo sensors-detect
# sensors-detect revision 5984 (2011-07-10 21:22:53 +0200)
# System: BIOSTAR Group A780L3G

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors... Success!
     (driver `k10temp')
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
Intel digital thermal sensor...                             No
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      Yes
Found `ITE IT8718F Super IO Sensors' Success!
     (address 0xe80, driver `it87')
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): y
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): y
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): y
Using driver `i2c-piix4' for device 0000:00:14.0: ATI Technologies Inc 
SB600/SB700/SB800 SMBus
Module i2c-dev loaded successfully.

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `it87':
   * ISA bus, address 0xe80
     Chip `ITE IT8718F Super IO Sensors' (confidence: 9)

Driver `k10temp' (autoloaded):
   * Chip `AMD Family 10h thermal sensors' (confidence: 9)

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
it87
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)y
Successful!

Monitoring programs won't work until the needed modules are
loaded. You may want to run 'service module-init-tools start'
to load them.

Unloading i2c-dev... OK
Unloading cpuid... OK

bruce< at >bruce-A780L3G:~$




On 05/24/2013 01:03 AM, Jean Delvare wrote:


_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

ITE IT8518E supported in coreboot, helpful?

Santi Villalba — 2013-05-24T09:47:55

This controller is giving people some trouble, as it is shipped in more 
and more laptops [1] and the fans can become quite annoying in these 
systems.

In the past it was said that the main problem was the lack of a 
datasheet from ITE [2]. Recently there has been progress from the 
coreboot projects getting the info for quanta firmware on IT8518 [3]. 
Can this particular file help with the lack of specs or it depends on 
other factors?
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/ec/quanta/it8518/acpi/ec.asl;h=7549fa283da69b9b1fca8589b1fc7f59fd30f7a4;hb=7e568559634199668859b7c662aea7f6b41f3920

In my particular case, I have a noisy clevo p150em. I can help providing 
testing and perhaps developing - just looking at the code of other 
modules, it87, it seems to me I could give a hand beyond testing.

Thanks

[1] https://bbs.archlinux.org/viewtopic.php?id=154462
      http://forums.debian.net/viewtopic.php?f=7&t=76146
http://forums.opensuse.org/english/get-technical-help-here/laptop/486412-cpu-cooler-runs-almost-constantly.html
http://www.linuxmint-fr.org/forum/systeme/145143-ventilateur-qui-tournent-a-fond-no-pwm-capable-sensor-modules.html

[2] 
http://lists.lm-sensors.org/pipermail/lm-sensors/2012-February/035486.html

[3] 
http://review.coreboot.org/gitweb?p=coreboot.git;a=commitdiff;h=7e568559634199668859b7c662aea7f6b41f3920


_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH v3] hwmon (ds1621): Remove detection function

Jean Delvare — 2013-05-24T07:05:50

Hi Robert,

On Thu, 23 May 2013 09:22:22 -0700, Robert Coulson wrote:

Thanks for the update, looks good to me.

Acked-by: Jean Delvare <khali< at >linux-fr.org>

Guenter, please pick and apply.

Re: lm-sensors help question

Jean Delvare — 2013-05-24T07:03:51

Hi Bruce,

On Thu, 23 May 2013 21:40:27 -0600, Bruce Kettle wrote:

k10temp is the CPU core temp. The value might be different from what you
expect because these embedded sensors have very poor accuracy in low
temperature ranges. What the above value really means is that your CPU
is properly cooled and you do not have to worry about overheating
(unless the value gets close to 70°C under heavy load.)


What "chipset" are you talking about, please?


What monitoring chip do these programs report? I can't help you further
without the complete output of a recent version of sensors-detect (for
example http://dl.lm-sensors.org/lm-sensors/files/sensors-detect) on
your system.

Re: W83L786G not detected on vx800

Jean Delvare — 2013-05-24T06:59:27

Hi Richard,

On Fri, 24 May 2013 03:21:29 -0700, rh wrote:

Running sensors-detect on a monolithic kernel is rather pointless. The
whole purpose of sensors-detect is to tell you which kernel modules
should be loaded. If you built a monolithic kernel you must already
know that.


"lmsensors" is a set of tools. Which tool(s) are you claiming can't see
the device? sensors-detect? sensors? Both? Something else?

What does "sensors" return?


It is there indeed.


Should't matter, while the chips aren't 100% compatible they have the
same chip ID so the same driver supports both.


This is your W83L786G chip. sensors-detect would tell you if the driver
was built as a module rather than embedded in the kernel.

I have improved sensors-detect so that it can handle monolithic kernels
better. Please give it a try and report the output:
  http://khali.linux-fr.org/devel/lm-sensors/sensors-detect

lm-sensors help question

Bruce Kettle — 2013-05-24T03:40:27

Hi I have a Biostar a780l3g motherboard with a Phenom II 840 processor.  
I have Ubuntu 12.04 32-bit installed and current patches (kernel 
3.5.0-30-generic).  I installed lm-sensors and ran sensors-detect, it 
properly detected the k10 sensors.  But when I run sensors the output is 
as follows:

bruce< at >bruce-A780L3G:~$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +32.0°C  (crit = +127.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +23.5°C  (high = +70.0°C)
                        (crit = +90.0°C, hyst = +88.0°C)

I was hoping to be able to read core temps, but I don't think either of 
these are that.

It does not appear that Biostar provides Linux chipset drivers, although 
your FAQ indicates this should be supported in this version of the 
kernel.  Is there something I am doing wrong or is the board just not 
supported?  The sensors did work in Windows 7 in a variety of programs, 
so I don't think there is a hardware issue.

Thanks




_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Доброго Вам дня

tamazi.burduli — 2013-05-24T00:23:02

Самое хлебное предложение для посетителей нашего сайта http://goo.gl/cZgzh?/CahE 
_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

W83L786G not detected on vx800

rh — 2013-05-24T10:21:29

Hello,

On the MB there is a winbond W83L786G but it is not detected
by sensors-detect. The kernel is monolithic (i.e. no modules)
and it is linux3.9.2.

It seems that lmsensors is unable to see this device but it is there.

cat /sys/class/hwmon/hwmon1/device/name
w83l786ng

As I said the actual device is a w83l786g

Tips/pointers/suggestions much appreciated as the fans are
running at ~80% all the time.

# sensors-detect revision 6085 (2012-10-30 18:18:45 +0100)
# System: VIA Technologies Ltd. VX800 [1.0]

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... Success!
(driver `via-cputemp')
VIA Nano thermal sensor... No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-viapro' for device 0000:00:11.0: VIA Technologies VX800/VX820 South Bridge

Next adapter: viafb i2c io_port idx 0x26 (i2c-0)
Do you want to scan it? (YES/no/selectively):

Next adapter: viafb i2c io_port idx 0x31 (i2c-1)
Do you want to scan it? (YES/no/selectively):

Next adapter: viafb i2c io_port idx 0x2c (i2c-2)
Do you want to scan it? (YES/no/selectively):

Next adapter: SMBus Via Pro adapter at 0500 (i2c-3)
Do you want to scan it? (YES/no/selectively):
Client at address 0x2f can not be probed - unload all client drivers first!
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No

Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `via-cputemp':
* Chip `VIA C7 thermal sensor' (confidence: 9)

_______________________________________________
lm-sensors mailing list
lm-sensors-GZX6beZjE8VD60Wz+7aTrA< at >public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH v3] hwmon (ds1621): Remove detection function

Robert Coulson — 2013-05-23T16:22:22

Due to a lack of device and vendor identification registers, the
Dallas/Maxim DS16xx devices cannot be uniquely detected, sometimes
resulting in false positives. Therefore, the detection function is
being removed in favor of explicit device instantiation.

Signed-off-by: Robert Coulson <rob.coulson< at >gmail.com>
---
 Documentation/hwmon/ds1621 |   25 +++++++++++------------
 drivers/hwmon/ds1621.c     |   48 --------------------------------------------
 2 files changed, 12 insertions(+), 61 deletions(-)

v2:
- removed detect function references in ds1621 documentation
- replaced deprecated with removed and fixed a spelling error
v3:
- removed scanned addresses info, tables, and list

diff --git a/Documentation/hwmon/ds1621 b/Documentation/hwmon/ds1621
index 140eab5..2022379 100644
--- a/Documentation/hwmon/ds1621
+++ b/Documentation/hwmon/ds1621
< at >< at > -4,24 +4,22 < at >< at > Kernel driver ds1621
 Supported chips:
   * Dallas Semiconductor & Maxim Integrated DS1621
     Prefix: 'ds1621'
-    Addresses scanned: I2C 0x48 - 0x4f
+    Addresses scanned: none
     Datasheet: Publicly available from www.maximintegrated.com
 
   * Dallas Semiconductor DS1625
-    Prefix:
-     'ds1621' - if binding via _detect function
-     'ds1625' - explicit instantiation
-    Addresses scanned: I2C 0x48 - 0x4f
+    Prefix: 'ds1625'
+    Addresses scanned: none
     Datasheet: Publicly available from www.datasheetarchive.com
 
   * Maxim Integrated DS1631
     Prefix: 'ds1631'
-    Addresses scanned: I2C 0x48 - 0x4f
+    Addresses scanned: none
     Datasheet: Publicly available from www.maximintegrated.com
 
   * Maxim Integrated DS1721
     Prefix: 'ds1721'
-    Addresses scanned: I2C 0x48 - 0x4f
+    Addresses scanned: none
     Datasheet: Publicly available from www.maximintegrated.com
 
 Authors:
< at >< at > -77,12 +75,13 < at >< at > The DS1625 is pin compatible and functionally equivalent with the DS1621,
 but the DS1621 is meant to replace it. The DS1631 and DS1721 are also
 pin compatible with the DS1621, but provide multi-resolution support.
 
-Since there is no version register, there is no unique identification
-for these devices. In addition, the DS1631 and DS1721 will emulate a
-DS1621 device, if not explicitly instantiated (why? because the detect
-function compares the temperature register values bits and checks for a
-9-bit resolution). Therefore, for correct device identification and
-functionality, explicit device instantiation is required.
+Since there is no version or vendor identification register, there is
+no unique identification for these devices. Therefore, explicit device
+instantiation is required for correct device identification and functionality.
+
+And, for correct identification and operation, each device must be
+explicitly instantiated, one device per address, in this address
+range: 0x48..0x4f.
 
 The DS1721 is pin compatible with the DS1621, has an accuracy of +/- 1.0
 degree Celius over a -10 to +85 degree range, a minimum/maximum alarm
diff --git a/drivers/hwmon/ds1621.c b/drivers/hwmon/ds1621.c
index d4f02a8..1ecfcd0 100644
--- a/drivers/hwmon/ds1621.c
+++ b/drivers/hwmon/ds1621.c
< at >< at > -46,10 +46,6 < at >< at >
 #include <linux/sysfs.h>
 #include <linux/kernel.h>
 
-/* Addresses to scan */
-static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b, 0x4c,
-0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
-
 /* Supported devices */
 enum chips { ds1621, ds1625, ds1631, ds1721 };
 
< at >< at > -360,48 +356,6 < at >< at > static const struct attribute_group ds1621_group = {
 .is_visible = ds1621_attribute_visible
 };
 
-
-/* Return 0 if detection is successful, -ENODEV otherwise */
-static int ds1621_detect(struct i2c_client *client,
- struct i2c_board_info *info)
-{
-struct i2c_adapter *adapter = client->adapter;
-int conf, temp;
-int i;
-
-if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA
-     | I2C_FUNC_SMBUS_WORD_DATA
-     | I2C_FUNC_SMBUS_WRITE_BYTE))
-return -ENODEV;
-
-/*
- * Now, we do the remaining detection. It is lousy.
- *
- * The NVB bit should be low if no EEPROM write has been requested
- * during the latest 10ms, which is highly improbable in our case.
- */
-conf = i2c_smbus_read_byte_data(client, DS1621_REG_CONF);
-if (conf < 0 || conf & DS1621_REG_CONFIG_NVB)
-return -ENODEV;
-/*
- * The ds1621 & ds1625 use 9-bit resolution, so the 7 lowest bits
- * of the temperature should always be 0 (NOTE: The other chips
- * have multi-resolution support, so if they have 9-bit resolution
- * configured and the min/max temperature values set accordingly,
- * then if not explicitly instantiated, they *will* appear as and
- * emulate a ds1621 device).
- */
-for (i = 0; i < ARRAY_SIZE(DS1621_REG_TEMP); i++) {
-temp = i2c_smbus_read_word_data(client, DS1621_REG_TEMP[i]);
-if (temp < 0 || (temp & 0x7f00))
-return -ENODEV;
-}
-
-strlcpy(info->type, "ds1621", I2C_NAME_SIZE);
-
-return 0;
-}
-
 static int ds1621_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
< at >< at > -467,8 +421,6 < at >< at > static struct i2c_driver ds1621_driver = {
 .probe= ds1621_probe,
 .remove= ds1621_remove,
 .id_table= ds1621_id,
-.detect= ds1621_detect,
-.address_list= normal_i2c,
 };
 
 module_i2c_driver(ds1621_driver);

Re: [PATCH] fancontrol: Fix handling of absolute paths in config

Jean Delvare — 2013-05-23T14:18:09

Thanks for testing. Patch committed and added to the list of
recommended patches.

Re: [PATCH] fancontrol: Fix handling of absolute pathsin config

Marc Ferland — 2013-05-23T13:42:02


Yes. Just tested on my system and everything seems to run smoothly.

Thank you,

Marc

_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: sensors-detect:: Drop detection of DS1621-likechips

Robert Coulson — 2013-05-22T15:43:07


Good morning Jean,

you are correct and I apologize for the noise; i was not looking at the
master branch.

Rob.

_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH v2] hwmon (ds1621): Remove detectionfunction

Robert Coulson — 2013-05-22T15:37:47


Good morning Jean,




Thank you for the info, I appreciate it and will do so in the future.





agreed.



agreed and nice catch.



Your welcome.

I'll send an updated patch set shortly.

Rob
_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

широкодоступнее что у нас это задарма

margaritakapus10028 — 2013-05-22T02:09:26

самый-самые внушительные скидки на текущий момент  http://goo.gl/M5kZo?/EdkSfG И не вешай свой нос. 
_______________________________________________
lm-sensors mailing list
lm-sensors< at >lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH] fancontrol: Fix handling of absolute paths in config

Jean Delvare — 2013-05-21T08:23:36

Hi Marc,

On Fri, 22 Mar 2013 13:51:30 -0400, Marc Ferland wrote:

Thanks for the report and the patch, and sorry for the long delay.

You are right that DEVPATH and DEVNAME shouldn't be mandatory when
using absolute paths in the fancontrol configuration file. DEVPATH
doesn't even make sense in that case.

However DEVNAME does still make sense. Using absolute paths doesn't
guarantee that the device you point to after reboot is the same as the
one you configured originally, unfortunately. Specifically, i2c bus
numbers aren't guaranteed to be persistent over reboot. So your patch
is good to get things working again but it prevents the user from
asking fancontrol to check the device name when using absolute paths.

Thus I would prefer the more flexible change below:
---
 prog/pwm/fancontrol |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- lm-sensors.orig/prog/pwm/fancontrol2013-05-07 08:01:08.589879860 +0200
+++ lm-sensors/prog/pwm/fancontrol2013-05-21 10:21:57.223242288 +0200
< at >< at > -291,11 +291,16 < at >< at > fi
 cd $DIR
 
 # Check for configuration change
-if [ -z "$DEVPATH" -o -z "$DEVNAME" ]
+if [ "$DIR" != "/" ] && [ -z "$DEVPATH" -o -z "$DEVNAME" ]
 then
 echo "Configuration is too old, please run pwmconfig again" >&2
 exit 1
 fi
+if [ "$DIR" = "/" -a -n "$DEVPATH" ]
+then
+echo "Unneeded DEVPATH with absolute device paths" >&2
+exit 1
+fi
 if ! ValidateDevices "$DEVPATH" "$DEVNAME"
 then
 echo "Configuration appears to be outdated, please run pwmconfig again" >&2

This simply makes DEVPATH and DEVNAME mandatory when using relative
paths and DEVNAME optional when using absolute paths. Does it work for
you?