Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1673106 > unrolled thread

[PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-23 00:50 +0200
    [PATCH 2/7] drivers/hwmon/occ: Add command transport method for P8 and P9 Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-23 00:50 +0200
      Re: [PATCH 2/7] drivers/hwmon/occ: Add command transport method for  P8 and P9 Guenter Roeck <linux@roeck-us.net> - 2017-06-24 17:00 +0200
        Re: [PATCH 2/7] drivers/hwmon/occ: Add command transport method for  P8 and P9 Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-26 17:40 +0200
          Re: [PATCH 2/7] drivers/hwmon/occ: Add command transport method for  P8 and P9 Guenter Roeck <linux@roeck-us.net> - 2017-06-26 19:00 +0200
    [PATCH 6/7] drivers/hwmon/occ: Add non-hwmon attributes Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-23 00:50 +0200
    [PATCH 3/7] drivers/hwmon/occ: Parse OCC poll response Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-23 00:50 +0200
    [PATCH 7/7] drivers/hwmon/occ: Add error handling Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-23 01:00 +0200
    Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon  driver Guenter Roeck <linux@roeck-us.net> - 2017-06-23 07:00 +0200
      Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon  driver Eddie James <eajames@linux.vnet.ibm.com> - 2017-06-23 15:40 +0200

#1673106 — [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

From: "Edward A. James" <eajames@us.ibm.com>

This series adds a hwmon driver to support the OCC on POWER8 and POWER9
processors. The OCC is an embedded processor that provides realtime power and
thermal monitoring and management.

This driver has two different platform drivers as a "base" for the
hwmon stuff, as the means of communicating with the OCC on P8 and P9 is
completely different. For P8, the driver is an I2C client driver. For P9 the
driver is an FSI-based OCC client driver, and uses the OCC driver in-kernel
API.

There was a previous version of this driver that wasn't written with the
differences in communication methods between the two versions in mind. This
driver has been considerably simplified.

Edward A. James (7):
  drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver
  drivers/hwmon/occ: Add command transport method for P8 and P9
  drivers/hwmon/occ: Parse OCC poll response
  drivers/hwmon/occ: Add sensor types and versions
  drivers/hwmon/occ: Add sensor attributes and register hwmon device
  drivers/hwmon/occ: Add non-hwmon attributes
  drivers/hwmon/occ: Add error handling

 Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   77 ++
 .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   18 +
 .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
 Documentation/hwmon/occ                            |   84 ++
 drivers/hwmon/Kconfig                              |    2 +
 drivers/hwmon/Makefile                             |    1 +
 drivers/hwmon/occ/Kconfig                          |   28 +
 drivers/hwmon/occ/Makefile                         |   11 +
 drivers/hwmon/occ/common.c                         | 1242 ++++++++++++++++++++
 drivers/hwmon/occ/common.h                         |  151 +++
 drivers/hwmon/occ/p8_i2c.c                         |  250 ++++
 drivers/hwmon/occ/p9_sbe.c                         |  144 +++
 12 files changed, 2033 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
 create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
 create mode 100644 Documentation/hwmon/occ
 create mode 100644 drivers/hwmon/occ/Kconfig
 create mode 100644 drivers/hwmon/occ/Makefile
 create mode 100644 drivers/hwmon/occ/common.c
 create mode 100644 drivers/hwmon/occ/common.h
 create mode 100644 drivers/hwmon/occ/p8_i2c.c
 create mode 100644 drivers/hwmon/occ/p9_sbe.c

-- 
1.8.3.1

[toc] | [next] | [standalone]

#1673110 — [PATCH 2/7] drivers/hwmon/occ: Add command transport method for P8 and P9

From: "Edward A. James" <eajames@us.ibm.com>

For the P8 OCC, add the procedure to send a command to the OCC over I2C
bus. This involves writing the OCC command registers with serial
communication operations (SCOMs) interpreted by the I2C slave. For the
P9 OCC, add a procedure to use the OCC in-kernel API to send a command
to the OCC through the SBE engine.

Signed-off-by: Edward A. James <eajames@us.ibm.com>
---
 drivers/hwmon/occ/common.h |  13 ++++
 drivers/hwmon/occ/p8_i2c.c | 166 ++++++++++++++++++++++++++++++++++++++++++++-
 drivers/hwmon/occ/p9_sbe.c |  66 +++++++++++++++++-
 3 files changed, 243 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index dca642a..0c3f26f 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -15,6 +15,19 @@
 
 #define OCC_RESP_DATA_BYTES		4089
 
+#define OCC_TIMEOUT_MS			5000
+#define OCC_CMD_IN_PRG_MS		100
+
+/* OCC return codes */
+#define RESP_RETURN_CMD_IN_PRG		0xFF
+#define RESP_RETURN_SUCCESS		0
+#define RESP_RETURN_CMD_INVAL		0x11
+#define RESP_RETURN_CMD_LEN		0x12
+#define RESP_RETURN_DATA_INVAL		0x13
+#define RESP_RETURN_CHKSUM		0x14
+#define RESP_RETURN_OCC_ERR		0x15
+#define RESP_RETURN_STATE		0x16
+
 /* Same response format for all OCC versions.
  * Allocate the largest possible response.
  */
diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index 5075146..d6d70ce 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ b/drivers/hwmon/occ/p8_i2c.c
@@ -7,6 +7,7 @@
  * (at your option) any later version.
  */
 
+#include <asm/unaligned.h>
 #include "common.h"
 #include <linux/i2c.h>
 #include <linux/init.h>
@@ -19,9 +20,172 @@ struct p8_i2c_occ {
 
 #define to_p8_i2c_occ(x)	container_of((x), struct p8_i2c_occ, occ)
 
+static int p8_i2c_occ_getscom(struct i2c_client *client, u32 address, u8 *data)
+{
+	ssize_t rc;
+	__be64 buf_be;
+	u64 buf;
+	struct i2c_msg msgs[2];
+
+	/* p8 i2c slave requires shift */
+	address <<= 1;
+
+	msgs[0].addr = client->addr;
+	msgs[0].flags = client->flags & I2C_M_TEN;
+	msgs[0].len = sizeof(u32);
+	msgs[0].buf = (char *)&address;
+
+
+	msgs[1].addr = client->addr;
+	msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
+	msgs[1].len = sizeof(u64);
+	msgs[1].buf = (char *)&buf_be;
+
+	rc = i2c_transfer(client->adapter, msgs, 2);
+	if (rc < 0)
+		return rc;
+
+	buf = be64_to_cpu(buf_be);
+	memcpy(data, &buf, sizeof(u64));
+
+	return 0;
+}
+
+static int p8_i2c_occ_putscom(struct i2c_client *client, u32 address, u8 *data)
+{
+	u32 buf[3];
+	ssize_t rc;
+
+	/* p8 i2c slave requires shift */
+	address <<= 1;
+
+	buf[0] = address;
+	memcpy(&buf[1], &data[4], sizeof(u32));
+	memcpy(&buf[2], data, sizeof(u32));
+
+	rc = i2c_master_send(client, (const char *)buf, sizeof(buf));
+	if (rc < 0)
+		return rc;
+	else if (rc != sizeof(buf))
+		return -EIO;
+
+	return 0;
+}
+
+static int p8_i2c_occ_putscom_u32(struct i2c_client *client, u32 address,
+				  u32 data0, u32 data1)
+{
+	u8 buf[8];
+
+	memcpy(buf, &data0, 4);
+	memcpy(buf + 4, &data1, 4);
+
+	return p8_i2c_occ_putscom(client, address, buf);
+}
+
+static int p8_i2c_occ_putscom_be(struct i2c_client *client, u32 address,
+				 u8 *data)
+{
+	__be32 data0, data1;
+
+	memcpy(&data0, data, 4);
+	memcpy(&data1, data + 4, 4);
+
+	return p8_i2c_occ_putscom_u32(client, address, be32_to_cpu(data0),
+				      be32_to_cpu(data1));
+}
+
 static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
 {
-	return -EOPNOTSUPP;
+	int i, rc;
+	unsigned long start;
+	u16 data_length;
+	struct p8_i2c_occ *p8_i2c_occ = to_p8_i2c_occ(occ);
+	struct i2c_client *client = p8_i2c_occ->client;
+	struct occ_response *resp = &occ->resp;
+
+	start = jiffies;
+
+	/* set sram address for command */
+	rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF6000, 0);
+	if (rc)
+		goto err;
+
+	/* write command (must already be BE), i2c expects cpu-endian */
+	rc = p8_i2c_occ_putscom_be(client, 0x6B075, cmd);
+	if (rc)
+		goto err;
+
+	/* trigger OCC attention */
+	rc = p8_i2c_occ_putscom_u32(client, 0x6B035, 0x20010000, 0);
+	if (rc)
+		goto err;
+
+retry:
+	/* set sram address for response */
+	rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF7000, 0);
+	if (rc)
+		goto err;
+
+	/* read response */
+	rc = p8_i2c_occ_getscom(client, 0x6B075, (u8 *)resp);
+	if (rc)
+		goto err;
+
+	/* check the OCC response */
+	switch (resp->return_status) {
+	case RESP_RETURN_CMD_IN_PRG:
+		if (time_after(jiffies,
+			       start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
+			rc = -EALREADY;
+		else {
+			set_current_state(TASK_INTERRUPTIBLE);
+			schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
+
+			goto retry;
+		}
+		break;
+	case RESP_RETURN_SUCCESS:
+		rc = 0;
+		break;
+	case RESP_RETURN_CMD_INVAL:
+	case RESP_RETURN_CMD_LEN:
+	case RESP_RETURN_DATA_INVAL:
+	case RESP_RETURN_CHKSUM:
+		rc = -EINVAL;
+		break;
+	case RESP_RETURN_OCC_ERR:
+		rc = -EREMOTE;
+		break;
+	default:
+		rc = -EFAULT;
+	}
+
+	if (rc < 0) {
+		dev_warn(&client->dev, "occ bad response: %d\n",
+			 resp->return_status);
+		return rc;
+	}
+
+	data_length = get_unaligned_be16(&resp->data_length_be);
+	if (data_length > OCC_RESP_DATA_BYTES) {
+		dev_warn(&client->dev, "occ bad data length: %d\n",
+			 data_length);
+		return -EDOM;
+	}
+
+	/* read remaining response */
+	for (i = 8; i < data_length + 7; i += 8) {
+		rc = p8_i2c_occ_getscom(client, 0x6B075, ((u8 *)resp) + i);
+		if (rc)
+			goto err;
+	}
+
+	return data_length + 7;
+
+err:
+	dev_err(&client->dev, "i2c scom op failed rc: %d\n", rc);
+	return rc;
 }
 
 static int p8_i2c_occ_probe(struct i2c_client *client,
diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
index 0cef428..981c53f 100644
--- a/drivers/hwmon/occ/p9_sbe.c
+++ b/drivers/hwmon/occ/p9_sbe.c
@@ -22,7 +22,71 @@ struct p9_sbe_occ {
 
 static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd)
 {
-	return -EOPNOTSUPP;
+	int rc;
+	unsigned long start;
+	struct occ_client *client;
+	struct occ_response *resp = &occ->resp;
+	struct p9_sbe_occ *p9_sbe_occ = to_p9_sbe_occ(occ);
+
+	start = jiffies;
+
+retry:
+	client = occ_drv_open(p9_sbe_occ->sbe, 0);
+	if (!client)
+		return -ENODEV;
+
+	/* skip first byte (sequence number), OCC driver handles it */
+	rc = occ_drv_write(client, (const char *)&cmd[1], 7);
+	if (rc < 0)
+		goto err;
+
+	rc = occ_drv_read(client, (char *)resp, sizeof(*resp));
+	if (rc < 0)
+		goto err;
+
+	occ_drv_release(client);
+
+	/* check the OCC response */
+	switch (resp->return_status) {
+	case RESP_RETURN_CMD_IN_PRG:
+		if (time_after(jiffies,
+			       start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
+			rc = -EALREADY;
+		else {
+			set_current_state(TASK_INTERRUPTIBLE);
+			schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
+
+			goto retry;
+		}
+		break;
+	case RESP_RETURN_SUCCESS:
+		rc = 0;
+		break;
+	case RESP_RETURN_CMD_INVAL:
+	case RESP_RETURN_CMD_LEN:
+	case RESP_RETURN_DATA_INVAL:
+	case RESP_RETURN_CHKSUM:
+		rc = -EINVAL;
+		break;
+	case RESP_RETURN_OCC_ERR:
+		rc = -EREMOTE;
+		break;
+	default:
+		rc = -EFAULT;
+	}
+
+	if (rc < 0) {
+		dev_warn(occ->bus_dev, "occ bad response: %d\n",
+			 resp->return_status);
+		return rc;
+	}
+
+	return 0;
+
+err:
+	occ_drv_release(client);
+	dev_err(occ->bus_dev, "occ bus op failed rc: %d\n", rc);
+	return rc;
 }
 
 static int p9_sbe_occ_probe(struct platform_device *pdev)
-- 
1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1674090 — Re: [PATCH 2/7] drivers/hwmon/occ: Add command transport method for P8 and P9

On 06/22/2017 03:48 PM, Eddie James wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
> 
> For the P8 OCC, add the procedure to send a command to the OCC over I2C
> bus. This involves writing the OCC command registers with serial
> communication operations (SCOMs) interpreted by the I2C slave. For the
> P9 OCC, add a procedure to use the OCC in-kernel API to send a command
> to the OCC through the SBE engine.
> 
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> ---
>   drivers/hwmon/occ/common.h |  13 ++++
>   drivers/hwmon/occ/p8_i2c.c | 166 ++++++++++++++++++++++++++++++++++++++++++++-
>   drivers/hwmon/occ/p9_sbe.c |  66 +++++++++++++++++-
>   3 files changed, 243 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
> index dca642a..0c3f26f 100644
> --- a/drivers/hwmon/occ/common.h
> +++ b/drivers/hwmon/occ/common.h
> @@ -15,6 +15,19 @@
>   
>   #define OCC_RESP_DATA_BYTES		4089
>   
> +#define OCC_TIMEOUT_MS			5000

Five seconds ? Isn't that a bit excessive ?

> +#define OCC_CMD_IN_PRG_MS		100
> +
> +/* OCC return codes */
> +#define RESP_RETURN_CMD_IN_PRG		0xFF
> +#define RESP_RETURN_SUCCESS		0
> +#define RESP_RETURN_CMD_INVAL		0x11
> +#define RESP_RETURN_CMD_LEN		0x12
> +#define RESP_RETURN_DATA_INVAL		0x13
> +#define RESP_RETURN_CHKSUM		0x14
> +#define RESP_RETURN_OCC_ERR		0x15
> +#define RESP_RETURN_STATE		0x16
> +

Why are those return codes defined here ? They must be set somewhere
outside this driver, and I would expect them to be defined there.

Also see below - the missing context makes it all but impossible
th review this patch series.

>   /* Same response format for all OCC versions.
>    * Allocate the largest possible response.
>    */
> diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
> index 5075146..d6d70ce 100644
> --- a/drivers/hwmon/occ/p8_i2c.c
> +++ b/drivers/hwmon/occ/p8_i2c.c
> @@ -7,6 +7,7 @@
>    * (at your option) any later version.
>    */
>   
> +#include <asm/unaligned.h>

Alphabetic order, though it is ok to list linux.. includes first followed by
asm... includes followed by local includes.

>   #include "common.h"
>   #include <linux/i2c.h>
>   #include <linux/init.h>
> @@ -19,9 +20,172 @@ struct p8_i2c_occ {
>   
>   #define to_p8_i2c_occ(x)	container_of((x), struct p8_i2c_occ, occ)
>   
> +static int p8_i2c_occ_getscom(struct i2c_client *client, u32 address, u8 *data)
> +{
> +	ssize_t rc;
> +	__be64 buf_be;

_be is redundant. Yes, you have buf as well, but that is really not needed.

> +	u64 buf;
> +	struct i2c_msg msgs[2];
> +
> +	/* p8 i2c slave requires shift */
> +	address <<= 1;
> +
> +	msgs[0].addr = client->addr;
> +	msgs[0].flags = client->flags & I2C_M_TEN;
> +	msgs[0].len = sizeof(u32);
> +	msgs[0].buf = (char *)&address;

No endianness concerns here ?

> +
> +
checkpatch --strict, please

> +	msgs[1].addr = client->addr;
> +	msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
> +	msgs[1].len = sizeof(u64);
> +	msgs[1].buf = (char *)&buf_be;
> +
> +	rc = i2c_transfer(client->adapter, msgs, 2);
> +	if (rc < 0)
> +		return rc;
> +
> +	buf = be64_to_cpu(buf_be);
> +	memcpy(data, &buf, sizeof(u64));

	*(u64 *)data = be64_to_cpu(buf_be);

> +
> +	return 0;
> +}
> +
> +static int p8_i2c_occ_putscom(struct i2c_client *client, u32 address, u8 *data)
> +{
> +	u32 buf[3];
> +	ssize_t rc;
> +
> +	/* p8 i2c slave requires shift */
> +	address <<= 1;
> +
> +	buf[0] = address;
> +	memcpy(&buf[1], &data[4], sizeof(u32));
> +	memcpy(&buf[2], data, sizeof(u32));

No endianness concerns ? Presumably not, but that might warrant a comment
above, with the function declaration.

> +
> +	rc = i2c_master_send(client, (const char *)buf, sizeof(buf));
> +	if (rc < 0)
> +		return rc;
> +	else if (rc != sizeof(buf))
> +		return -EIO;
> +
> +	return 0;
> +}
> +
> +static int p8_i2c_occ_putscom_u32(struct i2c_client *client, u32 address,
> +				  u32 data0, u32 data1)
> +{
> +	u8 buf[8];
> +
> +	memcpy(buf, &data0, 4);
> +	memcpy(buf + 4, &data1, 4);
> +
> +	return p8_i2c_occ_putscom(client, address, buf);
> +}
> +
> +static int p8_i2c_occ_putscom_be(struct i2c_client *client, u32 address,
> +				 u8 *data)
> +{
> +	__be32 data0, data1;
> +
> +	memcpy(&data0, data, 4);
> +	memcpy(&data1, data + 4, 4);
> +
> +	return p8_i2c_occ_putscom_u32(client, address, be32_to_cpu(data0),
> +				      be32_to_cpu(data1));
> +}
> +
>   static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
>   {
> -	return -EOPNOTSUPP;
> +	int i, rc;
> +	unsigned long start;
> +	u16 data_length;
> +	struct p8_i2c_occ *p8_i2c_occ = to_p8_i2c_occ(occ);
> +	struct i2c_client *client = p8_i2c_occ->client;
> +	struct occ_response *resp = &occ->resp;
> +
> +	start = jiffies;
> +
> +	/* set sram address for command */
> +	rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF6000, 0);

Please declare those magics as defines to give readers an idea
what this is about.

> +	if (rc)
> +		goto err;
> +
> +	/* write command (must already be BE), i2c expects cpu-endian */
> +	rc = p8_i2c_occ_putscom_be(client, 0x6B075, cmd);
> +	if (rc)
> +		goto err;
> +
> +	/* trigger OCC attention */
> +	rc = p8_i2c_occ_putscom_u32(client, 0x6B035, 0x20010000, 0);
> +	if (rc)
> +		goto err;
> +
> +retry:
> +	/* set sram address for response */
> +	rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF7000, 0);
> +	if (rc)
> +		goto err;
> +
> +	/* read response */
> +	rc = p8_i2c_occ_getscom(client, 0x6B075, (u8 *)resp);
> +	if (rc)
> +		goto err;
> +
> +	/* check the OCC response */
> +	switch (resp->return_status) {
> +	case RESP_RETURN_CMD_IN_PRG:
> +		if (time_after(jiffies,
> +			       start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
> +			rc = -EALREADY;
> +		else {
> +			set_current_state(TASK_INTERRUPTIBLE);
> +			schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
> +
> +			goto retry;

Please refactor as loop.

> +		}
> +		break;
> +	case RESP_RETURN_SUCCESS:
> +		rc = 0;
> +		break;
> +	case RESP_RETURN_CMD_INVAL:
> +	case RESP_RETURN_CMD_LEN:
> +	case RESP_RETURN_DATA_INVAL:
> +	case RESP_RETURN_CHKSUM:
> +		rc = -EINVAL;
> +		break;
> +	case RESP_RETURN_OCC_ERR:
> +		rc = -EREMOTE;

"Object is remote"

> +		break;
> +	default:
> +		rc = -EFAULT;

"Bad address" ?

> +	}
> +
> +	if (rc < 0) {
> +		dev_warn(&client->dev, "occ bad response: %d\n",
> +			 resp->return_status);
> +		return rc;
> +	}
> +
> +	data_length = get_unaligned_be16(&resp->data_length_be);
> +	if (data_length > OCC_RESP_DATA_BYTES) {
> +		dev_warn(&client->dev, "occ bad data length: %d\n",
> +			 data_length);
> +		return -EDOM;

"Math argument out of domain" ?


Your error codes seem to be kind of random.

> +	}
> +
> +	/* read remaining response */
> +	for (i = 8; i < data_length + 7; i += 8) {
> +		rc = p8_i2c_occ_getscom(client, 0x6B075, ((u8 *)resp) + i);
> +		if (rc)
> +			goto err;
> +	}
> +
> +	return data_length + 7;
> +
> +err:
> +	dev_err(&client->dev, "i2c scom op failed rc: %d\n", rc);
> +	return rc;
>   }
>   
>   static int p8_i2c_occ_probe(struct i2c_client *client,
> diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
> index 0cef428..981c53f 100644
> --- a/drivers/hwmon/occ/p9_sbe.c
> +++ b/drivers/hwmon/occ/p9_sbe.c
> @@ -22,7 +22,71 @@ struct p9_sbe_occ {
>   
>   static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd)
>   {
> -	return -EOPNOTSUPP;
> +	int rc;
> +	unsigned long start;
> +	struct occ_client *client;
> +	struct occ_response *resp = &occ->resp;
> +	struct p9_sbe_occ *p9_sbe_occ = to_p9_sbe_occ(occ);
> +
> +	start = jiffies;
> +
> +retry:
> +	client = occ_drv_open(p9_sbe_occ->sbe, 0);

Where does this come from ? Ah, I see, there is an "include <linux/occ.h>",
but no mention where it comes from.

I'll stop reviewing the series here. I can not review it without complete context.

> +	if (!client)
> +		return -ENODEV;
> +
> +	/* skip first byte (sequence number), OCC driver handles it */
> +	rc = occ_drv_write(client, (const char *)&cmd[1], 7);
> +	if (rc < 0)
> +		goto err;
> +
> +	rc = occ_drv_read(client, (char *)resp, sizeof(*resp));
> +	if (rc < 0)
> +		goto err;
> +
> +	occ_drv_release(client);

Might as well cann release() first to save the double call below.

> +
> +	/* check the OCC response */
> +	switch (resp->return_status) {
> +	case RESP_RETURN_CMD_IN_PRG:
> +		if (time_after(jiffies,
> +			       start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
> +			rc = -EALREADY;

This is another odd return value. Normally one would expect something like
-ETIMEDOUT.

> +		else {
> +			set_current_state(TASK_INTERRUPTIBLE);
> +			schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
> +

Does the called code generate an interrupt if the command is complete ?

Makes me wonder why the write/read sequence isn't just synchronous.
Again, missing context.

> +			goto retry;

Please refactor as loop.

> +		}
> +		break;
> +	case RESP_RETURN_SUCCESS:
> +		rc = 0;
> +		break;
> +	case RESP_RETURN_CMD_INVAL:
> +	case RESP_RETURN_CMD_LEN:
> +	case RESP_RETURN_DATA_INVAL:
> +	case RESP_RETURN_CHKSUM:
> +		rc = -EINVAL;
> +		break;
> +	case RESP_RETURN_OCC_ERR:
> +		rc = -EREMOTE;
> +		break;
> +	default:
> +		rc = -EFAULT;
> +	}
> +
> +	if (rc < 0) {
> +		dev_warn(occ->bus_dev, "occ bad response: %d\n",
> +			 resp->return_status);
> +		return rc;
> +	}
> +
> +	return 0;
> +
> +err:
> +	occ_drv_release(client);
> +	dev_err(occ->bus_dev, "occ bus op failed rc: %d\n", rc);

Is all this noise really needed ? I can understand it for debugging,
but for released code ?

> +	return rc;
>   }
>   
>   static int p9_sbe_occ_probe(struct platform_device *pdev)
> 

[toc] | [prev] | [next] | [standalone]

#1674881 — Re: [PATCH 2/7] drivers/hwmon/occ: Add command transport method for P8 and P9

On 06/24/2017 09:49 AM, Guenter Roeck wrote:
> On 06/22/2017 03:48 PM, Eddie James wrote:
>> From: "Edward A. James" <eajames@us.ibm.com>
>>
>> For the P8 OCC, add the procedure to send a command to the OCC over I2C
>> bus. This involves writing the OCC command registers with serial
>> communication operations (SCOMs) interpreted by the I2C slave. For the
>> P9 OCC, add a procedure to use the OCC in-kernel API to send a command
>> to the OCC through the SBE engine.
>>
>> Signed-off-by: Edward A. James <eajames@us.ibm.com>
>> ---
>>   drivers/hwmon/occ/common.h |  13 ++++
>>   drivers/hwmon/occ/p8_i2c.c | 166 
>> ++++++++++++++++++++++++++++++++++++++++++++-
>>   drivers/hwmon/occ/p9_sbe.c |  66 +++++++++++++++++-
>>   3 files changed, 243 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
>> index dca642a..0c3f26f 100644
>> --- a/drivers/hwmon/occ/common.h
>> +++ b/drivers/hwmon/occ/common.h
>> @@ -15,6 +15,19 @@
>>     #define OCC_RESP_DATA_BYTES        4089
>>   +#define OCC_TIMEOUT_MS            5000
>
> Five seconds ? Isn't that a bit excessive ?
>
>> +#define OCC_CMD_IN_PRG_MS        100
>> +
>> +/* OCC return codes */
>> +#define RESP_RETURN_CMD_IN_PRG        0xFF
>> +#define RESP_RETURN_SUCCESS        0
>> +#define RESP_RETURN_CMD_INVAL        0x11
>> +#define RESP_RETURN_CMD_LEN        0x12
>> +#define RESP_RETURN_DATA_INVAL        0x13
>> +#define RESP_RETURN_CHKSUM        0x14
>> +#define RESP_RETURN_OCC_ERR        0x15
>> +#define RESP_RETURN_STATE        0x16
>> +
>
> Why are those return codes defined here ? They must be set somewhere
> outside this driver, and I would expect them to be defined there.

They are defined in code that runs on the OCC itself, and perhaps in 
applications that talk to the OCC, but it's nowhere in the kernel. I'm 
not aware of any plans to either define or use these codes anywhere else 
in the kernel at the moment.

>
> Also see below - the missing context makes it all but impossible
> th review this patch series.

Agreed, I have sent you links to the FSI client driver series that this 
driver uses. Thanks for the review, will include your suggestions in a 
v2 soon. Couple of comments below.

Thanks,
Eddie

>
>>   /* Same response format for all OCC versions.
>>    * Allocate the largest possible response.
>>    */
>> diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
>> index 5075146..d6d70ce 100644
>> --- a/drivers/hwmon/occ/p8_i2c.c
>> +++ b/drivers/hwmon/occ/p8_i2c.c
>> @@ -7,6 +7,7 @@
>>    * (at your option) any later version.
>>    */
>>   +#include <asm/unaligned.h>
>
> Alphabetic order, though it is ok to list linux.. includes first 
> followed by
> asm... includes followed by local includes.
>
>>   #include "common.h"
>>   #include <linux/i2c.h>
>>   #include <linux/init.h>
>> @@ -19,9 +20,172 @@ struct p8_i2c_occ {
>>     #define to_p8_i2c_occ(x)    container_of((x), struct p8_i2c_occ, 
>> occ)
>>   +static int p8_i2c_occ_getscom(struct i2c_client *client, u32 
>> address, u8 *data)
>> +{
>> +    ssize_t rc;
>> +    __be64 buf_be;
>
> _be is redundant. Yes, you have buf as well, but that is really not 
> needed.
>
>> +    u64 buf;
>> +    struct i2c_msg msgs[2];
>> +
>> +    /* p8 i2c slave requires shift */
>> +    address <<= 1;
>> +
>> +    msgs[0].addr = client->addr;
>> +    msgs[0].flags = client->flags & I2C_M_TEN;
>> +    msgs[0].len = sizeof(u32);
>> +    msgs[0].buf = (char *)&address;
>
> No endianness concerns here ?
>
>> +
>> +
> checkpatch --strict, please
>
>> +    msgs[1].addr = client->addr;
>> +    msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
>> +    msgs[1].len = sizeof(u64);
>> +    msgs[1].buf = (char *)&buf_be;
>> +
>> +    rc = i2c_transfer(client->adapter, msgs, 2);
>> +    if (rc < 0)
>> +        return rc;
>> +
>> +    buf = be64_to_cpu(buf_be);
>> +    memcpy(data, &buf, sizeof(u64));
>
>     *(u64 *)data = be64_to_cpu(buf_be);
>
>> +
>> +    return 0;
>> +}
>> +
>> +static int p8_i2c_occ_putscom(struct i2c_client *client, u32 
>> address, u8 *data)
>> +{
>> +    u32 buf[3];
>> +    ssize_t rc;
>> +
>> +    /* p8 i2c slave requires shift */
>> +    address <<= 1;
>> +
>> +    buf[0] = address;
>> +    memcpy(&buf[1], &data[4], sizeof(u32));
>> +    memcpy(&buf[2], data, sizeof(u32));
>
> No endianness concerns ? Presumably not, but that might warrant a comment
> above, with the function declaration.
>
>> +
>> +    rc = i2c_master_send(client, (const char *)buf, sizeof(buf));
>> +    if (rc < 0)
>> +        return rc;
>> +    else if (rc != sizeof(buf))
>> +        return -EIO;
>> +
>> +    return 0;
>> +}
>> +
>> +static int p8_i2c_occ_putscom_u32(struct i2c_client *client, u32 
>> address,
>> +                  u32 data0, u32 data1)
>> +{
>> +    u8 buf[8];
>> +
>> +    memcpy(buf, &data0, 4);
>> +    memcpy(buf + 4, &data1, 4);
>> +
>> +    return p8_i2c_occ_putscom(client, address, buf);
>> +}
>> +
>> +static int p8_i2c_occ_putscom_be(struct i2c_client *client, u32 
>> address,
>> +                 u8 *data)
>> +{
>> +    __be32 data0, data1;
>> +
>> +    memcpy(&data0, data, 4);
>> +    memcpy(&data1, data + 4, 4);
>> +
>> +    return p8_i2c_occ_putscom_u32(client, address, be32_to_cpu(data0),
>> +                      be32_to_cpu(data1));
>> +}
>> +
>>   static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
>>   {
>> -    return -EOPNOTSUPP;
>> +    int i, rc;
>> +    unsigned long start;
>> +    u16 data_length;
>> +    struct p8_i2c_occ *p8_i2c_occ = to_p8_i2c_occ(occ);
>> +    struct i2c_client *client = p8_i2c_occ->client;
>> +    struct occ_response *resp = &occ->resp;
>> +
>> +    start = jiffies;
>> +
>> +    /* set sram address for command */
>> +    rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF6000, 0);
>
> Please declare those magics as defines to give readers an idea
> what this is about.
>
>> +    if (rc)
>> +        goto err;
>> +
>> +    /* write command (must already be BE), i2c expects cpu-endian */
>> +    rc = p8_i2c_occ_putscom_be(client, 0x6B075, cmd);
>> +    if (rc)
>> +        goto err;
>> +
>> +    /* trigger OCC attention */
>> +    rc = p8_i2c_occ_putscom_u32(client, 0x6B035, 0x20010000, 0);
>> +    if (rc)
>> +        goto err;
>> +
>> +retry:
>> +    /* set sram address for response */
>> +    rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF7000, 0);
>> +    if (rc)
>> +        goto err;
>> +
>> +    /* read response */
>> +    rc = p8_i2c_occ_getscom(client, 0x6B075, (u8 *)resp);
>> +    if (rc)
>> +        goto err;
>> +
>> +    /* check the OCC response */
>> +    switch (resp->return_status) {
>> +    case RESP_RETURN_CMD_IN_PRG:
>> +        if (time_after(jiffies,
>> +                   start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
>> +            rc = -EALREADY;
>> +        else {
>> +            set_current_state(TASK_INTERRUPTIBLE);
>> + schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
>> +
>> +            goto retry;
>
> Please refactor as loop.
>
>> +        }
>> +        break;
>> +    case RESP_RETURN_SUCCESS:
>> +        rc = 0;
>> +        break;
>> +    case RESP_RETURN_CMD_INVAL:
>> +    case RESP_RETURN_CMD_LEN:
>> +    case RESP_RETURN_DATA_INVAL:
>> +    case RESP_RETURN_CHKSUM:
>> +        rc = -EINVAL;
>> +        break;
>> +    case RESP_RETURN_OCC_ERR:
>> +        rc = -EREMOTE;
>
> "Object is remote"

Closest error code i could find to say "the error is not in the driver, 
but on the OCC". I'll add a comment.

>
>> +        break;
>> +    default:
>> +        rc = -EFAULT;
>
> "Bad address" ?
>
>> +    }
>> +
>> +    if (rc < 0) {
>> +        dev_warn(&client->dev, "occ bad response: %d\n",
>> +             resp->return_status);
>> +        return rc;
>> +    }
>> +
>> +    data_length = get_unaligned_be16(&resp->data_length_be);
>> +    if (data_length > OCC_RESP_DATA_BYTES) {
>> +        dev_warn(&client->dev, "occ bad data length: %d\n",
>> +             data_length);
>> +        return -EDOM;
>
> "Math argument out of domain" ?
>
>
> Your error codes seem to be kind of random.

Tricky to match up the OCC errors with linux errnos.

>
>> +    }
>> +
>> +    /* read remaining response */
>> +    for (i = 8; i < data_length + 7; i += 8) {
>> +        rc = p8_i2c_occ_getscom(client, 0x6B075, ((u8 *)resp) + i);
>> +        if (rc)
>> +            goto err;
>> +    }
>> +
>> +    return data_length + 7;
>> +
>> +err:
>> +    dev_err(&client->dev, "i2c scom op failed rc: %d\n", rc);
>> +    return rc;
>>   }
>>     static int p8_i2c_occ_probe(struct i2c_client *client,
>> diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
>> index 0cef428..981c53f 100644
>> --- a/drivers/hwmon/occ/p9_sbe.c
>> +++ b/drivers/hwmon/occ/p9_sbe.c
>> @@ -22,7 +22,71 @@ struct p9_sbe_occ {
>>     static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd)
>>   {
>> -    return -EOPNOTSUPP;
>> +    int rc;
>> +    unsigned long start;
>> +    struct occ_client *client;
>> +    struct occ_response *resp = &occ->resp;
>> +    struct p9_sbe_occ *p9_sbe_occ = to_p9_sbe_occ(occ);
>> +
>> +    start = jiffies;
>> +
>> +retry:
>> +    client = occ_drv_open(p9_sbe_occ->sbe, 0);
>
> Where does this come from ? Ah, I see, there is an "include 
> <linux/occ.h>",
> but no mention where it comes from.
>
> I'll stop reviewing the series here. I can not review it without 
> complete context.
>
>> +    if (!client)
>> +        return -ENODEV;
>> +
>> +    /* skip first byte (sequence number), OCC driver handles it */
>> +    rc = occ_drv_write(client, (const char *)&cmd[1], 7);
>> +    if (rc < 0)
>> +        goto err;
>> +
>> +    rc = occ_drv_read(client, (char *)resp, sizeof(*resp));
>> +    if (rc < 0)
>> +        goto err;
>> +
>> +    occ_drv_release(client);
>
> Might as well cann release() first to save the double call below.
>
>> +
>> +    /* check the OCC response */
>> +    switch (resp->return_status) {
>> +    case RESP_RETURN_CMD_IN_PRG:
>> +        if (time_after(jiffies,
>> +                   start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
>> +            rc = -EALREADY;
>
> This is another odd return value. Normally one would expect something 
> like
> -ETIMEDOUT.

Could do, but EALREADY more closely matches the "command in progress" 
return code from the OCC.

>
>> +        else {
>> +            set_current_state(TASK_INTERRUPTIBLE);
>> + schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
>> +
>
> Does the called code generate an interrupt if the command is complete ?
>
> Makes me wonder why the write/read sequence isn't just synchronous.
> Again, missing context.
>
>> +            goto retry;
>
> Please refactor as loop.
>
>> +        }
>> +        break;
>> +    case RESP_RETURN_SUCCESS:
>> +        rc = 0;
>> +        break;
>> +    case RESP_RETURN_CMD_INVAL:
>> +    case RESP_RETURN_CMD_LEN:
>> +    case RESP_RETURN_DATA_INVAL:
>> +    case RESP_RETURN_CHKSUM:
>> +        rc = -EINVAL;
>> +        break;
>> +    case RESP_RETURN_OCC_ERR:
>> +        rc = -EREMOTE;
>> +        break;
>> +    default:
>> +        rc = -EFAULT;
>> +    }
>> +
>> +    if (rc < 0) {
>> +        dev_warn(occ->bus_dev, "occ bad response: %d\n",
>> +             resp->return_status);
>> +        return rc;
>> +    }
>> +
>> +    return 0;
>> +
>> +err:
>> +    occ_drv_release(client);
>> +    dev_err(occ->bus_dev, "occ bus op failed rc: %d\n", rc);
>
> Is all this noise really needed ? I can understand it for debugging,
> but for released code ?

Errors can come from a lot of different places in this driver, so I 
thought it helpful. We'd only get one dev_x print per failure, so 
doesn't seem too excessive to me.

>
>> +    return rc;
>>   }
>>     static int p9_sbe_occ_probe(struct platform_device *pdev)
>>
>

[toc] | [prev] | [next] | [standalone]

#1674943 — Re: [PATCH 2/7] drivers/hwmon/occ: Add command transport method for P8 and P9

On Mon, Jun 26, 2017 at 10:30:28AM -0500, Eddie James wrote:
> 
> 
> On 06/24/2017 09:49 AM, Guenter Roeck wrote:
> >On 06/22/2017 03:48 PM, Eddie James wrote:
> >>From: "Edward A. James" <eajames@us.ibm.com>
> >>
> >>For the P8 OCC, add the procedure to send a command to the OCC over I2C
> >>bus. This involves writing the OCC command registers with serial
> >>communication operations (SCOMs) interpreted by the I2C slave. For the
> >>P9 OCC, add a procedure to use the OCC in-kernel API to send a command
> >>to the OCC through the SBE engine.
> >>
> >>Signed-off-by: Edward A. James <eajames@us.ibm.com>
> >>---
> >>  drivers/hwmon/occ/common.h |  13 ++++
> >>  drivers/hwmon/occ/p8_i2c.c | 166
> >>++++++++++++++++++++++++++++++++++++++++++++-
> >>  drivers/hwmon/occ/p9_sbe.c |  66 +++++++++++++++++-
> >>  3 files changed, 243 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
> >>index dca642a..0c3f26f 100644
> >>--- a/drivers/hwmon/occ/common.h
> >>+++ b/drivers/hwmon/occ/common.h
> >>@@ -15,6 +15,19 @@
> >>    #define OCC_RESP_DATA_BYTES        4089
> >>  +#define OCC_TIMEOUT_MS            5000
> >
> >Five seconds ? Isn't that a bit excessive ?
> >
> >>+#define OCC_CMD_IN_PRG_MS        100
> >>+
> >>+/* OCC return codes */
> >>+#define RESP_RETURN_CMD_IN_PRG        0xFF
> >>+#define RESP_RETURN_SUCCESS        0
> >>+#define RESP_RETURN_CMD_INVAL        0x11
> >>+#define RESP_RETURN_CMD_LEN        0x12
> >>+#define RESP_RETURN_DATA_INVAL        0x13
> >>+#define RESP_RETURN_CHKSUM        0x14
> >>+#define RESP_RETURN_OCC_ERR        0x15
> >>+#define RESP_RETURN_STATE        0x16
> >>+
> >
> >Why are those return codes defined here ? They must be set somewhere
> >outside this driver, and I would expect them to be defined there.
> 
> They are defined in code that runs on the OCC itself, and perhaps in
> applications that talk to the OCC, but it's nowhere in the kernel. I'm not
> aware of any plans to either define or use these codes anywhere else in the
> kernel at the moment.
> 
Ok.

> >
> >Also see below - the missing context makes it all but impossible
> >th review this patch series.
> 
> Agreed, I have sent you links to the FSI client driver series that this
> driver uses. Thanks for the review, will include your suggestions in a v2
> soon. Couple of comments below.
> 
> Thanks,
> Eddie
> 
> >
> >>  /* Same response format for all OCC versions.
> >>   * Allocate the largest possible response.
> >>   */
> >>diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
> >>index 5075146..d6d70ce 100644
> >>--- a/drivers/hwmon/occ/p8_i2c.c
> >>+++ b/drivers/hwmon/occ/p8_i2c.c
> >>@@ -7,6 +7,7 @@
> >>   * (at your option) any later version.
> >>   */
> >>  +#include <asm/unaligned.h>
> >
> >Alphabetic order, though it is ok to list linux.. includes first followed
> >by
> >asm... includes followed by local includes.
> >
> >>  #include "common.h"
> >>  #include <linux/i2c.h>
> >>  #include <linux/init.h>
> >>@@ -19,9 +20,172 @@ struct p8_i2c_occ {
> >>    #define to_p8_i2c_occ(x)    container_of((x), struct p8_i2c_occ,
> >>occ)
> >>  +static int p8_i2c_occ_getscom(struct i2c_client *client, u32 address,
> >>u8 *data)
> >>+{
> >>+    ssize_t rc;
> >>+    __be64 buf_be;
> >
> >_be is redundant. Yes, you have buf as well, but that is really not
> >needed.
> >
> >>+    u64 buf;
> >>+    struct i2c_msg msgs[2];
> >>+
> >>+    /* p8 i2c slave requires shift */
> >>+    address <<= 1;
> >>+
> >>+    msgs[0].addr = client->addr;
> >>+    msgs[0].flags = client->flags & I2C_M_TEN;
> >>+    msgs[0].len = sizeof(u32);
> >>+    msgs[0].buf = (char *)&address;
> >
> >No endianness concerns here ?
> >
> >>+
> >>+
> >checkpatch --strict, please
> >
> >>+    msgs[1].addr = client->addr;
> >>+    msgs[1].flags = (client->flags & I2C_M_TEN) | I2C_M_RD;
> >>+    msgs[1].len = sizeof(u64);
> >>+    msgs[1].buf = (char *)&buf_be;
> >>+
> >>+    rc = i2c_transfer(client->adapter, msgs, 2);
> >>+    if (rc < 0)
> >>+        return rc;
> >>+
> >>+    buf = be64_to_cpu(buf_be);
> >>+    memcpy(data, &buf, sizeof(u64));
> >
> >    *(u64 *)data = be64_to_cpu(buf_be);
> >
> >>+
> >>+    return 0;
> >>+}
> >>+
> >>+static int p8_i2c_occ_putscom(struct i2c_client *client, u32 address,
> >>u8 *data)
> >>+{
> >>+    u32 buf[3];
> >>+    ssize_t rc;
> >>+
> >>+    /* p8 i2c slave requires shift */
> >>+    address <<= 1;
> >>+
> >>+    buf[0] = address;
> >>+    memcpy(&buf[1], &data[4], sizeof(u32));
> >>+    memcpy(&buf[2], data, sizeof(u32));
> >
> >No endianness concerns ? Presumably not, but that might warrant a comment
> >above, with the function declaration.
> >
> >>+
> >>+    rc = i2c_master_send(client, (const char *)buf, sizeof(buf));
> >>+    if (rc < 0)
> >>+        return rc;
> >>+    else if (rc != sizeof(buf))
> >>+        return -EIO;
> >>+
> >>+    return 0;
> >>+}
> >>+
> >>+static int p8_i2c_occ_putscom_u32(struct i2c_client *client, u32
> >>address,
> >>+                  u32 data0, u32 data1)
> >>+{
> >>+    u8 buf[8];
> >>+
> >>+    memcpy(buf, &data0, 4);
> >>+    memcpy(buf + 4, &data1, 4);
> >>+
> >>+    return p8_i2c_occ_putscom(client, address, buf);
> >>+}
> >>+
> >>+static int p8_i2c_occ_putscom_be(struct i2c_client *client, u32
> >>address,
> >>+                 u8 *data)
> >>+{
> >>+    __be32 data0, data1;
> >>+
> >>+    memcpy(&data0, data, 4);
> >>+    memcpy(&data1, data + 4, 4);
> >>+
> >>+    return p8_i2c_occ_putscom_u32(client, address, be32_to_cpu(data0),
> >>+                      be32_to_cpu(data1));
> >>+}
> >>+
> >>  static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
> >>  {
> >>-    return -EOPNOTSUPP;
> >>+    int i, rc;
> >>+    unsigned long start;
> >>+    u16 data_length;
> >>+    struct p8_i2c_occ *p8_i2c_occ = to_p8_i2c_occ(occ);
> >>+    struct i2c_client *client = p8_i2c_occ->client;
> >>+    struct occ_response *resp = &occ->resp;
> >>+
> >>+    start = jiffies;
> >>+
> >>+    /* set sram address for command */
> >>+    rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF6000, 0);
> >
> >Please declare those magics as defines to give readers an idea
> >what this is about.
> >
> >>+    if (rc)
> >>+        goto err;
> >>+
> >>+    /* write command (must already be BE), i2c expects cpu-endian */
> >>+    rc = p8_i2c_occ_putscom_be(client, 0x6B075, cmd);
> >>+    if (rc)
> >>+        goto err;
> >>+
> >>+    /* trigger OCC attention */
> >>+    rc = p8_i2c_occ_putscom_u32(client, 0x6B035, 0x20010000, 0);
> >>+    if (rc)
> >>+        goto err;
> >>+
> >>+retry:
> >>+    /* set sram address for response */
> >>+    rc = p8_i2c_occ_putscom_u32(client, 0x6B070, 0xFFFF7000, 0);
> >>+    if (rc)
> >>+        goto err;
> >>+
> >>+    /* read response */
> >>+    rc = p8_i2c_occ_getscom(client, 0x6B075, (u8 *)resp);
> >>+    if (rc)
> >>+        goto err;
> >>+
> >>+    /* check the OCC response */
> >>+    switch (resp->return_status) {
> >>+    case RESP_RETURN_CMD_IN_PRG:
> >>+        if (time_after(jiffies,
> >>+                   start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
> >>+            rc = -EALREADY;
> >>+        else {
> >>+            set_current_state(TASK_INTERRUPTIBLE);
> >>+ schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
> >>+
> >>+            goto retry;
> >
> >Please refactor as loop.
> >
> >>+        }
> >>+        break;
> >>+    case RESP_RETURN_SUCCESS:
> >>+        rc = 0;
> >>+        break;
> >>+    case RESP_RETURN_CMD_INVAL:
> >>+    case RESP_RETURN_CMD_LEN:
> >>+    case RESP_RETURN_DATA_INVAL:
> >>+    case RESP_RETURN_CHKSUM:
> >>+        rc = -EINVAL;
> >>+        break;
> >>+    case RESP_RETURN_OCC_ERR:
> >>+        rc = -EREMOTE;
> >
> >"Object is remote"
> 
> Closest error code i could find to say "the error is not in the driver, but
> on the OCC". I'll add a comment.
> 
This is not the meaning of this error code. It means that an object is remote,
not that the remote end had an error. You can use EIO or EREMOTEIO, but you
can not redefine existing error codes.

> >
> >>+        break;
> >>+    default:
> >>+        rc = -EFAULT;
> >
> >"Bad address" ?
> >

-EFAULT reflects a bad _memory_ address, while the actual error is that
there is an unknown return code. -EPROTO, maybe, or -EIO if you don't know
any better.

> >>+    }
> >>+
> >>+    if (rc < 0) {
> >>+        dev_warn(&client->dev, "occ bad response: %d\n",
> >>+             resp->return_status);
> >>+        return rc;
> >>+    }
> >>+
> >>+    data_length = get_unaligned_be16(&resp->data_length_be);
> >>+    if (data_length > OCC_RESP_DATA_BYTES) {
> >>+        dev_warn(&client->dev, "occ bad data length: %d\n",
> >>+             data_length);
> >>+        return -EDOM;
> >
> >"Math argument out of domain" ?
> >
> >
> >Your error codes seem to be kind of random.
> 
> Tricky to match up the OCC errors with linux errnos.
> 
Maybe, but that doesn't mean you can just randomly pick error codes.
The above might be -EPROTO, for example.

> >
> >>+    }
> >>+
> >>+    /* read remaining response */
> >>+    for (i = 8; i < data_length + 7; i += 8) {
> >>+        rc = p8_i2c_occ_getscom(client, 0x6B075, ((u8 *)resp) + i);
> >>+        if (rc)
> >>+            goto err;
> >>+    }
> >>+
> >>+    return data_length + 7;
> >>+
> >>+err:
> >>+    dev_err(&client->dev, "i2c scom op failed rc: %d\n", rc);
> >>+    return rc;
> >>  }
> >>    static int p8_i2c_occ_probe(struct i2c_client *client,
> >>diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
> >>index 0cef428..981c53f 100644
> >>--- a/drivers/hwmon/occ/p9_sbe.c
> >>+++ b/drivers/hwmon/occ/p9_sbe.c
> >>@@ -22,7 +22,71 @@ struct p9_sbe_occ {
> >>    static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd)
> >>  {
> >>-    return -EOPNOTSUPP;
> >>+    int rc;
> >>+    unsigned long start;
> >>+    struct occ_client *client;
> >>+    struct occ_response *resp = &occ->resp;
> >>+    struct p9_sbe_occ *p9_sbe_occ = to_p9_sbe_occ(occ);
> >>+
> >>+    start = jiffies;
> >>+
> >>+retry:
> >>+    client = occ_drv_open(p9_sbe_occ->sbe, 0);
> >
> >Where does this come from ? Ah, I see, there is an "include
> ><linux/occ.h>",
> >but no mention where it comes from.
> >
> >I'll stop reviewing the series here. I can not review it without complete
> >context.
> >
> >>+    if (!client)
> >>+        return -ENODEV;
> >>+
> >>+    /* skip first byte (sequence number), OCC driver handles it */
> >>+    rc = occ_drv_write(client, (const char *)&cmd[1], 7);
> >>+    if (rc < 0)
> >>+        goto err;
> >>+
> >>+    rc = occ_drv_read(client, (char *)resp, sizeof(*resp));
> >>+    if (rc < 0)
> >>+        goto err;
> >>+
> >>+    occ_drv_release(client);
> >
> >Might as well cann release() first to save the double call below.
> >
> >>+
> >>+    /* check the OCC response */
> >>+    switch (resp->return_status) {
> >>+    case RESP_RETURN_CMD_IN_PRG:
> >>+        if (time_after(jiffies,
> >>+                   start + msecs_to_jiffies(OCC_TIMEOUT_MS)))
> >>+            rc = -EALREADY;
> >
> >This is another odd return value. Normally one would expect something like
> >-ETIMEDOUT.
> 
> Could do, but EALREADY more closely matches the "command in progress" return
> code from the OCC.
> 

Yes, but it has a different meaning in Linux, and it is only the case
in the first place because you keep resending the request. Logically,
this is a timeout.

> >
> >>+        else {
> >>+            set_current_state(TASK_INTERRUPTIBLE);
> >>+ schedule_timeout(msecs_to_jiffies(OCC_CMD_IN_PRG_MS));
> >>+
> >
> >Does the called code generate an interrupt if the command is complete ?
> >
> >Makes me wonder why the write/read sequence isn't just synchronous.
> >Again, missing context.
> >
> >>+            goto retry;
> >
> >Please refactor as loop.
> >
> >>+        }
> >>+        break;
> >>+    case RESP_RETURN_SUCCESS:
> >>+        rc = 0;
> >>+        break;
> >>+    case RESP_RETURN_CMD_INVAL:
> >>+    case RESP_RETURN_CMD_LEN:
> >>+    case RESP_RETURN_DATA_INVAL:
> >>+    case RESP_RETURN_CHKSUM:
> >>+        rc = -EINVAL;
> >>+        break;
> >>+    case RESP_RETURN_OCC_ERR:
> >>+        rc = -EREMOTE;
> >>+        break;
> >>+    default:
> >>+        rc = -EFAULT;
> >>+    }
> >>+
> >>+    if (rc < 0) {
> >>+        dev_warn(occ->bus_dev, "occ bad response: %d\n",
> >>+             resp->return_status);
> >>+        return rc;
> >>+    }
> >>+
> >>+    return 0;
> >>+
> >>+err:
> >>+    occ_drv_release(client);
> >>+    dev_err(occ->bus_dev, "occ bus op failed rc: %d\n", rc);
> >
> >Is all this noise really needed ? I can understand it for debugging,
> >but for released code ?
> 
> Errors can come from a lot of different places in this driver, so I thought
> it helpful. We'd only get one dev_x print per failure, so doesn't seem too
> excessive to me.
> 

Unless the error is permanent or likely to be repeated if seen once,
in which case it fills up the log.

> >
> >>+    return rc;
> >>  }
> >>    static int p9_sbe_occ_probe(struct platform_device *pdev)
> >>
> >
> 

[toc] | [prev] | [next] | [standalone]

#1673112 — [PATCH 6/7] drivers/hwmon/occ: Add non-hwmon attributes

From: "Edward A. James" <eajames@us.ibm.com>

Create device attributes for additional OCC properties that do not
belong as hwmon sensors. These provide additional information as to the
state of the processor and system.

Signed-off-by: Edward A. James <eajames@us.ibm.com>
---
 Documentation/ABI/testing/sysfs-driver-occ-hwmon |  65 +++++++++++++
 drivers/hwmon/occ/common.c                       | 114 +++++++++++++++++++++++
 drivers/hwmon/occ/common.h                       |  14 +++
 drivers/hwmon/occ/p8_i2c.c                       |   8 ++
 drivers/hwmon/occ/p9_sbe.c                       |   8 ++
 5 files changed, 209 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-occ-hwmon b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
new file mode 100644
index 0000000..ddf6cd7
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
@@ -0,0 +1,65 @@
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_active
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates (with a "1" or a "0",
+		respectively) whether or not this OCC is in the "active" state.
+
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_dvfs_ot
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates (with a "1" or a "0",
+		respectively) whether or not this OCC has limited the processor
+		frequency due to over-temperature.
+
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_dvfs_power
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates (with a "1" or a "0",
+		respectively) whether or not this OCC has limited the processor
+		frequency due to power usage.
+
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_master
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates (with a "1" or a "0",
+		respectively) whether or not this OCC is the "master" OCC.
+
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_mem_throttle
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates (with a "1" or a "0",
+		respectively) whether or not the OCC has throttled memory due
+		to over-temperature.
+
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_quick_drop
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates (with a "1" or a "0",
+		respectively) whether or not this OCC has asserted the "quick
+		power drop" signal.
+
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_status
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates the current OCC state. The
+		value of the attribute will be one of the following states:
+		0: Reserved
+		1: Standby
+		2: Observation
+		3: Active
+		4: Safe
+		5: Characterization
diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index eb1f1a1..1645776 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -993,6 +993,102 @@ static int occ_setup_sensor_attrs(struct occ *occ)
 	return 0;
 }
 
+static ssize_t occ_show_status(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	int rc;
+	int val;
+	struct occ *occ = dev_get_drvdata(dev);
+	struct occ_poll_response_header *header;
+	struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
+
+	rc = occ_update_response(occ);
+	if (rc)
+		return rc;
+
+	header = (struct occ_poll_response_header *)occ->resp.data;
+
+	switch (sattr->index) {
+	case 0:
+		val = (header->status & OCC_STAT_MASTER) ? 1 : 0;
+		break;
+	case 1:
+		val = (header->status & OCC_STAT_ACTIVE) ? 1 : 0;
+		break;
+	case 2:
+		val = (header->ext_status & OCC_EXT_STAT_DVFS_OT) ? 1 : 0;
+		break;
+	case 3:
+		val = (header->ext_status & OCC_EXT_STAT_DVFS_POWER) ? 1 : 0;
+		break;
+	case 4:
+		val = (header->ext_status & OCC_EXT_STAT_MEM_THROTTLE) ? 1 : 0;
+		break;
+	case 5:
+		val = (header->ext_status & OCC_EXT_STAT_QUICK_DROP) ? 1 : 0;
+		break;
+	case 6:
+		val = header->occ_state;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return snprintf(buf, PAGE_SIZE - 1, "%d\n", val);
+}
+
+static int occ_create_status_attrs(struct occ *occ)
+{
+	int rc, i;
+	struct device *dev = occ->bus_dev;
+
+	occ->status_attrs = devm_kzalloc(dev, sizeof(*occ->status_attrs) *
+					 OCC_NUM_STATUS_ATTRS, GFP_KERNEL);
+	if (!occ->status_attrs)
+		return -ENOMEM;
+
+	occ->status_attrs[0] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_master, 0444,
+							    occ_show_status,
+							    NULL, 0);
+	occ->status_attrs[1] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_active, 0444,
+							    occ_show_status,
+							    NULL, 1);
+	occ->status_attrs[2] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_dvfs_ot, 0444,
+							    occ_show_status,
+							    NULL, 2);
+	occ->status_attrs[3] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_dvfs_power,
+							    0444,
+							    occ_show_status,
+							    NULL, 3);
+	occ->status_attrs[4] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_mem_throttle,
+							    0444,
+							    occ_show_status,
+							    NULL, 4);
+	occ->status_attrs[5] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_quick_drop,
+							    0444,
+							    occ_show_status,
+							    NULL, 5);
+	occ->status_attrs[6] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_status, 0444,
+							    occ_show_status,
+							    NULL, 6);
+
+	for (i = 0; i < OCC_NUM_STATUS_ATTRS; ++i) {
+		rc = device_create_file(dev, &occ->status_attrs[i].dev_attr);
+		if (rc)
+			dev_warn(dev, "error %d creating status attr %d\n", rc,
+				 i);
+	}
+
+	return 0;
+}
+
 /* only need to do this once at startup, as OCC won't change sensors on us */
 static void occ_parse_poll_response(struct occ *occ)
 {
@@ -1073,5 +1169,23 @@ int occ_setup(struct occ *occ, const char *name)
 		return rc;
 	}
 
+	rc = occ_create_status_attrs(occ);
+	if (rc) {
+		dev_err(occ->bus_dev, "failed to setup status attrs: %d\n",
+			rc);
+		return rc;
+	}
+
+	return 0;
+}
+
+int occ_shutdown(struct occ *occ)
+{
+	int i;
+
+	for (i = 0; i < OCC_NUM_STATUS_ATTRS; ++i)
+		device_remove_file(occ->bus_dev,
+				   &occ->status_attrs[i].dev_attr);
+
 	return 0;
 }
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index 4bcf3ca..dd23eac 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -13,6 +13,8 @@
 #include <linux/hwmon-sysfs.h>
 #include <linux/sysfs.h>
 
+#define OCC_NUM_STATUS_ATTRS		7
+
 #define OCC_RESP_DATA_BYTES		4089
 
 #define OCC_UPDATE_FREQUENCY		msecs_to_jiffies(1000)
@@ -29,6 +31,14 @@
 #define RESP_RETURN_OCC_ERR		0x15
 #define RESP_RETURN_STATE		0x16
 
+/* OCC status bits */
+#define OCC_STAT_MASTER			0x80
+#define OCC_STAT_ACTIVE			0x01
+#define OCC_EXT_STAT_DVFS_OT		0x80
+#define OCC_EXT_STAT_DVFS_POWER		0x40
+#define OCC_EXT_STAT_MEM_THROTTLE	0x20
+#define OCC_EXT_STAT_QUICK_DROP		0x10
+
 /* Same response format for all OCC versions.
  * Allocate the largest possible response.
  */
@@ -119,8 +129,12 @@ struct occ {
 	struct occ_attribute *attrs;
 	struct attribute_group group;
 	const struct attribute_group *groups[2];
+
+	/* non-hwmon attributes for more OCC properties */
+	struct sensor_device_attribute *status_attrs;
 };
 
 int occ_setup(struct occ *occ, const char *name);
+int occ_shutdown(struct occ *occ);
 
 #endif /* OCC_COMMON_H */
diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index d6d70ce..cab4448 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ b/drivers/hwmon/occ/p8_i2c.c
@@ -209,6 +209,13 @@ static int p8_i2c_occ_probe(struct i2c_client *client,
 	return occ_setup(occ, "p8_occ");
 }
 
+static int p8_i2c_occ_remove(struct i2c_client *client)
+{
+	struct occ *occ = dev_get_drvdata(&client->dev);
+
+	return occ_shutdown(occ);
+}
+
 static const struct of_device_id p8_i2c_occ_of_match[] = {
 	{ .compatible = "ibm,p8-occ-hwmon" },
 	{}
@@ -224,6 +231,7 @@ static int p8_i2c_occ_probe(struct i2c_client *client,
 		.of_match_table = p8_i2c_occ_of_match,
 	},
 	.probe = p8_i2c_occ_probe,
+	.remove = p8_i2c_occ_remove,
 	.address_list = p8_i2c_occ_addr,
 };
 
diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
index 981c53f..72ee9b4 100644
--- a/drivers/hwmon/occ/p9_sbe.c
+++ b/drivers/hwmon/occ/p9_sbe.c
@@ -109,6 +109,13 @@ static int p9_sbe_occ_probe(struct platform_device *pdev)
 	return occ_setup(occ, "p9_occ");
 }
 
+static int p9_sbe_occ_remove(struct platform_device *pdev)
+{
+	struct occ *occ = platform_get_drvdata(pdev);
+
+	return occ_shutdown(occ);
+}
+
 static const struct of_device_id p9_sbe_occ_of_match[] = {
 	{ .compatible = "ibm,p9-occ-hwmon" },
 	{ },
@@ -120,6 +127,7 @@ static int p9_sbe_occ_probe(struct platform_device *pdev)
 		.of_match_table	= p9_sbe_occ_of_match,
 	},
 	.probe	= p9_sbe_occ_probe,
+	.remove = p9_sbe_occ_remove,
 };
 
 module_platform_driver(p9_sbe_occ_driver);
-- 
1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1673114 — [PATCH 3/7] drivers/hwmon/occ: Parse OCC poll response

From: "Edward A. James" <eajames@us.ibm.com>

Add method to parse the response from the OCC poll command. This only
needs to be done during probe(), since the OCC shouldn't change the
number or format of sensors while it's running. The parsed response
allows quick access to sensor data, as well as information on the
number and version of sensors, which we need to instantiate hwmon
attributes.

Signed-off-by: Edward A. James <eajames@us.ibm.com>
---
 drivers/hwmon/occ/common.c | 49 +++++++++++++++++++++++++++++++++++++++++
 drivers/hwmon/occ/common.h | 54 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+)

diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 60c808c..d032ef0 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -28,6 +28,53 @@ static int occ_poll(struct occ *occ)
 	return occ->send_cmd(occ, cmd);
 }
 
+/* only need to do this once at startup, as OCC won't change sensors on us */
+static void occ_parse_poll_response(struct occ *occ)
+{
+	unsigned int i, offset = 0, size = 0;
+	struct occ_sensor *sensor;
+	struct occ_sensors *sensors = &occ->sensors;
+	struct occ_response *resp = &occ->resp;
+	struct occ_poll_response *poll =
+		(struct occ_poll_response *)&resp->data[0];
+	struct occ_poll_response_header *header = &poll->header;
+	struct occ_sensor_data_block *block = &poll->block;
+
+	for (i = 0; i < header->num_sensor_data_blocks; ++i) {
+		block = (struct occ_sensor_data_block *)((u8 *)block + offset);
+		offset = (block->header.num_sensors *
+			  block->header.sensor_length) + sizeof(block->header);
+		size += offset;
+
+		/* validate all the length/size fields */
+		if ((size + sizeof(*header)) >= OCC_RESP_DATA_BYTES) {
+			dev_warn(occ->bus_dev, "exceeded response buffer\n");
+			return;
+		}
+
+		/* match sensor block type */
+		if (strncmp(block->header.eye_catcher, "TEMP", 4) == 0)
+			sensor = &sensors->temp;
+		else if (strncmp(block->header.eye_catcher, "FREQ", 4) == 0)
+			sensor = &sensors->freq;
+		else if (strncmp(block->header.eye_catcher, "POWR", 4) == 0)
+			sensor = &sensors->power;
+		else if (strncmp(block->header.eye_catcher, "CAPS", 4) == 0)
+			sensor = &sensors->caps;
+		else if (strncmp(block->header.eye_catcher, "EXTN", 4) == 0)
+			sensor = &sensors->extended;
+		else {
+			dev_warn(occ->bus_dev, "sensor not supported %.4s\n",
+				 block->header.eye_catcher);
+			continue;
+		}
+
+		sensor->num_sensors = block->header.num_sensors;
+		sensor->version = block->header.sensor_format;
+		sensor->data = &block->data;
+	}
+}
+
 int occ_setup(struct occ *occ, const char *name)
 {
 	int rc;
@@ -39,5 +86,7 @@ int occ_setup(struct occ *occ, const char *name)
 		return rc;
 	}
 
+	occ_parse_poll_response(occ);
+
 	return 0;
 }
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index 0c3f26f..b5b7f02 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -40,10 +40,64 @@ struct occ_response {
 	u16 checksum_be;
 } __packed;
 
+struct occ_sensor_data_block_header {
+	u8 eye_catcher[4];
+	u8 reserved;
+	u8 sensor_format;
+	u8 sensor_length;
+	u8 num_sensors;
+} __packed;
+
+struct occ_sensor_data_block {
+	struct occ_sensor_data_block_header header;
+	u32 data;
+} __packed;
+
+struct occ_poll_response_header {
+	u8 status;
+	u8 ext_status;
+	u8 occs_present;
+	u8 config_data;
+	u8 occ_state;
+	u8 mode;
+	u8 ips_status;
+	u8 error_log_id;
+	u32 error_log_start_address_be;
+	u16 error_log_length_be;
+	u16 reserved;
+	u8 occ_code_level[16];
+	u8 eye_catcher[6];
+	u8 num_sensor_data_blocks;
+	u8 sensor_data_block_header_version;
+} __packed;
+
+struct occ_poll_response {
+	struct occ_poll_response_header header;
+	struct occ_sensor_data_block block;
+} __packed;
+
+struct occ_sensor {
+	u8 num_sensors;
+	u8 version;
+	void *data;	/* pointer to sensor data start within response */
+};
+
+/* OCC only provides one sensor data block of each type, but any number of
+ * sensors within that block.
+ */
+struct occ_sensors {
+	struct occ_sensor temp;
+	struct occ_sensor freq;
+	struct occ_sensor power;
+	struct occ_sensor caps;
+	struct occ_sensor extended;
+};
+
 struct occ {
 	struct device *bus_dev;
 
 	struct occ_response resp;
+	struct occ_sensors sensors;
 
 	u8 poll_cmd_data;		/* to perform OCC poll command */
 	int (*send_cmd)(struct occ *occ, u8 *cmd);
-- 
1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1673122 — [PATCH 7/7] drivers/hwmon/occ: Add error handling

From: "Edward A. James" <eajames@us.ibm.com>

Add logic to detect a number of error scenarios on the OCC. Export any
error through an additional non-hwmon device attribute.

Signed-off-by: Edward A. James <eajames@us.ibm.com>
---
 Documentation/ABI/testing/sysfs-driver-occ-hwmon | 12 ++++++
 drivers/hwmon/occ/common.c                       | 53 +++++++++++++++++++++++-
 drivers/hwmon/occ/common.h                       | 13 +++++-
 drivers/hwmon/occ/p8_i2c.c                       | 10 ++++-
 drivers/hwmon/occ/p9_sbe.c                       |  9 +++-
 5 files changed, 93 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-occ-hwmon b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
index ddf6cd7..9e2be27 100644
--- a/Documentation/ABI/testing/sysfs-driver-occ-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
@@ -24,6 +24,18 @@ Description:
 		respectively) whether or not this OCC has limited the processor
 		frequency due to power usage.
 
+What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_error
+Date:		June 2017
+KernelVersion:	4.14
+Contact:	eajames@us.ibm.com
+Description:
+		A read-only attribute that indicates any error condition
+		observed by the OCC or detected by the driver. Reading the
+		attribute will return an integer. A positive integer indicates
+		an error response from the OCC. A negative integer indicates a
+		possible bus error or other error condition detected by the
+		driver. A "0" indicates no error.
+
 What:		/sys/bus/platform/drivers/occ-hwmon/<dev>/occ_master
 Date:		June 2017
 KernelVersion:	4.14
diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 1645776..f124f87 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -11,6 +11,9 @@
 #include "common.h"
 #include <linux/hwmon.h>
 
+/* counter so we can verify against count from OCC response */
+static atomic_t occ_num_occs = ATOMIC_INIT(0);
+
 /* OCC sensor type and version definitions */
 
 struct temp_sensor_1 {
@@ -112,6 +115,9 @@ struct extended_sensor {
 
 static int occ_poll(struct occ *occ)
 {
+	int rc;
+	struct occ_poll_response_header *header =
+		(struct occ_poll_response_header *)occ->resp.data;
 	u16 checksum = occ->poll_cmd_data + 1;
 	u8 cmd[8];
 
@@ -126,7 +132,32 @@ static int occ_poll(struct occ *occ)
 	cmd[7] = 0;
 
 	/* mutex should already be locked if necessary */
-	return occ->send_cmd(occ, cmd);
+	rc = occ->send_cmd(occ, cmd);
+	if (rc < 0)
+		return rc;
+
+	/* check for "safe" state */
+	if (header->occ_state == OCC_STATE_SAFE) {
+		if (occ->last_safe) {
+			if (time_after(jiffies,
+				       occ->last_safe + OCC_SAFE_TIMEOUT))
+				occ->error = -EHOSTDOWN;
+		} else
+			occ->last_safe = jiffies;
+	} else
+		occ->last_safe = 0;
+
+	/* verify number of present OCCs */
+	if (header->status & OCC_STAT_MASTER) {
+		if (hweight8(header->occs_present) !=
+		    atomic_read(&occ_num_occs)) {
+			occ->error = -EXDEV;
+			occ->bad_present_count++;
+		} else
+			occ->bad_present_count = 0;
+	}
+
+	return rc;
 }
 
 static int occ_set_user_power_cap(struct occ *occ, u16 user_power_cap)
@@ -993,6 +1024,19 @@ static int occ_setup_sensor_attrs(struct occ *occ)
 	return 0;
 }
 
+static ssize_t occ_show_error(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	int error = 0;
+	struct occ *occ = dev_get_drvdata(dev);
+
+	if (occ->error_count > OCC_ERROR_COUNT_THRESHOLD || occ->last_safe ||
+	    occ->bad_present_count > OCC_ERROR_COUNT_THRESHOLD)
+		error = occ->error;
+
+	return snprintf(buf, PAGE_SIZE - 1, "%d\n", error);
+}
+
 static ssize_t occ_show_status(struct device *dev,
 			       struct device_attribute *attr, char *buf)
 {
@@ -1078,6 +1122,10 @@ static int occ_create_status_attrs(struct occ *occ)
 		(struct sensor_device_attribute)SENSOR_ATTR(occ_status, 0444,
 							    occ_show_status,
 							    NULL, 6);
+	occ->status_attrs[7] =
+		(struct sensor_device_attribute)SENSOR_ATTR(occ_error, 0444,
+							    occ_show_error,
+							    NULL, 0);
 
 	for (i = 0; i < OCC_NUM_STATUS_ATTRS; ++i) {
 		rc = device_create_file(dev, &occ->status_attrs[i].dev_attr);
@@ -1140,6 +1188,7 @@ int occ_setup(struct occ *occ, const char *name)
 {
 	int rc;
 
+	atomic_inc(&occ_num_occs);
 	mutex_init(&occ->lock);
 	occ->groups[0] = &occ->group;
 
@@ -1187,5 +1236,7 @@ int occ_shutdown(struct occ *occ)
 		device_remove_file(occ->bus_dev,
 				   &occ->status_attrs[i].dev_attr);
 
+	atomic_dec(&occ_num_occs);
+
 	return 0;
 }
diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
index dd23eac..cd04ee0 100644
--- a/drivers/hwmon/occ/common.h
+++ b/drivers/hwmon/occ/common.h
@@ -13,10 +13,13 @@
 #include <linux/hwmon-sysfs.h>
 #include <linux/sysfs.h>
 
-#define OCC_NUM_STATUS_ATTRS		7
+#define OCC_ERROR_COUNT_THRESHOLD	2
+
+#define OCC_NUM_STATUS_ATTRS		8
 
 #define OCC_RESP_DATA_BYTES		4089
 
+#define OCC_SAFE_TIMEOUT		msecs_to_jiffies(60000) /* 1 min */
 #define OCC_UPDATE_FREQUENCY		msecs_to_jiffies(1000)
 #define OCC_TIMEOUT_MS			5000
 #define OCC_CMD_IN_PRG_MS		100
@@ -39,6 +42,9 @@
 #define OCC_EXT_STAT_MEM_THROTTLE	0x20
 #define OCC_EXT_STAT_QUICK_DROP		0x10
 
+/* OCC state enumeration */
+#define OCC_STATE_SAFE			4
+
 /* Same response format for all OCC versions.
  * Allocate the largest possible response.
  */
@@ -132,6 +138,11 @@ struct occ {
 
 	/* non-hwmon attributes for more OCC properties */
 	struct sensor_device_attribute *status_attrs;
+
+	int error;
+	unsigned int error_count;		/* num errors observed */
+	unsigned int bad_present_count;		/* num polls w/bad num occs */
+	unsigned long last_safe;		/* time entered safe state */
 };
 
 int occ_setup(struct occ *occ, const char *name);
diff --git a/drivers/hwmon/occ/p8_i2c.c b/drivers/hwmon/occ/p8_i2c.c
index cab4448..a915b79 100644
--- a/drivers/hwmon/occ/p8_i2c.c
+++ b/drivers/hwmon/occ/p8_i2c.c
@@ -161,7 +161,10 @@ static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
 		rc = -EFAULT;
 	}
 
+	occ->error = resp->return_status;
+
 	if (rc < 0) {
+		occ->error_count++;
 		dev_warn(&client->dev, "occ bad response: %d\n",
 			 resp->return_status);
 		return rc;
@@ -169,9 +172,11 @@ static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
 
 	data_length = get_unaligned_be16(&resp->data_length_be);
 	if (data_length > OCC_RESP_DATA_BYTES) {
+		occ->error_count++;
+		occ->error = -EDOM;
 		dev_warn(&client->dev, "occ bad data length: %d\n",
 			 data_length);
-		return -EDOM;
+		return occ->error;
 	}
 
 	/* read remaining response */
@@ -181,9 +186,12 @@ static int p8_i2c_occ_send_cmd(struct occ *occ, u8 *cmd)
 			goto err;
 	}
 
+	occ->error_count = 0;
 	return data_length + 7;
 
 err:
+	occ->error_count++;
+	occ->error = rc;
 	dev_err(&client->dev, "i2c scom op failed rc: %d\n", rc);
 	return rc;
 }
diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
index 72ee9b4..5b5885e 100644
--- a/drivers/hwmon/occ/p9_sbe.c
+++ b/drivers/hwmon/occ/p9_sbe.c
@@ -9,6 +9,7 @@
 
 #include "common.h"
 #include <linux/init.h>
+#include <linux/hwmon.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/occ.h>
@@ -33,7 +34,7 @@ static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd)
 retry:
 	client = occ_drv_open(p9_sbe_occ->sbe, 0);
 	if (!client)
-		return -ENODEV;
+		return -ENODEV;		/* don't increment error counter */
 
 	/* skip first byte (sequence number), OCC driver handles it */
 	rc = occ_drv_write(client, (const char *)&cmd[1], 7);
@@ -75,15 +76,21 @@ static int p9_sbe_occ_send_cmd(struct occ *occ, u8 *cmd)
 		rc = -EFAULT;
 	}
 
+	occ->error = resp->return_status;
+
 	if (rc < 0) {
+		occ->error_count++;
 		dev_warn(occ->bus_dev, "occ bad response: %d\n",
 			 resp->return_status);
 		return rc;
 	}
 
+	occ->error_count = 0;
 	return 0;
 
 err:
+	occ->error_count++;
+	occ->error = rc;
 	occ_drv_release(client);
 	dev_err(occ->bus_dev, "occ bus op failed rc: %d\n", rc);
 	return rc;
-- 
1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1673248 — Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

On 06/22/2017 03:48 PM, Eddie James wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
> 
> This series adds a hwmon driver to support the OCC on POWER8 and POWER9
> processors. The OCC is an embedded processor that provides realtime power and
> thermal monitoring and management.
> 
> This driver has two different platform drivers as a "base" for the
> hwmon stuff, as the means of communicating with the OCC on P8 and P9 is
> completely different. For P8, the driver is an I2C client driver. For P9 the
> driver is an FSI-based OCC client driver, and uses the OCC driver in-kernel
> API.
> 
> There was a previous version of this driver that wasn't written with the
> differences in communication methods between the two versions in mind. This
> driver has been considerably simplified.
> 

I thought I did see this before.

It is customary to use "v2" in such situations, and add a change log.
You expect me to go into the two versions and compare them to figure
out what changed to evaluate if it makes sense. Do you really believe that
I have enough time to do that, and that I would be willing to spend that
time in the first place ?

Presumably you know what changed. Why not just tell me ?

Guenter

> Edward A. James (7):
>    drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver
>    drivers/hwmon/occ: Add command transport method for P8 and P9
>    drivers/hwmon/occ: Parse OCC poll response
>    drivers/hwmon/occ: Add sensor types and versions
>    drivers/hwmon/occ: Add sensor attributes and register hwmon device
>    drivers/hwmon/occ: Add non-hwmon attributes
>    drivers/hwmon/occ: Add error handling
> 
>   Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   77 ++
>   .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   18 +
>   .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
>   Documentation/hwmon/occ                            |   84 ++
>   drivers/hwmon/Kconfig                              |    2 +
>   drivers/hwmon/Makefile                             |    1 +
>   drivers/hwmon/occ/Kconfig                          |   28 +
>   drivers/hwmon/occ/Makefile                         |   11 +
>   drivers/hwmon/occ/common.c                         | 1242 ++++++++++++++++++++
>   drivers/hwmon/occ/common.h                         |  151 +++
>   drivers/hwmon/occ/p8_i2c.c                         |  250 ++++
>   drivers/hwmon/occ/p9_sbe.c                         |  144 +++
>   12 files changed, 2033 insertions(+)
>   create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
>   create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
>   create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
>   create mode 100644 Documentation/hwmon/occ
>   create mode 100644 drivers/hwmon/occ/Kconfig
>   create mode 100644 drivers/hwmon/occ/Makefile
>   create mode 100644 drivers/hwmon/occ/common.c
>   create mode 100644 drivers/hwmon/occ/common.h
>   create mode 100644 drivers/hwmon/occ/p8_i2c.c
>   create mode 100644 drivers/hwmon/occ/p9_sbe.c
> 

[toc] | [prev] | [next] | [standalone]

#1673557 — Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

On 06/22/2017 11:52 PM, Guenter Roeck wrote:
> On 06/22/2017 03:48 PM, Eddie James wrote:
>> From: "Edward A. James" <eajames@us.ibm.com>
>>
>> This series adds a hwmon driver to support the OCC on POWER8 and POWER9
>> processors. The OCC is an embedded processor that provides realtime 
>> power and
>> thermal monitoring and management.
>>
>> This driver has two different platform drivers as a "base" for the
>> hwmon stuff, as the means of communicating with the OCC on P8 and P9 is
>> completely different. For P8, the driver is an I2C client driver. For 
>> P9 the
>> driver is an FSI-based OCC client driver, and uses the OCC driver 
>> in-kernel
>> API.
>>
>> There was a previous version of this driver that wasn't written with the
>> differences in communication methods between the two versions in 
>> mind. This
>> driver has been considerably simplified.
>>
>
> I thought I did see this before.
>
> It is customary to use "v2" in such situations, and add a change log.
> You expect me to go into the two versions and compare them to figure
> out what changed to evaluate if it makes sense. Do you really believe 
> that
> I have enough time to do that, and that I would be willing to spend that
> time in the first place ?
>
> Presumably you know what changed. Why not just tell me ?

Hi,

This driver does not build upon the previous patch set at all, so I 
didn't mark it as a v2. It is completely rewritten from scratch. I sent 
a note saying that the previous patch set was abandoned. There may be 
some similarities with the previous one, simply because the drivers do 
the same thing, but I don't think there is any need to compare it with 
the old driver I mailed out.

Thanks for your time,
Eddie

>
> Guenter
>
>> Edward A. James (7):
>>    drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver
>>    drivers/hwmon/occ: Add command transport method for P8 and P9
>>    drivers/hwmon/occ: Parse OCC poll response
>>    drivers/hwmon/occ: Add sensor types and versions
>>    drivers/hwmon/occ: Add sensor attributes and register hwmon device
>>    drivers/hwmon/occ: Add non-hwmon attributes
>>    drivers/hwmon/occ: Add error handling
>>
>>   Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   77 ++
>>   .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   18 +
>>   .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
>>   Documentation/hwmon/occ                            |   84 ++
>>   drivers/hwmon/Kconfig                              |    2 +
>>   drivers/hwmon/Makefile                             |    1 +
>>   drivers/hwmon/occ/Kconfig                          |   28 +
>>   drivers/hwmon/occ/Makefile                         |   11 +
>>   drivers/hwmon/occ/common.c                         | 1242 
>> ++++++++++++++++++++
>>   drivers/hwmon/occ/common.h                         |  151 +++
>>   drivers/hwmon/occ/p8_i2c.c                         |  250 ++++
>>   drivers/hwmon/occ/p9_sbe.c                         |  144 +++
>>   12 files changed, 2033 insertions(+)
>>   create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
>>   create mode 100644 
>> Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
>>   create mode 100644 
>> Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
>>   create mode 100644 Documentation/hwmon/occ
>>   create mode 100644 drivers/hwmon/occ/Kconfig
>>   create mode 100644 drivers/hwmon/occ/Makefile
>>   create mode 100644 drivers/hwmon/occ/common.c
>>   create mode 100644 drivers/hwmon/occ/common.h
>>   create mode 100644 drivers/hwmon/occ/p8_i2c.c
>>   create mode 100644 drivers/hwmon/occ/p9_sbe.c
>>
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web