On Mon, Mar 18, 2013 at 09:02:41AM +0100, Jean Delvare wrote: > On Sun, 17 Mar 2013 06:19:33 -0700, Guenter Roeck wrote: > > On Sun, Mar 17, 2013 at 01:39:20PM +0100, Jean Delvare wrote: > > > I'd like to add something at this point. > > > > > > We have historically created the hwmon attributes in the hardware (i2c, > > > platform...) device, and then created an empty hwmon class device on > > > top of it so that libsensors etc. can locate all hardware monitoring > > > chips on the system. This is probably wrong and this may explain the > > > difference of views between Greg and Guenter. > > > > > > I suspect that ideally all hwmon-related attributes should belong to the > > > hwmon-class device and not the physical device. Would doing so solve > > > the problem of is_visible() needing chip-specific information that can > > > only be gathered during probe()? Sure this is an interface change, but > > > a few hwmon drivers already do it that way (the ones without an actual > > > hardware device, e.g. ACPI thermal zones) and libsensors supports this > > > since version 3.0.3, which was released in September 2008 - 4.5 years > > > ago. > > > > > > This would require creating the attributes after calling > > > hwmon_device_register() rather than before, but from the ongoing > > > discussion I seem to understand that the driver core supports creating > > > the attributes for us, possibly at the same time as the class device > > > will be created. Would this solve the userspace timing issue? > > > > > This is what I had in mind as ultimate possibility when I created > > the second API mentioned in my other e-mail. > > > > struct device *devm_hwmon_device_register(struct device *dev, > > const struct attribute_group **groups) > > > > The attributes are still attached to dev (ie to the hardware device) > > in my current code, but it should be possible to attach them to the > > hwmon class device instead. > > > > Problem with that approach is that it makes drivers larger, not smaller, > > at least if is_visible is needed. So it kind of defeats the purpose. > > > > We can go along that route anyway if people think it is the right or a better > > approach, but I am not sure if it is worth it. I can send out the patches if > > there is interest. > > Really, I don't know. All I know is that I do not have any time to > devote to this ATM. > Hi Jean, Can't help it. Worst case I learned how make better use of is_visible and how to avoid its pitfalls. Guenter _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
