From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] asb_100 sensor location in /sys heirarchy changes
Date: Sun, 08 Apr 2007 18:49:41 +0000 [thread overview]
Message-ID: <46193945.80002@hhs.nl> (raw)
In-Reply-To: <4615F494.6070403@hhs.nl>
Jean Delvare wrote:
> Hi Hans,
>
> On Fri, 06 Apr 2007 09:19:48 +0200, Hans de Goede wrote:
>> Here is what I have on my system:
>> /sys/bus/i2c/devices/0-0050
>> /sys/bus/i2c/devices/0-0051
>>
>> And here is what I would like to have:
>> /sys/bus/i2c/devices/viapro-0-0050
>> /sys/bus/i2c/devices/viapro-0-0051
>>
>> The idea here is that the 0 added here is in case one can have multiple
>> instances of the same i2c master driver
>
> Which directly points to a weakness in your proposal: if you have two
> adapters of the same type, they'll get named foo-0 and foo-1. How do
> you know which is which? You don't, so you only moved the problem one
> step further, you didn't solve it.
>
I agree, but still I think there is some worth in my proposal. For one it makes
the problem smaller, for example in case of the poster of the asb_100 problem,
it will make the problem go away.
Also say I have a system with multiple identical masters, for example 2 nvidea
cards in SDI. Last time I looked at the device model code (2 years ago) when
you would register a new driver, the bus code would do a linear pass along all
the devices on the bus (and sub-busses) and see if the driver matched a device,
device by device, then upon a match the bus code will call the driver_detect
method, and once that has returned, it will go look at the next device on the
bus, etc. Thus AFAIK assuming for example PCI masters, foo-0 and foo-1 will
always get enumerated in fixed order.
> My understanding is that this is a problem for user-space to solve, it
> should not assume stable device numbering accross reboots. But it used
> to be the case and many user-space tools still rely on this.
>
After writing my initial mail about this, I've done some more thinking about
this and I agree, this should be solved at the userspace level.
So in our case in libsensors, thus I would like to propose to change the
libsensors name format for i2c from chipname-i2c-busnumber-address to
chipname-i2cmastername-masternumber-address
So for example. the SPD eeprom at i2c address 50 of my via smbus master would
be: "eeprom-i2c_viapro-0-50", Yes i know libsensors doesn't handle eeproms,
this is just an example.
I have also been thinking about ways to give the masters even uniquer names
then just numbering indentical masters, but anything I came up with was full of
holes.
The whole idea behind this "exercise" is to be able to make the dmi autoloaded
configs more explicit on which chip is located on which bus, and thus not
loading any drivers on i2c busses where they might do harm.
Which brings me to the question, when insmodding an i2c-client driver, is it
possible to tell it which masters to scan?
Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2007-04-08 18:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-06 7:19 [lm-sensors] asb_100 sensor location in /sys heirarchy changes Hans de Goede
2007-04-06 15:52 ` jk
2007-04-06 16:21 ` Hans de Goede
2007-04-06 17:21 ` jk
2007-04-06 18:10 ` jk
2007-04-06 18:51 ` Hans de Goede
2007-04-06 18:57 ` Hans de Goede
2007-04-08 17:50 ` Jean Delvare
2007-04-08 18:40 ` Jean Delvare
2007-04-08 18:42 ` Hans de Goede
2007-04-08 18:49 ` Hans de Goede [this message]
2007-04-08 20:17 ` lmsensors
2007-04-09 10:06 ` Jean Delvare
2007-04-09 11:01 ` Jean Delvare
2007-04-17 9:19 ` Jean Delvare
2007-04-17 13:34 ` Jeffrey J. Kosowsky
2007-04-17 19:02 ` Jean Delvare
2007-04-17 20:52 ` Jeffrey J. Kosowsky
2007-04-19 18:35 ` Jean Delvare
2007-04-19 18:50 ` Jeffrey J. Kosowsky
2007-04-23 5:38 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46193945.80002@hhs.nl \
--to=j.w.r.degoede@hhs.nl \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.