More on hotplug issue w/HAL

[Matthew Mastracci]

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.