On Mon, Apr 13, 2020 at 01:34:19AM +0530, Naveen Krishna Ch wrote: > Hi Guenter > [ ... ] > > Constraint: > The platform has 2 sets of energy sensors, one at core level, one at > socket level. > If i populate the chip_info type as "hwmon_energy" for both sensors. > The naming of the sysfs entries are going to be continuous and the > user application > should read the label to identify which entry belongs to which sensor set. > I am a bit at loss. what is the problem with having multiple _energy attributes (energy1_input, energy2_input, ..., energy100_input) ? > Possible solutions : > I could think of following ways to avoid this > 1. Create 2 different hwmon devices You could do that, following the approach used by the k10temp driver. This is really your call. The question in that case, though, would be why you would want have a separate driver to start with and not just enhance the k10temp driver to also report energy (and power consumption, though I understand that the registers reporting it are not published). > 2. Use "hwmon_in" as type for one of the sensor sets and > "hwmon_energy" for other. _in is for voltages. Please don't tell me you plan to report voltages with this driver. If so, please extend the k10temp driver instead. > 3. Use "groups" for one of the sensor sets and populate the other via chip. This is a no-go. > What do you suggest ? > > Also, I noticed that the sysfs filename index for the hwmon_energy > type is starting with 1, > while hwmon_in starts with 0. Was this a design choice ? I think this was mostly historic, but it preceeds my involvement with the hwmon subsystem, so I don't really know. Guenter
