[PATCH] hwmon: (ibmpowernv) Add current(A) sensors

Shilpasri G Bhat shilpa.bhat at linux.vnet.ibm.com
Tue Jun 20 14:47:48 AEST 2017


Hi Cedric,

On 06/19/2017 06:22 PM, Cédric Le Goater wrote:
> On 06/19/2017 11:25 AM, Shilpasri G Bhat wrote:
>> This patch exports current(A) sensors in inband sensors copied to
>> main memory by OCC.
>>
>> Signed-off-by: Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com>
>> ---
>>  drivers/hwmon/ibmpowernv.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>> index 862b832..e0557f9 100644
>> --- a/drivers/hwmon/ibmpowernv.c
>> +++ b/drivers/hwmon/ibmpowernv.c
>> @@ -50,6 +50,7 @@ enum sensors {
>>  	TEMP,
>>  	POWER_SUPPLY,
>>  	POWER_INPUT,
>> +	CURRENT,
>>  	MAX_SENSOR_TYPE,
>>  };
>>  
>> @@ -65,7 +66,8 @@ enum sensors {
>>  	{"fan", "ibm,opal-sensor-cooling-fan"},
>>  	{"temp", "ibm,opal-sensor-amb-temp"},
>>  	{"in", "ibm,opal-sensor-power-supply"},
>> -	{"power", "ibm,opal-sensor-power"}
>> +	{"power", "ibm,opal-sensor-power"},
>> +	{"curr", "ibm,opal-sensor-current"},
>>  };
>>  
>>  struct sensor_data {
>>
> 
> 
> I know why you are doing that but that is the old (cr?@#!y) way to 
> define sensor types. we should try to improve thing a little more 
> and use the "sensor-type" property only.
> 
> I think the patch below should help you adding new types without 
> too much changes to your skiboot patchset. Could you please check ? 
> 

Thanks for the patch. And yes this patch very neatly serves the purpose.
I will repost my patch on top of your patch.

Thanks and Regards,
Shilpa

> Thanks,
> 
> C. 
> 
> From: Cédric Le Goater <clg at kaod.org>
> Subject: [PATCH] hwmon: (ibmpowernv) introduce a legacy_compatibles array
> Date: Mon, 19 Jun 2017 14:29:29 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Today, the type of a PowerNV sensor system is determined with the
> "compatible" property for legacy Firmwares and with the "sensor-type"
> for newer ones. The same array of strings is used for both to do the
> matching and this raises some issue to introduce new sensor types.
> 
> Let's introduce two different arrays (legacy and current) to make
> things easier for new sensor types.
> 
> Signed-off-by: Cédric Le Goater <clg at kaod.org>
> ---


>  drivers/hwmon/ibmpowernv.c |   26 ++++++++++++++++++--------
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> Index: linux.git/drivers/hwmon/ibmpowernv.c
> ===================================================================
> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
> +++ linux.git/drivers/hwmon/ibmpowernv.c
> @@ -55,17 +55,27 @@ enum sensors {
> 
>  #define INVALID_INDEX (-1U)
> 
> +/*
> + * 'compatible' string properties for sensor types as defined in old
> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
> + */
> +static const char * const legacy_compatibles[] = {
> +	"ibm,opal-sensor-cooling-fan",
> +	"ibm,opal-sensor-amb-temp",
> +	"ibm,opal-sensor-power-supply",
> +	"ibm,opal-sensor-power"
> +};
> +
>  static struct sensor_group {
> -	const char *name;
> -	const char *compatible;
> +	const char *name; /* matches property 'sensor-type' */
>  	struct attribute_group group;
>  	u32 attr_count;
>  	u32 hwmon_index;
>  } sensor_groups[] = {
> -	{"fan", "ibm,opal-sensor-cooling-fan"},
> -	{"temp", "ibm,opal-sensor-amb-temp"},
> -	{"in", "ibm,opal-sensor-power-supply"},
> -	{"power", "ibm,opal-sensor-power"}
> +	{ "fan"   },
> +	{ "temp"  },
> +	{ "in"    },
> +	{ "power" }
>  };
> 
>  struct sensor_data {
> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device
>  	enum sensors type;
>  	const char *str;
> 
> -	for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> -		if (of_device_is_compatible(np, sensor_groups[type].compatible))
> +	for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
> +		if (of_device_is_compatible(np, legacy_compatibles[type]))
>  			return type;
>  	}
> 
> 



More information about the Linuxppc-dev mailing list