[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: More on hotplug issue w/HAL



David Zeuthen wrote:

Many thanks, I've just committed the code with a change in linux_osspec
to check if the device->bus_id starts with i2c instead of checking that
device->bus equals i2c. The latter was 'unknown' on my box - might be a
kernel or libsysfs issue.

I forgot to mention this - I'm discussing a kernel change with gregkh w/r/t the i2c-n adapters not appearing in the /sys/bus/i2c directory. Since they don't appear in this bus directory, libsysfs assign the adapters to the "unknown" bus. My patch registers these on the i2c bus to fix this, but Greg isn't certain this is the correct approach.


I can't consider myself an authority on this, so I'm not certain if this is even the correct way to do things. I've CC'd you on my other message to greg and the sensors list - perhaps you might offer more insight.

If the patch isn't accepted, it might be necessary for libsysfs to enumerate the /sys/bus/class/i2c-adapter to place the i2c-n adapters correctly on the i2c bus. I don't know what the correct solution is in this case.

No capabilities are currently supported, but the devices nodes now show
up.


I've added that info.[category|capabilities] will be set to i2c. Btw, I
wonder what a desktop application would use such a device for, any
ideas?

A desktop motherboard monitor could detect available sensors via their capabilities and dynamically generate a list of available sensor items (if they appeared as "sensor").


As well, a TV-watching-app could detect all I2C tuner devices with "tuner" capabilities.

Both of these would require additional sysfs information - perhaps via FDI files?

BTW, Is there a way to easily add the linux driver to the info.* attributes?

Matt.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]