drivers: hwmon: Add On-Chip Controller driver

From: "Edward A. James" <[email protected]>

Add a generic mechanism to expose the sensors provided by the OCC in sysfs.

Signed-off-by Edward A. James <[email protected]>

Signed-off-by Andrew Jeffery <[email protected]>

---
 Documentation/hwmon/occ       |  62 +++++++++++
 drivers/hwmon/occ/Makefile    |   2 +-
 drivers/hwmon/occ/occ_sysfs.c | 253 ++++++++++++++++++++++++++++++++++++++++++
 drivers/hwmon/occ/occ_sysfs.h |  25 +++++
 4 files changed, 341 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h

Documentation/hwmon/occ +62 -0

index d1c863b..580af26 100644
@@ -27,6 +27,68 @@ Currently, all versions of the OCC support four types of sensor data: power,
 temperature, frequency, and "caps," which indicate limits and thresholds used
 internally on the OCC.
 
+sysfs Entries
+-------------
+
+The OCC driver uses the hwmon sysfs framework to provide data to userspace.
+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though many of the
+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.
+
+Below are detailed the names and meaning of each sensor file for both types of
+processors. All sensors are read-only unless otherwise specified. <x> indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please
+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+	all processors:
+		in<x>_input - frequency value
+		in<x>_label - sensor id
+temperature:
+	POWER8:
+		temp<x>_input - temperature value
+		temp<x>_label - sensor id
+	POWER9 (in addition to above):
+		temp<x>_type - FRU type
+
+power:
+	POWER8:
+		power<x>_input - power value
+		power<x>_label - sensor id
+		power<x>_average - accumulator
+		power<x>_average_interval - update tag (number of samples in
+			accumulator)
+	POWER9:
+		power<x>_input - power value
+		power<x>_label - sensor id
+		power<x>_average_min - accumulator[0]
+		power<x>_average_max - accumulator[1] (64 bits total)
+		power<x>_average_interval - update tag
+		power<x>_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+	POWER8:
+		power<x>_cap - current powercap
+		power<x>_cap_max - max powercap
+		power<x>_cap_min - min powercap
+		power<x>_max - normal powercap
+		power<x>_alarm - user powercap, r/w
+	POWER9:
+		power<x>_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be multiple
+OCCs present on the system, these two files are only present for the "master"
+OCC.
+	name - read the name of the driver
+	update_interval - read or write the minimum interval for polling the
+		OCC.
+
 BMC - Host Communications
 -------------------------
 

drivers/hwmon/occ/Makefile +1 -1

index 3ed79a5..67b5367 100644
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o

drivers/hwmon/occ/occ_sysfs.c new file +78 -0

new file mode 100644
index 0000000..50b20e2
@@ -0,0 +1,253 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define OCC_HWMON_NAME_LENGTH	32
+
+struct occ_sysfs {
+	struct device *dev;
+	struct occ *occ;
+
+	char label_buffer[OCC_HWMON_NAME_LENGTH + 1];
+	char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
+	const u32 *sensor_hwmon_configs;
+	struct hwmon_channel_info **occ_sensors;
+	struct hwmon_chip_info occ_info;
+	u16 user_powercap;
+};
+
+static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+			  u32 attr, int channel, long *val)
+{
+	int rc;
+	struct occ_sysfs *driver = dev_get_drvdata(dev);
+	struct occ *occ = driver->occ;
+
+	switch (type) {
+	case hwmon_in:
+		rc = occ_get_sensor_field(occ, FREQ, channel, attr, val);
+		break;
+	case hwmon_temp:
+		rc = occ_get_sensor_field(occ, TEMP, channel, attr, val);
+		break;
+	case hwmon_power:
+		rc = occ_get_sensor_field(occ, POWER, channel, attr, val);
+		break;
+	default:
+		rc = -EOPNOTSUPP;
+	}
+
+	return rc;
+}
+
+static int occ_hwmon_read_string(struct device *dev,
+				 enum hwmon_sensor_types type, u32 attr,
+				 int channel, const char **str)
+{
+	int rc;
+	unsigned long val = 0;
+	struct occ_sysfs *driver = dev_get_drvdata(dev);
+
+	if (!((type == hwmon_in && attr == hwmon_in_label) ||
+	    (type == hwmon_temp && attr == hwmon_temp_label) ||
+	    (type == hwmon_power && attr == hwmon_power_label)))
+		return -EOPNOTSUPP;

Quoted 204 lines · Eddie James

From: "Edward A. James" <[email protected]>

Add a generic mechanism to expose the sensors provided by the OCC in sysfs.

Signed-off-by Edward A. James <[email protected]>

Signed-off-by Andrew Jeffery <[email protected]>

---
 Documentation/hwmon/occ       |  62 +++++++++++
 drivers/hwmon/occ/Makefile    |   2 +-
 drivers/hwmon/occ/occ_sysfs.c | 253 
++++++++++++++++++++++++++++++++++++++++++
 drivers/hwmon/occ/occ_sysfs.h |  25 +++++
 4 files changed, 341 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h

Documentation/hwmon/occ +0 -0

index d1c863b..580af26 100644
@@ -27,6 +27,68 @@ Currently, all versions of the OCC support four 
 types of sensor data: power,
 temperature, frequency, and "caps," which indicate limits and 

thresholds used
internally on the OCC.

Documentation/hwmon/occ +4 -0

+sysfs Entries
+-------------
+
+The OCC driver uses the hwmon sysfs framework to provide data to 

userspace.

Documentation/hwmon/occ +3 -0

+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though 

many of the

Documentation/hwmon/occ +3 -0

+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be 

used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.

Documentation/hwmon/occ +2 -0

+
+Below are detailed the names and meaning of each sensor file for 

both types of
+processors. All sensors are read-only unless otherwise specified. <x> indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please

Documentation/hwmon/occ +40 -0

+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+    all processors:
+        in<x>_input - frequency value
+        in<x>_label - sensor id
+temperature:
+    POWER8:
+        temp<x>_input - temperature value
+        temp<x>_label - sensor id
+    POWER9 (in addition to above):
+        temp<x>_type - FRU type
+
+power:
+    POWER8:
+        power<x>_input - power value
+        power<x>_label - sensor id
+        power<x>_average - accumulator
+        power<x>_average_interval - update tag (number of samples in
+            accumulator)
+    POWER9:
+        power<x>_input - power value
+        power<x>_label - sensor id
+        power<x>_average_min - accumulator[0]
+        power<x>_average_max - accumulator[1] (64 bits total)
+        power<x>_average_interval - update tag
+        power<x>_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+    POWER8:
+        power<x>_cap - current powercap
+        power<x>_cap_max - max powercap
+        power<x>_cap_min - min powercap
+        power<x>_max - normal powercap
+        power<x>_alarm - user powercap, r/w
+    POWER9:
+        power<x>_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be 

multiple
+OCCs present on the system, these two files are only present for the "master"

Documentation/hwmon/occ +3 -0

+OCC.
+    name - read the name of the driver
+    update_interval - read or write the minimum interval for polling 

the

Documentation/hwmon/occ +2 -0

+        OCC.
+
 BMC - Host Communications
 -------------------------

drivers/hwmon/occ/Makefile +1 -1

index 3ed79a5..67b5367 100644
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o

drivers/hwmon/occ/occ_sysfs.c new file +4 -0

new file mode 100644
index 0000000..50b20e2
@@ -0,0 +1,253 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for 

implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */

drivers/hwmon/occ/occ_sysfs.c new file +30 -0

+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define OCC_HWMON_NAME_LENGTH    32
+
+struct occ_sysfs {
+    struct device *dev;
+    struct occ *occ;
+
+    char label_buffer[OCC_HWMON_NAME_LENGTH + 1];
+    char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
+    const u32 *sensor_hwmon_configs;
+    struct hwmon_channel_info **occ_sensors;
+    struct hwmon_chip_info occ_info;
+    u16 user_powercap;
+};
+
+static int occ_hwmon_read(struct device *dev, enum 

hwmon_sensor_types type,

drivers/hwmon/occ/occ_sysfs.c new file +42 -0

+              u32 attr, int channel, long *val)
+{
+    int rc;
+    struct occ_sysfs *driver = dev_get_drvdata(dev);
+    struct occ *occ = driver->occ;
+
+    switch (type) {
+    case hwmon_in:
+        rc = occ_get_sensor_field(occ, FREQ, channel, attr, val);
+        break;
+    case hwmon_temp:
+        rc = occ_get_sensor_field(occ, TEMP, channel, attr, val);
+        break;
+    case hwmon_power:
+        rc = occ_get_sensor_field(occ, POWER, channel, attr, val);
+        break;
+    default:
+        rc = -EOPNOTSUPP;
+    }
+
+    return rc;
+}
+
+static int occ_hwmon_read_string(struct device *dev,
+                 enum hwmon_sensor_types type, u32 attr,
+                 int channel, const char **str)
+{
+    int rc;
+    unsigned long val = 0;
+    struct occ_sysfs *driver = dev_get_drvdata(dev);
+
+    if (!((type == hwmon_in && attr == hwmon_in_label) ||
+        (type == hwmon_temp && attr == hwmon_temp_label) ||
+        (type == hwmon_power && attr == hwmon_power_label)))
+        return -EOPNOTSUPP;
+
+    /* will fetch the "label", the sensor_id */
+    rc = occ_hwmon_read(dev, type, attr, channel, &val);
+    if (rc < 0)
+        return rc;
+
+    /* just use one label buffer for all sensors. works with current 

hwmon

drivers/hwmon/occ/occ_sysfs.c line 88

Quoted 3 lines

drivers/hwmon/occ/occ_sysfs.c new file +3 -0

+     * implementation. only alternative is to store a buffer for each
+     * sensor, which gets expensive quickly.
+     */

Sorry for the late reply.

No, this doesn't work and is racy. Reading all labels from multiple threads in parallel will result in random data.

The label is supposed to be constant for each sensor. If it isn't, it is not a label. Either create it as constant and use the generated string, or drop the attribute.

Guenter