In 2.4 all sensor chip got a subdirectory with name derived from type_name - a
single word describing sensor, like
adm1021.c: type_name = "max1617";
adm1021.c: type_name = "max1617a";
adm1021.c: type_name = "adm1021";
adm1021.c: type_name = "adm1023";
adm1021.c: type_name = "thmc10";
adm1021.c: type_name = "lm84";
adm1021.c: type_name = "gl523sm";
adm1021.c: type_name = "mc1066";
...
etc. All user-level configuration (sensors, gkrellm) have been using these
names to match available sensors and configuration data.
In 2.6 sensors appear under /sysfs, type_name no more used and the only
identification available is .../name, but it seems to be arbitrary chosen
like
- single word ("it87") - lm87.c
- "name chip" or "name subclient" - most others (lm78.c, wd83781d.c etc)
- completely arbitrary shiny description - "Generic LM85", "National LM85-B"
etc in lm85.c
This means, any user program accessing sensors need incompatible changes and
comfiuration cannot be shared between 2.4 and 2.6 without serious redesign
and/or some translation layer.
If there are serious reasons to keep current names in "name" - what about
adding extra type_name property that will hold type_name compatible with 2.4,
at least for those drivers that are also available there. This would allow
easily reuse existing sensors configuration.
TIA
-andrey
On Tue, Jul 15, 2003 at 10:14:38PM +0400, Andrey Borzenkov wrote:
> In 2.4 all sensor chip got a subdirectory with name derived from type_name - a
> single word describing sensor, like
And they used sysctl and proc, ugh, ugly :)
> adm1021.c: type_name = "max1617";
> adm1021.c: type_name = "max1617a";
> adm1021.c: type_name = "adm1021";
> adm1021.c: type_name = "adm1023";
> adm1021.c: type_name = "thmc10";
> adm1021.c: type_name = "lm84";
> adm1021.c: type_name = "gl523sm";
> adm1021.c: type_name = "mc1066";
> ...
>
> etc. All user-level configuration (sensors, gkrellm) have been using these
> names to match available sensors and configuration data.
>
> In 2.6 sensors appear under /sysfs, type_name no more used and the only
> identification available is .../name, but it seems to be arbitrary chosen
> like
>
> - single word ("it87") - lm87.c
> - "name chip" or "name subclient" - most others (lm78.c, wd83781d.c etc)
> - completely arbitrary shiny description - "Generic LM85", "National LM85-B"
> etc in lm85.c
>
> This means, any user program accessing sensors need incompatible changes and
> comfiuration cannot be shared between 2.4 and 2.6 without serious redesign
> and/or some translation layer.
The "translation layer" is libsensors. libsensors needs to be rewritten
for 2.6. The sensors people know this, and it's even detailed on their
web page. Any help with this is greatly appreciated.
> If there are serious reasons to keep current names in "name" - what about
> adding extra type_name property that will hold type_name compatible with 2.4,
> at least for those drivers that are also available there. This would allow
> easily reuse existing sensors configuration.
Patches to help do this are always welcome :)
thanks,
greg k-h
On Wednesday 16 July 2003 00:18, Greg KH wrote:
[...]
> The "translation layer" is libsensors. libsensors needs to be rewritten
> for 2.6. The sensors people know this, and it's even detailed on their
> web page. Any help with this is greatly appreciated.
>
I do mean libsensors. Also gkrellm does not use libsensors (it interfaces with
proc/sys directly) and I already have user reports about naming problems.
> > If there are serious reasons to keep current names in "name" - what about
> > adding extra type_name property that will hold type_name compatible with
> > 2.4, at least for those drivers that are also available there. This would
> > allow easily reuse existing sensors configuration.
>
> Patches to help do this are always welcome :)
>
Attached is patch against 2.6.0-test1 that adds type_name to all in-tree
sensors; it sets it to the same values as corr. 2.4 senors and (in one case)
changes client name to match that of 2.4.
Assuming this patch (or variant thereof) is accepted I can then produce
libsensors patch that will easily reuse current sensors.conf. I have already
done it for gkrellm and as Mandrake is going to include 2.6 in next release
sensors support becomes more of an issue.
It compiles and w83781d works. Comments appreciated.
regards
-andrey
> Attached is patch against 2.6.0-test1 that adds type_name to all in-tree
> sensors; it sets it to the same values as corr. 2.4 senors and (in one case)
> changes client name to match that of 2.4.
Well, it certainly doesn't with the lm85.c :-)
Hint - names are in lib/chips.h in sensors package :-)
Although, I will be working over lm85.c in the next week or so.
> +static const char *type_name = "";
> +static ssize_t show_type_name(struct device *dev, char *buf)
> +{
> + return sprintf(buf, "%s\n", type_name);
> +}
> +static DEVICE_ATTR(type_name, S_IRUGO, show_type_name, NULL);
> - const char *type_name = "";
> + device_create_file(&new_client->dev, &dev_attr_type_name);
Margit
>> Attached is patch against 2.6.0-test1 that adds type_name to all in-tree
>> sensors; it sets it to the same values as corr. 2.4 senors and (in one
case)
>> changes client name to match that of 2.4.
>
> Well, it certainly doesn't with the lm85.c :-)
> Hint - names are in lib/chips.h in sensors package :-)
It was my fault I should not start changing names, sorry. Sometimes this
happens.
If this patch is accepted it is OK though, we may change other names to be
more user-friendly as well.
-andrey
Please Cc me I am not on lkml
On Sat, Jul 26, 2003 at 10:00:51PM +0400, Andrey Borzenkov wrote:
>
> Attached is patch against 2.6.0-test1 that adds type_name to all in-tree
> sensors; it sets it to the same values as corr. 2.4 senors and (in one case)
> changes client name to match that of 2.4.
>
> Assuming this patch (or variant thereof) is accepted I can then produce
> libsensors patch that will easily reuse current sensors.conf. I have already
> done it for gkrellm and as Mandrake is going to include 2.6 in next release
> sensors support becomes more of an issue.
I like this idea, but now that the name logic has changed in the i2c
code, care to re-do this patch? Just set the name field instead of
creating a new file in sysfs.
Sound ok?
thanks,
greg k-h
On Saturday 16 August 2003 00:51, Greg KH wrote:
> On Sat, Jul 26, 2003 at 10:00:51PM +0400, Andrey Borzenkov wrote:
> > Attached is patch against 2.6.0-test1 that adds type_name to all in-tree
> > sensors; it sets it to the same values as corr. 2.4 senors and (in one
> > case) changes client name to match that of 2.4.
> >
> > Assuming this patch (or variant thereof) is accepted I can then produce
> > libsensors patch that will easily reuse current sensors.conf. I have
> > already done it for gkrellm and as Mandrake is going to include 2.6 in
> > next release sensors support becomes more of an issue.
>
> I like this idea, but now that the name logic has changed in the i2c
> code, care to re-do this patch? Just set the name field instead of
> creating a new file in sysfs.
>
something like attached patch? I like it as well :)
note that in 2.6.0-test3 name in sysfs is empty. I had to add a chunk to
i2c-core to at least test my patch. or may be I misunderstood how
client->name is used.
regards
-andrey
On Sat, Aug 16, 2003 at 07:38:47PM +0400, Andrey Borzenkov wrote:
> On Saturday 16 August 2003 00:51, Greg KH wrote:
> > On Sat, Jul 26, 2003 at 10:00:51PM +0400, Andrey Borzenkov wrote:
> > > Attached is patch against 2.6.0-test1 that adds type_name to all in-tree
> > > sensors; it sets it to the same values as corr. 2.4 senors and (in one
> > > case) changes client name to match that of 2.4.
> > >
> > > Assuming this patch (or variant thereof) is accepted I can then produce
> > > libsensors patch that will easily reuse current sensors.conf. I have
> > > already done it for gkrellm and as Mandrake is going to include 2.6 in
> > > next release sensors support becomes more of an issue.
> >
> > I like this idea, but now that the name logic has changed in the i2c
> > code, care to re-do this patch? Just set the name field instead of
> > creating a new file in sysfs.
> >
>
> something like attached patch? I like it as well :)
Why rename local variables? Your patch would be a lot smaller if you
just keep the same local name variable, and fix up the name strings.
> note that in 2.6.0-test3 name in sysfs is empty. I had to add a chunk to
> i2c-core to at least test my patch. or may be I misunderstood how
> client->name is used.
No, you are correct. I've added the name info back in the -bk tree
right now. Try 2.6.0-test3-bk4 for the proper usage.
thanks,
greg k-h
On Saturday 16 August 2003 20:50, Greg KH wrote:
> > > I like this idea, but now that the name logic has changed in the i2c
> > > code, care to re-do this patch? Just set the name field instead of
> > > creating a new file in sysfs.
> >
> > something like attached patch? I like it as well :)
>
> Why rename local variables? Your patch would be a lot smaller if you
> just keep the same local name variable, and fix up the name strings.
>
To make it clear for anyone porting other drivers that we are using type_name
and not client_name or whatever. In 2.4 every driver have both; mixing name,
type_name and client_name will just add to confusion.
I will redo patch if you insist but I really prefer having things consistent
if possible.
thank you
-andrey
On Mon, Aug 18, 2003 at 08:49:57PM +0400, Andrey Borzenkov wrote:
> On Saturday 16 August 2003 20:50, Greg KH wrote:
> > > > I like this idea, but now that the name logic has changed in the i2c
> > > > code, care to re-do this patch? Just set the name field instead of
> > > > creating a new file in sysfs.
> > >
> > > something like attached patch? I like it as well :)
> >
> > Why rename local variables? Your patch would be a lot smaller if you
> > just keep the same local name variable, and fix up the name strings.
> >
>
> To make it clear for anyone porting other drivers that we are using type_name
> and not client_name or whatever. In 2.4 every driver have both; mixing name,
> type_name and client_name will just add to confusion.
No, we don't need both a "type_name" and a "client_name" anymore, right?
So it's just a simple "name" for the i2c client device. "type_name" is
handled by the name of the client driver now.
> I will redo patch if you insist but I really prefer having things consistent
> if possible.
I prefer having things make sense :)
So yes, I'd prefer if you change your patch.
I've cced the sensors mailing list to get any feedback from them.
thanks,
greg k-h
On Tue, Aug 19, 2003 at 11:19:01PM +0400, Andrey Borzenkov wrote:
> On Sat, Jul 26, 2003 at 10:00:51PM +0400, Andrey Borzenkov wrote:
> > Assuming this patch (or variant thereof) is accepted I can then
> > produce libsensors patch that will easily reuse current sensors.conf.
> > I have already done it for gkrellm and as Mandrake is going to
> > include 2.6 in next release sensors support becomes more of an issue.
>
> There are more issues than just type_name.
Hey, one thing at a time :)
> In libsensors only one file need to be touched - proc.c (file that deals with
> kernel interface). Unfortunately, not all information expected by libsensors
> is currently available is sysfs. Here is output of first stab:
>
> {pts/1}% LD_LIBRARY_PATH=$PWD/lib ./prog/sensors/sensors
> as99127f-i2c-0-2d
> Adapter: DUMMY
> Algorithm: DUMMY
> VCore 1: +1.70 V (min = +1.49 V, max = +1.81 V)
> +3.3V: +3.47 V (min = +2.98 V, max = +3.63 V)
> +5V: +5.00 V (min = +4.52 V, max = +5.48 V)
> +12V: +11.37 V (min = +10.82 V, max = +13.13 V)
> -12V: -11.51 V (min = -12.33 V, max = -15.07 V) ALARM
> -5V: -5.03 V (min = -4.50 V, max = -5.49 V)
> CPU: 4753 RPM (min = 3000 RPM, div = 2)
> Front: 2909 RPM (min = 3000 RPM, div = 2) ALARM
> ERROR: Can't get TEMP1 data!
> ERROR: Can't get TEMP2 data!
> ERROR: Can't get TEMP3 data!
> vid: +1.650 V
> alarms:
> beep_enable:
> Sound alarm enabled
>
> So we have following problems:
>
> 1. I do not know where to get information on adapters (called busses actually
> in libsensors) and algorithms. I.e. the information corresponding to 2.4:
>
> {pts/2}% cat ~/tmp/i2c-bus
> i2c-0 smbus SMBus I801 adapter at e800 Non-I2C SMBus adapter
Look in /sys/class/i2c-adapter/ It shows all of the i2c adapters in the
system, and points to where they are in the device tree. For example,
on my desktop:
$ tree ../class/i2c-adapter/
../class/i2c-adapter/
|-- i2c-0
| |-- device -> ../../../devices/pci0000:00/0000:00:1f.3/i2c-0
| `-- driver -> ../../../bus/i2c/drivers/i2c_adapter
`-- i2c-1
|-- device -> ../../../devices/legacy/i2c-1
`-- driver -> ../../../bus/i2c/drivers/i2c_adapter
Then look at the device directory for the i2c-0 adapter:
$ ls /sys/class/i2c-adapter/i2c-0/device/
0-0048/ 0-0049/ 0-0053/ detach_state name power/
Hm, a name file:
$ cat /sys/class/i2c-adapter/i2c-0/device/name
SMBus I801 adapter at 8000
Ah, the same info as you showed for 2.4 :)
> 2. I do not know - and sysfs does not provide any information - how to
> identify chips-of-interest as opposed to generic i2c devices. I.e. w83781d
> has both clients and subclients (2.4 again):
>
> {pts/2}% cat ~/tmp/i2c-0-bus
> 2d AS99127F chip W83781D sensor driver
> 48 AS99127F subclient W83781D sensor driver
> 49 AS99127F subclient W83781D sensor driver
>
> and we are interested in clients only. In 2.4 we get this information from
> kernel as result of sysctl :))
>
> {pts/2}% cat ~/tmp/i2c-sysctl-chips
> 256 as99127f-i2c-0-2d
>
> while in 2.6 we see in sysfs all three devices:
>
> pts/2}% l /sys/bus/i2c/devices
> 0-002d@ 0-0048@ 0-0049@
>
> without any obvious way to know which one(s) to use.
That's what you are going to have to set the name file to in the
i2c_client structure, much like your patch did. Then look at the
different name files in each device directory to see what kind of device
it is (chip, subclient, etc.)
> 3. libsensors asks for hysteresis value. This one does not exist in sysfs (so
> all temp readings fail). Is it emulated by kernel or read off chip?
The kernel is exporting all of the info that it knows about through
sysfs. If we missed a value somewhere, please let us know. I'm pretty
sure they are all present:
$ ls /sys/class/i2c-adapter/i2c-0/device/0-0048/
detach_state name power/ temp_input temp_max temp_min
> 4. I do not have the slightest idea how ISA adapters look like in sysfs and
> where they are located. Anyone can give me example?
They show up on the legacy bus:
$ tree /sys/class/i2c-adapter/i2c-1/
/sys/class/i2c-adapter/i2c-1/
|-- device -> ../../../devices/legacy/i2c-1
`-- driver -> ../../../bus/i2c/drivers/i2c_adapter
$ ls /sys/class/i2c-adapter/i2c-1/device/
detach_state name power
I don't have any drivers loaded that are attached to this adapter right
now, but I think you get the idea (it's the same as for pci devices.)
> So the patch to ibsensors is actually trivial enough. Main issue is contents
> of sysfs
You might want to take a look at libsysfs, it makes finding all of the
devices and attributes in the sysfs tree a whole lot easer.
Hope this helps,
greg k-h
On Sat, Jul 26, 2003 at 10:00:51PM +0400, Andrey Borzenkov wrote:
> Assuming this patch (or variant thereof) is accepted I can then
> produce libsensors patch that will easily reuse current sensors.conf.
> I have already done it for gkrellm and as Mandrake is going to
> include 2.6 in next release sensors support becomes more of an issue.
There are more issues than just type_name.
In libsensors only one file need to be touched - proc.c (file that deals with
kernel interface). Unfortunately, not all information expected by libsensors
is currently available is sysfs. Here is output of first stab:
{pts/1}% LD_LIBRARY_PATH=$PWD/lib ./prog/sensors/sensors
as99127f-i2c-0-2d
Adapter: DUMMY
Algorithm: DUMMY
VCore 1: +1.70 V (min = +1.49 V, max = +1.81 V)
+3.3V: +3.47 V (min = +2.98 V, max = +3.63 V)
+5V: +5.00 V (min = +4.52 V, max = +5.48 V)
+12V: +11.37 V (min = +10.82 V, max = +13.13 V)
-12V: -11.51 V (min = -12.33 V, max = -15.07 V) ALARM
-5V: -5.03 V (min = -4.50 V, max = -5.49 V)
CPU: 4753 RPM (min = 3000 RPM, div = 2)
Front: 2909 RPM (min = 3000 RPM, div = 2) ALARM
ERROR: Can't get TEMP1 data!
ERROR: Can't get TEMP2 data!
ERROR: Can't get TEMP3 data!
vid: +1.650 V
alarms:
beep_enable:
Sound alarm enabled
So we have following problems:
1. I do not know where to get information on adapters (called busses actually
in libsensors) and algorithms. I.e. the information corresponding to 2.4:
{pts/2}% cat ~/tmp/i2c-bus
i2c-0 smbus SMBus I801 adapter at e800 Non-I2C SMBus
adapter
2. I do not know - and sysfs does not provide any information - how to
identify chips-of-interest as opposed to generic i2c devices. I.e. w83781d
has both clients and subclients (2.4 again):
{pts/2}% cat ~/tmp/i2c-0-bus
2d AS99127F chip W83781D sensor driver
48 AS99127F subclient W83781D sensor driver
49 AS99127F subclient W83781D sensor driver
and we are interested in clients only. In 2.4 we get this information from
kernel as result of sysctl :))
{pts/2}% cat ~/tmp/i2c-sysctl-chips
256 as99127f-i2c-0-2d
while in 2.6 we see in sysfs all three devices:
pts/2}% l /sys/bus/i2c/devices
0-002d@ 0-0048@ 0-0049@
without any obvious way to know which one(s) to use.
3. libsensors asks for hysteresis value. This one does not exist in sysfs (so
all temp readings fail). Is it emulated by kernel or read off chip?
4. I do not have the slightest idea how ISA adapters look like in sysfs and
where they are located. Anyone can give me example?
So the patch to ibsensors is actually trivial enough. Main issue is contents
of sysfs
On Tuesday 19 August 2003 23:45, Greg KH wrote:
> On Tue, Aug 19, 2003 at 11:19:01PM +0400, Andrey Borzenkov wrote:
[...]
> > There are more issues than just type_name.
[...]
> > 1. I do not know where to get information on adapters (called busses
> > actually in libsensors) and algorithms. I.e. the information
> > corresponding to 2.4:
> >
> > {pts/2}% cat ~/tmp/i2c-bus
> > i2c-0 smbus SMBus I801 adapter at e800 Non-I2C
> > SMBus adapter
>
> Look in /sys/class/i2c-adapter/
[...]
> Hm, a name file:
> $ cat /sys/class/i2c-adapter/i2c-0/device/name
> SMBus I801 adapter at 8000
>
> Ah, the same info as you showed for 2.4 :)
>
Sure it not the same info it is only part of it. I do not know if libsensors
just using this for display or needs it internally. Thank you for pointer
though.
> > 2. I do not know - and sysfs does not provide any information - how to
> > identify chips-of-interest as opposed to generic i2c devices. I.e.
> > w83781d has both clients and subclients (2.4 again):
> >
> > {pts/2}% cat ~/tmp/i2c-0-bus
> > 2d AS99127F chip W83781D sensor driver
> > 48 AS99127F subclient W83781D sensor driver
> > 49 AS99127F subclient W83781D sensor driver
> >
[...]
>
> That's what you are going to have to set the name file to in the
> i2c_client structure, much like your patch did. Then look at the
> different name files in each device directory to see what kind of device
> it is (chip, subclient, etc.)
>
OK attached patch sets all names to just chip name for chips themselves and
"chipname subclient" when subclient ios registered.
> > 3. libsensors asks for hysteresis value. This one does not exist in sysfs
> > (so all temp readings fail). Is it emulated by kernel or read off chip?
>
> The kernel is exporting all of the info that it knows about through
> sysfs.
it just arbitrarily (re-)names them. "min" is not hysteresis; name is badly
chosen.
[...]
> > 4. I do not have the slightest idea how ISA adapters look like in sysfs
> > and where they are located. Anyone can give me example?
>
> They show up on the legacy bus:
>
> $ tree /sys/class/i2c-adapter/i2c-1/
> /sys/class/i2c-adapter/i2c-1/
>
> |-- device -> ../../../devices/legacy/i2c-1
>
This does not help much. Libsensors expects as adapter identification either
"i2c-N" or "isa". If I set it to "isa" I do not have any way to determine
sysfs path except by rescanning /sys/class/i2c-adapter every time. Having
/sys/class/i2-adapter/isa/... would be better, apparently it is assumed that
only one such adapter can exist.
[...]
> > So the patch to ibsensors is actually trivial enough. Main issue is
> > contents of sysfs
>
> You might want to take a look at libsysfs, it makes finding all of the
> devices and attributes in the sysfs tree a whole lot easer.
>
No I did not want to make code dependent on libsysfs, besides arsing itself is
trivial.
Attached is patch against 2.6.0-test3-bk8 that sets all chip names to simply
chip names :) and patch for libsensors that makes use of it. libsensors still
needs to be built under 2.4, no attempt is made to allow building under 2.6.
I built it using make LINUX_HADERS=/home/bor/src/linux-2.4.21/linux
COMPILE_KERNEL=0. It is possible to get rid of this dependency but I'd like
to settle sysfs issue first. As can be seen the ugliest part is name
translation between sysfs attributes and libsensors feature names ... if
attributes were named consistently the whole would be much more simple.
This works perfectly for reading, writing does not work here but it is not my
patch. Reading:
{pts/2}% LD_LIBRARY_PATH=./lib ./prog/sensors/sensors
as99127f-i2c-0-2d
Adapter: SMBus I801 adapter at e800
Algorithm: Not available via sysfs
VCore 1: +1.70 V (min = +1.49 V, max = +1.81 V)
+3.3V: +3.47 V (min = +2.98 V, max = +3.63 V)
+5V: +5.00 V (min = +4.52 V, max = +5.48 V)
+12V: +11.37 V (min = +10.82 V, max = +13.13 V)
-12V: -11.57 V (min = -12.33 V, max = -15.07 V) ALARM
-5V: -5.03 V (min = -4.50 V, max = -5.49 V)
CPU: 4787 RPM (min = 3000 RPM, div = 2)
Front: 2922 RPM (min = 3000 RPM, div = 2) ALARM
MB: +28?C (limit = +127?C, hysteresis = +60?C)
CPU: +36.0?C (limit = +111?C, hysteresis = +97?C)
HDD: +37.0?C (limit = +120?C, hysteresis = +100?C)
vid: +1.650 V
alarms:
beep_enable:
Sound alarm enabled
writing:
{pts/2}% cat /sys/class/i2c-adapter/i2c-0/device/0-002d/in_max2
3632
{pts/2}% sudo zsh -c 'echo 3500 >
/sys/class/i2c-adapter/i2c-0/device/0-002d/in_max2'
{pts/2}% cat /sys/class/i2c-adapter/i2c-0/device/0-002d/in_max2
400
so writing is broken at least for w83781d driver
-andrey
On Sun, Aug 31, 2003 at 08:25:41PM +0400, Andrey Borzenkov wrote:
> On Tuesday 19 August 2003 23:45, Greg KH wrote:
> > That's what you are going to have to set the name file to in the
> > i2c_client structure, much like your patch did. Then look at the
> > different name files in each device directory to see what kind of device
> > it is (chip, subclient, etc.)
> >
>
> OK attached patch sets all names to just chip name for chips themselves and
> "chipname subclient" when subclient ios registered.
Thanks, I've applied this and will send it off to Linus in a bit.
> > > 3. libsensors asks for hysteresis value. This one does not exist in sysfs
> > > (so all temp readings fail). Is it emulated by kernel or read off chip?
> >
> > The kernel is exporting all of the info that it knows about through
> > sysfs.
>
> it just arbitrarily (re-)names them. "min" is not hysteresis; name is badly
> chosen.
Do you have a proposed change to the current
Documentation/i2c/sysfs-interface document? If you can think of better
names that make more sense, I'd be glad to change things to make it
easier.
> [...]
> > > 4. I do not have the slightest idea how ISA adapters look like in sysfs
> > > and where they are located. Anyone can give me example?
> >
> > They show up on the legacy bus:
> >
> > $ tree /sys/class/i2c-adapter/i2c-1/
> > /sys/class/i2c-adapter/i2c-1/
> >
> > |-- device -> ../../../devices/legacy/i2c-1
> >
>
> This does not help much. Libsensors expects as adapter identification either
> "i2c-N" or "isa". If I set it to "isa" I do not have any way to determine
> sysfs path except by rescanning /sys/class/i2c-adapter every time. Having
> /sys/class/i2-adapter/isa/... would be better, apparently it is assumed that
> only one such adapter can exist.
No, we internally do not differentiate between isa and non-isa adapters,
so why should we force that on the user? They work the same as far as
users notice, and now we are consistant in our naming.
thanks,
greg k-h
On Tuesday 23 September 2003 02:29, Greg KH wrote:
>
> Thanks, I've applied this and will send it off to Linus in a bit.
>
thank you.
> > it just arbitrarily (re-)names them. "min" is not hysteresis; name is
> > badly chosen.
>
> Do you have a proposed change to the current
> Documentation/i2c/sysfs-interface document? If you can think of better
> names that make more sense, I'd be glad to change things to make it
> easier.
>
it is probably too late now to change sysfs names when some programs already
use it. I'll check sysfs-interface, thank you for pointer.
> > > > 4. I do not have the slightest idea how ISA adapters look like in
> > > > sysfs and where they are located. Anyone can give me example?
> > >
> > > They show up on the legacy bus:
> > >
> > > $ tree /sys/class/i2c-adapter/i2c-1/
> > > /sys/class/i2c-adapter/i2c-1/
> > >
> > > |-- device -> ../../../devices/legacy/i2c-1
> >
> > This does not help much. Libsensors expects as adapter identification
> > either "i2c-N" or "isa". If I set it to "isa" I do not have any way to
> > determine sysfs path except by rescanning /sys/class/i2c-adapter every
> > time. Having /sys/class/i2-adapter/isa/... would be better, apparently it
> > is assumed that only one such adapter can exist.
>
> No, we internally do not differentiate between isa and non-isa adapters,
> so why should we force that on the user? They work the same as far as
> users notice, and now we are consistant in our naming.
>
Well, I just tried to match what users get out of libsensors on 2.4. The
reason was compatibility with /etc/sensors.conf where "isa" can possibly be
used as part of chip name. But I'd like that someone from sensors developers
comment on this.
thank you for your comments.
-andrey