linux-kernel - Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <568198ed-78e4-bd9d-3dad-0a8954bb97d1@kaod.org>
Date:   Tue, 20 Jun 2017 09:55:58 +0200
From:   Cédric Le Goater <clg@...d.org>
To:     Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>,
        linux@...ck-us.net, stewart@...ux.vnet.ibm.com
Cc:     jdelvare@...e.com, benh@...nel.crashing.org, paulus@...ba.org,
        mpe@...erman.id.au, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, svaidy@...ux.vnet.ibm.com,
        ego@...ux.vnet.ibm.com, linux-hwmon@...r.kernel.org
Subject: Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles
 array

On 06/20/2017 09:15 AM, Shilpasri G Bhat wrote:
> 
> 
> On 06/20/2017 11:36 AM, Cédric Le Goater wrote:
>> On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
>>> From: Cédric Le Goater <clg@...d.org>
>>>
>>> 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@...d.org>
>>> Tested-by: Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>
>>
>> Did you test on a Tuleta (IBM Power) system ? 
> 
> I have tested this patch on P9 FSP and Firestone.

OK. I just gave it a try on a Tuleta, P8 FSP, IBM Power system
Looks good.

Thanks,

C.

> 
>>
>> Thanks,
>>
>> C. 
>>
>>> ---
>>>  drivers/hwmon/ibmpowernv.c | 26 ++++++++++++++++++--------
>>>  1 file changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>>> index 862b832..6d8909c 100644
>>> --- a/drivers/hwmon/ibmpowernv.c
>>> +++ b/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_node *np)
>>>  	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;
>>>  	}
>>>  
>>>
>>
>