On Thu, 28 Apr 2011 10:31:15 +0100, Jonathan Cameron wrote: > Guenter / Jean - cc'd you two because we have an sysfs interface naming question for > AC sensors that touches on the edge of hwmon. > > > For the metering parts I think we need to define a few more channel types. > > > > How about this ones > > > > inSX S is the apparent power. > > inPX P is the active power. > > inQX Q is the reactive power. > > inVX V is the voltage. (only inX ?) > > inVRMSX VRMS is the quadratic mean voltage. > Call it 'root mean square' rather than quadratic in the docs. They have different > meanings in English. > > inIX I is the current. > currX as per hwmon? They also define a power attribute, but only 1 (as DC > I guess). Cc'd Guenter and Jean to see if we can / want to share an interface... > > Guenter/ Jean, do you think hwmon will ever handle AC sensors? Well, never say never ;) While I've never heard of such sensors, I guess it would make some sense for a computer PSU to include a sensor chip monitoring both the AC input and the DC output to measure the efficiency of the unit. > Maybe we want to be > well clear of your interfaces just to avoid confusion? Or define a new set of shared > names for the above that we will both use (when it becomes relevant?) It's hard to tell in advance what hwmon would implement, as we lack actual examples. All I can say is that we would never use "in" prefixes for power or current. The above power examples would most probably be named powerX_apparent_input, powerX_active_input and powerX_reactive_input, if we ever have to support these. And inX_rms_input for the root mean square voltage input. But then again, I'm not sure if there is any point in sharing anything, or forcing any difference, between hwmon and iio interfaces. They are different by nature, and if we don't strictly enforce their relation, they are bound to randomly diverge and converge anyway. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html