Date: Thu, 18 Dec 2003 22:42:36 +0100
From: Haakon Riiser <haakon.riiser@fys.uio.no>
To: sensors@Stimpy.netroedge.com
Subject: lm_sensors 2.8.2 / DESTDIR / root
The reason for this email is that I always try to avoid running
Makefiles as root, even during 'make install'. Therefore, I
always use the DESTDIR feature, when it's available. Until today,
I always built i2c and lm_sensors by doing
$ make
$ make -i install DESTDIR=/foo
$ cd /foo && su root && fix permissions/ownership && install
The -i flag to make install is a kludge to avoid having to be root
while installing to the DESTDIR, and it's only required because
the files are installed with "-o root -g root". Using the -i
flag is of course not a good idea, since more fatal errors can
easily fly by undetected.
Today, I upgraded to Linux 2.6.0, and tried a similar install
procedure for lm_sensors, except that the make target is now "user"
and the install target is "user_install". I now noticed that the
DESTDIR variable is not used everywhere in "user_install", so I
couldn't use the -i kludge anymore. Instead, I wrote a patch that
removes the "-o root -g root" arguments to install everywhere, and
I also tried to add DESTDIR to all files/directories installed.
(The patch only applies to lm_sensors, not i2c, since only
lm_sensors is required in Linux 2.6.0.)
There's really no reason to say -o root -g root anyway, since if you
do install directly with make install, you have to be logged in as
root, and then the files will get the right ownership by default.
Much of the point of installing to a temporary DESTDIR is that you
don't have to be root, and that you can prepare the installation
by hand. Fixing the ownership is trivial:
chown -R root.root $DESTDIR
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2189 7894878c-1315-0410-8ee3-d5d059ff63e0
Copy sysctl enums to chip drivers from sensors.h for now,
as seen in drivers included in 2.5 tree. File no longer included
from kernel side.
Apply i2c-proc change in CVS tagged -km2.
Partial clean and sort of includes everywhere.
Add i2c-dev.h, as a partial copy from i2c.
Add to sensors.h from i2c-proc.h to compile things.
Remove i2c-isa.h.
Reflect header file changes to lib/ and prog/.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1705 7894878c-1315-0410-8ee3-d5d059ff63e0
This driver is a copy of vt1211, which is almost identical.
The vt1211 is a super i/o chip and the vt8231 is a PCI chip.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1501 7894878c-1315-0410-8ee3-d5d059ff63e0
provides and API for NVRAM and RTC drivers to sit on top of this. An example
of drivers that uses this API are the Frodo RTC and NVRAM drivers.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1433 7894878c-1315-0410-8ee3-d5d059ff63e0
Replace VID_FROM_REG() with vid_from_reg() in new sensors_vid.h.
Update library so it can be set in sensors.conf.
Add new documentation. Update mkpatch for new file.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1352 7894878c-1315-0410-8ee3-d5d059ff63e0
From: Aurelien Jarno <aurelien@aurel32.net>
Hello,
I have to use the pcf8574 chip with my I2C interface, however, the pcf8574
drivers in lm-sensors is a bit basic. It supposes the pin P1 is used as an
input and the others pin as outputs.
Attached is a patch which corrects that, providing to files in /proc
interface, one for writting, the other for reading. It also modifies a bit
the driver to support the pcf8574a (it is a pcf8574 with a different address
range), and add a documentation file in doc/chips.
The patch also includes some cosmetic changes in the pcf8591 driver I wrote
previously, that is to say it modify the chip name in some places I had
forgotten to change when I made a copy/paste from another driver.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1318 7894878c-1315-0410-8ee3-d5d059ff63e0
The following patch does the following:
Fixed bug with not all alarms enabled.
Added ability to read battery voltage
Select temperature sensor type at module load time.
Added setting for Inside Technologies 786LCD board to example config file
I also fixed what looked like a typo in the existing it87 section where
in6_min/max was set twice and in7 was not set. As commented I think
the equation for the negative voltages are wrong but without that motherboard
I can't verify.
With the 786LCD board sensors-detect reports a lm78 which doesn't
exist and a sis5595 which may be part of the SIS630 chip but doesn't
perform the monitoring. The it8705F/SIS950 which is on the board is
reported as a misdetect. I didn't know enough about the various chips
to figure out how to get correct detections.
David Gesswein
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1146 7894878c-1315-0410-8ee3-d5d059ff63e0
patch from Christian Zuckschwerdt:
Hi,
On Fri, 15 Jun 2001, Mark D. Studebaker wrote:
> I looked at the patch and I see there are separate
> /proc entries for the 9 and 12 bit outputs.
> Why not just make the 12 bit output the only output using "temp"??
> I don't understand the need for all the new /proc entries,
> except perhaps for debugging inside #ifdef DEBUG.
> Would you or Jan be willing to develop a patch that way?
> I'm all for increased accuracy as a standard feature - why not?
Ok. I rewrote the patch to support standard (9bit) and enhanced (12bit)
accuracy via the "temp" entry. The "raw" interface is also gone.
There are some quirks needed for the sensors app. It seems that
prog/sensors/chips.c fixes the output to %+3.1f
Thats not good for 12bit mode which gives you 2 decimals and therefor
wrong scaling.
Precision is .062 with 12bit (4 decimal bits) instead of .5 with 9bit (1
decimal bit). That way 2 decimals seem a natural choice.
On the other hand I see no obvious reason not to fix decimals to 1...
I'm lost there -- suggestions anyone?
Another problem is that 12bit is slow and laggy. I don't recommend making
it the default mode.
cu.
:
Christian
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1145 7894878c-1315-0410-8ee3-d5d059ff63e0
Leave the files there for now.
Remove old installed sensors.o in kernel/Module.mk.
sensors.c was moved to i2c-proc.c in the i2c package.
i2c-isa.h was appended to i2c.h in the i2c package.
Delete all but the SYSCTL and ALARMS definitions in sensors.h,
as the rest of the file was moved to i2c-proc.h in the i2c package.
Remove #include "i2c-isa.h" lines in all chip drivers and
in bus driver i2c-isa.c.
This all probably breaks mkpatch.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1015 7894878c-1315-0410-8ee3-d5d059ff63e0
on both platforms). LM87 support is very far along, and should work
for a majority of users, but some minor tweaks are still on the to-do list.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@963 7894878c-1315-0410-8ee3-d5d059ff63e0
perfectly with the adm1023, but didn't take advantage of it's extra precision
for the remote temp sensor. Now, if an adm1023 is detected, it will.
For example, my adm1021 remote_temp looks like this:
phil@penn phil]$ cat /proc/sys/dev/sensors/adm1021*/remote_temp
60 20 23
My 1023 looks like this:
[root@penn lm_sensors2]# cat /proc/sys/dev/sensors/adm1023-i2c-2-2a/remote_temp
60.125 20.250 1.500 20.875
(Both from the same inserted driver)
Notice the extra 3 digit precision (actually, it's in increments of 0.125).
And, also notice the extra 'limit'. It's actually an offset register.
Right now it's adding 1.5 degrees to the reading for the remote_temp. This
same functionality could easily be done by editing /etc/sensors.conf, but
Analog Devices decided to put it into the chip instead. :')
Things to do: edit the default sensors.conf, and sensors-detect for this
new chip.
Oh, I also added SENSORS_INSMOD_7 into sensors.h. This was the first
driver to need it, apparently.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@904 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare