Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751205AbdFTFIm (ORCPT ); Tue, 20 Jun 2017 01:08:42 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51763 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751094AbdFTFIj (ORCPT ); Tue, 20 Jun 2017 01:08:39 -0400 From: Shilpasri G Bhat To: linux@roeck-us.net, clg@kaod.org, stewart@linux.vnet.ibm.com Cc: jdelvare@suse.com, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, svaidy@linux.vnet.ibm.com, ego@linux.vnet.ibm.com, linux-hwmon@vger.kernel.org Subject: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array Date: Tue, 20 Jun 2017 10:38:12 +0530 X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1497935293-31618-1-git-send-email-shilpa.bhat@linux.vnet.ibm.com> References: <1497935293-31618-1-git-send-email-shilpa.bhat@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable x-cbid: 17062005-0004-0000-0000-0000021AAF7E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062005-0005-0000-0000-00005DFE41F3 Message-Id: <1497935293-31618-2-git-send-email-shilpa.bhat@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-20_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200094 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2070 Lines: 67 From: Cédric Le Goater 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 Tested-by: Shilpasri G Bhat --- 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; } -- 1.8.3.1