Hi,
Sorry for breaking the thread (I was not subscribed to this list)...
I think that just simply linking current i2c device attributes intoclass structure is not the best thing to do. Since userspace needs tobe changed anyway (to a certain extent) we should evaluate whether itwould be beneficial to change layout too.
I would like to see something like this:
sys/class/sensors---fan---0---(min,in,div) | | | --1---(min,in,div) | |-temp---0---(type,min,max,hyst?) | | | --1---(type,min,max,hyst..) | --curr----0---(min,max,in)
This of course depends on Greg adding support for nested classes tothe driver code (how is it going, Greg?). Alternatively we couldflatten a tree a bit doingfan%d, temp%d...
We would have: sensors_register_fan, sensors_register_temp,sensors_register_curr, sensors_register_generic...
struct sensor_fan_dev { char name[MAX_SENSOR_NAME] int min, div; struct class_device class_dev;
int (*read)(struct sensor_temp_dev *); int (*start)(struct sensor_temp_dev *, int speed)};
struct sensor_temp_dev { char name[MAX_SENSOR_NAME] int type, min, max, hyst; struct class_device class_dev;
int (*read)(struct sensor_temp_dev *);};
This way every sensor input is registered as an independent classdevice, all their attributes are kept together, names are muchsimplier and there are less chances of clashes and I believe they areeasier to maintain. Other subsystems should also be able to add to thehierarchy without knowing anything about i2c internals.
What do you think?
-- Dmitry
