Re: [PATCH V3 2/6] hwmon: Add support for RPi voltage sensor

[Guenter Roeck]

On Fri, May 25, 2018 at 09:24:35PM +0200, Stefan Wahren wrote:
> Currently there is no easy way to detect undervoltage conditions on a
> remote Raspberry Pi. This hwmon driver retrieves the state of the
> undervoltage sensor via mailbox interface. The handling based on
> Noralf's modifications to the downstream firmware driver. In case of
> an undervoltage condition only an entry is written to the kernel log.
> 
> CC: "Noralf Trønnes" <nor...@tronnes.org>
> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>

Acked-by: Guenter Roeck <li...@roeck-us.net>

... assuming this will go through some arm tree.

> ---
>  Documentation/hwmon/raspberrypi-hwmon |  22 +
>  drivers/hwmon/Kconfig |  10 ++
>  drivers/hwmon/Makefile|   1 +
>  drivers/hwmon/raspberrypi-hwmon.c | 166 
> ++
>  4 files changed, 199 insertions(+)
>  create mode 100644 Documentation/hwmon/raspberrypi-hwmon
>  create mode 100644 drivers/hwmon/raspberrypi-hwmon.c
> 
> diff --git a/Documentation/hwmon/raspberrypi-hwmon 
> b/Documentation/hwmon/raspberrypi-hwmon
> new file mode 100644
> index 000..3c92e2c
> --- /dev/null
> +++ b/Documentation/hwmon/raspberrypi-hwmon
> @@ -0,0 +1,22 @@
> +Kernel driver raspberrypi-hwmon
> +===
> +
> +Supported boards:
> +  * Raspberry Pi A+ (via GPIO on SoC)
> +  * Raspberry Pi B+ (via GPIO on SoC)
> +  * Raspberry Pi 2 B (via GPIO on SoC)
> +  * Raspberry Pi 3 B (via GPIO on port expander)
> +  * Raspberry Pi 3 B+ (via PMIC)
> +
> +Author: Stefan Wahren <stefan.wah...@i2se.com>
> +
> +Description
> +---
> +
> +This driver periodically polls a mailbox property of the VC4 firmware to 
> detect
> +undervoltage conditions.
> +
> +Sysfs entries
> +-
> +
> +in0_lcrit_alarm  Undervoltage alarm
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index f10840a..fdaab82 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
> This driver can also be built as a module.  If so, the module
> will be called pwm-fan.
>  
> +config SENSORS_RASPBERRYPI_HWMON
> + tristate "Raspberry Pi voltage monitor"
> + depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> + help
> +   If you say yes here you get support for voltage sensor on the
> +   Raspberry Pi.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called raspberrypi-hwmon.
> +
>  config SENSORS_SHT15
>   tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>   depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index e7d52a3..a929770 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
>  obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o
>  obj-$(CONFIG_SENSORS_POWR1220)  += powr1220.o
>  obj-$(CONFIG_SENSORS_PWM_FAN)+= pwm-fan.o
> +obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)  += raspberrypi-hwmon.o
>  obj-$(CONFIG_SENSORS_S3C)+= s3c-hwmon.o
>  obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>  obj-$(CONFIG_SENSORS_SCH5627)+= sch5627.o
> diff --git a/drivers/hwmon/raspberrypi-hwmon.c 
> b/drivers/hwmon/raspberrypi-hwmon.c
> new file mode 100644
> index 000..fb4e4a6
> --- /dev/null
> +++ b/drivers/hwmon/raspberrypi-hwmon.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Raspberry Pi voltage sensor driver
> + *
> + * Based on firmware/raspberrypi.c by Noralf Trønnes
> + *
> + * Copyright (C) 2018 Stefan Wahren <stefan.wah...@i2se.com>
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define UNDERVOLTAGE_STICKY_BIT  BIT(16)
> +
> +struct rpi_hwmon_data {
> + struct device *hwmon_dev;
> + struct rpi_firmware *fw;
> + u32 last_throttled;
> + struct delayed_work get_values_poll_work;
> +};
> +
> +static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
> +{
> + u32 new_uv, old_uv, value;
> + int ret;
> +
> + /* Request firmware to clear sticky bits */
> + value = 0x;
> +
> + ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
> + , sizeof(value));
> + if (ret) {
> + dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
> +   

Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor

[Guenter Roeck]

On Wed, May 23, 2018 at 01:12:10PM +0100, Robin Murphy wrote:
> On 22/05/18 20:31, Stefan Wahren wrote:
> [...]
> >+static int rpi_hwmon_probe(struct platform_device *pdev)
> >+{
> >+struct device *dev = >dev;
> >+struct rpi_hwmon_data *data;
> >+int ret;
> >+
> >+data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >+if (!data)
> >+return -ENOMEM;
> >+
> >+data->fw = 
> >platform_get_drvdata(to_platform_device(dev->parent));
> >+if (!data->fw)
> >+return -EPROBE_DEFER;
> >+
> 
> I am a bit at loss here (and sorry I didn't bring this up before).
> How would this ever be possible, given that the driver is registered
> from the firmware driver ?
> >>>
> >>>Do you refer to the (wrong) return code, the assumption that the parent 
> >>>must be a platform driver or a possible race?
> >>>
> >>
> >>The return code is one thing. My question was how the driver would ever be 
> >>instantiated
> >>with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but 
> >>dev->parent != NULL),
> >>so I referred to the race. But, sure, a second question would be how that 
> >>would indicate
> >>that the parent is not instantiated yet (which by itself seems like an odd 
> >>question).
> >
> >This shouldn't happen and worth a log error. In patch #3 the registration is 
> >called after the complete private data of the firmware driver is 
> >initialized. Did i missed something?
> >
> >But i must confess that i didn't test all builtin/module combinations.
> 
> The point is that, by construction, a "raspberrypi-hwmon" device will only
> ever be created for this driver to bind to if the firmware device is both
> fully initialised and known to support the GET_THROTTLED call already. Thus
> trying to check those again from the hwmon driver is at best pointless, and
> at worst misleading. If somebody *does* manage to bind this driver to some
> random inappropriate device, you've still got no guarantee that dev->parent
> is valid or that dev_get_drvdata(dev->parent)) won't return something
> non-NULL that isn't a struct rpi_firmware pointer, at which point you're
> liable to pass the paranoid check yet still crash anyway.
> 
> IOW, you can't reasonably defend against incorrect operation, and under
> correct operation there's nothing to defend against, so either way it's
> pretty futile to waste effort trying.
> 

Well said.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor

[Guenter Roeck]

On 05/22/2018 06:51 AM, Stefan Wahren wrote:

Hi Guenter,


Guenter Roeck <li...@roeck-us.net> hat am 22. Mai 2018 um 15:41 geschrieben:


On 05/22/2018 04:21 AM, Stefan Wahren wrote:

Currently there is no easy way to detect undervoltage conditions on a
remote Raspberry Pi. This hwmon driver retrieves the state of the
undervoltage sensor via mailbox interface. The handling based on
Noralf's modifications to the downstream firmware driver. In case of
an undervoltage condition only an entry is written to the kernel log.

CC: "Noralf Trønnes" <nor...@tronnes.org>
Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
---
   Documentation/hwmon/raspberrypi-hwmon |  22 +
   drivers/hwmon/Kconfig |  10 ++
   drivers/hwmon/Makefile|   1 +
   drivers/hwmon/raspberrypi-hwmon.c | 168 
++
   4 files changed, 201 insertions(+)
   create mode 100644 Documentation/hwmon/raspberrypi-hwmon
   create mode 100644 drivers/hwmon/raspberrypi-hwmon.c

diff --git a/Documentation/hwmon/raspberrypi-hwmon 
b/Documentation/hwmon/raspberrypi-hwmon
new file mode 100644
index 000..3c92e2c
--- /dev/null
+++ b/Documentation/hwmon/raspberrypi-hwmon
@@ -0,0 +1,22 @@
+Kernel driver raspberrypi-hwmon
+===
+
+Supported boards:
+  * Raspberry Pi A+ (via GPIO on SoC)
+  * Raspberry Pi B+ (via GPIO on SoC)
+  * Raspberry Pi 2 B (via GPIO on SoC)
+  * Raspberry Pi 3 B (via GPIO on port expander)
+  * Raspberry Pi 3 B+ (via PMIC)
+
+Author: Stefan Wahren <stefan.wah...@i2se.com>
+
+Description
+---
+
+This driver periodically polls a mailbox property of the VC4 firmware to detect
+undervoltage conditions.
+
+Sysfs entries
+-
+
+in0_lcrit_alarmUndervoltage alarm
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 768aed5..9a5bdb0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
  This driver can also be built as a module.  If so, the module
  will be called pwm-fan.
   
+config SENSORS_RASPBERRYPI_HWMON

+   tristate "Raspberry Pi voltage monitor"
+   depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+   help
+ If you say yes here you get support for voltage sensor on the
+ Raspberry Pi.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-hwmon.
+
   config SENSORS_SHT15
tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a3..a929770 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427)   += pc87427.o
   obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o
   obj-$(CONFIG_SENSORS_POWR1220)  += powr1220.o
   obj-$(CONFIG_SENSORS_PWM_FAN)+= pwm-fan.o
+obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)+= raspberrypi-hwmon.o
   obj-$(CONFIG_SENSORS_S3C)+= s3c-hwmon.o
   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
   obj-$(CONFIG_SENSORS_SCH5627)+= sch5627.o
diff --git a/drivers/hwmon/raspberrypi-hwmon.c 
b/drivers/hwmon/raspberrypi-hwmon.c
new file mode 100644
index 000..6233e84
--- /dev/null
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Raspberry Pi voltage sensor driver
+ *
+ * Based on firmware/raspberrypi.c by Noralf Trønnes
+ *
+ * Copyright (C) 2018 Stefan Wahren <stefan.wah...@i2se.com>
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNDERVOLTAGE_STICKY_BITBIT(16)
+
+struct rpi_hwmon_data {
+   struct device *hwmon_dev;
+   struct rpi_firmware *fw;
+   u32 last_throttled;
+   struct delayed_work get_values_poll_work;
+};
+
+static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
+{
+   u32 new_uv, old_uv, value;
+   int ret;
+
+   /* Request firmware to clear sticky bits */
+   value = 0x;
+
+   ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
+   , sizeof(value));
+   if (ret) {
+   dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
+ret);
+   return;
+   }
+
+   new_uv = value & UNDERVOLTAGE_STICKY_BIT;
+   old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
+   data->last_throttled = value;
+
+   if (new_uv == old_uv)
+   return;
+
+   if (new_uv)
+   dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
+   else
+   dev_info(data->hwmon_dev, "Voltage normalised\n");
+
+   sysfs_notify(>hwmon_dev->kobj, NULL, "in0_lc

Re: [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor

[Guenter Roeck]

On 05/22/2018 04:21 AM, Stefan Wahren wrote:

Currently there is no easy way to detect undervoltage conditions on a
remote Raspberry Pi. This hwmon driver retrieves the state of the
undervoltage sensor via mailbox interface. The handling based on
Noralf's modifications to the downstream firmware driver. In case of
an undervoltage condition only an entry is written to the kernel log.

CC: "Noralf Trønnes" 
Signed-off-by: Stefan Wahren 
---
  Documentation/hwmon/raspberrypi-hwmon |  22 +
  drivers/hwmon/Kconfig |  10 ++
  drivers/hwmon/Makefile|   1 +
  drivers/hwmon/raspberrypi-hwmon.c | 168 ++
  4 files changed, 201 insertions(+)
  create mode 100644 Documentation/hwmon/raspberrypi-hwmon
  create mode 100644 drivers/hwmon/raspberrypi-hwmon.c

diff --git a/Documentation/hwmon/raspberrypi-hwmon 
b/Documentation/hwmon/raspberrypi-hwmon
new file mode 100644
index 000..3c92e2c
--- /dev/null
+++ b/Documentation/hwmon/raspberrypi-hwmon
@@ -0,0 +1,22 @@
+Kernel driver raspberrypi-hwmon
+===
+
+Supported boards:
+  * Raspberry Pi A+ (via GPIO on SoC)
+  * Raspberry Pi B+ (via GPIO on SoC)
+  * Raspberry Pi 2 B (via GPIO on SoC)
+  * Raspberry Pi 3 B (via GPIO on port expander)
+  * Raspberry Pi 3 B+ (via PMIC)
+
+Author: Stefan Wahren 
+
+Description
+---
+
+This driver periodically polls a mailbox property of the VC4 firmware to detect
+undervoltage conditions.
+
+Sysfs entries
+-
+
+in0_lcrit_alarmUndervoltage alarm
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 768aed5..9a5bdb0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1298,6 +1298,16 @@ config SENSORS_PWM_FAN
  This driver can also be built as a module.  If so, the module
  will be called pwm-fan.
  
+config SENSORS_RASPBERRYPI_HWMON

+   tristate "Raspberry Pi voltage monitor"
+   depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+   help
+ If you say yes here you get support for voltage sensor on the
+ Raspberry Pi.
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-hwmon.
+
  config SENSORS_SHT15
tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a3..a929770 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SENSORS_PC87427)   += pc87427.o
  obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
  obj-$(CONFIG_SENSORS_POWR1220)  += powr1220.o
  obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
+obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)+= raspberrypi-hwmon.o
  obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
  obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
  obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
diff --git a/drivers/hwmon/raspberrypi-hwmon.c 
b/drivers/hwmon/raspberrypi-hwmon.c
new file mode 100644
index 000..6233e84
--- /dev/null
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Raspberry Pi voltage sensor driver
+ *
+ * Based on firmware/raspberrypi.c by Noralf Trønnes
+ *
+ * Copyright (C) 2018 Stefan Wahren 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNDERVOLTAGE_STICKY_BITBIT(16)
+
+struct rpi_hwmon_data {
+   struct device *hwmon_dev;
+   struct rpi_firmware *fw;
+   u32 last_throttled;
+   struct delayed_work get_values_poll_work;
+};
+
+static void rpi_firmware_get_throttled(struct rpi_hwmon_data *data)
+{
+   u32 new_uv, old_uv, value;
+   int ret;
+
+   /* Request firmware to clear sticky bits */
+   value = 0x;
+
+   ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_THROTTLED,
+   , sizeof(value));
+   if (ret) {
+   dev_err_once(data->hwmon_dev, "Failed to get throttled (%d)\n",
+ret);
+   return;
+   }
+
+   new_uv = value & UNDERVOLTAGE_STICKY_BIT;
+   old_uv = data->last_throttled & UNDERVOLTAGE_STICKY_BIT;
+   data->last_throttled = value;
+
+   if (new_uv == old_uv)
+   return;
+
+   if (new_uv)
+   dev_crit(data->hwmon_dev, "Undervoltage detected!\n");
+   else
+   dev_info(data->hwmon_dev, "Voltage normalised\n");
+
+   sysfs_notify(>hwmon_dev->kobj, NULL, "in0_lcrit_alarm");
+}
+
+static void get_values_poll(struct work_struct *work)
+{
+   struct rpi_hwmon_data *data;
+
+   data = container_of(work, struct rpi_hwmon_data,
+   get_values_poll_work.work);
+
+   rpi_firmware_get_throttled(data);
+
+   /*
+* We 

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

[Guenter Roeck]

On Thu, Apr 12, 2018 at 10:09:51AM -0700, Jae Hyun Yoo wrote:
[ ... ]
> >>+static int find_core_index(struct peci_cputemp *priv, int channel)
> >>+{
> >>+    int core_channel = channel - DEFAULT_CHANNEL_NUMS;
> >>+    int idx, found = 0;
> >>+
> >>+    for (idx = 0; idx < priv->gen_info->core_max; idx++) {
> >>+    if (priv->core_mask & BIT(idx)) {
> >>+    if (core_channel == found)
> >>+    break;
> >>+
> >>+    found++;
> >>+    }
> >>+    }
> >>+
> >>+    return idx;
> >
> >What if nothing is found ?
> >
> 
> Core temperature group will be registered only when it detects at
> least one core checked by check_resolved_cores(), so
> find_core_index() can be called only when priv->core_mask has a
> non-zero value. The 'nothing is found' case will not happen.
> 
> >>>That doesn't guarantee a match. If what you are saying is correct
> >>>there should always be
> >>>a well defined match of channel -> idx, and the search should be
> >>>unnecessary.
> >>>
> >>
> >>There could be some disabled cores in the resolved core mask bit
> >>sequence also it should remove indexing gap in channel numbering so it
> >>is the reason why this search function is needed. Well defined match of
> >>channel -> idx would not be always satisfied.
> >>
> >Are you saying that each call to the function, with the same parameters,
> >can return a different result ?
> >
> 
> No, the result will be consistent. After reading the priv->core_mask once in
> check_resolved_cores(), the value will not be changed. I'm saying about this
> case, for example if core number 2 is unresolved in total 4 cores, then the
> idx order will be '0, 1, 3' but channel order will be '5, 6, 7' without
> making any indexing gap.
> 

And you yet you claim that this is not well defined ? Or are you concerned
about the amount of memory consumed by providing an array for the mapping ?

Note that an indexing gap is acceptable and, in many cases, preferred.

[ ... ]

> >>+
> >>+    dev_dbg(dev, "%s: sensor '%s'\n", dev_name(hwmon_dev),
> >>priv->name);
> >>+
> >>>
> >>>Why does this message display the device name twice ?
> >>>
> >>
> >>For an example, dev_name(hwmon_dev) shows 'hwmon5' and priv->name shows
> >>'peci-cputemp0'.
> >>
> >And dev_dbg() shows another device name. So you'll have something like
> >
> >peci-cputemp0: hwmon5: sensor 'peci-cputemp0'
> >
> 
> Practically it shows like
> 
> peci-cputemp 0-30:00: hwmon10: sensor 'peci_cputemp.cpu0'
> 
> where 0-30:00 is assigned by peci core.
> 

And what message would you see for cpu1 ?

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

[Guenter Roeck]

On 04/11/2018 07:51 PM, Jae Hyun Yoo wrote:

On 4/11/2018 5:34 PM, Guenter Roeck wrote:

On 04/11/2018 02:59 PM, Jae Hyun Yoo wrote:

Hi Guenter,

Thanks a lot for sharing your time. Please see my inline answers.

On 4/10/2018 3:28 PM, Guenter Roeck wrote:

On Tue, Apr 10, 2018 at 11:32:11AM -0700, Jae Hyun Yoo wrote:

This commit adds PECI cputemp and dimmtemp hwmon drivers.

Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.w...@linux.intel.com>
Reviewed-by: James Feist <james.fe...@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mau...@linux.intel.com>
Cc: Alan Cox <a...@linux.intel.com>
Cc: Andrew Jeffery <and...@aj.id.au>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Andy Shevchenko <andriy.shevche...@intel.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Fengguang Wu <fengguang...@intel.com>
Cc: Greg KH <gre...@linuxfoundation.org>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Jason M Biils <jason.m.bi...@linux.intel.com>
Cc: Jean Delvare <jdelv...@suse.com>
Cc: Joel Stanley <j...@jms.id.au>
Cc: Julia Cartwright <jul...@eso.teric.us>
Cc: Miguel Ojeda <miguel.ojeda.sando...@gmail.com>
Cc: Milton Miller II <milt...@us.ibm.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Randy Dunlap <rdun...@infradead.org>
Cc: Stef van Os <stef.van...@prodrive-technologies.com>
Cc: Sumeet R Pawnikar <sumeet.r.pawni...@intel.com>
---
  drivers/hwmon/Kconfig |  28 ++
  drivers/hwmon/Makefile    |   2 +
  drivers/hwmon/peci-cputemp.c  | 783 ++
  drivers/hwmon/peci-dimmtemp.c | 432 +++
  4 files changed, 1245 insertions(+)
  create mode 100644 drivers/hwmon/peci-cputemp.c
  create mode 100644 drivers/hwmon/peci-dimmtemp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index f249a4428458..c52f610f81d0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1259,6 +1259,34 @@ config SENSORS_NCT7904
    This driver can also be built as a module.  If so, the module
    will be called nct7904.
+config SENSORS_PECI_CPUTEMP
+    tristate "PECI CPU temperature monitoring support"
+    depends on OF
+    depends on PECI
+    help
+  If you say yes here you get support for the generic Intel PECI
+  cputemp driver which provides Digital Thermal Sensor (DTS) thermal
+  readings of the CPU package and CPU cores that are accessible using
+  the PECI Client Command Suite via the processor PECI client.
+  Check Documentation/hwmon/peci-cputemp for details.
+
+  This driver can also be built as a module.  If so, the module
+  will be called peci-cputemp.
+
+config SENSORS_PECI_DIMMTEMP
+    tristate "PECI DIMM temperature monitoring support"
+    depends on OF
+    depends on PECI
+    help
+  If you say yes here you get support for the generic Intel PECI hwmon
+  driver which provides Digital Thermal Sensor (DTS) thermal readings of
+  DIMM components that are accessible using the PECI Client Command
+  Suite via the processor PECI client.
+  Check Documentation/hwmon/peci-dimmtemp for details.
+
+  This driver can also be built as a module.  If so, the module
+  will be called peci-dimmtemp.
+
  config SENSORS_NSA320
  tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
  depends on GPIOLIB && OF
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a36e6c4..48d9598fcd3a 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -136,6 +136,8 @@ obj-$(CONFIG_SENSORS_NCT7802)    += nct7802.o
  obj-$(CONFIG_SENSORS_NCT7904)    += nct7904.o
  obj-$(CONFIG_SENSORS_NSA320)    += nsa320-hwmon.o
  obj-$(CONFIG_SENSORS_NTC_THERMISTOR)    += ntc_thermistor.o
+obj-$(CONFIG_SENSORS_PECI_CPUTEMP)    += peci-cputemp.o
+obj-$(CONFIG_SENSORS_PECI_DIMMTEMP)    += peci-dimmtemp.o
  obj-$(CONFIG_SENSORS_PC87360)    += pc87360.o
  obj-$(CONFIG_SENSORS_PC87427)    += pc87427.o
  obj-$(CONFIG_SENSORS_PCF8591)    += pcf8591.o
diff --git a/drivers/hwmon/peci-cputemp.c b/drivers/hwmon/peci-cputemp.c
new file mode 100644
index ..f0bc92687512
--- /dev/null
+++ b/drivers/hwmon/peci-cputemp.c
@@ -0,0 +1,783 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 Intel Corporation
+
+#include 
+#include 
+#include 


Is this include needed ?



No it isn't. Will drop the line.


+#include 
+#include 
+#include 
+#include 
+
+#define TEMP_TYPE_PECI    6  /* Sensor type 6: Intel PECI */
+
+#define CORE_MAX_ON_HSX   18 /* Max number of cores on Haswell */
+#define CORE_MAX_ON_BDX   24 /* Max number of cores on Broadwell */
+#define CORE_MAX_ON_SKX   28 /* Max number of cores on Skylake */
+
+#define DEFAULT_CHANNEL_NUMS  5
+#define CORETEMP_CHANNEL_NUMS CORE_

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

[Guenter Roeck]

On 04/11/2018 02:59 PM, Jae Hyun Yoo wrote:

Hi Guenter,

Thanks a lot for sharing your time. Please see my inline answers.

On 4/10/2018 3:28 PM, Guenter Roeck wrote:

On Tue, Apr 10, 2018 at 11:32:11AM -0700, Jae Hyun Yoo wrote:

This commit adds PECI cputemp and dimmtemp hwmon drivers.

Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.w...@linux.intel.com>
Reviewed-by: James Feist <james.fe...@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mau...@linux.intel.com>
Cc: Alan Cox <a...@linux.intel.com>
Cc: Andrew Jeffery <and...@aj.id.au>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Andy Shevchenko <andriy.shevche...@intel.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Fengguang Wu <fengguang...@intel.com>
Cc: Greg KH <gre...@linuxfoundation.org>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Jason M Biils <jason.m.bi...@linux.intel.com>
Cc: Jean Delvare <jdelv...@suse.com>
Cc: Joel Stanley <j...@jms.id.au>
Cc: Julia Cartwright <jul...@eso.teric.us>
Cc: Miguel Ojeda <miguel.ojeda.sando...@gmail.com>
Cc: Milton Miller II <milt...@us.ibm.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Randy Dunlap <rdun...@infradead.org>
Cc: Stef van Os <stef.van...@prodrive-technologies.com>
Cc: Sumeet R Pawnikar <sumeet.r.pawni...@intel.com>
---
  drivers/hwmon/Kconfig |  28 ++
  drivers/hwmon/Makefile    |   2 +
  drivers/hwmon/peci-cputemp.c  | 783 ++
  drivers/hwmon/peci-dimmtemp.c | 432 +++
  4 files changed, 1245 insertions(+)
  create mode 100644 drivers/hwmon/peci-cputemp.c
  create mode 100644 drivers/hwmon/peci-dimmtemp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index f249a4428458..c52f610f81d0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1259,6 +1259,34 @@ config SENSORS_NCT7904
    This driver can also be built as a module.  If so, the module
    will be called nct7904.
+config SENSORS_PECI_CPUTEMP
+    tristate "PECI CPU temperature monitoring support"
+    depends on OF
+    depends on PECI
+    help
+  If you say yes here you get support for the generic Intel PECI
+  cputemp driver which provides Digital Thermal Sensor (DTS) thermal
+  readings of the CPU package and CPU cores that are accessible using
+  the PECI Client Command Suite via the processor PECI client.
+  Check Documentation/hwmon/peci-cputemp for details.
+
+  This driver can also be built as a module.  If so, the module
+  will be called peci-cputemp.
+
+config SENSORS_PECI_DIMMTEMP
+    tristate "PECI DIMM temperature monitoring support"
+    depends on OF
+    depends on PECI
+    help
+  If you say yes here you get support for the generic Intel PECI hwmon
+  driver which provides Digital Thermal Sensor (DTS) thermal readings of
+  DIMM components that are accessible using the PECI Client Command
+  Suite via the processor PECI client.
+  Check Documentation/hwmon/peci-dimmtemp for details.
+
+  This driver can also be built as a module.  If so, the module
+  will be called peci-dimmtemp.
+
  config SENSORS_NSA320
  tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
  depends on GPIOLIB && OF
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e7d52a36e6c4..48d9598fcd3a 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -136,6 +136,8 @@ obj-$(CONFIG_SENSORS_NCT7802)    += nct7802.o
  obj-$(CONFIG_SENSORS_NCT7904)    += nct7904.o
  obj-$(CONFIG_SENSORS_NSA320)    += nsa320-hwmon.o
  obj-$(CONFIG_SENSORS_NTC_THERMISTOR)    += ntc_thermistor.o
+obj-$(CONFIG_SENSORS_PECI_CPUTEMP)    += peci-cputemp.o
+obj-$(CONFIG_SENSORS_PECI_DIMMTEMP)    += peci-dimmtemp.o
  obj-$(CONFIG_SENSORS_PC87360)    += pc87360.o
  obj-$(CONFIG_SENSORS_PC87427)    += pc87427.o
  obj-$(CONFIG_SENSORS_PCF8591)    += pcf8591.o
diff --git a/drivers/hwmon/peci-cputemp.c b/drivers/hwmon/peci-cputemp.c
new file mode 100644
index ..f0bc92687512
--- /dev/null
+++ b/drivers/hwmon/peci-cputemp.c
@@ -0,0 +1,783 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 Intel Corporation
+
+#include 
+#include 
+#include 


Is this include needed ?



No it isn't. Will drop the line.


+#include 
+#include 
+#include 
+#include 
+
+#define TEMP_TYPE_PECI    6  /* Sensor type 6: Intel PECI */
+
+#define CORE_MAX_ON_HSX   18 /* Max number of cores on Haswell */
+#define CORE_MAX_ON_BDX   24 /* Max number of cores on Broadwell */
+#define CORE_MAX_ON_SKX   28 /* Max number of cores on Skylake */
+
+#define DEFAULT_CHANNEL_NUMS  5
+#define CORETEMP_CHANNEL_NUMS CORE_MAX_ON_SKX
+#define CPUTEMP_CHANNEL_NUMS  (DEFAULT_CHANNEL_NUMS + CORETEMP_CHANNEL_NUMS)
+
+#defin

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

[Guenter Roeck]

On Tue, Apr 10, 2018 at 11:32:11AM -0700, Jae Hyun Yoo wrote:
> This commit adds PECI cputemp and dimmtemp hwmon drivers.
> 
> Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com>
> Reviewed-by: Haiyue Wang <haiyue.w...@linux.intel.com>
> Reviewed-by: James Feist <james.fe...@linux.intel.com>
> Reviewed-by: Vernon Mauery <vernon.mau...@linux.intel.com>
> Cc: Alan Cox <a...@linux.intel.com>
> Cc: Andrew Jeffery <and...@aj.id.au>
> Cc: Andrew Lunn <and...@lunn.ch>
> Cc: Andy Shevchenko <andriy.shevche...@intel.com>
> Cc: Arnd Bergmann <a...@arndb.de>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: Fengguang Wu <fengguang...@intel.com>
> Cc: Greg KH <gre...@linuxfoundation.org>
> Cc: Guenter Roeck <li...@roeck-us.net>
> Cc: Jason M Biils <jason.m.bi...@linux.intel.com>
> Cc: Jean Delvare <jdelv...@suse.com>
> Cc: Joel Stanley <j...@jms.id.au>
> Cc: Julia Cartwright <jul...@eso.teric.us>
> Cc: Miguel Ojeda <miguel.ojeda.sando...@gmail.com>
> Cc: Milton Miller II <milt...@us.ibm.com>
> Cc: Pavel Machek <pa...@ucw.cz>
> Cc: Randy Dunlap <rdun...@infradead.org>
> Cc: Stef van Os <stef.van...@prodrive-technologies.com>
> Cc: Sumeet R Pawnikar <sumeet.r.pawni...@intel.com>
> ---
>  drivers/hwmon/Kconfig |  28 ++
>  drivers/hwmon/Makefile|   2 +
>  drivers/hwmon/peci-cputemp.c  | 783 
> ++
>  drivers/hwmon/peci-dimmtemp.c | 432 +++
>  4 files changed, 1245 insertions(+)
>  create mode 100644 drivers/hwmon/peci-cputemp.c
>  create mode 100644 drivers/hwmon/peci-dimmtemp.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index f249a4428458..c52f610f81d0 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1259,6 +1259,34 @@ config SENSORS_NCT7904
> This driver can also be built as a module.  If so, the module
> will be called nct7904.
>  
> +config SENSORS_PECI_CPUTEMP
> + tristate "PECI CPU temperature monitoring support"
> + depends on OF
> + depends on PECI
> + help
> +   If you say yes here you get support for the generic Intel PECI
> +   cputemp driver which provides Digital Thermal Sensor (DTS) thermal
> +   readings of the CPU package and CPU cores that are accessible using
> +   the PECI Client Command Suite via the processor PECI client.
> +   Check Documentation/hwmon/peci-cputemp for details.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called peci-cputemp.
> +
> +config SENSORS_PECI_DIMMTEMP
> + tristate "PECI DIMM temperature monitoring support"
> + depends on OF
> + depends on PECI
> + help
> +   If you say yes here you get support for the generic Intel PECI hwmon
> +   driver which provides Digital Thermal Sensor (DTS) thermal readings of
> +   DIMM components that are accessible using the PECI Client Command
> +   Suite via the processor PECI client.
> +   Check Documentation/hwmon/peci-dimmtemp for details.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called peci-dimmtemp.
> +
>  config SENSORS_NSA320
>   tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
>   depends on GPIOLIB && OF
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index e7d52a36e6c4..48d9598fcd3a 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -136,6 +136,8 @@ obj-$(CONFIG_SENSORS_NCT7802) += nct7802.o
>  obj-$(CONFIG_SENSORS_NCT7904)+= nct7904.o
>  obj-$(CONFIG_SENSORS_NSA320) += nsa320-hwmon.o
>  obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
> +obj-$(CONFIG_SENSORS_PECI_CPUTEMP)   += peci-cputemp.o
> +obj-$(CONFIG_SENSORS_PECI_DIMMTEMP)  += peci-dimmtemp.o
>  obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o
>  obj-$(CONFIG_SENSORS_PC87427)+= pc87427.o
>  obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o
> diff --git a/drivers/hwmon/peci-cputemp.c b/drivers/hwmon/peci-cputemp.c
> new file mode 100644
> index ..f0bc92687512
> --- /dev/null
> +++ b/drivers/hwmon/peci-cputemp.c
> @@ -0,0 +1,783 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 Intel Corporation
> +
> +#include 
> +#include 
> +#include 

Is this include needed ?

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TEMP_TYPE_PECI6  /* Sensor type 6: Intel PECI */
> +
> +#define CORE_MAX_ON_HSX   

Re: [PATCH V2 3/9] dt-bindings: Tegra186 tachometer device tree bindings

[Guenter Roeck]

On 04/10/2018 06:30 AM, Rob Herring wrote:

On Mon, Apr 9, 2018 at 9:37 AM, Mikko Perttunen  wrote:



On 04/09/2018 04:21 PM, Rob Herring wrote:


On Mon, Apr 9, 2018 at 12:38 AM, Mikko Perttunen  wrote:


Rob,



Please don't top post to lists.


this binding is for a specific IP block (for measuring/aggregating input
pulses) on the Tegra186 SoC, so I don't think it fits into any generic
binding.



What is it hooked up to to measure? You only mention "fan" five times
in the doc.



In practice, fans.



You have #pwm-cells too, so this block has PWM output as well? If not,
then where's the PWM for the fan control because there is no point in
having fan tach without some control mechanism.



It doesn't provide a PWM output. The (Linux) PWM framework provides
functionality in both directions - control and capture. But if the device
tree #pwm-cells/pwms properties are only for control, we may need to
introduce a new #capture-pwm-cells/capture-pwms or similar.


Yes, perhaps. But there is no point in having
#capture-pwm-cells/capture-pwms if you aren't describing the
connection between the fan and the fan controller.


The idea is that the generic fan node can then specify two pwms, one for
control and one for capture, to enable e.g. closed-loop control (I'm not
personally familiar with the usecase for this but I could imagine something
like that). The control PWM can be something completely different, maybe not
a PWM in the first place (e.g. some fixed voltage).


Yes. As you can have different types of fans (3-wire, 4-wire, etc.)
they would have different compatibles and differing properties
associated with them.


There's only so many ways to control fans and types of fans, so yes,
the interface of control and feedback lines between a fan and its
controller should absolutely be generic.



I'm not quite getting what you mean by this. Clearly we need a custom
compatibility string for the tachometer as it's a different hardware block
with different programming than others.


Yes, of course. It's the interface between fan controllers and fans
that I'm concerned about.


Or are you complaining about the
nvidia,pulse-per-rev/capture-window-len properties?


Well, those sound like properties of a fan (at least the first one),
so they belong in a fan node.

The aspeed fan controller is probably the closest thing we have to a
fan binding. Look at that if you haven't already.



FWIW, this is a fan speed (tachometer) counter which is modeled as pwm input.
This, in my opinion, and as stated before, is conceptually wrong. The pwm
subsystem should not (need to) know anything about fans, much less about
specifics such as the number of pulses per revolution.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/9] hwmon: pwm-fan: add sysfs node to read rpm of fan

[Guenter Roeck]

On 03/20/2018 09:40 PM, Rajkumar Rampelli wrote:

Add fan device attribute fan1_input in pwm-fan driver
to read speed of fan in rotations per minute.

Signed-off-by: Rajkumar Rampelli 
---

V2: Removed generic-pwm-tachometer driver and using pwm-fan driver as per 
suggestions
 to read fan speed.
 Added fan device attribute to report speed of fan in rpms through hwmon 
sysfs.

  drivers/hwmon/pwm-fan.c | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 70cc0d1..8dda209 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -98,11 +98,34 @@ static ssize_t show_pwm(struct device *dev,
return sprintf(buf, "%u\n", ctx->pwm_value);
  }
  
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,

+   char *buf)
+{
+   struct pwm_fan_ctx *ptt = dev_get_drvdata(dev);
+   struct pwm_device *pwm = ptt->pwm;
+   struct pwm_capture result;
+   unsigned int rpm = 0;
+   int ret;
+
+   ret = pwm_capture(pwm, , 0);
+   if (ret < 0) {
+   pr_err("Failed to capture PWM: %d\n", ret);
+   return ret;
+   }
+
+   if (result.period)
+   rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+   result.period);
+
+   return sprintf(buf, "%u\n", rpm);
+}
  
  static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO | S_IWUSR, show_pwm, set_pwm, 0);

+static SENSOR_DEVICE_ATTR(fan1_input, 0444, show_rpm, NULL, 0);
  
  static struct attribute *pwm_fan_attrs[] = {

_dev_attr_pwm1.dev_attr.attr,
+   _dev_attr_fan1_input.dev_attr.attr,


This doesn't make sense. The same pwm can not both control the fan speed
and report it.

Guenter


NULL,
  };
  



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 31/47] watchdog: remove bfin_wdt driver

[Guenter Roeck]

On Wed, Mar 14, 2018 at 04:35:44PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this driver has
> become obsolete.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Acked-by: Guenter Roeck <li...@roeck-us.net>

> ---
>  Documentation/watchdog/watchdog-parameters.txt |   5 -
>  drivers/watchdog/Kconfig   |  17 -
>  drivers/watchdog/Makefile  |   7 -
>  drivers/watchdog/bfin_wdt.c| 476 
> -
>  4 files changed, 505 deletions(-)
>  delete mode 100644 drivers/watchdog/bfin_wdt.c
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index beea975980f6..6d6200ea27b8 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -55,11 +55,6 @@ wdt_time: Watchdog time in seconds. (default=30)
>  nowayout: Watchdog cannot be stopped once started
>   (default=kernel config parameter)
>  -
> -bfin_wdt:
> -timeout: Watchdog timeout in seconds. (1<=timeout<=((2^32)/SCLK), default=20)
> -nowayout: Watchdog cannot be stopped once started
> - (default=kernel config parameter)
> --
>  coh901327_wdt:
>  margin: Watchdog margin in seconds (default 60s)
>  -
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 098e5ed4ee3d..f89f8869ca2a 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -815,23 +815,6 @@ config SPRD_WATCHDOG
> Say Y here to include watchdog timer supported
> by Spreadtrum system.
>  
> -# BLACKFIN Architecture
> -
> -config BFIN_WDT
> - tristate "Blackfin On-Chip Watchdog Timer"
> - depends on BLACKFIN
> - ---help---
> -   If you say yes here you will get support for the Blackfin On-Chip
> -   Watchdog Timer. If you have one of these processors and wish to
> -   have watchdog support enabled, say Y, otherwise say N.
> -
> -   To compile this driver as a module, choose M here: the
> -   module will be called bfin_wdt.
> -
> -# CRIS Architecture
> -
> -# FRV Architecture
> -
>  # X86 (i386 + ia64 + x86_64) Architecture
>  
>  config ACQUIRE_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0474d38aa854..e209824541b8 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -91,13 +91,6 @@ obj-$(CONFIG_UNIPHIER_WATCHDOG) += uniphier_wdt.o
>  obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
>  obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
>  
> -# BLACKFIN Architecture
> -obj-$(CONFIG_BFIN_WDT) += bfin_wdt.o
> -
> -# CRIS Architecture
> -
> -# FRV Architecture
> -
>  # X86 (i386 + ia64 + x86_64) Architecture
>  obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
>  obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o
> diff --git a/drivers/watchdog/bfin_wdt.c b/drivers/watchdog/bfin_wdt.c
> deleted file mode 100644
> index aa4d2e8a8ef9..
> -- 
> 2.9.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 03/07/2018 11:57 PM, Mikko Perttunen wrote:



On 07.03.2018 16:20, Guenter Roeck wrote:

On 03/07/2018 01:47 AM, Rajkumar Rampelli wrote:



On Wednesday 28 February 2018 07:59 PM, Guenter Roeck wrote:

On 02/27/2018 11:03 PM, Mikko Perttunen wrote:

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the
speed of
a fan and exposes it in roatations per minute (RPM) to the user
space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli <rr...@nvidia.com>
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112
+
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan.
It uses the
+generic PWM interface and can be used on SoCs as along as the
SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli <rr...@nvidia.com>
+
+Description
+---
+
+The driver implements a simple interface for monitoring the
Fan speed using
+PWM module and Tachometer controller. It requests period value
through PWM
+capture interface to Tachometer and measures the Rotations per
minute using
+received period value. It exposes the Fan speed in RPM to the
user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    +=
wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights
reserved.
+ *
+ * This program is free software; you can redistribute it
and/or modify it
+ * under the terms and conditions of the GNU General Public
License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct
device_attribute *attr,
+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 03/07/2018 10:06 PM, Laxman Dewangan wrote:



On Wednesday 07 March 2018 07:50 PM, Guenter Roeck wrote:

On 03/07/2018 01:47 AM, Rajkumar Rampelli wrote:




While I am not opposed to ABI changes, the merits of those would need to be
discussed on the mailing list. But replacing "fan1_input" with "rpm" is
not an acceptable ABI change, even if it may measure something that turns
but isn't a fan.

If this _is_ in fact supposed to be used for something else but fans, we
would have to discuss what that might be, and if hwmon is the appropriate
subsystem to measure and report it. This does to some degree lead back to
my concern of having the "fan" part of this patch series in the pwm core.
I am still not sure if that makes sense.

Thanks,
Guenter

I am planning to add tachometer support in pwm-fan.c driver (drivers/hwmon/) 
instead of adding new generic-pwm-tachometer.c driver. Measuring RPM value will 
be done in pwm-fan driver itself using pwm capture feature and will add new 
sysfs attributes under this driver to report rpm value of fan.


There is an existing attribute to report the RPM of fans. It is called 
fan[1..n]_input.

"replacing "fan1_input" with "rpm" is not an acceptable ABI change"

Preemptive NACK.


The RPM is measured speed via PWM signal capture  which is output from fan.
So should we have the fan[1..n]_output_rpm?



No. I hear you clearly that you for some reason dislike fan[1..n]_input.
While ABIs are not always to our liking, that doesn't mean that we get
to change them at our whim. If that is not acceptable for you, I can't
help you. And you can't change inX_input to inX_voltage either, sorry.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 03/07/2018 01:47 AM, Rajkumar Rampelli wrote:



On Wednesday 28 February 2018 07:59 PM, Guenter Roeck wrote:

On 02/27/2018 11:03 PM, Mikko Perttunen wrote:

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli <rr...@nvidia.com>
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 +
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli <rr...@nvidia.com>
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, s

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 02/27/2018 11:03 PM, Mikko Perttunen wrote:

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli <rr...@nvidia.com>
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 +
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli <rr...@nvidia.com>
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+    _dev_attr_rpm.dev_attr.attr,
+    NULL

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli <rr...@nvidia.com>
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 +
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli <rr...@nvidia.com>
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+    _dev_attr_rpm.dev_attr.attr,
+    NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single standard hwmon sysfs attribute, having a hwmon driver is pointless

Re: [v2, 7/7] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Guenter Roeck]

On Fri, Jan 12, 2018 at 06:05:47PM -0700, Karthikeyan Ramasubramanian wrote:
> This driver supports GENI based UART Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including UART. This driver support console
> operations using FIFO mode of transfer.
> 
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> ---
>  drivers/tty/serial/Kconfig|   10 +
>  drivers/tty/serial/Makefile   |1 +
>  drivers/tty/serial/qcom_geni_serial.c | 1414 
> +
>  3 files changed, 1425 insertions(+)
>  create mode 100644 drivers/tty/serial/qcom_geni_serial.c
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index b788fee..1be30e5 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1098,6 +1098,16 @@ config SERIAL_MSM_CONSOLE
>   select SERIAL_CORE_CONSOLE
>   select SERIAL_EARLYCON
>  
> +config SERIAL_QCOM_GENI
> + tristate "QCOM on-chip GENI based serial port support"
> + depends on ARCH_QCOM
> + select SERIAL_CORE
> + select SERIAL_CORE_CONSOLE

Serial console drivers have to be bool, not tristate.
Building a console driver as module doesn't make sense
(it is needed before modules are loaded). It also results
in a build failure due to a symbol which is not exported.

> + select SERIAL_EARLYCON
> + help
> +   Serial driver for Qualcomm Technologies Inc's GENI based QUP
> +   hardware.
> +
>  config SERIAL_VT8500
>   bool "VIA VT8500 on-chip serial port support"
>   depends on ARCH_VT8500
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index 842d185..64a8d82 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_serial.o
>  obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
>  obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
>  obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
> +obj-$(CONFIG_SERIAL_QCOM_GENI) += qcom_geni_serial.o
>  obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
>  obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
>  obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
> diff --git a/drivers/tty/serial/qcom_geni_serial.c 
> b/drivers/tty/serial/qcom_geni_serial.c
> new file mode 100644
> index 000..0dbd329
> --- /dev/null
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -0,0 +1,1414 @@
> +/*
> + * Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* UART specific GENI registers */
> +#define SE_UART_TX_TRANS_CFG (0x25C)
> +#define SE_UART_TX_WORD_LEN  (0x268)
> +#define SE_UART_TX_STOP_BIT_LEN  (0x26C)
> +#define SE_UART_TX_TRANS_LEN (0x270)
> +#define SE_UART_RX_TRANS_CFG (0x280)
> +#define SE_UART_RX_WORD_LEN  (0x28C)
> +#define SE_UART_RX_STALE_CNT (0x294)
> +#define SE_UART_TX_PARITY_CFG(0x2A4)
> +#define SE_UART_RX_PARITY_CFG(0x2A8)
> +
> +/* SE_UART_TRANS_CFG */
> +#define UART_TX_PAR_EN   (BIT(0))
> +#define UART_CTS_MASK(BIT(1))
> +
> +/* SE_UART_TX_WORD_LEN */
> +#define TX_WORD_LEN_MSK  (GENMASK(9, 0))
> +
> +/* SE_UART_TX_STOP_BIT_LEN */
> +#define TX_STOP_BIT_LEN_MSK  (GENMASK(23, 0))
> +#define TX_STOP_BIT_LEN_1(0)
> +#define TX_STOP_BIT_LEN_1_5  (1)
> +#define TX_STOP_BIT_LEN_2(2)
> +
> +/* SE_UART_TX_TRANS_LEN */
> +#define TX_TRANS_LEN_MSK (GENMASK(23, 0))
> +
> +/* SE_UART_RX_TRANS_CFG */
> +#define UART_RX_INS_STATUS_BIT   (BIT(2))
> +#define UART_RX_PAR_EN   (BIT(3))
> +
> +/* SE_UART_RX_WORD_LEN */
> +#define RX_WORD_LEN_MASK (GENMASK(9, 0))
> +
> +/* SE_UART_RX_STALE_CNT */
> +#define RX_STALE_CNT (GENMASK(23, 0))
> +
> +/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
> +#define PAR_CALC_EN  (BIT(0))
> +#define PAR_MODE_MSK (GENMASK(2, 1))
> +#define PAR_MODE_SHFT(1)
> +#define PAR_EVEN (0x00)
> +#define PAR_ODD  (0x01)
> +#define PAR_SPACE(0x10)
> +#define PAR_MARK (0x11)
> +
> 

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

[Guenter Roeck]

On Wed, Feb 21, 2018 at 08:16:05AM -0800, Jae Hyun Yoo wrote:
> This commit adds a generic PECI hwmon client driver implementation.
> 
> Signed-off-by: Jae Hyun Yoo 
> ---
>  drivers/hwmon/Kconfig  |  10 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/peci-hwmon.c | 928 
> +
>  3 files changed, 939 insertions(+)
>  create mode 100644 drivers/hwmon/peci-hwmon.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index ef23553ff5cb..f22e0c31f597 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1246,6 +1246,16 @@ config SENSORS_NCT7904
> This driver can also be built as a module.  If so, the module
> will be called nct7904.
>  
> +config SENSORS_PECI_HWMON
> + tristate "PECI hwmon support"
> + depends on PECI
> + help
> +   If you say yes here you get support for the generic PECI hwmon
> +   driver.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called peci-hwmon.
> +
>  config SENSORS_NSA320
>   tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
>   depends on GPIOLIB && OF
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index f814b4ace138..946f54b168e5 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -135,6 +135,7 @@ obj-$(CONFIG_SENSORS_NCT7802) += nct7802.o
>  obj-$(CONFIG_SENSORS_NCT7904)+= nct7904.o
>  obj-$(CONFIG_SENSORS_NSA320) += nsa320-hwmon.o
>  obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
> +obj-$(CONFIG_SENSORS_PECI_HWMON) += peci-hwmon.o
>  obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o
>  obj-$(CONFIG_SENSORS_PC87427)+= pc87427.o
>  obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o
> diff --git a/drivers/hwmon/peci-hwmon.c b/drivers/hwmon/peci-hwmon.c
> new file mode 100644
> index ..edd27744adcb
> --- /dev/null
> +++ b/drivers/hwmon/peci-hwmon.c
> @@ -0,0 +1,928 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 Intel Corporation
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DIMM_SLOT_NUMS_MAX12  /* Max DIMM numbers (channel ranks x 2) */
> +#define CORE_NUMS_MAX 28  /* Max core numbers (max on SKX Platinum) 
> */
> +#define TEMP_TYPE_PECI6   /* Sensor type 6: Intel PECI */
> +
> +#define CORE_TEMP_ATTRS   5
> +#define DIMM_TEMP_ATTRS   2
> +#define ATTR_NAME_LEN 24
> +
> +#define DEFAULT_ATTR_GRP_NUMS 5
> +
> +#define UPDATE_INTERVAL_MIN   HZ
> +#define DIMM_MASK_CHECK_DELAY msecs_to_jiffies(5000)
> +
> +enum sign {
> + POS,
> + NEG
> +};
> +
> +struct temp_data {
> + bool valid;
> + s32  value;
> + unsigned long last_updated;
> +};
> +
> +struct temp_group {
> + struct temp_data tjmax;
> + struct temp_data tcontrol;
> + struct temp_data tthrottle;
> + struct temp_data dts_margin;
> + struct temp_data die;
> + struct temp_data core[CORE_NUMS_MAX];
> + struct temp_data dimm[DIMM_SLOT_NUMS_MAX];
> +};
> +
> +struct core_temp_group {
> + struct sensor_device_attribute sd_attrs[CORE_TEMP_ATTRS];
> + char attr_name[CORE_TEMP_ATTRS][ATTR_NAME_LEN];
> + struct attribute *attrs[CORE_TEMP_ATTRS + 1];
> + struct attribute_group attr_group;
> +};
> +
> +struct dimm_temp_group {
> + struct sensor_device_attribute sd_attrs[DIMM_TEMP_ATTRS];
> + char attr_name[DIMM_TEMP_ATTRS][ATTR_NAME_LEN];
> + struct attribute *attrs[DIMM_TEMP_ATTRS + 1];
> + struct attribute_group attr_group;
> +};
> +
> +struct peci_hwmon {
> + struct peci_client *client;
> + struct device *dev;
> + struct device *hwmon_dev;
> + struct workqueue_struct *work_queue;
> + struct delayed_work work_handler;
> + char name[PECI_NAME_SIZE];
> + struct temp_group temp;
> + u8 addr;
> + uint cpu_no;
> + u32 core_mask;
> + u32 dimm_mask;
> + const struct attribute_group *core_attr_groups[CORE_NUMS_MAX + 1];
> + const struct attribute_group *dimm_attr_groups[DIMM_SLOT_NUMS_MAX + 1];
> + uint global_idx;
> + uint core_idx;
> + uint dimm_idx;
> +};
> +
> +enum label {
> + L_DIE,
> + L_DTS,
> + L_TCONTROL,
> + L_TTHROTTLE,
> + L_TJMAX,
> + L_MAX
> +};
> +
> +static const char *peci_label[L_MAX] = {
> + "Die\n",
> + "DTS margin to Tcontrol\n",
> + "Tcontrol\n",
> + "Tthrottle\n",
> + "Tjmax\n",
> +};
> +
> +static int send_peci_cmd(struct peci_hwmon *priv, enum peci_cmd cmd, void 
> *msg)
> +{
> + return peci_command(priv->client->adapter, cmd, msg);
> +}
> +
> +static int need_update(struct temp_data *temp)
> +{
> + if (temp->valid &&
> + time_before(jiffies, temp->last_updated + UPDATE_INTERVAL_MIN))
> + return 0;
> +
> + return 1;
> +}
> +
> +static s32 

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

[Guenter Roeck]

On Wed, Feb 21, 2018 at 01:24:48PM -0800, Jae Hyun Yoo wrote:
> Hi Guenter,
> 
> Thanks for sharing your time to review this code. Please check my answers
> inline.
> 
> On 2/21/2018 10:26 AM, Guenter Roeck wrote:
> >On Wed, Feb 21, 2018 at 08:16:05AM -0800, Jae Hyun Yoo wrote:
> >>This commit adds a generic PECI hwmon client driver implementation.
> >>
> >>Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com>
> >>---
> >>  drivers/hwmon/Kconfig  |  10 +
> >>  drivers/hwmon/Makefile |   1 +
> >>  drivers/hwmon/peci-hwmon.c | 928 
> >> +
> >>  3 files changed, 939 insertions(+)
> >>  create mode 100644 drivers/hwmon/peci-hwmon.c
> >>
> >>diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> >>index ef23553ff5cb..f22e0c31f597 100644
> >>--- a/drivers/hwmon/Kconfig
> >>+++ b/drivers/hwmon/Kconfig
> >>@@ -1246,6 +1246,16 @@ config SENSORS_NCT7904
> >>  This driver can also be built as a module.  If so, the module
> >>  will be called nct7904.
> >>+config SENSORS_PECI_HWMON
> >>+   tristate "PECI hwmon support"
> >>+   depends on PECI
> >>+   help
> >>+ If you say yes here you get support for the generic PECI hwmon
> >>+ driver.
> >>+
> >>+ This driver can also be built as a module.  If so, the module
> >>+ will be called peci-hwmon.
> >>+
> >>  config SENSORS_NSA320
> >>tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
> >>depends on GPIOLIB && OF
> >>diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> >>index f814b4ace138..946f54b168e5 100644
> >>--- a/drivers/hwmon/Makefile
> >>+++ b/drivers/hwmon/Makefile
> >>@@ -135,6 +135,7 @@ obj-$(CONFIG_SENSORS_NCT7802)   += nct7802.o
> >>  obj-$(CONFIG_SENSORS_NCT7904) += nct7904.o
> >>  obj-$(CONFIG_SENSORS_NSA320)  += nsa320-hwmon.o
> >>  obj-$(CONFIG_SENSORS_NTC_THERMISTOR)  += ntc_thermistor.o
> >>+obj-$(CONFIG_SENSORS_PECI_HWMON)   += peci-hwmon.o
> >>  obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
> >>  obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> >>  obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> >>diff --git a/drivers/hwmon/peci-hwmon.c b/drivers/hwmon/peci-hwmon.c
> >>new file mode 100644
> >>index ..edd27744adcb
> >>--- /dev/null
> >>+++ b/drivers/hwmon/peci-hwmon.c
> >>@@ -0,0 +1,928 @@
> >>+// SPDX-License-Identifier: GPL-2.0
> >>+// Copyright (c) 2018 Intel Corporation
> >>+
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+
> >>+#define DIMM_SLOT_NUMS_MAX12  /* Max DIMM numbers (channel ranks x 2) 
> >>*/
> >>+#define CORE_NUMS_MAX 28  /* Max core numbers (max on SKX 
> >>Platinum) */
> >>+#define TEMP_TYPE_PECI6   /* Sensor type 6: Intel PECI */
> >>+
> >>+#define CORE_TEMP_ATTRS   5
> >>+#define DIMM_TEMP_ATTRS   2
> >>+#define ATTR_NAME_LEN 24
> >>+
> >>+#define DEFAULT_ATTR_GRP_NUMS 5
> >>+
> >>+#define UPDATE_INTERVAL_MIN   HZ
> >>+#define DIMM_MASK_CHECK_DELAY msecs_to_jiffies(5000)
> >>+
> >>+enum sign {
> >>+   POS,
> >>+   NEG
> >>+};
> >>+
> >>+struct temp_data {
> >>+   bool valid;
> >>+   s32  value;
> >>+   unsigned long last_updated;
> >>+};
> >>+
> >>+struct temp_group {
> >>+   struct temp_data tjmax;
> >>+   struct temp_data tcontrol;
> >>+   struct temp_data tthrottle;
> >>+   struct temp_data dts_margin;
> >>+   struct temp_data die;
> >>+   struct temp_data core[CORE_NUMS_MAX];
> >>+   struct temp_data dimm[DIMM_SLOT_NUMS_MAX];
> >>+};
> >>+
> >>+struct core_temp_group {
> >>+   struct sensor_device_attribute sd_attrs[CORE_TEMP_ATTRS];
> >>+   char attr_name[CORE_TEMP_ATTRS][ATTR_NAME_LEN];
> >>+   struct attribute *attrs[CORE_TEMP_ATTRS + 1];
> >>+   struct attribute_group attr_group;
> >>+};
> >>+
> >>+struct dimm_temp_group {
> >>+   struct sensor_device_attribute sd_attrs[DIMM_TEMP_ATTRS];
> >>+   char attr_name[DIMM_TEMP_ATTRS][ATTR_NAME_LEN];
> >>+   

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On Wed, Feb 21, 2018 at 05:20:29PM +0200, Mikko Perttunen wrote:
> On 21.02.2018 16:46, Guenter Roeck wrote:
> >On 02/20/2018 11:15 PM, Mikko Perttunen wrote:
> >>AIUI, the PWM framework already exposes a sysfs node with period
> >>information. We should just use that instead of adding a new driver
> >>for this.
> >>
> >
> >I am kind of lost. Please explain.
> >
> >Are you saying that we should drop the pwm-fan driver as well (which goes
> >the opposite way), as well as any other drivers doing anything with pwm
> >signals,
> >because after all those signals are already exposed to userspace a sysfs
> >attributes,
> >and a kernel driver to abstract those values is thus not needed ?
> 
> The only thing this driver does is do a constant division in kernelspace.
> I'm not really seeing why that couldn't be done in userspace. But if you
> think it's appropriate to do the RPM conversion in kernelspace then I'm not
> greatly opposed to that.
> 
Isn't that true for any conversion from and to pwm values ? Voltages,
for example ? Should those be handled in userspace as well ?

Note that I am not entirely convinced that the approach suggested in this
patch series makes sense. Patch 4 seems to move the notion of a tachometer
into the pwm subsystem. I am not really convinced that this makes sense
(maybe all that code should be in the hwmon driver instead, or in a thermal
driver if the author prefers). But that is a different issue. The question
you raised is if there should be any abstraction to or from raw pwm values
in the kernel.

> >
> >>In any case, we cannot add something like this to device tree since
> >>it's not a hardware device.
> >>
> >
> >So you are saying there is no means to express in devicetree that
> >a pwm input is connected to a fan ? How is that not hardware ?
> >
> >If so, how do you express in devicetree that a pwm signal is connected
> >to anything ?
> 
> If we want to describe that the tachometer is connected to a fan, then we
> should have a fan node in the board's device tree. We don't have a chip that
> has a thing called "generic-pwm-tachometer" attached to it. (We have chips
> that have a "nvidia,tegra186-tachometer", so it's proper to have that.)
> 
So you are concerned about the property name ? I don't really care how
it is called.

Guenter

> Thanks,
> Mikko
> 
> >
> >Guenter
> >
> >>Mikko
> >>
> >>On 21.02.2018 08:58, Rajkumar Rampelli wrote:
> >>>Add generic PWM based tachometer driver via HWMON interface
> >>>to report the RPM of motor. This drivers get the period/duty
> >>>cycle from PWM IP which captures the motor PWM output.
> >>>
> >>>This driver implements a simple interface for monitoring the speed of
> >>>a fan and exposes it in roatations per minute (RPM) to the user space
> >>>by using the hwmon's sysfs interface
> >>>
> >>>Signed-off-by: Rajkumar Rampelli <rr...@nvidia.com>
> >>>---
> >>> Documentation/hwmon/generic-pwm-tachometer |  17 +
> >>> drivers/hwmon/Kconfig  |  10 +++
> >>> drivers/hwmon/Makefile |   1 +
> >>> drivers/hwmon/generic-pwm-tachometer.c | 112
> >>>+
> >>> 4 files changed, 140 insertions(+)
> >>> create mode 100644 Documentation/hwmon/generic-pwm-tachometer
> >>> create mode 100644 drivers/hwmon/generic-pwm-tachometer.c
> >>>
> >>>diff --git a/Documentation/hwmon/generic-pwm-tachometer
> >>>b/Documentation/hwmon/generic-pwm-tachometer
> >>>new file mode 100644
> >>>index 000..e0713ee
> >>>--- /dev/null
> >>>+++ b/Documentation/hwmon/generic-pwm-tachometer
> >>>@@ -0,0 +1,17 @@
> >>>+Kernel driver generic-pwm-tachometer
> >>>+
> >>>+
> >>>+This driver enables the use of a PWM module to monitor a fan. It
> >>>uses the
> >>>+generic PWM interface and can be used on SoCs as along as the SoC
> >>>supports
> >>>+Tachometer controller that moniors the Fan speed in periods.
> >>>+
> >>>+Author: Rajkumar Rampelli <rr...@nvidia.com>
> >>>+
> >>>+Description
> >>>+---
> >>>+
> >>>+The driver implements a simple interface for monitoring the Fan
> >>>speed using
> >>>+PWM module and Tachometer controller. It requests period value
> >>>through

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 +
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
  If you say yes here you get support for the temperature
  and power sensors for APM X-Gene SoC.
  
+config GENERIC_PWM_TACHOMETER

+   tristate "Generic PWM based tachometer driver"
+   depends on PWM
+   help
+ Enables a driver to use PWM signal from motor to use
+ for measuring the motor speed. The RPM is captured by
+ PWM modules which has PWM capture capability and this
+ drivers reads the captured data from PWM IP to convert
+ it to speed in RPM.
+
  if ACPI
  
  comment "ACPI drivers"

diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)   += xgene-hwmon.o
  
  obj-$(CONFIG_PMBUS)		+= pmbus/

+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
  
  ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  
diff --git a/drivers/hwmon/generic-pwm-tachometer.c b/drivers/hwmon/generic-pwm-tachometer.c

new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+   struct device   *dev;
+   struct pwm_device   *pwm;
+   struct device   *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+   struct pwm_device *pwm = ptt->pwm;
+   struct pwm_capture result;
+   int err;
+   unsigned int rpm = 0;
+
+   err = pwm_capture(pwm, , 0);
+   if (err < 0) {
+   dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+   return err;
+   }
+
+   if (result.period)
+   rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+   result.period);
+
+   return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+   _dev_attr_rpm.dev_attr.attr,
+   NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single standard hwmon sysfs attribute, having a hwmon driver is pointless.


+
+ATTRIBUTE_GROUPS(pwm_tach);
+
+static int 

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 02/20/2018 11:15 PM, Mikko Perttunen wrote:

AIUI, the PWM framework already exposes a sysfs node with period information. 
We should just use that instead of adding a new driver for this.



I am kind of lost. Please explain.

Are you saying that we should drop the pwm-fan driver as well (which goes
the opposite way), as well as any other drivers doing anything with pwm signals,
because after all those signals are already exposed to userspace a sysfs 
attributes,
and a kernel driver to abstract those values is thus not needed ?


In any case, we cannot add something like this to device tree since it's not a 
hardware device.



So you are saying there is no means to express in devicetree that
a pwm input is connected to a fan ? How is that not hardware ?

If so, how do you express in devicetree that a pwm signal is connected
to anything ?

Guenter


Mikko

On 21.02.2018 08:58, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
 Documentation/hwmon/generic-pwm-tachometer |  17 +
 drivers/hwmon/Kconfig  |  10 +++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 +
 4 files changed, 140 insertions(+)
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
   If you say yes here you get support for the temperature
   and power sensors for APM X-Gene SoC.

+config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
 if ACPI

 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o

 obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o

 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG

diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture 

Re: [PATCH 2/3] documentation: watchdog: remove documentation for ixp2000

[Guenter Roeck]

On Thu, Feb 01, 2018 at 08:44:11PM +, Corentin Labbe wrote:
> The ixp2000 watchdog driver was removed in commit 065e8238302b ("watchdog: 
> remove ixp2000 driver")
> 
> No need to keep its documentation, so remove it.
> 
> Signed-off-by: Corentin Labbe <cla...@baylibre.com>

Reviewed-by: Guenter Roeck <li...@roeck-us.net>

> ---
>  Documentation/watchdog/watchdog-parameters.txt | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 407d013b8643..603140485ac6 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -157,11 +157,6 @@ testmode: Watchdog test mode (1 = no reboot), default=0
>  nowayout: Watchdog cannot be stopped once started
>   (default=kernel config parameter)
>  -
> -ixp2000_wdt:
> -heartbeat: Watchdog heartbeat in seconds (default 60s)
> -nowayout: Watchdog cannot be stopped once started
> - (default=kernel config parameter)
> --
>  ixp4xx_wdt:
>  heartbeat: Watchdog heartbeat in seconds (default 60s)
>  nowayout: Watchdog cannot be stopped once started
> -- 
> 2.13.6
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] documentation: watchdog: remove documentation of at32ap700x_wdt

[Guenter Roeck]

On Thu, Feb 01, 2018 at 08:44:10PM +, Corentin Labbe wrote:
> Since at32ap700x_wdt is gone, no need to keep its documentation
> 
> Signed-off-by: Corentin Labbe <cla...@baylibre.com>

Reviewed-by: Guenter Roeck <li...@roeck-us.net>

> ---
>  Documentation/watchdog/watchdog-parameters.txt | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 6f9d7b418917..407d013b8643 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -40,11 +40,6 @@ margin: Watchdog margin in seconds (default=60)
>  nowayout: Disable watchdog shutdown on close
>   (default=kernel config parameter)
>  -
> -at32ap700x_wdt:
> -timeout: Timeout value. Limited to be 1 or 2 seconds. (default=2)
> -nowayout: Watchdog cannot be stopped once started
> - (default=kernel config parameter)
> --
>  at91rm9200_wdt:
>  wdt_time: Watchdog time in seconds. (default=5)
>  nowayout: Watchdog cannot be stopped once started
> -- 
> 2.13.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon

[Guenter Roeck]

On Thu, Jan 11, 2018 at 11:47:01AM -0800, Jae Hyun Yoo wrote:
> On 1/10/2018 1:47 PM, Guenter Roeck wrote:
> >On Tue, Jan 09, 2018 at 02:31:26PM -0800, Jae Hyun Yoo wrote:
> >>This commit adds driver implementation for a generic PECI hwmon.
> >>
> >>Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com>

[ ... ]

> >>+
> >>+   if (priv->temp.tcontrol.valid &&
> >>+   time_before(jiffies, priv->temp.tcontrol.last_updated +
> >>+UPDATE_INTERVAL_MIN))
> >>+   return 0;
> >>+
> >
> >Is the delay necessary ? Otherwise I would suggest to drop it.
> >It adds a lot of complexity to the driver. Also, if the user polls
> >values more often, that is presumably on purpose.
> >
> 
> I was intended to reduce traffic on PECI bus because it's low speed single
> wired bus, and temperature values don't change frequently because the value
> is sampled and averaged in CPU itself. I'll keep this.
> 
Then please try to move the common code into a single function.

[ ... ]

> >>+
> >>+   rc = of_property_read_u32(np, "cpu-id", >cpu_id);
> >
> >What entity determines cpu-id ?
> >
> 
> CPU ID numbering is determined by hardware SOCKET_ID strap pins. In this
> driver implementation, cpu-id is being used as CPU client indexing.
> 
Seems to me the necessary information to identify a given CPU should
be provided by the PECI core. Also, there are already "cpu" nodes
in devicetree which, if I recall correctly, may include information
such as CPU Ids.

> >>+   if (rc || priv->cpu_id >= CPU_ID_MAX) {
> >>+   dev_err(dev, "Invalid cpu-id configuration\n");
> >>+   return rc;
> >>+   }
> >>+
> >>+   rc = of_property_read_u32(np, "dimm-nums", >dimm_nums);
> >
> >This is an odd devicetree attribute. Normally the number of DIMMs
> >is dynamic. Isn't there a means to get all that information dynamically
> >instead of having to set it through devicetree ? What if someone adds
> >or removes a DIMM ? Who updates the devicetree ?
> >
> 
> It means the number of DIMM slots each CPU has, doesn't mean the number of
> currently installed DIMM components. If a DIMM is inserted a slot, CPU
> reports its actual temperature but on empty slot, CPU reports 0 instead of
> reporting an error so it is the reason why this driver enumerates all DIMM
> slots' attribute.
> 
And there is no other means to get the number of DIMM slots per CPU ?
It just seems to be that this is the wrong location to provide such
information.

[ ... ]

> >>+
> >>+static const struct of_device_id peci_of_table[] = {
> >>+   { .compatible = "peci-hwmon", },
> >
> >This does not look like a reference to some piece of hardware.
> >
> 
> This driver provides generic PECI hwmon function to which controller has
> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
> specific hardware. Should I remove this or any suggestion?
> 

I don't really know enough about the system to make a recommendation.
It seems to me that the PECI core should identify which functionality
it supports and instantiate the necessary driver(s). Maybe there should
be sub-nodes to the peci node with relevant information. Those sub-nodes
should specify the supported functionality in more detail, though -
such as indicating the supported CPU and/or DIMM sensors.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon

[Guenter Roeck]

On Tue, Jan 09, 2018 at 02:31:26PM -0800, Jae Hyun Yoo wrote:
> This commit adds driver implementation for a generic PECI hwmon.
> 
> Signed-off-by: Jae Hyun Yoo 
> ---
>  drivers/hwmon/Kconfig  |   6 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/peci-hwmon.c | 953 
> +
>  3 files changed, 960 insertions(+)
>  create mode 100644 drivers/hwmon/peci-hwmon.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 9256dd0..3a62c60 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1234,6 +1234,12 @@ config SENSORS_NCT7904
> This driver can also be built as a module.  If so, the module
> will be called nct7904.
>  
> +config SENSORS_PECI_HWMON
> + tristate "PECI hwmon support"
> + depends on ASPEED_PECI
> + help
> +   If you say yes here you get support for the generic PECI hwmon driver.
> +
>  config SENSORS_NSA320
>   tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
>   depends on GPIOLIB && OF
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 98000fc..41d43a5 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -131,6 +131,7 @@ obj-$(CONFIG_SENSORS_NCT7802) += nct7802.o
>  obj-$(CONFIG_SENSORS_NCT7904)+= nct7904.o
>  obj-$(CONFIG_SENSORS_NSA320) += nsa320-hwmon.o
>  obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
> +obj-$(CONFIG_SENSORS_PECI_HWMON) += peci-hwmon.o
>  obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o
>  obj-$(CONFIG_SENSORS_PC87427)+= pc87427.o
>  obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o
> diff --git a/drivers/hwmon/peci-hwmon.c b/drivers/hwmon/peci-hwmon.c
> new file mode 100644
> index 000..2d2a288
> --- /dev/null
> +++ b/drivers/hwmon/peci-hwmon.c
> @@ -0,0 +1,953 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017 Intel Corporation
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

misc, not linux ? That seems wrong.

> +
> +#define DEVICE_NAME "peci-hwmon"
> +#define HWMON_NAME "peci_hwmon"
> +
> +#define CPU_ID_MAX   8   /* Max CPU number configured by socket ID */
> +#define DIMM_NUMS_MAX16  /* Max DIMM numbers (channel ranks x 2) */
> +#define CORE_NUMS_MAX28  /* Max core numbers (max on SKX Platinum) */

I won't insist, but it would be better if this were dynamic,
otherwise we'll end up having to increase the defines in the future.

> +#define TEMP_TYPE_PECI   6   /* Sensor type 6: Intel PECI */
> +#define CORE_INDEX_OFFSET100 /* sysfs filename start offset for core 
> temp */
> +#define DIMM_INDEX_OFFSET200 /* sysfs filename start offset for DIMM 
> temp */

Did you test with the "sensors" command to ensure that this works,
with the large gaps in index values ?

Overall, I am not very happy with the indexing. Since each sensor as
a label, it might be better to just make it dynamic.

> +#define TEMP_NAME_HEADER_LEN 4   /* sysfs temp type header length */
> +#define OF_DIMM_NUMS_DEFAULT 16  /* default dimm-nums setting */
> +
> +#define CORE_TEMP_ATTRS  5
> +#define DIMM_TEMP_ATTRS  2
> +#define ATTR_NAME_LEN24
> +
> +#define UPDATE_INTERVAL_MIN  HZ
> +
> +enum sign_t {
> + POS,
> + NEG
> +};
> +
> +struct cpuinfo_t {
> + bool valid;
> + u32  dib;
> + u8   cpuid;
> + u8   platform_id;
> + u32  microcode;
> + u8   logical_thread_nums;
> +};
> +
> +struct temp_data_t {
> + bool valid;
> + s32  value;
> + unsigned long last_updated;
> +};
> +
> +struct temp_group_t {
> + struct temp_data_t tjmax;
> + struct temp_data_t tcontrol;
> + struct temp_data_t tthrottle;
> + struct temp_data_t dts_margin;
> + struct temp_data_t die;
> + struct temp_data_t core[CORE_NUMS_MAX];
> + struct temp_data_t dimm[DIMM_NUMS_MAX];
> +};
> +
> +struct core_temp_attr_group_t {
> + struct sensor_device_attribute sd_attrs[CORE_NUMS_MAX][CORE_TEMP_ATTRS];
> + char attr_name[CORE_NUMS_MAX][CORE_TEMP_ATTRS][ATTR_NAME_LEN];
> + struct attribute *attrs[CORE_NUMS_MAX][CORE_TEMP_ATTRS + 1];
> + struct attribute_group attr_group[CORE_NUMS_MAX];
> +};
> +
> +struct dimm_temp_attr_group_t {
> + struct sensor_device_attribute sd_attrs[DIMM_NUMS_MAX][DIMM_TEMP_ATTRS];
> + char attr_name[DIMM_NUMS_MAX][DIMM_TEMP_ATTRS][ATTR_NAME_LEN];
> + struct attribute *attrs[DIMM_NUMS_MAX][DIMM_TEMP_ATTRS + 1];
> + struct attribute_group attr_group[DIMM_NUMS_MAX];
> +};
> +
> +struct peci_hwmon {
> + struct device *dev;
> + struct device *hwmon_dev;
> + char name[NAME_MAX];
> + const struct attribute_group **groups;
> + struct cpuinfo_t cpuinfo;
> + struct temp_group_t temp;
> + u32 cpu_id;
> + bool show_core;
> + u32 core_nums;
> + u32 dimm_nums;
> + 

Re: [v6,4/4] pmbus (max31785): Add dual tachometer support

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:06PM +1030, Andrew Jeffery wrote:
> The dual tachometer feature is implemented in hardware with a TACHSEL
> input to indicate the rotor under measurement, and exposed on the device
> by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
> to read the non-standard four-byte response leads to a cut-down
> implementation of i2c_smbus_xfer_emulated() included in the driver.
> Further, to expose the second rotor tachometer value to userspace the
> values are exposed through virtual pages. We re-route accesses to
> FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on pages 23-28 (not defined by the
> hardware) to the same registers on pages 0-5, and with the latter command
> we extract the value from the second word of the four-byte response.
> 
> * The documentation recommends the slower rotor be associated with
> TACHSEL=0, which corresponds to the first word of the response. The
> TACHSEL=0 measurement is used by the controller's closed-loop fan
> management to judge target fan rate.
> 
> Signed-off-by: Andrew Jeffery 

Applied.

Thanks,
Guenter

> ---
>  Documentation/hwmon/max31785   |   8 +-
>  drivers/hwmon/pmbus/max31785.c | 147 ++-
>  2 files changed, 152 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
> index 7b0a0a8cdb6b..270c5f865261 100644
> --- a/Documentation/hwmon/max31785
> +++ b/Documentation/hwmon/max31785
> @@ -17,8 +17,9 @@ management with temperature and remote voltage sensing. 
> Various fan control
>  features are provided, including PWM frequency control, temperature 
> hysteresis,
>  dual tachometer measurements, and fan health monitoring.
>  
> -For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of 
> the
> -two in the fan[1-4]_input attributes.
> +For dual-rotor configurations the MAX31785A exposes the second rotor 
> tachometer
> +readings in attributes fan[5-8]_input. By contrast the MAX31785 only exposes
> +the slowest rotor measurement, and does so in the fan[1-4]_input attributes.
>  
>  Usage Notes
>  ---
> @@ -31,7 +32,8 @@ Sysfs attributes
>  
>  fan[1-4]_alarm   Fan alarm.
>  fan[1-4]_fault   Fan fault.
> -fan[1-4]_input   Fan RPM.
> +fan[1-8]_input   Fan RPM. On the MAX31785A, inputs 5-8 
> correspond to the
> + second rotor of fans 1-4
>  fan[1-4]_target  Fan input target
>  
>  in[1-6]_crit Critical maximum output voltage
> diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
> index 8706a696c89a..bffab449be39 100644
> --- a/drivers/hwmon/pmbus/max31785.c
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -16,9 +16,79 @@
>  
>  enum max31785_regs {
>   MFR_REVISION= 0x9b,
> + MFR_FAN_CONFIG  = 0xf1,
>  };
>  
> +#define MAX31785 0x3030
> +#define MAX31785A0x3040
> +
> +#define MFR_FAN_CONFIG_DUAL_TACH BIT(12)
> +
>  #define MAX31785_NR_PAGES23
> +#define MAX31785_NR_FAN_PAGES6
> +
> +static int max31785_read_byte_data(struct i2c_client *client, int page,
> +int reg)
> +{
> + if (page < MAX31785_NR_PAGES)
> + return -ENODATA;
> +
> + switch (reg) {
> + case PMBUS_VOUT_MODE:
> + return -ENOTSUPP;
> + case PMBUS_FAN_CONFIG_12:
> + return pmbus_read_byte_data(client, page - MAX31785_NR_PAGES,
> + reg);
> + }
> +
> + return -ENODATA;
> +}
> +
> +static int max31785_write_byte(struct i2c_client *client, int page, u8 value)
> +{
> + if (page < MAX31785_NR_PAGES)
> + return -ENODATA;
> +
> + return -ENOTSUPP;
> +}
> +
> +static int max31785_read_long_data(struct i2c_client *client, int page,
> +int reg, u32 *data)
> +{
> + unsigned char cmdbuf[1];
> + unsigned char rspbuf[4];
> + int rc;
> +
> + struct i2c_msg msg[2] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .len = sizeof(cmdbuf),
> + .buf = cmdbuf,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = sizeof(rspbuf),
> + .buf = rspbuf,
> + },
> + };
> +
> + cmdbuf[0] = reg;
> +
> + rc = pmbus_set_page(client, page);
> + if (rc < 0)
> + return rc;
> +
> + rc = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
> + if (rc < 0)
> + return rc;
> +
> + *data = (rspbuf[0] << (0 * 8)) | (rspbuf[1] << (1 * 8)) |
> + (rspbuf[2] << (2 * 8)) | (rspbuf[3] << (3 * 8));
> +
> + return rc;
> +}
>  
>  static int max31785_get_pwm(struct i2c_client *client, int page)
>  {
> 

Re: [v6,3/4] pmbus (core): Add virtual page config bit

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:05PM +1030, Andrew Jeffery wrote:
> Some circumstances call for virtual pages, to expose multiple values
> packed into an extended PMBus register in a manner non-compliant with
> the PMBus standard. An example of this is the Maxim MAX31785 controller,
> which extends the READ_FAN_SPEED_1 PMBus register from two to four bytes
> to support tach readings for both rotors of a dual rotor fan. This extended
> register contains two word-sized values, one reporting the rate of the
> fastest rotor, the other the rate of the slowest. The concept of virtual
> pages aids this situation by mapping the page number onto the value to be
> selected from the vectored result.
> 
> We should not try to set virtual pages on the device as such a page
> explicitly doesn't exist; add a flag so we can avoid doing so.
> 
> Signed-off-by: Andrew Jeffery 

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/pmbus/pmbus.h  |  2 ++
>  drivers/hwmon/pmbus/pmbus_core.c | 27 ++-
>  2 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> index b54d7604d3ef..d39d506aa63e 100644
> --- a/drivers/hwmon/pmbus/pmbus.h
> +++ b/drivers/hwmon/pmbus/pmbus.h
> @@ -372,6 +372,8 @@ enum pmbus_sensor_classes {
>  #define PMBUS_HAVE_PWM12 BIT(20)
>  #define PMBUS_HAVE_PWM34 BIT(21)
>  
> +#define PMBUS_PAGE_VIRTUAL   BIT(31)
> +
>  enum pmbus_data_format { linear = 0, direct, vid };
>  enum vrm_version { vr11 = 0, vr12, vr13 };
>  
> diff --git a/drivers/hwmon/pmbus/pmbus_core.c 
> b/drivers/hwmon/pmbus/pmbus_core.c
> index edc25efe7552..e215bbd403a5 100644
> --- a/drivers/hwmon/pmbus/pmbus_core.c
> +++ b/drivers/hwmon/pmbus/pmbus_core.c
> @@ -161,18 +161,27 @@ EXPORT_SYMBOL_GPL(pmbus_clear_cache);
>  int pmbus_set_page(struct i2c_client *client, int page)
>  {
>   struct pmbus_data *data = i2c_get_clientdata(client);
> - int rv = 0;
> - int newpage;
> + int rv;
> +
> + if (page < 0 || page == data->currpage)
> + return 0;
>  
> - if (page >= 0 && page != data->currpage) {
> + if (!(data->info->func[page] & PMBUS_PAGE_VIRTUAL)) {
>   rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
> - newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
> - if (newpage != page)
> - rv = -EIO;
> - else
> - data->currpage = page;
> + if (rv < 0)
> + return rv;
> +
> + rv = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
> + if (rv < 0)
> + return rv;
> +
> + if (rv != page)
> + return -EIO;
>   }
> - return rv;
> +
> + data->currpage = page;
> +
> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(pmbus_set_page);
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6,2/4] pmbus (max31785): Add fan control

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:04PM +1030, Andrew Jeffery wrote:
> The implementation makes use of the new fan control virtual registers
> exposed by the pmbus core. It mixes use of the default implementations
> with some overrides via the read/write handlers to handle FAN_COMMAND_1
> on the MAX31785, whose definition breaks the value range into various
> control bands dependent on RPM or PWM mode.
> 
> Signed-off-by: Andrew Jeffery 

Applied.

Thanks,
Guenter

> ---
>  Documentation/hwmon/max31785   |   7 ++-
>  drivers/hwmon/pmbus/max31785.c | 138 +-
>  2 files changed, 144 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
> index 45fb6093dec2..7b0a0a8cdb6b 100644
> --- a/Documentation/hwmon/max31785
> +++ b/Documentation/hwmon/max31785
> @@ -32,6 +32,7 @@ Sysfs attributes
>  fan[1-4]_alarm   Fan alarm.
>  fan[1-4]_fault   Fan fault.
>  fan[1-4]_input   Fan RPM.
> +fan[1-4]_target  Fan input target
>  
>  in[1-6]_crit Critical maximum output voltage
>  in[1-6]_crit_alarm   Output voltage critical high alarm
> @@ -44,6 +45,12 @@ in[1-6]_max_alarm  Output voltage high alarm
>  in[1-6]_min  Minimum output voltage
>  in[1-6]_min_alarmOutput voltage low alarm
>  
> +pwm[1-4] Fan target duty cycle (0..255)
> +pwm[1-4]_enable  0: Full-speed
> + 1: Manual PWM control
> + 2: Automatic PWM (tach-feedback RPM fan-control)
> + 3: Automatic closed-loop (temp-feedback fan-control)
> +
>  temp[1-11]_crit  Critical high temperature
>  temp[1-11]_crit_alarmChip temperature critical high alarm
>  temp[1-11]_input Measured temperature
> diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
> index 9313849d5160..8706a696c89a 100644
> --- a/drivers/hwmon/pmbus/max31785.c
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -20,8 +20,136 @@ enum max31785_regs {
>  
>  #define MAX31785_NR_PAGES23
>  
> +static int max31785_get_pwm(struct i2c_client *client, int page)
> +{
> + int rv;
> +
> + rv = pmbus_get_fan_rate_device(client, page, 0, percent);
> + if (rv < 0)
> + return rv;
> + else if (rv >= 0x8000)
> + return 0;
> + else if (rv >= 0x2711)
> + return 0x2710;
> +
> + return rv;
> +}
> +
> +static int max31785_get_pwm_mode(struct i2c_client *client, int page)
> +{
> + int config;
> + int command;
> +
> + config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
> + if (config < 0)
> + return config;
> +
> + command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
> + if (command < 0)
> + return command;
> +
> + if (config & PB_FAN_1_RPM)
> + return (command >= 0x8000) ? 3 : 2;
> +
> + if (command >= 0x8000)
> + return 3;
> + else if (command >= 0x2711)
> + return 0;
> +
> + return 1;
> +}
> +
> +static int max31785_read_word_data(struct i2c_client *client, int page,
> +int reg)
> +{
> + int rv;
> +
> + switch (reg) {
> + case PMBUS_VIRT_PWM_1:
> + rv = max31785_get_pwm(client, page);
> + break;
> + case PMBUS_VIRT_PWM_ENABLE_1:
> + rv = max31785_get_pwm_mode(client, page);
> + break;
> + default:
> + rv = -ENODATA;
> + break;
> + }
> +
> + return rv;
> +}
> +
> +static inline u32 max31785_scale_pwm(u32 sensor_val)
> +{
> + /*
> +  * The datasheet describes the accepted value range for manual PWM as
> +  * [0, 0x2710], while the hwmon pwmX sysfs interface accepts values in
> +  * [0, 255]. The MAX31785 uses DIRECT mode to scale the FAN_COMMAND
> +  * registers and in PWM mode the coefficients are m=1, b=0, R=2. The
> +  * important observation here is that 0x2710 == 1 == 100 * 100.
> +  *
> +  * R=2 (== 10^2 == 100) accounts for scaling the value provided at the
> +  * sysfs interface into the required hardware resolution, but it does
> +  * not yet yield a value that we can write to the device (this initial
> +  * scaling is handled by pmbus_data2reg()). Multiplying by 100 below
> +  * translates the parameter value into the percentage units required by
> +  * PMBus, and then we scale back by 255 as required by the hwmon pwmX
> +  * interface to yield the percentage value at the appropriate
> +  * resolution for hardware.
> +  */
> + return (sensor_val * 100) / 255;
> +}
> +
> +static int max31785_pwm_enable(struct i2c_client *client, int page,
> + u16 word)
> +{
> + int config = 0;
> + int rate;
> +
> + switch (word) {
> + case 0:
> + rate = 0x7fff;
> + break;
> + case 

Re: [v6,1/4] pmbus (core): Add fan control support

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:03PM +1030, Andrew Jeffery wrote:
> Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
> 
> Fans in a PMBus device are driven by the configuration of two registers,
> FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
> and the tacho operate (if installed), while FAN_COMMAND_x sets the
> desired fan rate. The unit of FAN_COMMAND_x is dependent on the
> operational fan mode, RPM or PWM percent duty, as determined by the
> corresponding configuration in FAN_CONFIG_x_y.
> 
> The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
> FAN_COMMAND_x is implemented with the addition of virtual registers to
> facilitate the necessary side-effects of each access:
> 
> 1. PMBUS_VIRT_FAN_TARGET_x
> 2. PMBUS_VIRT_PWM_x
> 3. PMBUS_VIRT_PWM_ENABLE_x
> 
> Some complexity arises with the fanX_target and pwmX attributes both mapping
> onto FAN_COMMAND_x: There is no general mapping between PWM percent duty and
> RPM, so we can't display values in either attribute in terms of the other
> (which in my mind is the intuitive, if impossible, behaviour). This problem
> also affects the pwmX_enable attribute which allows userspace to switch 
> between
> full speed, manual PWM and a number of automatic control modes, possibly
> including a switch to RPM behaviour (e.g. automatically adjusting PWM duty to
> reach a RPM target, the behaviour of fanX_target).
> 
> The next most intuitive behaviour is for fanX_target and pwmX to simply be
> independent, to retain their most recently set value even if that value is not
> active on the hardware (due to switching to the alternative control mode). 
> This
> property of retaining the value independent of the hardware state has useful
> results for both userspace and the kernel: Userspace always sees a sensible
> value in the attribute (the last thing it was set to, as opposed to 0 or
> receiving an error on read), and the kernel can use the attributes as a value
> cache. This latter point eases the implementation of pwmX_enable, which can
> look up the associated pmbus_sensor object, take its cached value and apply it
> to hardware on changing control mode. This ensures we will not arbitrarily set
> a PWM value as an RPM value or vice versa, and we can assume that the RPM or
> PWM value set was sensible at least at some point in the past.
> 
> Finally, the DIRECT mode coefficients of some controllers is different between
> RPM and PWM percent duty control modes, so PSC_PWM is introduced to capture 
> the
> necessary coefficients. As pmbus core had no PWM support previously PSC_FAN
> continues to be used to capture the RPM DIRECT coefficients, but in order to
> avoid falsely applying RPM scaling to PWM values I have introduced the
> PMBUS_HAVE_PWM12 and PMB_BUS_HAVE_PWM34 feature bits. These feature bits allow
> drivers to explicitly declare PWM support in order to have the attributes
> exposed.
> 
> Signed-off-by: Andrew Jeffery 

Appled (fixed whitespace problem).

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] watchdog: introduce watchdog.open_timeout commandline parameter

[Guenter Roeck]

On Wed, Nov 29, 2017 at 11:56:57AM +0100, Rasmus Villemoes wrote:
> On 2017-11-28 23:14, Guenter Roeck wrote:
> > On Tue, Nov 28, 2017 at 11:35:49AM +0100, Rasmus Villemoes wrote:
> >>
> >> The unit is milliseconds rather than seconds because that covers more
> >> use cases. For example, one can effectively disable the kernel handling
> >> by setting the open_timeout to 1 ms. There are also customers with very
> >> strict requirements that may want to set the open_timeout to something
> >> like 4500 ms, which combined with a hardware watchdog that must be
> >> pinged every 250 ms ensures userspace is up no more than 5 seconds after
> >> the bootloader hands control to the kernel (250 ms until the driver gets
> >> registered and kernel handling starts, 4500 ms of kernel handling, and
> >> then up to 250 ms from the last ping until userspace takes over).
> > 
> > This is quite vague, especially since it doesn't count the time from
> > boot to starting the watchdog driver,
> 
> My example is bad, and I now realize one cannot really get such precise
> guarantees. But the example _did_ actually account for the time from
> boot to device registration - it allowed 250 ms for the kernel to get
> that far.
> 
> which can vary even across boots.
> > Why not make it specific, for example by adjusting the open timeout with
> > ktime_get_boot_ns() ?
> 
> If by "boot" we mean the moment the bootloader hands control to the
> kernel, ktime_get_boot_ns() doesn't give that either - at best, it gives
> an approximation of the time since timekeeping_init(), but it's not very
> accurate that early (I simply injected printks of ktime_get_boot_ns at
> various places in init/main.c and timestamped the output lines). If it
> overshoots, we'd be subtracting more of the allowance than we should,
> and I don't think we have any way of knowing when that happens or to
> correct for it. So I'd rather keep the code simple and let it count from
> the time the watchdog framework knows about the device, which is also
> around the time when the kernel's timekeeping is reasonably accurate.
> 
We should try to make things as accurate as possible. "It won't be perfect"
is not an argument against that.

> > I would actually make it even more specific and calculate the open
> > timeout such that the system would reboot after open_timeout, not
> > after . Any reason for not doing that ?
> > The upside would be more accuracy, and I don't really see a downside.
> 
> I don't think it would be that much more accurate - we schedule the
> pings at a frequency of half the max_hw_heartbeat_ms==$x, with the
> current code we'd get rebooted somewhere between [open_deadline + $x/2,
> open_deadline + $x], and subtracting $x from the open_timeout that would
> become [open_deadline - $x/2, open_deadline]. I'd rather not have the
> reboot happen before the open_deadline. Sure, we could subtract $x/2
> instead. Then there's the case where ->max_hw_heartbeat_ms is not set,
> so we have to use ->timeout for $x, and then there's the case of $x (or
> $x/2) being greater than $open_timeout. I'd really like to keep the code
> simple. If it helps, I'd be happy to document the exact semantics of the
> open_timeout with a nice ascii art timeline.
> 
It was not much of a problem to get that right after a watchdog was opened,
by timing pings accordingly such that the HW times out when it should.
It should not be that hard to get it working for the pre-open case as well.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] watchdog: introduce watchdog.open_timeout commandline parameter

[Guenter Roeck]

On Tue, Nov 28, 2017 at 11:35:49AM +0100, Rasmus Villemoes wrote:
> The watchdog framework takes care of feeding a hardware watchdog until
> userspace opens /dev/watchdogN. If that never happens for some reason
> (buggy init script, corrupt root filesystem or whatnot) but the kernel
> itself is fine, the machine stays up indefinitely. This patch allows
> setting an upper limit for how long the kernel will take care of the
> watchdog, thus ensuring that the watchdog will eventually reset the
> machine.
> 
> This is particularly useful for embedded devices where some fallback
> logic is implemented in the bootloader (e.g., use a different root
> partition, boot from network, ...).
> 
> The existing handle_boot_enabled parameter has the same purpose, but
> that is only usable when the hardware watchdog has a sufficiently long
> timeout (possibly configured by the bootloader). Many hardware watchdogs
> cannot be configured, or can only be configured up to a certain value,
> making the timeout short enough that it is completely impossible to have
> userspace ready soon enough. Hence it is necessary for the kernel to
> handle those watchdogs for a while.
> 
> The open timeout is also used as a maximum time for an application to
> re-open /dev/watchdogN after closing it.
> 
> A value of 0 (the default) means infinite timeout, preserving the
> current behaviour.
> 
> The unit is milliseconds rather than seconds because that covers more
> use cases. For example, one can effectively disable the kernel handling
> by setting the open_timeout to 1 ms. There are also customers with very
> strict requirements that may want to set the open_timeout to something
> like 4500 ms, which combined with a hardware watchdog that must be
> pinged every 250 ms ensures userspace is up no more than 5 seconds after
> the bootloader hands control to the kernel (250 ms until the driver gets
> registered and kernel handling starts, 4500 ms of kernel handling, and
> then up to 250 ms from the last ping until userspace takes over).

This is quite vague, especially since it doesn't count the time from
boot to starting the watchdog driver, which can vary even across boots.
Why not make it specific, for example by adjusting the open timeout with
ktime_get_boot_ns() ?

I would actually make it even more specific and calculate the open
timeout such that the system would reboot after open_timeout, not
after . Any reason for not doing that ?
The upside would be more accuracy, and I don't really see a downside.

Thanks,
Guenter

> 
> Signed-off-by: Rasmus Villemoes 
> Reviewed-by: Esben Haabendal 
> ---
>  Documentation/watchdog/watchdog-parameters.txt |  8 
>  drivers/watchdog/watchdog_dev.c| 27 
> +-
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 6f9d7b4..5363bf3 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -8,6 +8,14 @@ See Documentation/admin-guide/kernel-parameters.rst for 
> information on
>  providing kernel parameters for builtin drivers versus loadable
>  modules.
>  
> +The watchdog core parameter watchdog.open_timeout is the maximum time,
> +in milliseconds, for which the watchdog framework will take care of
> +pinging a hardware watchdog until userspace opens the corresponding
> +/dev/watchdogN device. A value of 0 (the default) means an infinite
> +timeout. Setting this to a non-zero value can be useful to ensure that
> +either userspace comes up properly, or the board gets reset and allows
> +fallback logic in the bootloader to try something else.
> +
>  
>  -
>  acquirewdt:
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 1e971a5..b4985db 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -67,6 +67,7 @@ struct watchdog_core_data {
>   struct mutex lock;
>   unsigned long last_keepalive;
>   unsigned long last_hw_keepalive;
> + unsigned long open_deadline;
>   struct delayed_work work;
>   unsigned long status;   /* Internal status bits */
>  #define _WDOG_DEV_OPEN   0   /* Opened ? */
> @@ -83,6 +84,19 @@ static struct workqueue_struct *watchdog_wq;
>  
>  static bool handle_boot_enabled =
>   IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
> +static unsigned open_timeout;
> +
> +static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
> +{
> + if (!open_timeout)
> + return false;
> + return time_is_before_jiffies(data->open_deadline);
> +}
> +
> +static void watchdog_set_open_deadline(struct watchdog_core_data *data)
> +{
> + data->open_deadline = jiffies + msecs_to_jiffies(open_timeout);


> +}
>  
>  static inline 

Re: [v3,10/12] hwmon (occ): Add non-hwmon attributes

[Guenter Roeck]

On Mon, Nov 20, 2017 at 05:53:39PM -0600, eaja...@linux.vnet.ibm.com wrote:
> From: "Edward A. James" 
> 
> 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.
> 
... and those attributes should really not be part of the hwmon driver.

> Signed-off-by: Edward A. James 
> ---
>  drivers/hwmon/occ/common.c | 93 
> ++
>  drivers/hwmon/occ/common.h |  1 +
>  drivers/hwmon/occ/p8_i2c.c | 10 +
>  drivers/hwmon/occ/p9_sbe.c |  2 +
>  4 files changed, 106 insertions(+)
> 
> diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
> index 337f286b..53e3592 100644
> --- a/drivers/hwmon/occ/common.c
> +++ b/drivers/hwmon/occ/common.c
> @@ -24,6 +24,14 @@
>  
>  #define OCC_FRU_TYPE_VRM 0x3
>  
> +/* 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_THROTTLE0x20
> +#define OCC_EXT_STAT_QUICK_DROP  0x10
> +
>  /* OCC sensor type and version definitions */
>  
>  struct temp_sensor_1 {
> @@ -1108,6 +1116,81 @@ 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 = 0;
> + 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;
> + case 7:
> + if (header->status & OCC_STAT_MASTER)
> + val = hweight8(header->occs_present);
> + else
> + val = 1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return snprintf(buf, PAGE_SIZE - 1, "%d\n", val);
> +}
> +
> +static SENSOR_DEVICE_ATTR(occ_master, 0444, occ_show_status, NULL, 0);
> +static SENSOR_DEVICE_ATTR(occ_active, 0444, occ_show_status, NULL, 1);
> +static SENSOR_DEVICE_ATTR(occ_dvfs_ot, 0444, occ_show_status, NULL, 2);
> +static SENSOR_DEVICE_ATTR(occ_dvfs_power, 0444, occ_show_status, NULL, 3);
> +static SENSOR_DEVICE_ATTR(occ_mem_throttle, 0444, occ_show_status, NULL, 4);
> +static SENSOR_DEVICE_ATTR(occ_quick_drop, 0444, occ_show_status, NULL, 5);
> +static SENSOR_DEVICE_ATTR(occ_status, 0444, occ_show_status, NULL, 6);
> +static SENSOR_DEVICE_ATTR(occs_present, 0444, occ_show_status, NULL, 7);
> +
> +static struct attribute *occ_attributes[] = {
> + _dev_attr_occ_master.dev_attr.attr,
> + _dev_attr_occ_active.dev_attr.attr,
> + _dev_attr_occ_dvfs_ot.dev_attr.attr,
> + _dev_attr_occ_dvfs_power.dev_attr.attr,
> + _dev_attr_occ_mem_throttle.dev_attr.attr,
> + _dev_attr_occ_quick_drop.dev_attr.attr,
> + _dev_attr_occ_status.dev_attr.attr,
> + _dev_attr_occs_present.dev_attr.attr,
> + NULL
> +};
> +
> +static const struct attribute_group occ_attr_group = {
> + .attrs = occ_attributes,
> +};
> +
>  /* 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)
>  {
> @@ -1188,5 +1271,15 @@ int occ_setup(struct occ *occ, const char *name)
>   return rc;
>   }
>  
> + rc = sysfs_create_group(>bus_dev->kobj, _attr_group);
> + if (rc)
> + dev_warn(occ->bus_dev, "failed to create status attrs: %d\n",
> +  rc);
> +
>   return 0;
>  }
> +
> +void occ_shutdown(struct occ *occ)
> +{
> + sysfs_remove_group(>bus_dev->kobj, _attr_group);
> +}
> diff --git a/drivers/hwmon/occ/common.h b/drivers/hwmon/occ/common.h
> index 049c3b4..dc9e06d 100644
> --- a/drivers/hwmon/occ/common.h
> +++ b/drivers/hwmon/occ/common.h
> @@ -110,5 +110,6 

Re: [v3, 09/12] hwmon (occ): Add sensor attributes and register hwmon device

[Guenter Roeck]

On Mon, Nov 20, 2017 at 05:53:38PM -0600, eaja...@linux.vnet.ibm.com wrote:
> From: "Edward A. James" 
> 
> Setup the sensor attributes for every OCC sensor found by the first poll
> response. Register the attributes with hwmon. Add hwmon documentation
> for the driver.
> 
> Signed-off-by: Edward A. James 
> ---
>  drivers/hwmon/occ/common.c | 450 
> +
>  drivers/hwmon/occ/common.h |  15 ++

I seem to be missing the documentation.

Documentation/hwmon/submitting-patches:

* Document the driver in Documentation/hwmon/.

* Do not create non-standard attributes unless really needed. If you have to use
  non-standard attributes, or you believe you do, discuss it on the mailing list
  first. Either case, provide a detailed explanation why you need the
  non-standard attribute(s).
  Standard attributes are specified in Documentation/hwmon/sysfs-interface.

I really would expect a detailed explanation and, even more so,
documentation for all the non-standard attributes you are adding.

power%d_update_time
power%d_update_tag
power%d_accumulator

really need to be documented, you really need to explain the need for those
attributes. To me they don't mean anything.

Note that you'd probably be much better off using
devm_register_hwmon_with_info() nowadays, but i'll leave that for you to
decide.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3, 02/12] Documentation: ABI: Add occ-hwmon driver sysfs documentation

[Guenter Roeck]

On Mon, Nov 20, 2017 at 05:53:31PM -0600, eaja...@linux.vnet.ibm.com wrote:
> From: "Edward A. James" 
> 
> Detail the sysfs attributes provided by the occ-hwmon driver.
> 

This describes my problem with this driver: All the sysfs attributes
described here are not really hardware monitoring related. A later patch
describes this in more detail:

"The OCC can provide the raw sensor data as well as perform thermal
 and power management on the system."

Is it possible to extract the non-hwmon functionality (maybe into an
mfd driver) and limit the hwmon part to just hardware monitoring ?

Guenter


> Signed-off-by: Edward A. James 
> ---
>  Documentation/ABI/testing/sysfs-driver-occ-hwmon | 85 
> 
>  1 file changed, 85 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 000..8873cc3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-occ-hwmon
> @@ -0,0 +1,85 @@
> +What:/sys/bus/platform/drivers/occ-hwmon//occ_active
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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//occ_dvfs_ot
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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//occ_dvfs_power
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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//occ_error
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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 negative integer indicates
> + either an error response from the OCC or bus error or other
> + error condition detected by the driver. A "0" indicates no
> + error.
> +
> +What:/sys/bus/platform/drivers/occ-hwmon//occ_master
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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//occ_mem_throttle
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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//occs_present
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@us.ibm.com
> +Description:
> + A read-only attribute that indicates the number of OCCs present
> + on the system.
> +
> +What:/sys/bus/platform/drivers/occ-hwmon//occ_quick_drop
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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//occ_status
> +Date:November 2017
> +KernelVersion:   4.14
> +Contact: eaja...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v5 3/4] pmbus (core): Add virtual page config bit

[Guenter Roeck]

On 11/17/2017 07:26 PM, Andrew Jeffery wrote:

Some circumstances call for virtual pages, to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. An example of this is the Maxim MAX31785 controller, which
extends the READ_FAN_SPEED_1 PMBus register from two to four bytes to support
tach readings for both rotors of a dual rotor fan. This extended register
contains two word-sized values, one reporting the rate of the fastest rotor,
the other the rate of the slowest. The concept of virtual pages aids this
situation by mapping the page number onto the value to be selected from the
vectored result.

We should not try to set virtual pages on the device as such a page explicitly
doesn't exist; add a flag so we can avoid doing so.

Signed-off-by: Andrew Jeffery 
---
  drivers/hwmon/pmbus/pmbus.h  |  2 ++
  drivers/hwmon/pmbus/pmbus_core.c | 10 +++---
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index b54d7604d3ef..d39d506aa63e 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -372,6 +372,8 @@ enum pmbus_sensor_classes {
  #define PMBUS_HAVE_PWM12  BIT(20)
  #define PMBUS_HAVE_PWM34  BIT(21)
  
+#define PMBUS_PAGE_VIRTUAL	BIT(31)

+
  enum pmbus_data_format { linear = 0, direct, vid };
  enum vrm_version { vr11 = 0, vr12, vr13 };
  
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c

index 631db88526b6..ba97230fcde7 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -164,14 +164,18 @@ int pmbus_set_page(struct i2c_client *client, int page)
int rv = 0;
int newpage;
  
-	if (page >= 0 && page != data->currpage) {

+   if (page < 0 || page == data->currpage)
+   return 0;
+
+   if (!(data->info->func[page] & PMBUS_PAGE_VIRTUAL)) {
rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
if (newpage != page)
rv = -EIO;


This should probably be something like
rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
if (rv < 0)
return rv;
newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
if (newpage < 0)
return newpage;
if (newpage != page)
return -EIO;

We can actually drop 'newpage' and just use 'rv'.


-   else
-   data->currpage = page;
}
+
+   data->currpage = page;
+


... otherwise currpage is set even on error.


return rv;


this can then be
return 0;


  }
  EXPORT_SYMBOL_GPL(pmbus_set_page);



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v4,3/6] pmbus: core: Add fan control support

[Guenter Roeck]

On 11/09/2017 07:03 PM, Andrew Jeffery wrote:

On Sun, 2017-11-05 at 06:39 -0800, Guenter Roeck wrote:

On Fri, Nov 03, 2017 at 03:53:03PM +1100, Andrew Jeffery wrote:

Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.

Fans in a PMBus device are driven by the configuration of two registers:
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding FAN_CONFIG_x_y.

The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers and
generic implementations in the core:

1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x

The virtual registers facilitate the necessary side-effects of each
access. Examples of the read case, assuming m = 1, b = 0, R = 0:

  Read |  With  || Gives
  ---
Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
  --++---
   fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
   pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
   pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
   fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
   pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
   pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1

And the write case:

  Write| With  ||   Sets
  -+---+++---
Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
  -+---+++---
   fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
   pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
   pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064

Also, the DIRECT mode scaling of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to
capture the necessary coefficients.

Signed-off-by: Andrew Jeffery <and...@aj.id.au>
---
  drivers/hwmon/pmbus/pmbus.h  |  29 +
  drivers/hwmon/pmbus/pmbus_core.c | 224 ---
  2 files changed, 238 insertions(+), 15 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 4efa2bd4f6d8..cdf3e288e626 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -190,6 +190,28 @@ enum pmbus_regs {
PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
PMBUS_VIRT_STATUS_VMON,
+
+   /*
+* RPM and PWM Fan control
+*
+* Drivers wanting to expose PWM control must define the behaviour of
+* PMBUS_VIRT_PWM_ENABLE_[1-4] in the {read,write}_word_data callback.
+*
+* pmbus core provides default implementations for
+* PMBUS_VIRT_FAN_TARGET_[1-4] and PMBUS_VIRT_PWM_[1-4].
+*/
+   PMBUS_VIRT_FAN_TARGET_1,
+   PMBUS_VIRT_FAN_TARGET_2,
+   PMBUS_VIRT_FAN_TARGET_3,
+   PMBUS_VIRT_FAN_TARGET_4,
+   PMBUS_VIRT_PWM_1,
+   PMBUS_VIRT_PWM_2,
+   PMBUS_VIRT_PWM_3,
+   PMBUS_VIRT_PWM_4,
+   PMBUS_VIRT_PWM_ENABLE_1,
+   PMBUS_VIRT_PWM_ENABLE_2,
+   PMBUS_VIRT_PWM_ENABLE_3,
+   PMBUS_VIRT_PWM_ENABLE_4,
  };
  
  /*

@@ -223,6 +245,8 @@ enum pmbus_regs {
  #define PB_FAN_1_RPM  BIT(6)
  #define PB_FAN_1_INSTALLEDBIT(7)
  
+enum pmbus_fan_mode { percent = 0, rpm };

+
  /*
   * STATUS_BYTE, STATUS_WORD (lower)
   */
@@ -313,6 +337,7 @@ enum pmbus_sensor_classes {
PSC_POWER,
PSC_TEMPERATURE,
PSC_FAN,
+   PSC_PWM,
PSC_NUM_CLASSES /* Number of power sensor classes */
  };
  
@@ -339,6 +364,8 @@ enum pmbus_sensor_classes {

  #define PMBUS_HAVE_STATUS_FAN34   BIT(17)
  #define PMBUS_HAVE_VMON   BIT(18)
  #define PMBUS_HAVE_STATUS_VMONBIT(19)
+#define PMBUS_HAVE_PWM12   BIT(20)
+#define PMBUS_HAVE_PWM34   BIT(21)
  
  enum pmbus_data_format { linear = 0, direct, vid };

  enum vrm_version { vr11 = 0, vr12, vr13 };
@@ -413,6 +440,8 @@ int pmbus_write_byte_data(struct i2c_client *client, int 
page, u8 reg,
  u8 value);
  int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
   u8 mask, u8 value);
+int pmbus_update_fan(struct i2c_client *client, int page, int id,
+u8 config, u8 mask, u16 command);
  void pmbus_clear_faults(struct i2c_client *client);
  bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
  bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
diff --git a/drivers/hwmon

Re: [v4,4/6] pmbus: max31785: Add fan control

[Guenter Roeck]

On 11/09/2017 07:10 PM, Andrew Jeffery wrote:

On Sun, 2017-11-05 at 07:04 -0800, Guenter Roeck wrote:

On Fri, Nov 03, 2017 at 03:53:04PM +1100, Andrew Jeffery wrote:

The implementation makes use of the new fan control virtual registers
exposed by the pmbus core. It mixes use of the default implementations
with some overrides via the read/write handlers to handle FAN_COMMAND_1
on the MAX31785, whose definition breaks the value range into various
control bands dependent on RPM or PWM mode.

Signed-off-by: Andrew Jeffery <and...@aj.id.au>
---
  Documentation/hwmon/max31785   |   4 ++
  drivers/hwmon/pmbus/max31785.c | 104 -
  2 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index 45fb6093dec2..e9edbf11948f 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -32,6 +32,7 @@ Sysfs attributes
  fan[1-4]_alarmFan alarm.
  fan[1-4]_faultFan fault.
  fan[1-4]_inputFan RPM.
+fan[1-4]_targetFan input target
  
  in[1-6]_crit		Critical maximum output voltage

  in[1-6]_crit_alarmOutput voltage critical high alarm
@@ -44,6 +45,9 @@ in[1-6]_max_alarm Output voltage high alarm
  in[1-6]_min   Minimum output voltage
  in[1-6]_min_alarm Output voltage low alarm
  
+pwm[1-4]		Fan target duty cycle (0..255)

+pwm[1-4]_enable0: full-speed, 1: manual control, 2: automatic
+
  temp[1-11]_crit   Critical high temperature
  temp[1-11]_crit_alarm Chip temperature critical high alarm
  temp[1-11]_input  Measured temperature
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 9313849d5160..0d97ddf67079 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -20,8 +20,102 @@ enum max31785_regs {
  
  #define MAX31785_NR_PAGES		23
  
+static int max31785_get_pwm(struct i2c_client *client, int page)

+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 0;
+   else if (command >= 0x2711)
+   return 0x2710;
+
+   return command;
+   }
+
+   return 0;
+}
+
+static int max31785_get_pwm_mode(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 2;
+   else if (command >= 0x2711)
+   return 0;
+
+   return 1;
+   }
+
+   return (command >= 0x8000) ? 2 : 1;
+}
+
+static int max31785_read_word_data(struct i2c_client *client, int page,
+  int reg)
+{
+   int rv;
+
+   switch (reg) {
+   case PMBUS_VIRT_PWM_1:
+   rv = max31785_get_pwm(client, page);
+   if (rv < 0)
+   return rv;
+
+   rv *= 255;
+   rv /= 100;
+   break;
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   rv = max31785_get_pwm_mode(client, page);
+   break;


I do wonder ... does it even make sense to specify generic code
for the new virtual attributes in the pmbus core code, or would
it be better to have it all in this driver, at least for now ?


I think I'll pull the generic implementations out in light of my
response on 3/6. At best the generic implementation for the PWM virtual
regs is a guess. We can always put it back if others come to need it.



SGTM.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v4,1/6] dt-bindings: pmbus: Add Maxim MAX31785 documentation

[Guenter Roeck]

On Fri, Nov 03, 2017 at 03:53:01PM +1100, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery 
> Acked-by: Rob Herring 

Applied to hwmon-next.

Thanks,
Guenter

> ---
>  .../devicetree/bindings/hwmon/max31785.txt | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/max31785.txt 
> b/Documentation/devicetree/bindings/hwmon/max31785.txt
> new file mode 100644
> index ..106e08c56aaa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/max31785.txt
> @@ -0,0 +1,22 @@
> +Bindings for the Maxim MAX31785 Intelligent Fan Controller
> +==
> +
> +Reference:
> +
> +https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
> +
> +The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
> +management with temperature and remote voltage sensing. Various fan control
> +features are provided, including PWM frequency control, temperature 
> hysteresis,
> +dual tachometer measurements, and fan health monitoring.
> +
> +Required properties:
> +- compatible : One of "maxim,max31785" or "maxim,max31785a"
> +- reg: I2C address, one of 0x52, 0x53, 0x54, 0x55.
> +
> +Example:
> +
> +fans@52 {
> +compatible = "maxim,max31785";
> +reg = <0x52>;
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v4,6/6] pmbus: max31785: Add dual tachometer support

[Guenter Roeck]

On Fri, Nov 03, 2017 at 03:53:06PM +1100, Andrew Jeffery wrote:
> The dual tachometer feature is implemented in hardware with a TACHSEL
> input to indicate the rotor under measurement, and exposed on the device
> by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
> to read the non-standard four-byte response leads to a cut-down
> implementation of i2c_smbus_xfer_emulated() included in the driver.
> Further, to expose the second rotor tachometer value to userspace the
> values are exposed through virtual pages. We re-route accesses to
> FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on undefined (in hardware) pages
> 23-28 to the same registers on pages 0-5, and with the latter command we
> extract the value from the second word of the four-byte response.
> 
> * The documentation recommends the slower rotor be associated with
> TACHSEL=0, which provides the first word of the response. The TACHSEL=0
> measurement is used by the controller's closed-loop fan management.
> 
> Signed-off-by: Andrew Jeffery 
> ---
>  Documentation/hwmon/max31785   |   8 ++-
>  drivers/hwmon/pmbus/max31785.c | 159 
> -
>  2 files changed, 163 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
> index e9edbf11948f..8e75efc5e4b9 100644
> --- a/Documentation/hwmon/max31785
> +++ b/Documentation/hwmon/max31785
> @@ -17,8 +17,9 @@ management with temperature and remote voltage sensing. 
> Various fan control
>  features are provided, including PWM frequency control, temperature 
> hysteresis,
>  dual tachometer measurements, and fan health monitoring.
>  
> -For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of 
> the
> -two in the fan[1-4]_input attributes.
> +For dual-rotor configurations the MAX31785A exposes the second rotor 
> tachometer
> +readings in attributes fan[5-8]_input. By contrast the MAX31785 only exposes
> +the slowest rotor measurement, and does so in the fan[1-4]_input attributes.
>  
>  Usage Notes
>  ---
> @@ -31,7 +32,8 @@ Sysfs attributes
>  
>  fan[1-4]_alarm   Fan alarm.
>  fan[1-4]_fault   Fan fault.
> -fan[1-4]_input   Fan RPM.
> +fan[1-8]_input   Fan RPM. On the MAX31785A, inputs 5-8 
> correspond to the
> + second rotor of fans 1-4
>  fan[1-4]_target  Fan input target
>  
>  in[1-6]_crit Critical maximum output voltage
> diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
> index 0d97ddf67079..2ca7febb2843 100644
> --- a/drivers/hwmon/pmbus/max31785.c
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -16,10 +16,82 @@
>  
>  enum max31785_regs {
>   MFR_REVISION= 0x9b,
> + MFR_FAN_CONFIG  = 0xf1,
>  };
>  
> +#define MAX31785 0x3030
> +#define MAX31785A0x3040
> +
> +#define MFR_FAN_CONFIG_DUAL_TACH BIT(12)
> +
>  #define MAX31785_NR_PAGES23
>  
> +static int max31785_read_byte_data(struct i2c_client *client, int page,
> +int reg)
> +{
> + switch (reg) {
> + case PMBUS_VOUT_MODE:
> + if (page < MAX31785_NR_PAGES)
> + return -ENODATA;
> +
> + return -ENOTSUPP;
> + case PMBUS_FAN_CONFIG_12:
> + if (page < MAX31785_NR_PAGES)
> + return -ENODATA;
> +
> + return pmbus_read_byte_data(client, page - MAX31785_NR_PAGES,
> + reg);
> + }
> +
> + return -ENODATA;
> +}
> +
> +static int max31785_write_byte(struct i2c_client *client, int page, u8 value)
> +{
> + if (page < MAX31785_NR_PAGES)
> + return -ENODATA;
> +
> + return -ENOTSUPP;
> +}
> +
> +static int max31785_read_long_data(struct i2c_client *client, int page,
> +int reg, u32 *data)
> +{
> + unsigned char cmdbuf[1];
> + unsigned char rspbuf[4];
> + int rc;
> +
> + struct i2c_msg msg[2] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .len = sizeof(cmdbuf),
> + .buf = cmdbuf,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = sizeof(rspbuf),
> + .buf = rspbuf,
> + },
> + };
> +
> + cmdbuf[0] = reg;
> +
> + rc = pmbus_set_page(client, page);
> + if (rc < 0)
> + return rc;
> +
> + rc = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
> + if (rc < 0)
> + return rc;
> +
> + *data = (rspbuf[0] << (0 * 8)) | (rspbuf[1] << (1 * 8)) |
> + (rspbuf[2] << (2 * 8)) | (rspbuf[3] << (3 * 8));
> +
> + return rc;
> +}
> +
>  static int max31785_get_pwm(struct i2c_client *client, int page)
>  {
> 

Re: [v4,3/6] pmbus: core: Add fan control support

[Guenter Roeck]

On Fri, Nov 03, 2017 at 03:53:03PM +1100, Andrew Jeffery wrote:
> Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
> 
> Fans in a PMBus device are driven by the configuration of two registers:
> FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
> and the tacho operate (if installed), while FAN_COMMAND_x sets the
> desired fan rate. The unit of FAN_COMMAND_x is dependent on the
> operational fan mode, RPM or PWM percent duty, as determined by the
> corresponding FAN_CONFIG_x_y.
> 
> The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
> FAN_COMMAND_x is implemented with the addition of virtual registers and
> generic implementations in the core:
> 
> 1. PMBUS_VIRT_FAN_TARGET_x
> 2. PMBUS_VIRT_PWM_x
> 3. PMBUS_VIRT_PWM_ENABLE_x
> 
> The virtual registers facilitate the necessary side-effects of each
> access. Examples of the read case, assuming m = 1, b = 0, R = 0:
> 
>  Read |  With  || Gives
>  ---
>Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
>  --++---
>   fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
>   pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
>   pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
>   fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
>   pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
>   pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1
> 
> And the write case:
> 
>  Write| With  ||   Sets
>  -+---+++---
>Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
>  -+---+++---
>   fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
>   pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
>   pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064
> 
> Also, the DIRECT mode scaling of some controllers is different between
> RPM and PWM percent duty control modes, so PSC_PWM is introduced to
> capture the necessary coefficients.
> 
> Signed-off-by: Andrew Jeffery 
> ---
>  drivers/hwmon/pmbus/pmbus.h  |  29 +
>  drivers/hwmon/pmbus/pmbus_core.c | 224 
> ---
>  2 files changed, 238 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> index 4efa2bd4f6d8..cdf3e288e626 100644
> --- a/drivers/hwmon/pmbus/pmbus.h
> +++ b/drivers/hwmon/pmbus/pmbus.h
> @@ -190,6 +190,28 @@ enum pmbus_regs {
>   PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
>   PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
>   PMBUS_VIRT_STATUS_VMON,
> +
> + /*
> +  * RPM and PWM Fan control
> +  *
> +  * Drivers wanting to expose PWM control must define the behaviour of
> +  * PMBUS_VIRT_PWM_ENABLE_[1-4] in the {read,write}_word_data callback.
> +  *
> +  * pmbus core provides default implementations for
> +  * PMBUS_VIRT_FAN_TARGET_[1-4] and PMBUS_VIRT_PWM_[1-4].
> +  */
> + PMBUS_VIRT_FAN_TARGET_1,
> + PMBUS_VIRT_FAN_TARGET_2,
> + PMBUS_VIRT_FAN_TARGET_3,
> + PMBUS_VIRT_FAN_TARGET_4,
> + PMBUS_VIRT_PWM_1,
> + PMBUS_VIRT_PWM_2,
> + PMBUS_VIRT_PWM_3,
> + PMBUS_VIRT_PWM_4,
> + PMBUS_VIRT_PWM_ENABLE_1,
> + PMBUS_VIRT_PWM_ENABLE_2,
> + PMBUS_VIRT_PWM_ENABLE_3,
> + PMBUS_VIRT_PWM_ENABLE_4,
>  };
>  
>  /*
> @@ -223,6 +245,8 @@ enum pmbus_regs {
>  #define PB_FAN_1_RPM BIT(6)
>  #define PB_FAN_1_INSTALLED   BIT(7)
>  
> +enum pmbus_fan_mode { percent = 0, rpm };
> +
>  /*
>   * STATUS_BYTE, STATUS_WORD (lower)
>   */
> @@ -313,6 +337,7 @@ enum pmbus_sensor_classes {
>   PSC_POWER,
>   PSC_TEMPERATURE,
>   PSC_FAN,
> + PSC_PWM,
>   PSC_NUM_CLASSES /* Number of power sensor classes */
>  };
>  
> @@ -339,6 +364,8 @@ enum pmbus_sensor_classes {
>  #define PMBUS_HAVE_STATUS_FAN34  BIT(17)
>  #define PMBUS_HAVE_VMON  BIT(18)
>  #define PMBUS_HAVE_STATUS_VMON   BIT(19)
> +#define PMBUS_HAVE_PWM12 BIT(20)
> +#define PMBUS_HAVE_PWM34 BIT(21)
>  
>  enum pmbus_data_format { linear = 0, direct, vid };
>  enum vrm_version { vr11 = 0, vr12, vr13 };
> @@ -413,6 +440,8 @@ int pmbus_write_byte_data(struct i2c_client *client, int 
> page, u8 reg,
> u8 value);
>  int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
>  u8 mask, u8 value);
> +int pmbus_update_fan(struct i2c_client *client, int page, int id,
> +  u8 config, u8 mask, u16 command);
>  void pmbus_clear_faults(struct i2c_client *client);
>  bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
>  bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
> diff --git 

Re: [v4, 2/6] pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller

[Guenter Roeck]

On Fri, Nov 03, 2017 at 03:53:02PM +1100, Andrew Jeffery wrote:
> The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
> management with temperature and remote voltage sensing. Various fan control
> features are provided, including PWM frequency control, temperature 
> hysteresis,
> dual tachometer measurements, and fan health monitoring.
> 
I updated the above text a little to make it more obvious that "are provided"
refers to the chip, not (yet) to the driver.

> This patch presents a basic driver using only the existing features of the
> PMBus subsystem.
> 
> Signed-off-by: Andrew Jeffery 

Applied to hwmon-next.

> ---
>  Documentation/hwmon/max31785   |  51 ++
>  drivers/hwmon/pmbus/Kconfig|  10 
>  drivers/hwmon/pmbus/Makefile   |   1 +
>  drivers/hwmon/pmbus/max31785.c | 116 
> +
>  4 files changed, 178 insertions(+)
>  create mode 100644 Documentation/hwmon/max31785
>  create mode 100644 drivers/hwmon/pmbus/max31785.c
> 
> diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
> new file mode 100644
> index ..45fb6093dec2
> --- /dev/null
> +++ b/Documentation/hwmon/max31785
> @@ -0,0 +1,51 @@
> +Kernel driver max31785
> +==
> +
> +Supported chips:
> +  * Maxim MAX31785, MAX31785A
> +Prefix: 'max31785' or 'max31785a'
> +Addresses scanned: -
> +Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
> +
> +Author: Andrew Jeffery 
> +
> +Description
> +---
> +
> +The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
> +management with temperature and remote voltage sensing. Various fan control
> +features are provided, including PWM frequency control, temperature 
> hysteresis,
> +dual tachometer measurements, and fan health monitoring.
> +
> +For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of 
> the
> +two in the fan[1-4]_input attributes.
> +
> +Usage Notes
> +---
> +
> +This driver does not probe for PMBus devices. You will have to instantiate
> +devices explicitly.
> +
> +Sysfs attributes
> +
> +
> +fan[1-4]_alarm   Fan alarm.
> +fan[1-4]_fault   Fan fault.
> +fan[1-4]_input   Fan RPM.
> +
> +in[1-6]_crit Critical maximum output voltage
> +in[1-6]_crit_alarm   Output voltage critical high alarm
> +in[1-6]_inputMeasured output voltage
> +in[1-6]_label"vout[18-23]"
> +in[1-6]_lcritCritical minimum output voltage
> +in[1-6]_lcrit_alarm  Output voltage critical low alarm
> +in[1-6]_max  Maximum output voltage
> +in[1-6]_max_alarmOutput voltage high alarm
> +in[1-6]_min  Minimum output voltage
> +in[1-6]_min_alarmOutput voltage low alarm
> +
> +temp[1-11]_crit  Critical high temperature
> +temp[1-11]_crit_alarmChip temperature critical high alarm
> +temp[1-11]_input Measured temperature
> +temp[1-11]_max   Maximum temperature
> +temp[1-11]_max_alarm Chip temperature high alarm
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 40019325b517..08479006c7f9 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -114,6 +114,16 @@ config SENSORS_MAX20751
> This driver can also be built as a module. If so, the module will
> be called max20751.
>  
> +config SENSORS_MAX31785
> + tristate "Maxim MAX31785 and compatibles"
> + default n
> + help
> +   If you say yes here you get hardware monitoring support for Maxim
> +   MAX31785.
> +
> +   This driver can also be built as a module. If so, the module will
> +   be called max31785.
> +
>  config SENSORS_MAX34440
>   tristate "Maxim MAX34440 and compatibles"
>   default n
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 459a6be3390e..a8bf0e490db9 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_LTC2978)   += ltc2978.o
>  obj-$(CONFIG_SENSORS_LTC3815)+= ltc3815.o
>  obj-$(CONFIG_SENSORS_MAX16064)   += max16064.o
>  obj-$(CONFIG_SENSORS_MAX20751)   += max20751.o
> +obj-$(CONFIG_SENSORS_MAX31785)   += max31785.o
>  obj-$(CONFIG_SENSORS_MAX34440)   += max34440.o
>  obj-$(CONFIG_SENSORS_MAX8688)+= max8688.o
>  obj-$(CONFIG_SENSORS_TPS40422)   += tps40422.o
> diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
> new file mode 100644
> index ..9313849d5160
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -0,0 +1,116 @@
> +/*
> + * Copyright (C) 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; 

Re: [7/8] Documentation: fix selftests related file refs

[Guenter Roeck]

On Thu, Oct 12, 2017 at 03:24:10PM -0500, Tom Saeger wrote:
> Make refs to selftests files valid including:
>   - watchdog-test.c
>   - dnotify_test.c
> 
> Signed-off-by: Tom Saeger <tom.sae...@oracle.com>
> Signed-off-by: Jerry Hoemann <jerry.hoem...@hpe.com>

That should have been a Reviewed-by: for the hpwdt code.

Otherwise

Reviewed-by: Guenter Roeck <li...@roeck-us.net>

> ---
>  Documentation/filesystems/dnotify.txt| 2 +-
>  Documentation/watchdog/hpwdt.txt | 2 +-
>  Documentation/watchdog/pcwd-watchdog.txt | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/filesystems/dnotify.txt 
> b/Documentation/filesystems/dnotify.txt
> index 6baf88f46859..15156883d321 100644
> --- a/Documentation/filesystems/dnotify.txt
> +++ b/Documentation/filesystems/dnotify.txt
> @@ -62,7 +62,7 @@ disabled, fcntl(fd, F_NOTIFY, ...) will return -EINVAL.
>  
>  Example
>  ---
> -See Documentation/filesystems/dnotify_test.c for an example.
> +See tools/testing/selftests/filesystems/dnotify_test.c for an example.
>  
>  NOTE
>  
> diff --git a/Documentation/watchdog/hpwdt.txt 
> b/Documentation/watchdog/hpwdt.txt
> index 7a9f635d0258..6d866c537127 100644
> --- a/Documentation/watchdog/hpwdt.txt
> +++ b/Documentation/watchdog/hpwdt.txt
> @@ -15,7 +15,7 @@ Last reviewed: 05/20/2016
>  
>   Watchdog functionality is enabled like any other common watchdog driver. 
> That
>   is, an application needs to be started that kicks off the watchdog timer. A
> - basic application exists in the Documentation/watchdog/src directory called
> + basic application exists in tools/testing/selftests/watchdog/ named
>   watchdog-test.c. Simply compile the C file and kick it off. If the system
>   gets into a bad state and hangs, the HPE ProLiant iLO timer register will
>   not be updated in a timely fashion and a hardware system reset (also known 
> as
> diff --git a/Documentation/watchdog/pcwd-watchdog.txt 
> b/Documentation/watchdog/pcwd-watchdog.txt
> index 4f68052395c0..b8e60a441a43 100644
> --- a/Documentation/watchdog/pcwd-watchdog.txt
> +++ b/Documentation/watchdog/pcwd-watchdog.txt
> @@ -25,7 +25,7 @@ Last reviewed: 10/05/2007
>  
>   If you want to write a program to be compatible with the PC Watchdog
>   driver, simply use of modify the watchdog test program:
> - Documentation/watchdog/src/watchdog-test.c
> + tools/testing/selftests/watchdog/watchdog-test.c
>  
>  
>   Other IOCTL functions include:
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] dt-bindings: hwmon: Add ti-max-expected-current-microamp property to ina2xx

[Guenter Roeck]

On Tue, Oct 17, 2017 at 03:36:31PM -0500, Rob Herring wrote:
> On Thu, Oct 12, 2017 at 02:36:04PM +0200, Maciej Purski wrote:
> > Add optional max expected current property which allows calibrating
> > the ina sensor in order to achieve requested measure scale. Document
> > the changes in Documentation/hwmon/ina2xx.
> > 
> > Signed-off-by: Maciej Purski 
> > ---
> >  Documentation/devicetree/bindings/hwmon/ina2xx.txt | 4 +++-
> >  Documentation/hwmon/ina2xx | 3 +++
> >  2 files changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/ina2xx.txt 
> > b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
> > index 02af0d9..49ef0be 100644
> > --- a/Documentation/devicetree/bindings/hwmon/ina2xx.txt
> > +++ b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
> > @@ -14,11 +14,13 @@ Optional properties:
> >  
> >  - shunt-resistor
> > Shunt resistor value in micro-Ohm
> > -
> > +- ti-max-expected-current-microamp
> > +   Max expected current value in mA
> 
> ti,max-...
> 
> The property name is a bit long. Does "expected" add anything? Is there 
> a max unexpected current?
> 
I am not too happy with it either. To me it suggests that there _can_ be
an unexpected current (why specify a max _expected_ current otherwise ?),
and that unexpected current won't be measurable and thus not reported
because it is ... well, unexpected.

Guenter

> >  Example:
> >  
> >  ina220@44 {
> > compatible = "ti,ina220";
> > reg = <0x44>;
> > shunt-resistor = <1000>;
> > +   ti-max-expected-current-microamp = <3000>;
> >  };
> > diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
> > index cfd31d9..30620e8 100644
> > --- a/Documentation/hwmon/ina2xx
> > +++ b/Documentation/hwmon/ina2xx
> > @@ -55,6 +55,9 @@ The shunt value in micro-ohms can be set via platform 
> > data or device tree at
> >  compile-time or via the shunt_resistor attribute in sysfs at run-time. 
> > Please
> >  refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
> >  if the device tree is used.
> > +The max expected current value in miliamp can be set via platform data
> > +or device tree at compile-time or via currX_max attribute in sysfs
> > +at run-time.
> >  
> >  Additionally ina226 supports update_interval attribute as described in
> >  Documentation/hwmon/sysfs-interface. Internally the interval is the sum of
> > -- 
> > 2.7.4
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] dt-bindings: hwmon: Add ti-max-expected-current-microamp property to ina2xx

[Guenter Roeck]

On 10/12/2017 06:00 AM, Maciej Purski wrote:



On 10/12/2017 02:39 PM, Krzysztof Kozlowski wrote:

On Thu, Oct 12, 2017 at 2:36 PM, Maciej Purski  wrote:

Add optional max expected current property which allows calibrating
the ina sensor in order to achieve requested measure scale. Document
the changes in Documentation/hwmon/ina2xx.

Signed-off-by: Maciej Purski 
---
  Documentation/devicetree/bindings/hwmon/ina2xx.txt | 4 +++-
  Documentation/hwmon/ina2xx | 3 +++
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/hwmon/ina2xx.txt 
b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
index 02af0d9..49ef0be 100644
--- a/Documentation/devicetree/bindings/hwmon/ina2xx.txt
+++ b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
@@ -14,11 +14,13 @@ Optional properties:

  - shunt-resistor
 Shunt resistor value in micro-Ohm
-
+- ti-max-expected-current-microamp
+   Max expected current value in mA
  Example:

  ina220@44 {
 compatible = "ti,ina220";
 reg = <0x44>;
 shunt-resistor = <1000>;
+   ti-max-expected-current-microamp = <3000>;
  };
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index cfd31d9..30620e8 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -55,6 +55,9 @@ The shunt value in micro-ohms can be set via platform data or 
device tree at
  compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
  refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
  if the device tree is used.
+The max expected current value in miliamp can be set via platform data


mili or micro?

BR,
Krzysztof


Sorry, these should be mili everywhere. I'll fix this.



You sure ? I think DT usually uses micro.

Guenter




+or device tree at compile-time or via currX_max attribute in sysfs
+at run-time.

  Additionally ina226 supports update_interval attribute as described in
  Documentation/hwmon/sysfs-interface. Internally the interval is the sum of
--
2.7.4









--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] kbuild: Cache exploratory calls to the compiler

[Guenter Roeck]

On Wed, Oct 4, 2017 at 3:37 PM, Douglas Anderson <diand...@chromium.org> wrote:
> This two-patch series attempts to speed incremental builds of the
> kernel up by a bit.  How much of a speedup you get depends a lot on
> your environment, specifically the speed of your workstation and how
> fast it takes to invoke the compiler.
>
> In the Chrome OS build environment you get a really big win.  For an
> incremental build (via emerge) I measured a speedup from ~1 minute to
> ~35 seconds.  ...but Chrome OS calls the compiler through a number of
> wrapper scripts and also calls the kernel make at least twice for an
> emerge (during compile stage and install stage), so it's a bit of a
> worst case.
>
> Perhaps a more realistic measure of the speedup others might see is
> running "time make help > /dev/null" outside of the Chrome OS build
> environment on my system.  When I do this I see that it took more than
> 1.0 seconds before and less than 0.2 seconds after.  So presumably
> this has the ability to shave ~0.8 seconds off an incremental build
> for most folks out there.  While 0.8 seconds savings isn't huge, it
> does make incremental builds feel a lot snappier.
>
> Caveats from v1 still copied here, though with Masahiro Yamada's
> suggestions from v1 this is starting to feel a little more baked and
> I've even dropped the RFC from it (though extra testing still
> appreciated):
>
> Please note that I make no illusions of being a Makefile expert nor do
> I have any belief that I fully understand the Linux kernel build
> system.  Please take this patch series as the start of a discussion
> about whether others feel like this type of speedup is worthwhile and
> how to best accomplish it.  Specific things to note:
>
> - I'm happy to paint the bikeshed any color that maintainers want.  If
>   you'd like the cache named differently, in a slightly different
>   format, or you want me to adjust the spacing / names of Makefile
>   stuff then please just let me know.
>
> - If this is totally the wrong approach and you have a better idea
>   then let me know.  If you want something that's super complicated to
>   explain then feel free to post a replacement patch and I'm happy to
>   test.
>
> - This patch definitely needs extra testing.  I've tested it on a very
>   limited build environment and it seems to be working fine, but I
>   could believe that with some weird compiler options or on certain
>   architectures you might need some extra escaping here and there.
>

Not being a makefile expert, I can't say anything about the merits of
this series. However, it does pass a run on my test farm at
kerneltests.org. So. I'll give it a

Tested-by: Guenter Roeck <li...@roeck-us.net>

Guenter

> Changes in v2:
> - Abstract at a different level (like shell-cached) per Masahiro Yamada
> - Include ld-version, which I missed the first time
>
> Douglas Anderson (2):
>   kbuild: Add a cache for generated variables
>   kbuild: Cache a few more calls to the compiler
>
>  Documentation/kbuild/makefiles.txt | 21 +
>  Makefile   |  4 +-
>  scripts/Kbuild.include | 90 
> --
>  3 files changed, 99 insertions(+), 16 deletions(-)
>
> --
> 2.14.2.920.gcf0c67979c-goog
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] hwmon: (ina2xx) Make max expected current configurable

[Guenter Roeck]

On 09/28/2017 05:50 AM, Maciej Purski wrote:

Max expected current is used for calculating calibration register value,
Current LSB and Power LSB according to equations found in ina datasheet.
Max expected current is now implicitly set to default value,
which is 2^15, thanks to which Current LSB is equal to 1 mA and
Power LSB is equal to 2 uW or 25000 uW depending on ina model.

Make max expected current configurable, just like it's already done
with shunt resistance: from device tree, platform_data or later
from sysfs. On each max_expected_current change, calculate new values
for Current LSB and Power LSB. According to datasheet Current LSB should
be calculated by dividing max expected current by 2^15, as values read
from device registers are in this case 16-bit integers. Power LSB
is calculated by multiplying Current LSB by a factor, which is defined
in ina documentation.

Signed-off-by: Maciej Purski 
---
  drivers/hwmon/ina2xx.c | 105 +++--
  1 file changed, 93 insertions(+), 12 deletions(-)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 62e38fa..d956013 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -80,6 +80,8 @@
  /* common attrs, ina226 attrs and NULL */
  #define INA2XX_MAX_ATTRIBUTE_GROUPS   3
  
+#define INA2XX_MAX_EXPECTED_A_DEFAULT  (1 << 15)   /* current_lsb = 1 mA */

+
  /*
   * Both bus voltage and shunt voltage conversion times for ina226 are set
   * to 0b0100 on POR, which translates to 2200 microseconds in total.
@@ -100,13 +102,16 @@ struct ina2xx_config {
int shunt_div;
int bus_voltage_shift;
int bus_voltage_lsb;/* uV */
-   int power_lsb;  /* uW */
+   int power_lsb_factor;
  };
  
  struct ina2xx_data {

const struct ina2xx_config *config;
  
-	long rshunt;

+   long rshunt;/* uOhms */
+   unsigned int max_expected_current;  /* mA */
+   int current_lsb;/* uA */
+   int power_lsb;  /* uW */
struct mutex config_lock;
struct regmap *regmap;
  
@@ -121,7 +126,7 @@ static const struct ina2xx_config ina2xx_config[] = {

.shunt_div = 100,
.bus_voltage_shift = 3,
.bus_voltage_lsb = 4000,
-   .power_lsb = 2,
+   .power_lsb_factor = 20,
},
[ina226] = {
.config_default = INA226_CONFIG_DEFAULT,
@@ -130,7 +135,7 @@ static const struct ina2xx_config ina2xx_config[] = {
.shunt_div = 400,
.bus_voltage_shift = 0,
.bus_voltage_lsb = 1250,
-   .power_lsb = 25000,
+   .power_lsb_factor = 25,
},
  };
  
@@ -169,10 +174,17 @@ static u16 ina226_interval_to_reg(int interval)

return INA226_SHIFT_AVG(avg_bits);
  }
  
+/*

+ * Calculate calibration value according to equation 1 in ina226 datasheet
+ * http://www.ti.com/lit/ds/symlink/ina226.pdf.
+ * Current LSB is in uA and RShunt is in uOhms, so in order to keep
+ * calibration value scaled RShunt must be converted to mOhms.
+ */
  static int ina2xx_calibrate(struct ina2xx_data *data)
  {
+   int r_shunt = DIV_ROUND_CLOSEST(data->rshunt, 1000);
u16 val = DIV_ROUND_CLOSEST(data->config->calibration_factor,
-   data->rshunt);
+   data->current_lsb * r_shunt);
  
  	return regmap_write(data->regmap, INA2XX_CALIBRATION, val);

  }
@@ -187,13 +199,28 @@ static int ina2xx_init(struct ina2xx_data *data)
if (ret < 0)
return ret;
  
-	/*

-* Set current LSB to 1mA, shunt is in uOhms
-* (equation 13 in datasheet).
-*/
return ina2xx_calibrate(data);
  }
  
+/*

+ * Set max_expected_current (mA) and calculate current_lsb (uA),
+ * according to equation 2 in ina226 datasheet. Power LSB is calculated
+ * by multiplying Current LSB by a given factor, which may vary depending
+ * on ina version.
+ */
+static int set_max_expected_current(struct ina2xx_data *data, unsigned int val)
+{
+   if (val <= 0 || val > data->config->calibration_factor)
+   return -EINVAL;
+
+   data->max_expected_current = val;
+   data->current_lsb = DIV_ROUND_CLOSEST(data->max_expected_current * 1000,
+ 1 << 15);
+   data->power_lsb = data->current_lsb * data->config->power_lsb_factor;
+
+   return 0;
+}
+
  static int ina2xx_read_reg(struct device *dev, int reg, unsigned int *regval)
  {
struct ina2xx_data *data = dev_get_drvdata(dev);
@@ -268,11 +295,11 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8 
reg,
val = DIV_ROUND_CLOSEST(val, 1000);
break;
case INA2XX_POWER:
-   val = regval * data->config->power_lsb;
+   val = regval * 

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/07/2017 08:40 PM, Andrew Jeffery wrote:

On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:

I can't test with devicetree. x86 system.
  
2,100+ iterations with your driver, no failures.


Great. I really appreciate your testing here, so thanks for your
efforts. I owe you a few drinks if we ever happen to meet.


Actually, on that, how did you chop out the devicetree parts? Did you
keep the configuration writes at the end of max31785_of_fan_config()
and max31785_of_tmp_config()? Or did you just not call them? These two
functions cause the bulk of the bus traffic with on probe.


fan config hardcoded, four fans connected. Still no failure.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/07/2017 08:40 PM, Andrew Jeffery wrote:

On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:

I can't test with devicetree. x86 system.
  
2,100+ iterations with your driver, no failures.


Great. I really appreciate your testing here, so thanks for your
efforts. I owe you a few drinks if we ever happen to meet.


Actually, on that, how did you chop out the devicetree parts? Did you
keep the configuration writes at the end of max31785_of_fan_config()
and max31785_of_tmp_config()? Or did you just not call them? These two
functions cause the bulk of the bus traffic with on probe.



I didn't change to code, just compiled and run it. Guess that means
this part was skipped.

I'll replaced the fan configuration with some hard-coded values.
We'll see if it makes a difference.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/07/2017 07:06 PM, Andrew Jeffery wrote:

On Thu, 2017-09-07 at 18:26 -0700, Guenter Roeck wrote:

On 09/07/2017 06:02 PM, Andrew Jeffery wrote:

On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:

On 09/07/2017 08:22 AM, Andrew Jeffery wrote:

On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:

On 09/06/2017 04:32 PM, Andrew Jeffery wrote:

 
Guess I need to dig up my eval board and see if I can reproduce the problem.

Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?


Yeah. We're also seeing bad behaviour under other command sequences as well,
which lead to this hack of a work-around patch[1].

I'd be very interested in the results of testing against the eval board. I
don't have access to one and it seems Maxim have discontinued them.



Do you have a somewhat reliable means to reproduce the problem ?


It seems we hit a bunch of problems by just continually
binding/unbinding the driver, if you don't apply that hacky oneshot
retry patch. We can hit problems (in our design?) with something like:

# cd /sys/bus/i2c/drivers/max31785; \
echo $addr > unbind; \
while echo $addr > bind; \
do echo $addr > unbind; echo -n .; done;

It should hit issues covered by this patch, as the register checks are
used in the operations used by probe.



Hmm ... I didn't use your driver but my prototype driver which also supports
temperature and voltage attributes, so if anything it should create more
stress on the chip.


I did add the temp and voltage attributes...

Any chance you can give mine a try? I don't know what I would have done
to invoke this kind of behaviour, so it would be useful to know whether
or not it happens with one driver but not the other.



Will do.


Thanks. For reference, here's a devicetree description:

https://github.com/openbmc/linux/blob/dev-4.10/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts#L283



I can't test with devicetree. x86 system.

2,100+ iterations with your driver, no failures.

Either it is because my chip is a MAX31785 (not A), or the configuration makes 
a difference,
or it is your hardware.

I'll try to connect a couple of fans next (so far I did without) and try again.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/07/2017 06:02 PM, Andrew Jeffery wrote:

On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:

On 09/07/2017 08:22 AM, Andrew Jeffery wrote:

On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:

On 09/06/2017 04:32 PM, Andrew Jeffery wrote:


Guess I need to dig up my eval board and see if I can reproduce the problem.

Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?


Yeah. We're also seeing bad behaviour under other command sequences as well,
which lead to this hack of a work-around patch[1].

I'd be very interested in the results of testing against the eval board. I
don't have access to one and it seems Maxim have discontinued them.



Do you have a somewhat reliable means to reproduce the problem ?


It seems we hit a bunch of problems by just continually
binding/unbinding the driver, if you don't apply that hacky oneshot
retry patch. We can hit problems (in our design?) with something like:

# cd /sys/bus/i2c/drivers/max31785; \
echo $addr > unbind; \
while echo $addr > bind; \
do echo $addr > unbind; echo -n .; done;

It should hit issues covered by this patch, as the register checks are
used in the operations used by probe.



Hmm ... I didn't use your driver but my prototype driver which also supports
temperature and voltage attributes, so if anything it should create more
stress on the chip.


I did add the temp and voltage attributes...

Any chance you can give mine a try? I don't know what I would have done
to invoke this kind of behaviour, so it would be useful to know whether
or not it happens with one driver but not the other.



Will do.


  No error so far, after running the script for a couple
of minutes. How long does it take for errors to appear, and how do I see
that there is an error ?


I'm seeing failures after anything from a handful of bind/unbinds, to
hundreds of bind/unbinds. It seems to vary.


Does the driver fail to instantiate ?


Typically probe fails so the loop exits. It usually gets -EIO and the
shell spits out "No such device".

Thanks for testing, it's a useful data point for us hunting down the
source of our problems.


I aborted the test after ~2,500 loops without error.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/07/2017 08:22 AM, Andrew Jeffery wrote:

On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:

On 09/06/2017 04:32 PM, Andrew Jeffery wrote:

   
Guess I need to dig up my eval board and see if I can reproduce the problem.

Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?


Yeah. We're also seeing bad behaviour under other command sequences as well,
which lead to this hack of a work-around patch[1].

I'd be very interested in the results of testing against the eval board. I
don't have access to one and it seems Maxim have discontinued them.



Do you have a somewhat reliable means to reproduce the problem ?


It seems we hit a bunch of problems by just continually
binding/unbinding the driver, if you don't apply that hacky oneshot
retry patch. We can hit problems (in our design?) with something like:

# cd /sys/bus/i2c/drivers/max31785; \
echo $addr > unbind; \
while echo $addr > bind; \
do echo $addr > unbind; echo -n .; done;

It should hit issues covered by this patch, as the register checks are
used in the operations used by probe.



Hmm ... I didn't use your driver but my prototype driver which also supports
temperature and voltage attributes, so if anything it should create more
stress on the chip. No error so far, after running the script for a couple
of minutes. How long does it take for errors to appear, and how do I see
that there is an error ? Does the driver fail to instantiate ?

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/06/2017 04:32 PM, Andrew Jeffery wrote:

  
Guess I need to dig up my eval board and see if I can reproduce the problem.

Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?


Yeah. We're also seeing bad behaviour under other command sequences as well,
which lead to this hack of a work-around patch[1].

I'd be very interested in the results of testing against the eval board. I
don't have access to one and it seems Maxim have discontinued them.



Do you have a somewhat reliable means to reproduce the problem ?

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On 09/06/2017 04:32 PM, Andrew Jeffery wrote:

On Wed, 2017-09-06 at 15:51 -0700, Guenter Roeck wrote:

On Wed, Sep 06, 2017 at 10:23:37AM +1000, Andrew Jeffery wrote:

On Tue, 2017-09-05 at 10:00 -0700, Guenter Roeck wrote:

On Tue, Sep 05, 2017 at 05:01:32PM +1000, Andrew Jeffery wrote:

Some functions exposed by pmbus core conflated errors that occurred when
setting the page to access with errors that occurred when accessing
registers in a page. In some cases, this caused legitimate errors to be
hidden under the guise of the register not being supported.
  
  
I'll have to look into this. If I recall correctly, the reason for not returning

errors from the "clear faults" command was that some early chips did not support
it, or did not support it on all pages. Those chips would now always fail.
  
Yes, that is a concern.
  
However, shouldn't the lack of support for CLEAR_FAULTS be a described

property of the chip or page?
  
Regardless, the issue here is the PAGE command is sometimes failing

(more below). This means we won't have issued a CLEAR_FAULTS against
the page even if the page supports CLEAR_FAULTS. That to me is
something that should be propagated back up the call chain, as faults
that can be cleared will not have been.
  
  
We could also consider

- retry


I guess that leads to the usual retries problem: How many? Oneshot? More?

My expectation is that oneshot would be enough, but we'd still need to consider
what to do if that wasn't successful.

Does the retry policy need to be in the kernel? I guess if it's not we would
need all operations in the path to the failure to be idempotent.


- Add a marker indicating that faults (specifically command errors)
   are unreliable after clearing faults failed


What kind of marker were you thinking? Something in dmesg? If it's anything
else we'd probably want something to respond to the condition, which nothing
would do currently.

  
If we can't reliably clear faults, all bets are off.


Yeah, it's a messy problem. However even if we resolve our issues in hardware
(i.e. it's discovered that it is a design failure or something), I don't think
we should drop a resolution to the problem highlighted by this patch.

  
  
On a higher level, I am not sure if it is a good idea to return an error

from a function intended to clear faults (and nothing else). That seems
counterproductive.
  
Is this a problem you have actually observed ?
  
Unfortunately yes. I was trying to reproduce some issues that we are

seeing in userspace but wasn't having much luck (getting -EIO on
reading a hwmon attribute). I ended up instrumenting our I2C bus
driver, and found that the problem was more prevalent than what the
read failures in userspace were indicating. The paths that were
triggering these unreported conditions all traced through the check
register and clear fault functions, which on analysis were swallowing
the error.
  

If so, what is the chip ?
  
Well, the chip that I'm *communicating* with is the Maxim MAX31785

Intelligent Fan Controller. As to whether that's what is *causing* the
PAGE command to fail is still up in the air. I would not be surprised
if we have other issues in the hardware design.
  
I haven't sent a follow-up to the series introducing the MAX31785

driver because I've been chasing down communication issues. I felt it
was important to understand whether the device has quirks that need to
be worked around in the driver, or if our hardware design has bigger
problems that should be handled in other ways. I've been in touch with
Maxim who have asserted that some of the problems we're seeing cannot
be caused by their chip.
  
  
Guess I need to dig up my eval board and see if I can reproduce the problem.

Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?


Yeah. We're also seeing bad behaviour under other command sequences as well,
which lead to this hack of a work-around patch[1].

I'd be very interested in the results of testing against the eval board. I
don't have access to one and it seems Maxim have discontinued them.

[1] https://patchwork.kernel.org/patch/9876083/

  
The MAX31785 is microcode based, so I would not be entirely surprised if

it sometimes fails to reply if a sequence of 
commands is executed.


Have you seen this behaviour in other microcode-based chips?



ltc2978 (commit e04d1ce9bbb) and most of the Zilker Labs chips (zl6100.c).

You could try the approach I used in the zl6100 driver: Add a minimum time
between accesses to the chip. I would probably no longer use udelay(), though,
but usleeep_range(), if I were to implement the code today.

  
If possible, you might try reducing the i2c clock. I have not seen that with

Maxim chips, but some other PMBus chips don't operate reliably at 400 KHz.


It's already running at 100kHz, which is the maximum clock rate the device is
specified for. I've even underclocked the bus to 75kH

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On Wed, Sep 06, 2017 at 10:23:37AM +1000, Andrew Jeffery wrote:
> On Tue, 2017-09-05 at 10:00 -0700, Guenter Roeck wrote:
> > On Tue, Sep 05, 2017 at 05:01:32PM +1000, Andrew Jeffery wrote:
> > > Some functions exposed by pmbus core conflated errors that occurred when
> > > setting the page to access with errors that occurred when accessing
> > > registers in a page. In some cases, this caused legitimate errors to be
> > > hidden under the guise of the register not being supported.
> > > 
> > 
> > I'll have to look into this. If I recall correctly, the reason for not 
> > returning
> > errors from the "clear faults" command was that some early chips did not 
> > support
> > it, or did not support it on all pages. Those chips would now always fail.
> 
> Yes, that is a concern.
> 
> However, shouldn't the lack of support for CLEAR_FAULTS be a described
> property of the chip or page?
> 
> Regardless, the issue here is the PAGE command is sometimes failing
> (more below). This means we won't have issued a CLEAR_FAULTS against
> the page even if the page supports CLEAR_FAULTS. That to me is
> something that should be propagated back up the call chain, as faults
> that can be cleared will not have been.
> 
We could also consider
- retry
- Add a marker indicating that faults (specifically command errors)
  are unreliable after clearing faults failed

If we can't reliably clear faults, all bets are off.

> > 
> > On a higher level, I am not sure if it is a good idea to return an error
> > from a function intended to clear faults (and nothing else). That seems
> > counterproductive.
> > 
> > Is this a problem you have actually observed ? 
> 
> Unfortunately yes. I was trying to reproduce some issues that we are
> seeing in userspace but wasn't having much luck (getting -EIO on
> reading a hwmon attribute). I ended up instrumenting our I2C bus
> driver, and found that the problem was more prevalent than what the
> read failures in userspace were indicating. The paths that were
> triggering these unreported conditions all traced through the check
> register and clear fault functions, which on analysis were swallowing
> the error.
> 
> > If so, what is the chip ?
> 
> Well, the chip that I'm *communicating* with is the Maxim MAX31785
> Intelligent Fan Controller. As to whether that's what is *causing* the
> PAGE command to fail is still up in the air. I would not be surprised
> if we have other issues in the hardware design.
> 
> I haven't sent a follow-up to the series introducing the MAX31785
> driver because I've been chasing down communication issues. I felt it
> was important to understand whether the device has quirks that need to
> be worked around in the driver, or if our hardware design has bigger
> problems that should be handled in other ways. I've been in touch with
> Maxim who have asserted that some of the problems we're seeing cannot
> be caused by their chip.
> 

Guess I need to dig up my eval board and see if I can reproduce the problem.
Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?

The MAX31785 is microcode based, so I would not be entirely surprised if
it sometimes fails to reply if a sequence of 
commands is executed.

If possible, you might try reducing the i2c clock. I have not seen that with
Maxim chips, but some other PMBus chips don't operate reliably at 400 KHz.

Guenter

> > 
> > > > > Signed-off-by: Andrew Jeffery <and...@aj.id.au>
> > > ---
> > >  Documentation/hwmon/pmbus-core   |  12 ++--
> > >  drivers/hwmon/pmbus/pmbus.h  |   6 +-
> > >  drivers/hwmon/pmbus/pmbus_core.c | 115 
> > > +--
> > >  3 files changed, 95 insertions(+), 38 deletions(-)
> > > 
> > > diff --git a/Documentation/hwmon/pmbus-core 
> > > b/Documentation/hwmon/pmbus-core
> > > index 8ed10e9ddfb5..3e9f41bb756f 100644
> > > --- a/Documentation/hwmon/pmbus-core
> > > +++ b/Documentation/hwmon/pmbus-core
> > > @@ -218,17 +218,17 @@ Specifically, it provides the following information.
> > >    This function calls the device specific write_byte function if defined.
> > >    Therefore, it must _not_ be called from that function.
> > >  
> > > -  bool pmbus_check_byte_register(struct i2c_client *client, int page, 
> > > int reg);
> > > +  int pmbus_check_byte_register(struct i2c_client *client, int page, int 
> > > reg);
> > >  
> > > -  Check if byte register exists. Return true if the register exists, 
> > > false
&g

Re: [PATCH] hwmon: pmbus: Make reg check and clear faults functions return errors

[Guenter Roeck]

On Tue, Sep 05, 2017 at 05:01:32PM +1000, Andrew Jeffery wrote:
> Some functions exposed by pmbus core conflated errors that occurred when
> setting the page to access with errors that occurred when accessing
> registers in a page. In some cases, this caused legitimate errors to be
> hidden under the guise of the register not being supported.
> 

I'll have to look into this. If I recall correctly, the reason for not returning
errors from the "clear faults" command was that some early chips did not support
it, or did not support it on all pages. Those chips would now always fail.

On a higher level, I am not sure if it is a good idea to return an error
from a function intended to clear faults (and nothing else). That seems
counterproductive.

Is this a problem you have actually observed ? If so, what is the chip ?

Thanks,
Guenter

> Signed-off-by: Andrew Jeffery 
> ---
>  Documentation/hwmon/pmbus-core   |  12 ++--
>  drivers/hwmon/pmbus/pmbus.h  |   6 +-
>  drivers/hwmon/pmbus/pmbus_core.c | 115 
> +--
>  3 files changed, 95 insertions(+), 38 deletions(-)
> 
> diff --git a/Documentation/hwmon/pmbus-core b/Documentation/hwmon/pmbus-core
> index 8ed10e9ddfb5..3e9f41bb756f 100644
> --- a/Documentation/hwmon/pmbus-core
> +++ b/Documentation/hwmon/pmbus-core
> @@ -218,17 +218,17 @@ Specifically, it provides the following information.
>This function calls the device specific write_byte function if defined.
>Therefore, it must _not_ be called from that function.
>  
> -  bool pmbus_check_byte_register(struct i2c_client *client, int page, int 
> reg);
> +  int pmbus_check_byte_register(struct i2c_client *client, int page, int 
> reg);
>  
> -  Check if byte register exists. Return true if the register exists, false
> -  otherwise.
> +  Check if byte register exists. Returns 1 if the register exists, 0 if it 
> does
> +  not, and less than zero on an unexpected error.
>This function calls the device specific write_byte function if defined to
>obtain the chip status. Therefore, it must _not_ be called from that 
> function.
>  
> -  bool pmbus_check_word_register(struct i2c_client *client, int page, int 
> reg);
> +  int pmbus_check_word_register(struct i2c_client *client, int page, int 
> reg);
>  
> -  Check if word register exists. Return true if the register exists, false
> -  otherwise.
> +  Check if word register exists. Returns 1 if the register exists, 0 if it 
> does
> +  not, and less than zero on an unexpected error.
>This function calls the device specific write_byte function if defined to
>obtain the chip status. Therefore, it must _not_ be called from that 
> function.
>  
> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> index bfcb13bae34b..c53032a04a6f 100644
> --- a/drivers/hwmon/pmbus/pmbus.h
> +++ b/drivers/hwmon/pmbus/pmbus.h
> @@ -413,9 +413,9 @@ int pmbus_write_byte_data(struct i2c_client *client, int 
> page, u8 reg,
> u8 value);
>  int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
>  u8 mask, u8 value);
> -void pmbus_clear_faults(struct i2c_client *client);
> -bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
> -bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
> +int pmbus_clear_faults(struct i2c_client *client);
> +int pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
> +int pmbus_check_word_register(struct i2c_client *client, int page, int reg);
>  int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
>  struct pmbus_driver_info *info);
>  int pmbus_do_remove(struct i2c_client *client);
> diff --git a/drivers/hwmon/pmbus/pmbus_core.c 
> b/drivers/hwmon/pmbus/pmbus_core.c
> index f1eff6b6c798..153700e35431 100644
> --- a/drivers/hwmon/pmbus/pmbus_core.c
> +++ b/drivers/hwmon/pmbus/pmbus_core.c
> @@ -304,18 +304,24 @@ static int _pmbus_read_byte_data(struct i2c_client 
> *client, int page, int reg)
>   return pmbus_read_byte_data(client, page, reg);
>  }
>  
> -static void pmbus_clear_fault_page(struct i2c_client *client, int page)
> +static int pmbus_clear_fault_page(struct i2c_client *client, int page)
>  {
> - _pmbus_write_byte(client, page, PMBUS_CLEAR_FAULTS);
> + return _pmbus_write_byte(client, page, PMBUS_CLEAR_FAULTS);
>  }
>  
> -void pmbus_clear_faults(struct i2c_client *client)
> +int pmbus_clear_faults(struct i2c_client *client)
>  {
>   struct pmbus_data *data = i2c_get_clientdata(client);
> + int rv;
>   int i;
>  
> - for (i = 0; i < data->info->pages; i++)
> - pmbus_clear_fault_page(client, i);
> + for (i = 0; i < data->info->pages; i++) {
> + rv = pmbus_clear_fault_page(client, i);
> + if (rv)
> + return rv;
> + }
> +
> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(pmbus_clear_faults);
>  
> @@ 

Re: [PATCH 2/2] hwmon: (ucd9000) Add sysfs attribute to clear logged faults

[Guenter Roeck]

On Wed, Aug 30, 2017 at 01:55:36PM -0500, Christopher Bostic wrote:
> Add ability to clear logged faults via sysfs.
> 
I am not in favor of such chip specific commands, in this case for several
reasons (besides it being a non-standard attribute).

The logged faults are not read or used by the driver in the first place.
Clearing them doesn't add any benefit for the driver.

The command as written only clears non-paged logged faults, but no paged
faults.

While PMBus "lingo" talks of faults, those are really often just status bits,
not "faults" from hwmon perspective.

The content of the various fault bits and bites is highly chip specific.
On top of that, each chip supported by the driver has different fault bits
and bytes.

To read the logged faults you have to access the chip directly, not through
the driver. I don't see the benefit of providing a sysfs attribute to clear
non-paged logged faults, but not doing anything else with it.

If you want to do something special with those faults (or status bits/nytes),
it might be more appropriate to create debugfs entries.

Thanks,
Guenter

> Signed-off-by: Christopher Bostic 
> ---
>  drivers/hwmon/pmbus/ucd9000.c | 45 
> ++-
>  1 file changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/pmbus/ucd9000.c b/drivers/hwmon/pmbus/ucd9000.c
> index b74dbec..8bd8cb1 100644
> --- a/drivers/hwmon/pmbus/ucd9000.c
> +++ b/drivers/hwmon/pmbus/ucd9000.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "pmbus.h"
>  
>  enum chips { ucd9000, ucd90120, ucd90124, ucd90160, ucd9090, ucd90910 };
> @@ -35,6 +37,7 @@
>  #define UCD9000_NUM_PAGES0xd6
>  #define UCD9000_FAN_CONFIG_INDEX 0xe7
>  #define UCD9000_FAN_CONFIG   0xe8
> +#define UCD9000_LOGGED_FAULTS0xea
>  #define UCD9000_DEVICE_ID0xfd
>  
>  #define UCD9000_MON_TYPE(x)  (((x) >> 5) & 0x07)
> @@ -109,6 +112,36 @@ static int ucd9000_read_byte_data(struct i2c_client 
> *client, int page, int reg)
>   return ret;
>  }
>  
> +static ssize_t ucd9000_clear_logged_faults(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + int ret;
> +
> + /* No page set required */
> + ret = i2c_smbus_write_byte_data(client, UCD9000_LOGGED_FAULTS, 0);
> + if (ret) {
> + dev_err(>dev, "Failed to clear logged faults: %d\n",
> + ret);
> + return ret;
> + }
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(clear_logged_faults, 0200, NULL,
> + ucd9000_clear_logged_faults);
> +
> +static struct attribute *ucd9000_attributes[] = {
> + _attr_clear_logged_faults.attr,
> + NULL
> +};
> +
> +static const struct attribute_group ucd9000_attr_group = {
> + .attrs = ucd9000_attributes,
> +};
> +
>  static const struct i2c_device_id ucd9000_id[] = {
>   {"ucd9000", ucd9000},
>   {"ucd90120", ucd90120},
> @@ -263,9 +296,19 @@ static int ucd9000_probe(struct i2c_client *client,
> | PMBUS_HAVE_FAN34 | PMBUS_HAVE_STATUS_FAN34;
>   }
>  
> + ret = sysfs_create_group(>dev.kobj, _attr_group);
> + if (ret < 0)
> + return ret;
> +
>   return pmbus_do_probe(client, mid, info);
>  }
>  
> +static int ucd9000_remove(struct i2c_client *client)
> +{
> + sysfs_remove_group(>dev.kobj, _attr_group);
> + return pmbus_do_remove(client);
> +}
> +
>  /* This is the driver that will be inserted */
>  static struct i2c_driver ucd9000_driver = {
>   .driver = {
> @@ -273,7 +316,7 @@ static int ucd9000_probe(struct i2c_client *client,
>   .of_match_table = of_match_ptr(ucd9000_of_match),
>   },
>   .probe = ucd9000_probe,
> - .remove = pmbus_do_remove,
> + .remove = ucd9000_remove,
>   .id_table = ucd9000_id,
>  };
>  
> -- 
> 1.8.2.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2/2] hwmon: (pmbus/lm25066) Add support for TI LM5066I

[Guenter Roeck]

On Tue, Aug 29, 2017 at 02:21:17PM -0700, Xo Wang wrote:
> The TI LM5066I hotswap controller is a more accurate version of the
> LM5066 device already supported. It has different measurement conversion
> coefficients than the LM5066, so it needs to be recognized as a
> different device.
> 
> Signed-off-by: Xo Wang <x...@google.com>

Applied to hwmon-next.

Thanks,
Guenter

> ---
>  Documentation/hwmon/lm25066   |  9 +++--
>  drivers/hwmon/pmbus/lm25066.c | 41 +++--
>  2 files changed, 46 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066
> index 2cb20ebb234d..3fa6bf820c88 100644
> --- a/Documentation/hwmon/lm25066
> +++ b/Documentation/hwmon/lm25066
> @@ -29,6 +29,11 @@ Supported chips:
>  Addresses scanned: -
>  Datasheet:
>   http://www.national.com/pf/LM/LM5066.html
> +  * Texas Instruments LM5066I
> +Prefix: 'lm5066i'
> +Addresses scanned: -
> + Datasheet:
> +http://www.ti.com/product/LM5066I
>  
>  Author: Guenter Roeck <li...@roeck-us.net>
>  
> @@ -37,8 +42,8 @@ Description
>  ---
>  
>  This driver supports hardware monitoring for National Semiconductor / TI 
> LM25056,
> -LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, 
> and
> -Protection ICs.
> +LM25063, LM25066, LM5064, and LM5066/LM5066I Power Management, Monitoring,
> +Control, and Protection ICs.
>  
>  The driver is a client driver to the core PMBus driver. Please see
>  Documentation/hwmon/pmbus for details on PMBus client drivers.
> diff --git a/drivers/hwmon/pmbus/lm25066.c b/drivers/hwmon/pmbus/lm25066.c
> index 232b4af13e12..10d17fb8f283 100644
> --- a/drivers/hwmon/pmbus/lm25066.c
> +++ b/drivers/hwmon/pmbus/lm25066.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include "pmbus.h"
>  
> -enum chips { lm25056, lm25063, lm25066, lm5064, lm5066 };
> +enum chips { lm25056, lm25063, lm25066, lm5064, lm5066, lm5066i };
>  
>  #define LM25066_READ_VAUX0xd0
>  #define LM25066_MFR_READ_IIN 0xd1
> @@ -65,7 +65,7 @@ struct __coeff {
>  #define PSC_CURRENT_IN_L (PSC_NUM_CLASSES)
>  #define PSC_POWER_L  (PSC_NUM_CLASSES + 1)
>  
> -static struct __coeff lm25066_coeff[5][PSC_NUM_CLASSES + 2] = {
> +static struct __coeff lm25066_coeff[6][PSC_NUM_CLASSES + 2] = {
>   [lm25056] = {
>   [PSC_VOLTAGE_IN] = {
>   .m = 16296,
> @@ -210,6 +210,41 @@ static struct __coeff lm25066_coeff[5][PSC_NUM_CLASSES + 
> 2] = {
>   .m = 16,
>   },
>   },
> + [lm5066i] = {
> + [PSC_VOLTAGE_IN] = {
> + .m = 4617,
> + .b = -140,
> + .R = -2,
> + },
> + [PSC_VOLTAGE_OUT] = {
> + .m = 4602,
> + .b = 500,
> + .R = -2,
> + },
> + [PSC_CURRENT_IN] = {
> + .m = 15076,
> + .b = -504,
> + .R = -2,
> + },
> + [PSC_CURRENT_IN_L] = {
> + .m = 7645,
> + .b = 100,
> + .R = -2,
> + },
> + [PSC_POWER] = {
> + .m = 1701,
> + .b = -4000,
> + .R = -3,
> + },
> + [PSC_POWER_L] = {
> + .m = 861,
> + .b = -965,
> + .R = -3,
> + },
> + [PSC_TEMPERATURE] = {
> + .m = 16,
> + },
> + },
>  };
>  
>  struct lm25066_data {
> @@ -250,6 +285,7 @@ static int lm25066_read_word_data(struct i2c_client 
> *client, int page, int reg)
>   ret = DIV_ROUND_CLOSEST(ret * 70, 453);
>   break;
>   case lm5066:
> + case lm5066i:
>   /* VIN: 2.18 mV VAUX: 725 uV LSB */
>   ret = DIV_ROUND_CLOSEST(ret * 725, 2180);
>   break;
> @@ -511,6 +547,7 @@ static const struct i2c_device_id lm25066_id[] = {
>   {"lm25066", lm25066},
>   {"lm5064", lm5064},
>   {"lm5066", lm5066},
> + {"lm5066i", lm5066i},
>   { }
>  };
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/2] hwmon: (pmbus/lm25066) Offset coefficient depends on CL

[Guenter Roeck]

On Tue, Aug 29, 2017 at 02:21:16PM -0700, Xo Wang wrote:
> When converting the DIRECT format CURRENT_IN and POWER commands, make
> the offset coefficient ("b") predicate on the value of the current limit
> setting.
> 
> Signed-off-by: Xo Wang 

Applied to hwmon-next.

Thanks,
Guenter

> ---
>  drivers/hwmon/pmbus/lm25066.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/lm25066.c b/drivers/hwmon/pmbus/lm25066.c
> index a3d912cd3b8d..232b4af13e12 100644
> --- a/drivers/hwmon/pmbus/lm25066.c
> +++ b/drivers/hwmon/pmbus/lm25066.c
> @@ -488,16 +488,18 @@ static int lm25066_probe(struct i2c_client *client,
>   info->m[PSC_VOLTAGE_OUT] = coeff[PSC_VOLTAGE_OUT].m;
>   info->b[PSC_VOLTAGE_OUT] = coeff[PSC_VOLTAGE_OUT].b;
>   info->R[PSC_VOLTAGE_OUT] = coeff[PSC_VOLTAGE_OUT].R;
> - info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].b;
>   info->R[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].R;
> - info->b[PSC_POWER] = coeff[PSC_POWER].b;
>   info->R[PSC_POWER] = coeff[PSC_POWER].R;
>   if (config & LM25066_DEV_SETUP_CL) {
>   info->m[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].m;
> + info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].b;
>   info->m[PSC_POWER] = coeff[PSC_POWER_L].m;
> + info->b[PSC_POWER] = coeff[PSC_POWER_L].b;
>   } else {
>   info->m[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].m;
> + info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].b;
>   info->m[PSC_POWER] = coeff[PSC_POWER].m;
> + info->b[PSC_POWER] = coeff[PSC_POWER].b;
>   }
>  
>   return pmbus_do_probe(client, id, info);
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/3] Documentation: hwmon: Document the IBM CFF power supply

[Guenter Roeck]

On Mon, Aug 14, 2017 at 02:26:20PM -0500, Eddie James wrote:
> 
> 
> On 08/14/2017 01:53 PM, Guenter Roeck wrote:
> >On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote:
> >>From: "Edward A. James" <eaja...@us.ibm.com>
> >>
> >>Signed-off-by: Edward A. James <eaja...@us.ibm.com>
> >>---
> >>  Documentation/hwmon/ibm-cffps | 54 
> >> +++
> >>  1 file changed, 54 insertions(+)
> >>  create mode 100644 Documentation/hwmon/ibm-cffps
> >>
> >>diff --git a/Documentation/hwmon/ibm-cffps b/Documentation/hwmon/ibm-cffps
> >>new file mode 100644
> >>index 000..e091ff2
> >>--- /dev/null
> >>+++ b/Documentation/hwmon/ibm-cffps
> >>@@ -0,0 +1,54 @@
> >>+Kernel driver ibm-cffps
> >>+===
> >>+
> >>+Supported chips:
> >>+  * IBM Common Form Factor power supply
> >>+
> >>+Author: Eddie James <eaja...@us.ibm.com>
> >>+
> >>+Description
> >>+---
> >>+
> >>+This driver supports IBM Common Form Factor (CFF) power supplies. This 
> >>driver
> >>+is a client to the core PMBus driver.
> >>+
> >>+Usage Notes
> >>+---
> >>+
> >>+This driver does not auto-detect devices. You will have to instantiate the
> >>+devices explicitly. Please see Documentation/i2c/instantiating-devices for
> >>+details.
> >>+
> >>+Sysfs entries
> >>+-
> >>+
> >>+The following attributes are supported:
> >>+
> >>+curr1_alarmOutput current over-current fault.
> >>+curr1_inputMeasured output current in mA.
> >>+curr1_label"iout1"
> >>+
> >>+fan1_alarm Fan 1 warning.
> >>+fan1_fault Fan 1 fault.
> >>+fan1_input Fan 1 speed in RPM.
> >>+fan2_alarm Fan 2 warning.
> >>+fan2_fault Fan 2 fault.
> >>+fan2_input Fan 2 speed in RPM.
> >>+
> >>+in1_alarm  Input voltage under-voltage fault.
> >Just noticed. Are you sure you mean 'fault' here and below ?
> >'alarm' attributes normally report an over- or under- condition,
> >but not a fault. Faults should be reported with 'fault' attributes.
> >In PMBus lingo (which doesn't distinguish a real 'fault' from
> >a critical over- or under- condition), the "FAULT" condition
> >usually maps with the 'crit_alarm' or 'lcrit_alarm' attributes.
> >Also, under-voltages would normally be reported as min_alarm
> >or clrit_alarm, not in_alarm.
> 
> Thanks, I better change this doc to "alarm." The spec reports all these as
> "faults" but many of them are merely over-temp or over-voltage, etc, and
> should be "alarm" to be consistent with PMBus.
> 
> The problem with this power supply is that it doesn't report any "limits."
> So unless I set up my read_byte function to return some limits, we can't get
> any lower or upper limits and therefore won't get the crit_alarm,
> lcrit_alarm, etc. Do you think I should "fake" the limits in the driver?
> 
Good question. Are the limits documented ? If yes, that would make sense.
I am quite sure that limits are word registers, though.

Guenter

> >
> >>+in1_input  Measured input voltage in mV.
> >>+in1_label  "vin"
> >>+in2_alarm  Output voltage over-voltage fault.
> >>+in2_input  Measured output voltage in mV.
> >>+in2_label  "vout1"
> >>+
> >>+power1_alarm   Input fault.
> >Another example; this maps to PMBUS_PIN_OP_WARN_LIMIT which is an
> >input power alarm, not an indication of a fault condition.
> 
> Hm, with my latest changes to look at the higher byte of STATUS_WORD, it
> looks like we now have the same name for both the pin generic alarm
> attribute and the pin_limit_attr... So in this device's case, it would map
> to PB_STATUS_INPUT bit of STATUS_WORD. Didn't think about that... any
> suggestions? Can't really change the name of the limit one without breaking
> people's code...
> 
> >
> >>+power1_input   Measured input power in uW.
> >>+power1_label   "pin"
> >>+
> >>+temp1_alarmPSU inlet ambient temperature over-temperature 
> >>fault.
> >>+temp1_inputMeasured PSU inlet ambient temp in millidegrees 
> >>C.
> >

Re: [PATCH v3 3/3] Documentation: hwmon: Document the IBM CFF power supply

[Guenter Roeck]

On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote:
> From: "Edward A. James" 
> 
> Signed-off-by: Edward A. James 
> ---
>  Documentation/hwmon/ibm-cffps | 54 
> +++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/hwmon/ibm-cffps
> 
> diff --git a/Documentation/hwmon/ibm-cffps b/Documentation/hwmon/ibm-cffps
> new file mode 100644
> index 000..e091ff2
> --- /dev/null
> +++ b/Documentation/hwmon/ibm-cffps
> @@ -0,0 +1,54 @@
> +Kernel driver ibm-cffps
> +===
> +
> +Supported chips:
> +  * IBM Common Form Factor power supply
> +
> +Author: Eddie James 
> +
> +Description
> +---
> +
> +This driver supports IBM Common Form Factor (CFF) power supplies. This driver
> +is a client to the core PMBus driver.
> +
> +Usage Notes
> +---
> +
> +This driver does not auto-detect devices. You will have to instantiate the
> +devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +details.
> +
> +Sysfs entries
> +-
> +
> +The following attributes are supported:
> +
> +curr1_alarm  Output current over-current fault.
> +curr1_input  Measured output current in mA.
> +curr1_label  "iout1"
> +
> +fan1_alarm   Fan 1 warning.
> +fan1_fault   Fan 1 fault.
> +fan1_input   Fan 1 speed in RPM.
> +fan2_alarm   Fan 2 warning.
> +fan2_fault   Fan 2 fault.
> +fan2_input   Fan 2 speed in RPM.
> +
> +in1_alarmInput voltage under-voltage fault.

Just noticed. Are you sure you mean 'fault' here and below ?
'alarm' attributes normally report an over- or under- condition,
but not a fault. Faults should be reported with 'fault' attributes.
In PMBus lingo (which doesn't distinguish a real 'fault' from
a critical over- or under- condition), the "FAULT" condition
usually maps with the 'crit_alarm' or 'lcrit_alarm' attributes.
Also, under-voltages would normally be reported as min_alarm
or clrit_alarm, not in_alarm.

> +in1_inputMeasured input voltage in mV.
> +in1_label"vin"
> +in2_alarmOutput voltage over-voltage fault.
> +in2_inputMeasured output voltage in mV.
> +in2_label"vout1"
> +
> +power1_alarm Input fault.

Another example; this maps to PMBUS_PIN_OP_WARN_LIMIT which is an
input power alarm, not an indication of a fault condition.

> +power1_input Measured input power in uW.
> +power1_label "pin"
> +
> +temp1_alarm  PSU inlet ambient temperature over-temperature fault.
> +temp1_input  Measured PSU inlet ambient temp in millidegrees C.
> +temp2_alarm  Secondary rectifier temp over-temperature fault.

Interestingly, PMBus does not distinguish between a critical temperature
alarm and an actual "fault". Makes me wonder if the IBM PS reports
CFFPS_MFR_THERMAL_FAULT if there is an actual fault (chip or sensor failure),
or if it has the same meaning as PB_TEMP_OT_FAULT, ie an excessively high
temperature.

If it is a real fault (a detected sensor failure), we should possibly
consider adding a respective "virtual" temperature status flag. The same
is true for other status bits reported in the manufacturer status
register if any of those reflect a "real" fault, ie a chip failure.

> +temp2_input  Measured secondary rectifier temp in millidegrees C.
> +temp3_alarm  ORing FET temperature over-temperature fault.
> +temp3_input  Measured ORing FET temperature in millidegrees C.
> -- 
> 1.8.3.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] hwmon: (pmbus): Add POWER system power supply driver

[Guenter Roeck]

On Fri, Aug 11, 2017 at 09:30:59AM -0500, Eddie James wrote:
> 
> 
> On 08/10/2017 08:18 PM, Guenter Roeck wrote:
> >On Thu, Aug 10, 2017 at 05:19:45PM -0500, Eddie James wrote:
> >>From: "Edward A. James" <eaja...@us.ibm.com>
> >>
> >>Add the driver to monitor POWER system power supplies with hwmon over
> >>pmbus.
> >>
> >>Signed-off-by: Edward A. James <eaja...@us.ibm.com>
> >>---
> >>  drivers/hwmon/pmbus/Kconfig   |  10 +++
> >>  drivers/hwmon/pmbus/Makefile  |   1 +
> >>  drivers/hwmon/pmbus/powerps.c | 144 
> >> ++
> >>  3 files changed, 155 insertions(+)
> >>  create mode 100644 drivers/hwmon/pmbus/powerps.c
> >>
> >>diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> >>index 68d717a..8925c1a 100644
> >>--- a/drivers/hwmon/pmbus/Kconfig
> >>+++ b/drivers/hwmon/pmbus/Kconfig
> >>@@ -125,6 +125,16 @@ config SENSORS_MAX8688
> >>  This driver can also be built as a module. If so, the module will
> >>  be called max8688.
> >>+config SENSORS_POWERPS
> >>+   tristate "IBM POWER System Power Supply"
> >>+   default n
> >>+   help
> >>+ If you say yes here you get hardware monitoring support for the IBM
> >>+ POWER system power supply.
> >>+
> >>+ This driver can also be built as a module. If so, the module will
> >>+ be called powerps.
> >>+
> >>  config SENSORS_TPS40422
> >>tristate "TI TPS40422"
> >>default n
> >>diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> >>index 75bb7ca..3303af5 100644
> >>--- a/drivers/hwmon/pmbus/Makefile
> >>+++ b/drivers/hwmon/pmbus/Makefile
> >>@@ -13,6 +13,7 @@ obj-$(CONFIG_SENSORS_MAX16064)+= max16064.o
> >>  obj-$(CONFIG_SENSORS_MAX20751)+= max20751.o
> >>  obj-$(CONFIG_SENSORS_MAX34440)+= max34440.o
> >>  obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
> >>+obj-$(CONFIG_SENSORS_POWERPS)  += powerps.o
> >>  obj-$(CONFIG_SENSORS_TPS40422)+= tps40422.o
> >>  obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
> >>  obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
> >>diff --git a/drivers/hwmon/pmbus/powerps.c b/drivers/hwmon/pmbus/powerps.c
> >>new file mode 100644
> >>index 000..21d28f2
> >>--- /dev/null
> >>+++ b/drivers/hwmon/pmbus/powerps.c
> >>@@ -0,0 +1,144 @@
> >>+/*
> >>+ * 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 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+
> >>+#include "pmbus.h"
> >>+
> >>+/* STATUS_MFR_SPECIFIC bits */
> >>+#define POWERPS_MFR_FAN_FAULT  BIT(0)
> >>+#define POWERPS_MFR_THERMAL_FAULT  BIT(1)
> >>+#define POWERPS_MFR_OV_FAULT   BIT(2)
> >>+#define POWERPS_MFR_UV_FAULT   BIT(3)
> >>+#define POWERPS_MFR_PS_KILLBIT(4)
> >>+#define POWERPS_MFR_OC_FAULT   BIT(5)
> >>+#define POWERPS_MFR_VAUX_FAULT BIT(6)
> >>+#define POWERPS_MFR_CURRENT_SHARE_WARNING  BIT(7)
> >>+
> >>+static int powerps_read_byte_data(struct i2c_client *client, int page, int 
> >>reg)
> >>+{
> >>+   int rc, mfr;
> >>+
> >>+   switch (reg) {
> >>+   case PMBUS_STATUS_VOUT:
> >>+   case PMBUS_STATUS_IOUT:
> >>+   case PMBUS_STATUS_TEMPERATURE:
> >>+   case PMBUS_STATUS_FAN_12:
> >>+   rc = pmbus_read_byte_data(client, page, reg);
> >>+   if (rc < 0)
> >>+   return rc;
> >>+
> >>+   mfr = pmbus_read_byte_data(client, page,
> >>+  PMBUS_STATUS_MFR_SPECIFIC);
> >>+   if (mfr < 0)
> >>+   return rc;
> > return mfr; ?
> 
> Well I returned rc because we read the status register without error, so
> just return the status register contents without the additional mfr bits.
> It's not ve

Re: [PATCH v2 3/3] Documentation: hwmon: Add POWER system power supply documentation

[Guenter Roeck]

On Thu, Aug 10, 2017 at 05:19:46PM -0500, Eddie James wrote:
> From: "Edward A. James" 
> 
> Signed-off-by: Edward A. James 
> ---
>  Documentation/hwmon/powerps | 54 
> +
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/hwmon/powerps
> 
> diff --git a/Documentation/hwmon/powerps b/Documentation/hwmon/powerps
> new file mode 100644
> index 000..a4fbe92
> --- /dev/null
> +++ b/Documentation/hwmon/powerps
> @@ -0,0 +1,54 @@
> +Kernel driver powerps
> +=
> +
> +Supported chips:
> +  * POWER system power supply
> +
> +Author: Eddie James 
> +
> +Description
> +---
> +
> +This driver supports POWER system power supplies. This driver is a client
> +to the core PMBus driver.
> +
> +Usage Notes
> +---
> +
> +This driver should auto-detect devices. In the event that it does not, you 
> will

Not really, unless specified in devicetree or by other means in the kernel.
But the _driver_ won't do it. pmbus drivers don't have detect functions.

> +have to instantiate the devices explicitly. Please see
> +Documentation/i2c/instantiating-devices for details.
> +
> +Sysfs entries
> +-
> +
> +The following attributes are supported:
> +
> +curr1_alarm  Output current over-current fault.
> +curr1_input  Measured output current in mA.
> +curr1_label  "iout1"
> +
> +fan1_alarm   Fan 1 warning.
> +fan1_fault   Fan 1 fault.
> +fan1_input   Fan 1 speed in RPM.
> +fan2_alarm   Fan 2 warning.
> +fan2_fault   Fan 2 fault.
> +fan2_input   Fan 2 speed in RPM.
> +
> +in1_alarmInput voltage under-voltage fault.
> +in1_inputMeasured input voltage in mV.
> +in1_label"vin"
> +in2_alarmOutput voltage over-voltage fault.
> +in2_inputMeasured output voltage in mV.
> +in2_label"vout1"
> +
> +power1_alarm Input fault.
> +power1_input Measured input power in uW.
> +power1_label "pin"
> +
> +temp1_alarm  PSU inlet ambient temperature over-temperature fault.
> +temp1_input  Measured PSU inlet ambient temp in millidegrees C.
> +temp2_alarm  Secondary rectifier temp over-temperature fault.
> +temp2_input  Measured secondary rectifier temp in millidegrees C.
> +temp3_alarm  ORing FET temperature over-temperature fault.
> +temp3_input  Measured ORing FET temperature in millidegrees C.
> -- 
> 1.8.3.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] hwmon: (pmbus): Add POWER system power supply driver

[Guenter Roeck]

On Thu, Aug 10, 2017 at 05:19:45PM -0500, Eddie James wrote:
> From: "Edward A. James" 
> 
> Add the driver to monitor POWER system power supplies with hwmon over
> pmbus.
> 
> Signed-off-by: Edward A. James 
> ---
>  drivers/hwmon/pmbus/Kconfig   |  10 +++
>  drivers/hwmon/pmbus/Makefile  |   1 +
>  drivers/hwmon/pmbus/powerps.c | 144 
> ++
>  3 files changed, 155 insertions(+)
>  create mode 100644 drivers/hwmon/pmbus/powerps.c
> 
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 68d717a..8925c1a 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -125,6 +125,16 @@ config SENSORS_MAX8688
> This driver can also be built as a module. If so, the module will
> be called max8688.
>  
> +config SENSORS_POWERPS
> + tristate "IBM POWER System Power Supply"
> + default n
> + help
> +   If you say yes here you get hardware monitoring support for the IBM
> +   POWER system power supply.
> +
> +   This driver can also be built as a module. If so, the module will
> +   be called powerps.
> +
>  config SENSORS_TPS40422
>   tristate "TI TPS40422"
>   default n
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 75bb7ca..3303af5 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_SENSORS_MAX16064)  += max16064.o
>  obj-$(CONFIG_SENSORS_MAX20751)   += max20751.o
>  obj-$(CONFIG_SENSORS_MAX34440)   += max34440.o
>  obj-$(CONFIG_SENSORS_MAX8688)+= max8688.o
> +obj-$(CONFIG_SENSORS_POWERPS)+= powerps.o
>  obj-$(CONFIG_SENSORS_TPS40422)   += tps40422.o
>  obj-$(CONFIG_SENSORS_UCD9000)+= ucd9000.o
>  obj-$(CONFIG_SENSORS_UCD9200)+= ucd9200.o
> diff --git a/drivers/hwmon/pmbus/powerps.c b/drivers/hwmon/pmbus/powerps.c
> new file mode 100644
> index 000..21d28f2
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/powerps.c
> @@ -0,0 +1,144 @@
> +/*
> + * 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 
> +#include 
> +#include 
> +#include 
> +
> +#include "pmbus.h"
> +
> +/* STATUS_MFR_SPECIFIC bits */
> +#define POWERPS_MFR_FAN_FAULTBIT(0)
> +#define POWERPS_MFR_THERMAL_FAULTBIT(1)
> +#define POWERPS_MFR_OV_FAULT BIT(2)
> +#define POWERPS_MFR_UV_FAULT BIT(3)
> +#define POWERPS_MFR_PS_KILL  BIT(4)
> +#define POWERPS_MFR_OC_FAULT BIT(5)
> +#define POWERPS_MFR_VAUX_FAULT   BIT(6)
> +#define POWERPS_MFR_CURRENT_SHARE_WARNINGBIT(7)
> +
> +static int powerps_read_byte_data(struct i2c_client *client, int page, int 
> reg)
> +{
> + int rc, mfr;
> +
> + switch (reg) {
> + case PMBUS_STATUS_VOUT:
> + case PMBUS_STATUS_IOUT:
> + case PMBUS_STATUS_TEMPERATURE:
> + case PMBUS_STATUS_FAN_12:
> + rc = pmbus_read_byte_data(client, page, reg);
> + if (rc < 0)
> + return rc;
> +
> + mfr = pmbus_read_byte_data(client, page,
> +PMBUS_STATUS_MFR_SPECIFIC);
> + if (mfr < 0)
> + return rc;

return mfr; ?

> +
> + /* Add MFR_SPECIFIC bits to the standard pmbus status regs. */
> + if (reg == PMBUS_STATUS_FAN_12) {
> + if (mfr & POWERPS_MFR_FAN_FAULT)
> + rc |= PB_FAN_FAN1_FAULT;
> + } else if (reg == PMBUS_STATUS_TEMPERATURE) {
> + if (mfr & POWERPS_MFR_THERMAL_FAULT)
> + rc |= PB_TEMP_OT_FAULT;
> + } else if (reg == PMBUS_STATUS_VOUT) {
> + if (mfr &
> + (POWERPS_MFR_OV_FAULT | POWERPS_MFR_VAUX_FAULT))

Wondering - this suggests that there is a VAUX. Would it make sense
to map it to PMBUS_VIRT_READ_VMON ?

> + rc |= PB_VOLTAGE_OV_FAULT;
> + if (mfr & POWERPS_MFR_UV_FAULT)
> + rc |= PB_VOLTAGE_UV_FAULT;
> + } else if (reg == PMBUS_STATUS_IOUT) {
> + if (mfr & POWERPS_MFR_OC_FAULT)
> + rc |= PB_IOUT_OC_FAULT;
> + if (mfr & POWERPS_MFR_CURRENT_SHARE_WARNING)
> + rc |= PB_CURRENT_SHARE_FAULT;
> + }
> + break;
> + default:
> + rc = -ENODATA;
> + break;
> + }
> +
> + return rc;
> +}
> +
> +static int powerps_read_word_data(struct i2c_client 

Re: [v6,3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT

[Guenter Roeck]

On Tue, May 30, 2017 at 10:56:47AM +0200, Rasmus Villemoes wrote:
> This allows setting a default value for the watchdog.open_timeout
> commandline parameter via Kconfig.
> 
> Some BSPs allow remote updating of the kernel image and root file
> system, but updating the bootloader requires physical access. Hence, if
> one has a firmware update that requires relaxing the
> watchdog.open_timeout a little, the value used must be baked into the
> kernel image itself and cannot come from the u-boot environment via the
> kernel command line.
> 
> Being able to set the initial value in .config doesn't change the fact
> that the value on the command line, if present, takes precedence, and is
> of course immensely useful for development purposes while one has
> console acccess, as well as usable in the cases where one can make a
> permanent update of the kernel command line.
> 
> Signed-off-by: Rasmus Villemoes 

Wim, any thoughts on making this configurable ? I used to be opposed to it,
but it does seem to make some sense to me now after thinking about it.

Thanks,
Guenter

> ---
>  Documentation/watchdog/watchdog-parameters.txt | 3 ++-
>  drivers/watchdog/Kconfig   | 9 +
>  drivers/watchdog/watchdog_dev.c| 2 +-
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 8577c27..fa34625 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -11,7 +11,8 @@ modules.
>  The watchdog core parameter watchdog.open_timeout is the maximum time,
>  in milliseconds, for which the watchdog framework will take care of
>  pinging a hardware watchdog until userspace opens the corresponding
> -/dev/watchdogN device. A value of 0 (the default) means an infinite
> +/dev/watchdogN device. The defalt value is
> +CONFIG_WATCHDOG_OPEN_TIMEOUT. A value of 0 means an infinite
>  timeout. Setting this to a non-zero value can be useful to ensure that
>  either userspace comes up properly, or the board gets reset and allows
>  fallback logic in the bootloader to try something else.
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 8b9049d..11946fb 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -52,6 +52,15 @@ config WATCHDOG_SYSFS
> Say Y here if you want to enable watchdog device status read through
> sysfs attributes.
>  
> +config WATCHDOG_OPEN_TIMEOUT
> + int "Timeout value for opening watchdog device"
> + default 0
> + help
> +   The maximum time, in milliseconds, for which the watchdog
> +   framework takes care of pinging a hardware watchdog. A value
> +   of 0 means infinite. The value set here can be overridden by
> +   the commandline parameter "watchdog.open_timeout".
> +
>  #
>  # General Watchdog drivers
>  #
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index c807067..098b9cb 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -81,7 +81,7 @@ static struct watchdog_core_data *old_wd_data;
>  
>  static struct workqueue_struct *watchdog_wq;
>  
> -static unsigned open_timeout;
> +static unsigned open_timeout = CONFIG_WATCHDOG_OPEN_TIMEOUT;
>  module_param(open_timeout, uint, 0644);
>  
>  static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6, 2/3] watchdog: introduce watchdog.open_timeout commandline parameter

[Guenter Roeck]

On Tue, May 30, 2017 at 10:56:46AM +0200, Rasmus Villemoes wrote:
> The watchdog framework takes care of feeding a hardware watchdog until
> userspace opens /dev/watchdogN. If that never happens for some reason
> (buggy init script, corrupt root filesystem or whatnot) but the kernel
> itself is fine, the machine stays up indefinitely. This patch allows
> setting an upper limit for how long the kernel will take care of the
> watchdog, thus ensuring that the watchdog will eventually reset the
> machine.
> 
> This is particularly useful for embedded devices where some fallback
> logic is implemented in the bootloader (e.g., use a different root
> partition, boot from network, ...).
> 
> The open timeout is also used as a maximum time for an application to
> re-open /dev/watchdogN after closing it.
> 
> A value of 0 (the default) means infinite timeout, preserving the
> current behaviour.
> 
> The unit is milliseconds rather than seconds because that covers more
> use cases. For example, one can effectively disable the kernel handling
> by setting the open_timeout to 1 ms. There are also customers with very
> strict requirements that may want to set the open_timeout to something
> like 4500 ms, which combined with a hardware watchdog that must be
> pinged every 250 ms ensures userspace is up no more than 5 seconds after
> the bootloader hands control to the kernel (250 ms until the driver gets
> registered and kernel handling starts, 4500 ms of kernel handling, and
> then up to 250 ms from the last ping until userspace takes over).
> 
> Signed-off-by: Rasmus Villemoes 

I finally found the time to look into this. It is sufficiently different
to handle_boot_enabled to keep it separate. I am mostly ok with the patch.
One comment below.

> ---
>  Documentation/watchdog/watchdog-parameters.txt |  8 
>  drivers/watchdog/watchdog_dev.c| 26 
> +-
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> b/Documentation/watchdog/watchdog-parameters.txt
> index 914518a..8577c27 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -8,6 +8,14 @@ See Documentation/admin-guide/kernel-parameters.rst for 
> information on
>  providing kernel parameters for builtin drivers versus loadable
>  modules.
>  
> +The watchdog core parameter watchdog.open_timeout is the maximum time,
> +in milliseconds, for which the watchdog framework will take care of
> +pinging a hardware watchdog until userspace opens the corresponding
> +/dev/watchdogN device. A value of 0 (the default) means an infinite
> +timeout. Setting this to a non-zero value can be useful to ensure that
> +either userspace comes up properly, or the board gets reset and allows
> +fallback logic in the bootloader to try something else.
> +
>  
>  -
>  acquirewdt:
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index caa4b90..c807067 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -66,6 +66,7 @@ struct watchdog_core_data {
>   struct mutex lock;
>   unsigned long last_keepalive;
>   unsigned long last_hw_keepalive;
> + unsigned long open_deadline;
>   struct delayed_work work;
>   unsigned long status;   /* Internal status bits */
>  #define _WDOG_DEV_OPEN   0   /* Opened ? */
> @@ -80,6 +81,21 @@ static struct watchdog_core_data *old_wd_data;
>  
>  static struct workqueue_struct *watchdog_wq;
>  
> +static unsigned open_timeout;
> +module_param(open_timeout, uint, 0644);

MODULE_PARM_DESC is missing. I would also prefer to keep module_param()
and MODULE_PARM_DESC() together with the existing module parameter, ie at
the end of the file.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

[Guenter Roeck]

On 06/08/2017 12:53 AM, Andrew Jeffery wrote:

On Wed, 2017-06-07 at 08:55 -0700, Guenter Roeck wrote:

On Tue, Jun 06, 2017 at 04:32:30PM +0930, Andrew Jeffery wrote:

Add a basic driver for the MAX31785, focusing on the fan control
features but ignoring the temperature and voltage monitoring
features of the device.

This driver supports all fan control modes and tachometer / PWM
readback where applicable.


Signed-off-by: Timothy Pearson <tpear...@raptorengineering.com>
Signed-off-by: Andrew Jeffery <and...@aj.id.au>

---
Hello,

This is a rework of Timothy Pearson's original patch:

 https://www.mail-archive.com/linux-hwmon@vger.kernel.org/msg00868.html

I've labelled it as v3 to differentiate from Timothy's postings.

The original thread had some discussion about the MAX31785 being a PMBus device
and that it should thus be a PMBus driver. The implementation still makes use


After thinking about it, that is what it should be. If I accept it as non-PMBus
driver, it will be all but impossible to convert it to a PMBus driver later on,
and that just doesn't make any sense.


Hopefully not being too ignorant here, but can you expand on why it
would be all but impossible to convert?



I've got a lot of noise recently just for converting a driver from the old to 
the
new API (which changes the attribute location). Changing the driver from 
non-PMBus
to PMBus would very quite likely change some attributes as well.

Besides that, I think it is a bad idea to bypass an infrastructure just because
it may require a few tweaks. That generates a bad precedent, and people _would_
use that to argue that the next PMBus chip driver should not use the 
infrastructure
either.

Guenter



With no one interested in writing that driver, I'll try to give it some more
priority myself. I do have an evaluation board somewhere, which should help.

Note that the second fan reading should be implemented as just that, not with
a non-standard attribute.


Agreed.

Andrew



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

[Guenter Roeck]

On Wed, Jun 07, 2017 at 04:15:06PM +0930, Andrew Jeffery wrote:
> On Wed, 2017-06-07 at 12:18 +0930, Joel Stanley wrote:
> > On Wed, Jun 7, 2017 at 1:50 AM, Matthew Barth
> > > <msba...@linux.vnet.ibm.com> wrote:
> > > 
> > > On 06/06/17 8:33 AM, Guenter Roeck wrote:
> > > > 
> > > > On 06/06/2017 12:02 AM, Andrew Jeffery wrote:
> > > > > Over and above the features of the original patch is support for a
> > > > > secondary
> > > > > rotor measurement value that is provided by MAX31785 chips with a 
> > > > > revised
> > > > > firmware. The feature(s) of the firmware are determined at probe time 
> > > > > and
> > > > > extra
> > > > > attributes exposed accordingly. Specifically, the MFR_REVISION 0x3040 
> > > > > of
> > > > > the
> > > > > firmware supports 'slow' and 'fast' rotor reads. The feature is
> > > > > implemented by
> > > > > command 0x90 (READ_FAN_SPEED_1) providing a 4-byte response (with the
> > > > > 'fast'
> > > > > measurement in the second word) rather than the 2-bytes response in 
> > > > > the
> > > > > original firmware (MFR_REVISION 0x3030).
> > > > > 
> > > > 
> > > > Taking the pmbus driver question out, why would this warrant another
> > > > non-standard
> > > > attribute outside the ABI ? I could see the desire to replace the 'slow'
> > > > access
> > > > with the 'fast' one, but provide two attributes ? No, I don't see the
> > > > point, sorry,
> > > > even more so without detailed explanation why the second attribute in
> > > > addition
> > > > to the first one would add any value.
> > > 
> > > In the case of counter-rotating(CR) fans which contain two rotors to 
> > > provide
> > > more airflow there are then two tach feedbacks. These CR fans take a 
> > > single
> > > target speed and provide individual feedbacks for each rotor contained
> > > within the fan enclosure. Providing these individual feedbacks assists in
> > > fan fault driven speed changes, improved thermal characterization among
> > > other things.
> > > 
> > > Maxim provided this as a 'slow' / 'fast' set of bytes to be user
> > > compatible(so the 'slow' rotor speed, regardless of which rotor, is in the
> > > first 2 bytes with the 'slow' version of firmware as well). In some cases,
> > > mfg systems could have a mix of these revisions.
> > 
> > Andrew, instead of creating the _fast sysfs nodes, I think you could
> > expose the extra rotors are separate fan devices in sysfs. This would
> > not introduce new ABI.
> 
> I considered this approach: I debated whether to consider the fan unit
> as a single entity with two inputs, or just separate fans, and ended up
> leaning towards the former. To go the latter path we need to consider
> whether or not to expose the writeable properties for the second input
> (given they also affect the first) and how to sensibly arrange the
> pairs given the functionality is determined at probe-time. Not rocket
> science but decisions we need to make.
> 

There are many other examples with one writeable and multiple readable
attributes. Temperature offset attributes are an excellent example.
Next question would be what exactly would be writable. pwm attributes are
commonly completely independent of fan attributes. pwm1 output doesn't
mean that fan1 is the matching input; in fact, most of the time it isn't.
The only question would be numbering (is the pair numbered fan1/2 or
fan1/fan(1+X) ?) which is just a matter of personal preference. However,
everything is better than coming up with non-standard attributes which
can not be used with any standard application beyond the application of the
person submitting the driver. It is bad enough if a non-standard attribute
describes something really driver specific. But a non-standard attribute
for a fan speed reading ? Please no. We don't use outX_output instead of
inX_input for voltage outputs either.

Guenter

> There's also the issue that the physical fan that each element of an
> input pair represents will change as the fan speeds vary, based on the
> behaviour that Matt outlined. I don't feel this maps well onto the
> expectations of the sysfs interface, but then I'm not sure there's much
> we can do to alleviate it either other than designating one of the
> input attributes of a fan pair as the fastest input.
> 
> Regardless, I'll look into it in the anticipation that this is a viable
> way forward.
> 
> Cheers,
> 
> Andrew


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

[Guenter Roeck]

On Tue, Jun 06, 2017 at 04:32:30PM +0930, Andrew Jeffery wrote:
> Add a basic driver for the MAX31785, focusing on the fan control
> features but ignoring the temperature and voltage monitoring
> features of the device.
> 
> This driver supports all fan control modes and tachometer / PWM
> readback where applicable.
> 
> Signed-off-by: Timothy Pearson 
> Signed-off-by: Andrew Jeffery 
> ---
> Hello,
> 
> This is a rework of Timothy Pearson's original patch:
> 
> https://www.mail-archive.com/linux-hwmon@vger.kernel.org/msg00868.html
> 
> I've labelled it as v3 to differentiate from Timothy's postings.
> 
> The original thread had some discussion about the MAX31785 being a PMBus 
> device
> and that it should thus be a PMBus driver. The implementation still makes use

After thinking about it, that is what it should be. If I accept it as non-PMBus
driver, it will be all but impossible to convert it to a PMBus driver later on,
and that just doesn't make any sense.

With no one interested in writing that driver, I'll try to give it some more
priority myself. I do have an evaluation board somewhere, which should help.

Note that the second fan reading should be implemented as just that, not with
a non-standard attribute.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

[Guenter Roeck]

On 06/06/2017 01:08 AM, Rasmus Villemoes wrote:

On 2017-05-30 10:56, Rasmus Villemoes wrote:


v6 tweaks the wording in watchdog-parameters.txt to avoid having to
update it if and when the watchdog core grows new parameters. It also
adds a little more rationale to the commit messages for 2/3 and 3/3,
and adds Reviewed-bys to 1/3 which is unchanged from v5.


Ping. Guenther, is there anything I can do on my end to get this in
before the 4.13 merge window opens? I realize you're busy, but I'd
really appreciate just a brief response to this and the other emails
I've sent the past few weeks.




You made a suggestion that this overlaps with another option, which forces me
to go back and check the entire exchange from the start, for which I did not
have time yet, sorry.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller

[Guenter Roeck]

On 06/06/2017 12:02 AM, Andrew Jeffery wrote:

Add a basic driver for the MAX31785, focusing on the fan control
features but ignoring the temperature and voltage monitoring
features of the device.

This driver supports all fan control modes and tachometer / PWM
readback where applicable.

Signed-off-by: Timothy Pearson 
Signed-off-by: Andrew Jeffery 
---
Hello,

This is a rework of Timothy Pearson's original patch:

 https://www.mail-archive.com/linux-hwmon@vger.kernel.org/msg00868.html

I've labelled it as v3 to differentiate from Timothy's postings.

The original thread had some discussion about the MAX31785 being a PMBus device
and that it should thus be a PMBus driver. The implementation still makes use
of features not available in the pmbus core, so I've taken up the earlier
suggestion and ported it to the devm_hwmon_device_register_with_info()
interface. This gave a modest reduction in lines-of-code and at least to me is
more aesthetically pleasing.

Over and above the features of the original patch is support for a secondary
rotor measurement value that is provided by MAX31785 chips with a revised
firmware. The feature(s) of the firmware are determined at probe time and extra
attributes exposed accordingly. Specifically, the MFR_REVISION 0x3040 of the
firmware supports 'slow' and 'fast' rotor reads. The feature is implemented by
command 0x90 (READ_FAN_SPEED_1) providing a 4-byte response (with the 'fast'
measurement in the second word) rather than the 2-bytes response in the
original firmware (MFR_REVISION 0x3030).



Taking the pmbus driver question out, why would this warrant another 
non-standard
attribute outside the ABI ? I could see the desire to replace the 'slow' access
with the 'fast' one, but provide two attributes ? No, I don't see the point, 
sorry,
even more so without detailed explanation why the second attribute in addition
to the first one would add any value.


This feature is not documented in the public datasheet[1].

[1] https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf

The need to read a 4-byte value drives the addition of a helper that is a
cut-down version of i2c_smbus_xfer_emulated(), as 4-byte transactions aren't a
defined transaction type in the PMBus spec. This seemed more tasteful than
hacking the PMBus core to support the quirks of a single device.



That is why we have PMBus helper drivers.

Guenter


Also changed from Timothy's original posting is I've massaged the locking a bit
and removed what seemed to be a copy/paste bug around max31785_fan_set_pulses()
setting the fan_command member.

Tested on an IBM Witherspoon machine.

Cheers,

Andrew

  Documentation/hwmon/max31785 |  44 +++
  drivers/hwmon/Kconfig|  10 +
  drivers/hwmon/Makefile   |   1 +
  drivers/hwmon/max31785.c | 824 +++
  4 files changed, 879 insertions(+)
  create mode 100644 Documentation/hwmon/max31785
  create mode 100644 drivers/hwmon/max31785.c

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
new file mode 100644
index ..dd891c06401e
--- /dev/null
+++ b/Documentation/hwmon/max31785
@@ -0,0 +1,44 @@
+Kernel driver max31785
+==
+
+Supported chips:
+  * Maxim MAX31785
+Prefix: 'max31785'
+Addresses scanned: 0x52 0x53 0x54 0x55
+Datasheet: http://pdfserv.maximintegrated.com/en/ds/MAX31785.pdf
+
+Author: Timothy Pearson 
+
+
+Description
+---
+
+This driver implements support for the Maxim MAX31785 chip.
+
+The MAX31785 controls the speeds of up to six fans using six independent
+PWM outputs. The desired fan speeds (or PWM duty cycles) are written
+through the I2C interface. The outputs drive "4-wire" fans directly,
+or can be used to modulate the fan's power terminals using an external
+pass transistor.
+
+Tachometer inputs monitor fan tachometer logic outputs for precise (+/-1%)
+monitoring and control of fan RPM as well as detection of fan failure.
+
+
+Sysfs entries
+-
+
+fan[1-6]_input   RO  fan tachometer speed in RPM
+fan[1-6]_fault   RO  fan experienced fault
+fan[1-6]_pulses  RW  tachometer pulses per fan revolution
+fan[1-6]_target  RW  desired fan speed in RPM
+pwm[1-6]_enable  RW  pwm mode, 0=disabled, 1=pwm, 2=rpm, 3=automatic
+pwm[1-6] RW  fan target duty cycle (0-255)
+
+Dynamic sysfs entries
+
+
+Whether these entries are present depends on the firmware features detected on
+the device during probe.
+
+fan[1-6]_input_fast  RO  fan tachometer speed in RPM (fast rotor 
measurement)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index e80ca81577f4..c75d6072c823 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -886,6 +886,16 @@ config SENSORS_MAX6697
  This driver can also be built as a module.  If so, the module
  will be called 

Re: [PATCH v5 2/3] watchdog: introduce watchdog.open_timeout commandline parameter

[Guenter Roeck]

On 05/22/2017 07:06 AM, Rasmus Villemoes wrote:

The watchdog framework takes care of feeding a hardware watchdog until
userspace opens /dev/watchdogN. If that never happens for some reason
(buggy init script, corrupt root filesystem or whatnot) but the kernel
itself is fine, the machine stays up indefinitely. This patch allows
setting an upper limit for how long the kernel will take care of the
watchdog, thus ensuring that the watchdog will eventually reset the
machine.

This is particularly useful for embedded devices where some fallback
logic is implemented in the bootloader (e.g., use a different root
partition, boot from network, ...).

The open timeout is also used as a maximum time for an application to
re-open /dev/watchdogN after closing it.

A value of 0 (the default) means infinite timeout, preserving the
current behaviour.

Signed-off-by: Rasmus Villemoes 
---
  Documentation/watchdog/watchdog-parameters.txt |  9 +
  drivers/watchdog/watchdog_dev.c| 26 +-
  2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/Documentation/watchdog/watchdog-parameters.txt 
b/Documentation/watchdog/watchdog-parameters.txt
index 914518a..4801ec6 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -8,6 +8,15 @@ See Documentation/admin-guide/kernel-parameters.rst for 
information on
  providing kernel parameters for builtin drivers versus loadable
  modules.
  
+The watchdog core currently understands one parameter,


We have a second parameter queued, handle_boot_enabled. Please rephrase
so we don't have to change the text with each new parameter.

Thanks,
Guenter


+watchdog.open_timeout. This is the maximum time, in milliseconds, for
+which the watchdog framework will take care of pinging a hardware
+watchdog until userspace opens the corresponding /dev/watchdogN
+device. A value of 0 (the default) means an infinite timeout. Setting
+this to a non-zero value can be useful to ensure that either userspace
+comes up properly, or the board gets reset and allows fallback logic
+in the bootloader to try something else.
+
  
  -

  acquirewdt:
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index caa4b90..c807067 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -66,6 +66,7 @@ struct watchdog_core_data {
struct mutex lock;
unsigned long last_keepalive;
unsigned long last_hw_keepalive;
+   unsigned long open_deadline;
struct delayed_work work;
unsigned long status;   /* Internal status bits */
  #define _WDOG_DEV_OPEN0   /* Opened ? */
@@ -80,6 +81,21 @@ static struct watchdog_core_data *old_wd_data;
  
  static struct workqueue_struct *watchdog_wq;
  
+static unsigned open_timeout;

+module_param(open_timeout, uint, 0644);
+
+static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
+{
+   if (!open_timeout)
+   return false;
+   return time_is_before_jiffies(data->open_deadline);
+}
+
+static void watchdog_set_open_deadline(struct watchdog_core_data *data)
+{
+   data->open_deadline = jiffies + msecs_to_jiffies(open_timeout);
+}
+
  static inline bool watchdog_need_worker(struct watchdog_device *wdd)
  {
/* All variables in milli-seconds */
@@ -196,7 +212,13 @@ static bool watchdog_worker_should_ping(struct 
watchdog_core_data *wd_data)
  {
struct watchdog_device *wdd = wd_data->wdd;
  
-	return wdd && (watchdog_active(wdd) || watchdog_hw_running(wdd));

+   if (!wdd)
+   return false;
+
+   if (watchdog_active(wdd))
+   return true;
+
+   return watchdog_hw_running(wdd) && 
!watchdog_past_open_deadline(wd_data);
  }
  
  static void watchdog_ping_work(struct work_struct *work)

@@ -857,6 +879,7 @@ static int watchdog_release(struct inode *inode, struct 
file *file)
watchdog_ping(wdd);
}
  
+	watchdog_set_open_deadline(wd_data);

watchdog_update_worker(wdd);
  
  	/* make sure that /dev/watchdog can be re-opened */

@@ -955,6 +978,7 @@ static int watchdog_cdev_register(struct watchdog_device 
*wdd, dev_t devno)
  
  	/* Record time of most recent heartbeat as 'just before now'. */

wd_data->last_hw_keepalive = jiffies - 1;
+   watchdog_set_open_deadline(wd_data);
  
  	/*

 * If the watchdog is running, prevent its driver from being unloaded,



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN

[Guenter Roeck]

On Mon, May 22, 2017 at 07:07:51PM +0100, Alan Cox wrote:
> On Mon, 22 May 2017 16:06:36 +0200
> Rasmus Villemoes  wrote:
> 
> > If a watchdog driver tells the framework that the device is running,
> > the framework takes care of feeding the watchdog until userspace opens
> > the device. If the userspace application which is supposed to do that
> > never comes up properly, the watchdog is fed indefinitely by the
> > kernel. This can be especially problematic for embedded devices.
> > 
> > These patches allow one to set a maximum time for which the kernel
> > will feed the watchdog, thus ensuring that either userspace has come
> > up, or the board gets reset. This allows fallback logic in the
> > bootloader to attempt some recovery (for example, if an automatic
> > update is in progress, it could roll back to the previous version).
> 
> 
> This makes sense except for being a CONFIG_ option not a boot parameter.
> If it's a boot parameter then the same kernel works for multiple systems
> and is general. If it's compile time then you have to build a custom
> kernel.
> 
> For some embedded stuff that might not matter (although I bet they'd
> prefer it command line/device tree too) but for something like an x86
> platform where you are deploying a standard vendor supplied kernel it's
> bad to do it that way IMHO.
> 
> In other words I think you should drop patch 3 but the rest is good.
> 

Same here. Can we assume a formal Reviewed-by: from you for the first two
patches ?

Thanks,
Guenter

> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c

[Guenter Roeck]

On 05/21/2017 01:34 PM, Wolfram Sang wrote:

It doesn't make sense to use include/linux/i2c for client drivers which may in
fact rather be hwmon or input or whatever devices. As a result, I want to
deprecate include/linux/i2c for good. This series moves the include files to a
better location, largely include/platform_data because that is what most of th 
> moved include files contain. Note that some files don't seem to have upstream
users in board code, so they maybe could even be removed? I didn't check for


While I understand where you are coming from, I am not typically that 
aggressive.
Such removals force vendors who are not really forthcoming with upstreaming to
deviate even further from upstream. It makes them even less likely to submit 
their
code upstream, and it may result in enforcing their belief that upstream doesn't
really care about vendors struggling to release boards and systems to their
customers.


that now, but I did it for one i2c master driver recently. So, it may be
possible. pmbus.h got moved just one layer upwards, see the patch description
there.

I prefer the series to go upstream via the subsystem tree; if you prefer that I
take it via I2C, just let me know.


Series applied to hwmon-next.

Thanks,
Guenter


No runtime testing because of no HW, but buildbot is happy with this series at
least. A branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data

Thanks and kind regards,

Wolfram


Wolfram Sang (5):
   hwmon: ads1015: move header file out of I2C realm
   hwmon: ds620: move header file out of I2C realm
   hwmon: ltc4245: move header file out of I2C realm
   hwmon: max6639: move header file out of I2C realm
   hwmon: pmbus: move header file out of I2C realm

  Documentation/hwmon/ads1015| 2 +-
  Documentation/hwmon/ltc4245| 2 +-
  Documentation/hwmon/pmbus-core | 2 +-
  MAINTAINERS| 4 ++--
  drivers/hwmon/ads1015.c| 2 +-
  drivers/hwmon/ds620.c  | 2 +-
  drivers/hwmon/ltc4245.c| 2 +-
  drivers/hwmon/max6639.c| 2 +-
  drivers/hwmon/pmbus/pmbus.c| 2 +-
  drivers/hwmon/pmbus/pmbus_core.c   | 2 +-
  drivers/hwmon/pmbus/ucd9000.c  | 2 +-
  drivers/hwmon/pmbus/ucd9200.c  | 2 +-
  drivers/iio/adc/ti-ads1015.c   | 2 +-
  include/linux/{i2c => platform_data}/ads1015.h | 0
  include/linux/{i2c => platform_data}/ds620.h   | 0
  include/linux/{i2c => platform_data}/ltc4245.h | 0
  include/linux/{i2c => platform_data}/max6639.h | 0
  include/linux/{i2c => }/pmbus.h| 0
  18 files changed, 14 insertions(+), 14 deletions(-)
  rename include/linux/{i2c => platform_data}/ads1015.h (100%)
  rename include/linux/{i2c => platform_data}/ds620.h (100%)
  rename include/linux/{i2c => platform_data}/ltc4245.h (100%)
  rename include/linux/{i2c => platform_data}/max6639.h (100%)
  rename include/linux/{i2c => }/pmbus.h (100%)



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

[Guenter Roeck]

On Tue, May 16, 2017 at 08:30:52PM +, Chris Packham wrote:
> On 16/05/17 20:23, kbuild test robot wrote:
> > Hi Chris,
> >
> > [auto build test ERROR on hwmon/hwmon-next]
> > [also build test ERROR on v4.12-rc1 next-20170516]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Chris-Packham/hwmon-adt7475-fan-stall-prevention/20170515-093530
> > base:   
> > https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> > hwmon-next
> > config: x86_64-rhel (attached as .config)
> > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/hwmon/adt7475.c: In function 'set_temp_st':
> >>> drivers/hwmon/adt7475.c:622:9: error: implicit declaration of function 
> >>> 'find_closest_descending' [-Werror=implicit-function-declaration]
> >   val = find_closest_descending(val, ad7475_st_map,
> > ^~~
> >cc1: some warnings being treated as errors
> >
> > vim +/find_closest_descending +622 drivers/hwmon/adt7475.c
> >
> >616  shift = 4;
> >617  idx = 1;
> >618  break;
> >619  }
> >620  
> >621  if (val > 0) {
> >  > 622  val = find_closest_descending(val, 
> > ad7475_st_map,
> >623
> > ARRAY_SIZE(ad7475_st_map));
> >624  val |= 0x8;
> >625  }
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> >
> 
> I'm not sure how this is failing. find_closest_descending() is a macro 
> defined in linux/util_macros.h which is explicitly included in 
> drivers/hwmon/adt7475.c. Aside from the include guards there's nothing 
> conditional about it.

I suspect it was tested out of sequence, without the preceding patches,
and the header file include was missing.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

[Guenter Roeck]

On 05/14/2017 06:30 PM, Chris Packham wrote:

When enabled temperature smoothing allows ramping the fan speed over a
configurable period of time instead of jumping to the new speed
instantaneously.

Signed-off-by: Chris Packham 


Applied to -next.


---
Changes in v2:
- use a single tempN_smoothing attribute
Changes in v3:
- change enh_acou to enh_acoustics
- simplify show_temp_st()
Changes in v4:
- removed dead code.
- Make the order of the smoothing attributes match the other temperature
  attributes.

Guenter,

We'd previously discussed making the smoothing values set CONFIG6[SLOW] to
expose the other set of potential values. I wasn't sure where you wanted to go
on that one.

Personally I was on the fence since the difference would only be noticeable for
the higher values. If we do want to add support for the other values it could
be done as a subsequent patch (or a v5 if you want it).


It can be added later if anyone cares.

Thanks,
Guenter


 Documentation/hwmon/adt7475 |  4 ++
 drivers/hwmon/adt7475.c | 91 +
 2 files changed, 95 insertions(+)

diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index dc0b55794c47..09d73a10644c 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -114,6 +114,10 @@ minimum (i.e. auto_point1_pwm). This behaviour can be 
configured using the
 pwm[1-*]_stall_disable sysfs attribute. A value of 0 means the fans will shut
 off. A value of 1 means the fans will run at auto_point1_pwm.

+The responsiveness of the ADT747x to temperature changes can be configured.
+This allows smoothing of the fan speed transition. To set the transition time
+set the value in ms in the temp[1-*]_smoothing sysfs attribute.
+
 Notes
 -

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 3eb8c5c2f8af..3056076fae27 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -526,6 +526,88 @@ static ssize_t set_temp(struct device *dev, struct 
device_attribute *attr,
return count;
 }

+/* Assuming CONFIG6[SLOW] is 0 */
+static const int ad7475_st_map[] = {
+   37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
+};
+
+static ssize_t show_temp_st(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   long val;
+
+   switch (sattr->index) {
+   case 0:
+   val = data->enh_acoustics[0] & 0xf;
+   break;
+   case 1:
+   val = (data->enh_acoustics[1] >> 4) & 0xf;
+   break;
+   case 2:
+   default:
+   val = data->enh_acoustics[1] & 0xf;
+   break;
+   }
+
+   if (val & 0x8)
+   return sprintf(buf, "%d\n", ad7475_st_map[val & 0x7]);
+   else
+   return sprintf(buf, "0\n");
+}
+
+static ssize_t set_temp_st(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   unsigned char reg;
+   int shift, idx;
+   ulong val;
+
+   if (kstrtoul(buf, 10, ))
+   return -EINVAL;
+
+   switch (sattr->index) {
+   case 0:
+   reg = REG_ENHANCE_ACOUSTICS1;
+   shift = 0;
+   idx = 0;
+   break;
+   case 1:
+   reg = REG_ENHANCE_ACOUSTICS2;
+   shift = 0;
+   idx = 1;
+   break;
+   case 2:
+   default:
+   reg = REG_ENHANCE_ACOUSTICS2;
+   shift = 4;
+   idx = 1;
+   break;
+   }
+
+   if (val > 0) {
+   val = find_closest_descending(val, ad7475_st_map,
+ ARRAY_SIZE(ad7475_st_map));
+   val |= 0x8;
+   }
+
+   mutex_lock(>lock);
+
+   data->enh_acoustics[idx] &= ~(0xf << shift);
+   data->enh_acoustics[idx] |= (val << shift);
+
+   i2c_smbus_write_byte_data(client, reg, data->enh_acoustics[idx]);
+
+   mutex_unlock(>lock);
+
+   return count;
+}
+
 /*
  * Table of autorange values - the user will write the value in millidegrees,
  * and we'll convert it
@@ -1008,6 +1090,8 @@ static SENSOR_DEVICE_ATTR_2(temp1_crit, S_IRUGO | 
S_IWUSR, show_temp, set_temp,
THERM, 0);
 static SENSOR_DEVICE_ATTR_2(temp1_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
set_temp, HYSTERSIS, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_smoothing, S_IRUGO | S_IWUSR, show_temp_st,
+   

Re: [PATCH v4 1/3] hwmon: (adt7475) fan stall prevention

[Guenter Roeck]

On 05/14/2017 06:30 PM, Chris Packham wrote:

By default adt7475 will stop the fans (pwm duty cycle 0%) when the
temperature drops past Tmin - hysteresis. Some systems want to keep the
fans moving even when the temperature drops so add new sysfs attributes
that configure the enhanced acoustics min 1-3 which allows the fans to
run at the minimum configure pwm duty cycle.

Signed-off-by: Chris Packham 


Applied to hwmon-next.

Thanks,
Guenter


---
Changes in v2:
- use pwmN_stall_dis as the attribute name. I think this describes the purpose
  pretty well. I went with a new attribute instead of overloading
  pwmN_auto_point1_pwm so this doesn't affect existing users.
Changes in v3:
- Fix grammar.
- change enh_acou to enh_acoustics
Changes in v4:
- Change sysfs attribute to pwmN_stall_disable

 Documentation/hwmon/adt7475 |  5 +
 drivers/hwmon/adt7475.c | 50 +
 2 files changed, 55 insertions(+)

diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 0502f2b464e1..dc0b55794c47 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to 
255 (full speed).
 Fan speed may be set to maximum when the temperature sensor associated with
 the PWM control exceeds temp#_max.

+At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or at the
+minimum (i.e. auto_point1_pwm). This behaviour can be configured using the
+pwm[1-*]_stall_disable sysfs attribute. A value of 0 means the fans will shut
+off. A value of 1 means the fans will run at auto_point1_pwm.
+
 Notes
 -

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index ec0c43fbcdce..3eb8c5c2f8af 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -79,6 +79,9 @@

 #define REG_TEMP_TRANGE_BASE   0x5F

+#define REG_ENHANCE_ACOUSTICS1 0x62
+#define REG_ENHANCE_ACOUSTICS2 0x63
+
 #define REG_PWM_MIN_BASE   0x64

 #define REG_TEMP_TMIN_BASE 0x67
@@ -209,6 +212,7 @@ struct adt7475_data {
u8 range[3];
u8 pwmctl[3];
u8 pwmchan[3];
+   u8 enh_acoustics[2];

u8 vid;
u8 vrm;
@@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *attr,
data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
i2c_smbus_write_byte_data(client, reg,
  data->pwm[sattr->nr][sattr->index]);
+   mutex_unlock(>lock);
+
+   return count;
+}
+
+static ssize_t show_stall_disable(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   u8 mask = BIT(5 + sattr->index);
+
+   return sprintf(buf, "%d\n", !!(data->enh_acoustics[0] & mask));
+}
+
+static ssize_t set_stall_disable(struct device *dev,
+struct device_attribute *attr, const char *buf,
+size_t count)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   long val;
+   u8 mask = BIT(5 + sattr->index);
+
+   if (kstrtol(buf, 10, ))
+   return -EINVAL;
+
+   mutex_lock(>lock);
+
+   data->enh_acoustics[0] &= ~mask;
+   if (val)
+   data->enh_acoustics[0] |= mask;
+
+   i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
+ data->enh_acoustics[0]);

mutex_unlock(>lock);

@@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, S_IRUGO 
| S_IWUSR, show_pwm,
set_pwm, MIN, 0);
 static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 0);
+static SENSOR_DEVICE_ATTR_2(pwm1_stall_disable, S_IRUGO | S_IWUSR,
+   show_stall_disable, set_stall_disable, 0, 0);
 static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
1);
 static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, S_IRUGO 
| S_IWUSR, show_pwm,
set_pwm, MIN, 1);
 static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 1);
+static SENSOR_DEVICE_ATTR_2(pwm2_stall_disable, S_IRUGO | S_IWUSR,
+   show_stall_disable, set_stall_disable, 0, 1);
 static SENSOR_DEVICE_ATTR_2(pwm3, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
2);
 static 

Re: [PATCH v3 3/4] hwmon: (adt7475) temperature smoothing

[Guenter Roeck]

On 05/14/2017 02:23 PM, Chris Packham wrote:

On 15/05/17 03:40, Guenter Roeck wrote:

On 05/10/2017 08:45 PM, Chris Packham wrote:

When enabled temperature smoothing allows ramping the fan speed over a
configurable period of time instead of jumping to the new speed
instantaneously.

Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz>
---

Changes in v2:
- use a single tempN_smoothing attribute


This is a bit confusing. tempN suggests that the attribute would be associated
with a given temperature, not with fan control. Not that I have a better idea
for an attribute name, though, so unless you find a better name I am ok with it.



The datasheet is a bit confusing in this respect.

 From the description of register 0x62:

"Assuming that PWMx is associated with the Remote 1 temperature channel,
these bits define the maximum rate of change of the PWMx output for
Remote 1 temperature related changes. Instead of the fan speed jumping
instantaneously to its newly determined speed, it ramps
gracefully at the rate determined by these bits. This feature ultimately
enhances the acoustics of the fan."

Based on my reading it's a property of the temperature input not of the
PWM. If you changed pwmN_auto_channels_temp this setting would stay with
the temperature sensor not the PWM.



Agreed, that is why I said that I don't have a better idea ...

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/4] hwmon: (adt7475) fan stall prevention

[Guenter Roeck]

On 05/10/2017 08:45 PM, Chris Packham wrote:

By default adt7475 will stop the fans (pwm duty cycle 0%) when the
temperature drops past Tmin - hysteresis. Some systems want to keep the
fans moving even when the temperature drops so add new sysfs attributes
that configure the enhanced acoustics min 1-3 which allows the fans to
run at the minimum configure pwm duty cycle.

Signed-off-by: Chris Packham 
---

Changes in v2:
- use pwmN_stall_dis as the attribute name. I think this describes the purpose
  pretty well. I went with a new attribute instead of overloading


Almost agree. Can we use pwmN_stall_disable ?

Thanks,
Guenter



  pwmN_auto_point1_pwm so this doesn't affect existing users.
Changes in v3:
- Fix grammar.
- change enh_acou to enh_acoustics

 Documentation/hwmon/adt7475 |  5 +
 drivers/hwmon/adt7475.c | 50 +
 2 files changed, 55 insertions(+)

diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 0502f2b464e1..3990bae60e78 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to 
255 (full speed).
 Fan speed may be set to maximum when the temperature sensor associated with
 the PWM control exceeds temp#_max.

+At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or at the
+minimum (i.e. auto_point1_pwm). This behaviour can be configured using the
+pwm[1-*]_stall_dis sysfs attribute. A value of 0 means the fans will shut off.
+A value of 1 means the fans will run at auto_point1_pwm.
+
 Notes
 -

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index ec0c43fbcdce..4d6c625fec70 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -79,6 +79,9 @@

 #define REG_TEMP_TRANGE_BASE   0x5F

+#define REG_ENHANCE_ACOUSTICS1 0x62
+#define REG_ENHANCE_ACOUSTICS2 0x63
+
 #define REG_PWM_MIN_BASE   0x64

 #define REG_TEMP_TMIN_BASE 0x67
@@ -209,6 +212,7 @@ struct adt7475_data {
u8 range[3];
u8 pwmctl[3];
u8 pwmchan[3];
+   u8 enh_acoustics[2];

u8 vid;
u8 vrm;
@@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *attr,
data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
i2c_smbus_write_byte_data(client, reg,
  data->pwm[sattr->nr][sattr->index]);
+   mutex_unlock(>lock);
+
+   return count;
+}
+
+
+static ssize_t show_stall_dis(struct device *dev, struct device_attribute 
*attr,
+ char *buf)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   u8 mask = BIT(5 + sattr->index);
+
+   return sprintf(buf, "%d\n", !!(data->enh_acoustics[0] & mask));
+}
+
+static ssize_t set_stall_dis(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   long val;
+   u8 mask = BIT(5 + sattr->index);
+
+   if (kstrtol(buf, 10, ))
+   return -EINVAL;
+
+   mutex_lock(>lock);
+
+   data->enh_acoustics[0] &= ~mask;
+   if (val)
+   data->enh_acoustics[0] |= mask;
+
+   i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
+ data->enh_acoustics[0]);

mutex_unlock(>lock);

@@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, S_IRUGO 
| S_IWUSR, show_pwm,
set_pwm, MIN, 0);
 static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 0);
+static SENSOR_DEVICE_ATTR_2(pwm1_stall_dis, S_IRUGO | S_IWUSR, show_stall_dis,
+   set_stall_dis, 0, 0);
 static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
1);
 static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, S_IRUGO 
| S_IWUSR, show_pwm,
set_pwm, MIN, 1);
 static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 1);
+static SENSOR_DEVICE_ATTR_2(pwm2_stall_dis, S_IRUGO | S_IWUSR, show_stall_dis,
+   set_stall_dis, 0, 1);
 static SENSOR_DEVICE_ATTR_2(pwm3, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
2);
 static SENSOR_DEVICE_ATTR_2(pwm3_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1052,6 +1097,8 @@ static 

Re: [RFC PATCH v2 3/3] hwmon: (adt7475) temperature smoothing

[Guenter Roeck]

On Wed, May 03, 2017 at 12:40:09PM +1200, Chris Packham wrote:
> When enabled temperature smoothing allows ramping the fan speed over a
> configurable period of time instead of jumping to the new speed
> instantaneously.
> 
> Signed-off-by: Chris Packham 
> ---
> Changes in v2:
> - use a single tempN_smoothing attribute
> 
>  Documentation/hwmon/adt7475 |  4 ++
>  drivers/hwmon/adt7475.c | 99 
> +
>  2 files changed, 103 insertions(+)
> 
> diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
> index 63507402cd4f..dd6433d819d0 100644
> --- a/Documentation/hwmon/adt7475
> +++ b/Documentation/hwmon/adt7475
> @@ -114,6 +114,10 @@ minimum (i.e. auto_point1_pwm). This behaviour be 
> configured using the
>  pwm[1-*]_stall_dis sysfs attribute. A value of 0 means the fans will shut 
> off.
>  A value of 1 means the fans will run at auto_point1_pwm.
>  
> +The responsiveness of the ADT747x to temperature changes can be configured.
> +This allows smoothing of the fan speed transition. To set the transition time
> +set the value in ms in the temp[1-*]_smoothing sysfs attribute.
> +
>  Notes
>  -
>  
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index 85957324cd85..41342de6e20c 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -526,6 +526,96 @@ static ssize_t set_temp(struct device *dev, struct 
> device_attribute *attr,
>   return count;
>  }
>  
> +/* Assuming CONFIG6[SLOW] is 0 */

Can you take that into account and calculate a "best fit" based on the
available options ?

> +static const int ad7475_st_map[] = {
> + 37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
> +};
> +
> +static ssize_t show_temp_st(struct device *dev, struct device_attribute 
> *attr,
> +   char *buf)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + int shift, idx;
> + long val;
> +
> + switch (sattr->index) {
> + case 0:
> + shift = 0;
> + idx = 0;
> + break;
> + case 1:
> + shift = 4;
> + idx = 1;
> + break;
> + case 2:
> + shift = 0;
> + idx = 1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + val = data->enh_acou[idx] >> shift;
> + if (val & 0x8) {
> + return sprintf(buf, "%d\n", ad7475_st_map[val & 0x7]);
> + } else {
> + return sprintf(buf, "0\n");
> + }
> +}
> +
> +static ssize_t set_temp_st(struct device *dev, struct device_attribute *attr,
> +  const char *buf, size_t count)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + unsigned char reg;
> + int shift, idx;
> + ulong val;
> +
> + if (kstrtoul(buf, 10, ))
> + return -EINVAL;
> +
> + switch (sattr->index) {
> + case 0:
> + reg = REG_ENHANCE_ACOUSTICS1;
> + shift = 0;
> + idx = 0;
> + break;
> + case 1:
> + reg = REG_ENHANCE_ACOUSTICS2;
> + shift = 4;
> + idx = 1;
> + break;
> + case 2:
> + reg = REG_ENHANCE_ACOUSTICS2;
> + shift = 0;
> + idx = 1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (val > 0) {
> + val = find_closest_descending(val, ad7475_st_map,
> +   ARRAY_SIZE(ad7475_st_map));
> + val |= 0x8;
> + }
> +
> + mutex_lock(>lock);
> +
> + data->enh_acou[idx] &= ~(0xf << shift);
> + data->enh_acou[idx] |= (val << shift);
> +
> + i2c_smbus_write_byte_data(client, reg, data->enh_acou[idx]);
> +
> + mutex_unlock(>lock);
> +
> + return count;
> +}
> +
>  /*
>   * Table of autorange values - the user will write the value in millidegrees,
>   * and we'll convert it
> @@ -1008,6 +1098,8 @@ static SENSOR_DEVICE_ATTR_2(temp1_crit, S_IRUGO | 
> S_IWUSR, show_temp, set_temp,
>   THERM, 0);
>  static SENSOR_DEVICE_ATTR_2(temp1_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
>   set_temp, HYSTERSIS, 0);
> +static SENSOR_DEVICE_ATTR_2(temp1_smoothing, S_IRUGO | S_IWUSR, show_temp_st,
> + set_temp_st, 0, 0);
>  static SENSOR_DEVICE_ATTR_2(temp2_input, S_IRUGO, show_temp, NULL, INPUT, 1);
>  static SENSOR_DEVICE_ATTR_2(temp2_alarm, S_IRUGO, show_temp, NULL, ALARM, 1);
>  static SENSOR_DEVICE_ATTR_2(temp2_max, S_IRUGO | S_IWUSR, show_temp, 
> set_temp,
> @@ -1024,6 +1116,8 @@ static 

Re: [RFC PATCH v2 2/3] hwmon: (adt7475) fan stall prevention

[Guenter Roeck]

On Wed, May 03, 2017 at 12:40:08PM +1200, Chris Packham wrote:
> By default adt7475 will stop the fans (pwm duty cycle 0%) when the
> temperature drops past Tmin - hysteresis. Some systems want to keep the
> fans moving even when the temperature drops so add new sysfs attributes
> that configure the enhanced acoustics min 1-3 which allows the fans to
> run at the minimum configure pwm duty cycle.
> 
> Signed-off-by: Chris Packham 
> ---
> Changes in v2:
> - use pwmN_stall_dis as the attribute name. I think this describes the purpose
>   pretty well. I went with a new attribute instead of overloading
>   pwmN_auto_point1_pwm so this doesn't affect existing users.
> 
>  Documentation/hwmon/adt7475 |  5 +
>  drivers/hwmon/adt7475.c | 50 
> +
>  2 files changed, 55 insertions(+)
> 
> diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
> index 0502f2b464e1..63507402cd4f 100644
> --- a/Documentation/hwmon/adt7475
> +++ b/Documentation/hwmon/adt7475
> @@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to 
> 255 (full speed).
>  Fan speed may be set to maximum when the temperature sensor associated with
>  the PWM control exceeds temp#_max.
>  
> +At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or at 
> the
> +minimum (i.e. auto_point1_pwm). This behaviour be configured using the
> +pwm[1-*]_stall_dis sysfs attribute. A value of 0 means the fans will shut 
> off.

That is really an awkward attribute name. I'll have to think about this some
more.

Guenter

> +A value of 1 means the fans will run at auto_point1_pwm.
> +
>  Notes
>  -
>  
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index ec0c43fbcdce..85957324cd85 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -79,6 +79,9 @@
>  
>  #define REG_TEMP_TRANGE_BASE 0x5F
>  
> +#define REG_ENHANCE_ACOUSTICS1   0x62
> +#define REG_ENHANCE_ACOUSTICS2   0x63
> +
>  #define REG_PWM_MIN_BASE 0x64
>  
>  #define REG_TEMP_TMIN_BASE   0x67
> @@ -209,6 +212,7 @@ struct adt7475_data {
>   u8 range[3];
>   u8 pwmctl[3];
>   u8 pwmchan[3];
> + u8 enh_acou[2];
>  
>   u8 vid;
>   u8 vrm;
> @@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct 
> device_attribute *attr,
>   data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
>   i2c_smbus_write_byte_data(client, reg,
> data->pwm[sattr->nr][sattr->index]);
> + mutex_unlock(>lock);
> +
> + return count;
> +}
> +
> +
> +static ssize_t show_stall_dis(struct device *dev, struct device_attribute 
> *attr,
> +   char *buf)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + u8 mask = BIT(5 + sattr->index);
> +
> + return sprintf(buf, "%d\n", !!(data->enh_acou[0] & mask));
> +}
> +
> +static ssize_t set_stall_dis(struct device *dev, struct device_attribute 
> *attr,
> +  const char *buf, size_t count)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + long val;
> + u8 mask = BIT(5 + sattr->index);
> +
> + if (kstrtol(buf, 10, ))
> + return -EINVAL;
> +
> + mutex_lock(>lock);
> +
> + data->enh_acou[0] &= ~mask;
> + if (val)
> + data->enh_acou[0] |= mask;
> +
> + i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
> +   data->enh_acou[0]);
>  
>   mutex_unlock(>lock);
>  
> @@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, 
> S_IRUGO | S_IWUSR, show_pwm,
>   set_pwm, MIN, 0);
>  static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, 
> show_pwm,
>   set_pwm, MAX, 0);
> +static SENSOR_DEVICE_ATTR_2(pwm1_stall_dis, S_IRUGO | S_IWUSR, 
> show_stall_dis,
> + set_stall_dis, 0, 0);
>  static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, 
> INPUT,
>   1);
>  static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
> @@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, 
> S_IRUGO | S_IWUSR, show_pwm,
>   set_pwm, MIN, 1);
>  static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, 
> show_pwm,
>   set_pwm, MAX, 1);
> +static SENSOR_DEVICE_ATTR_2(pwm2_stall_dis, S_IRUGO | S_IWUSR, 
> show_stall_dis,
> + set_stall_dis, 0, 1);
>  static SENSOR_DEVICE_ATTR_2(pwm3, S_IRUGO | S_IWUSR, show_pwm, set_pwm, 
> INPUT,
>  

Re: [RFC PATCH 3/3] hwmon: (adt7475) temperature smoothing

[Guenter Roeck]

On Tue, May 02, 2017 at 05:45:36PM +1200, Chris Packham wrote:
> When enabled temperature smoothing allows ramping the fan speed over a
> configurable period of time instead of jumping to the new speed
> instantaneously.
> 
> Signed-off-by: Chris Packham 
> ---
>  Documentation/hwmon/adt7475 |   5 ++
>  drivers/hwmon/adt7475.c | 121 
> 
>  2 files changed, 126 insertions(+)
> 
> diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
> index 85dc9e17bdee..31b15cb910ea 100644
> --- a/Documentation/hwmon/adt7475
> +++ b/Documentation/hwmon/adt7475
> @@ -114,6 +114,11 @@ at the minimum (i.e. auto_point1_pwm). This can be 
> configured using the
>  pwm[1-*]_min sysfs attribute. A value of 0 means the fans will shut off. A
>  value of 1 means the fans will run at auto_point1_pwm.
>  
> +The responsiveness of the ADT747x to temperature changes can be configured.
> +This allows smoothing of the fan speed transition. To enable temperature
> +smoothing used the temp[1-*]_smoothing_enable sysfs attribute. To set the
> +transition time set the value in ms in the temp[1-*]_smoothing sysfs 
> attribute.
> +
Does this require two attributes, or can setting '0' for temp[1-*]_smoothing
be used to disable it ?

Thanks,
Guenter

>  Notes
>  -
>  
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index 53f25bda0919..e1299eef7c51 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -526,6 +526,109 @@ static ssize_t set_temp(struct device *dev, struct 
> device_attribute *attr,
>   return count;
>  }
>  
> +/* Assuming CONFIG6[SLOW] is 0 */
> +static const int ad7475_st_map[] = {
> + 37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
> +};
> +
> +static ssize_t show_temp_st(struct device *dev, struct device_attribute 
> *attr,
> +   char *buf)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + int shift, idx;
> + long val;
> +
> + switch (sattr->index) {
> + case 0:
> + shift = 0;
> + idx = 0;
> + break;
> + case 1:
> + shift = 4;
> + idx = 1;
> + break;
> + case 2:
> + shift = 0;
> + idx = 1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + switch (sattr->nr) {
> + case CONTROL:
> + val = (data->enh_acou[idx] >> shift) & 0x8;
> + return sprintf(buf, "%d\n", !!val);
> + case MIN:
> + val = (data->enh_acou[idx] >> shift) & 0x7;
> + return sprintf(buf, "%d\n", ad7475_st_map[val]);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static ssize_t set_temp_st(struct device *dev, struct device_attribute *attr,
> +  const char *buf, size_t count)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + unsigned char reg;
> + int shift, idx;
> + int mask;
> + long val;
> +
> + if (kstrtol(buf, 10, ))
> + return -EINVAL;
> +
> + switch (sattr->index) {
> + case 0:
> + reg = REG_ENHANCE_ACOUSTICS1;
> + shift = 0;
> + idx = 0;
> + break;
> + case 1:
> + reg = REG_ENHANCE_ACOUSTICS2;
> + shift = 4;
> + idx = 1;
> + break;
> + case 2:
> + reg = REG_ENHANCE_ACOUSTICS2;
> + shift = 0;
> + idx = 1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + switch (sattr->nr) {
> + case CONTROL:
> + val = !!val << 3;
> + mask = 0x8;
> + break;
> + case MIN:
> + val = find_closest_descending(val, ad7475_st_map,
> +   ARRAY_SIZE(ad7475_st_map));
> + mask = 0x7;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + mutex_lock(>lock);
> +
> + data->enh_acou[idx] &= ~(mask << shift);
> + data->enh_acou[idx] |= (val << shift);
> +
> + i2c_smbus_write_byte_data(client, reg, data->enh_acou[idx]);
> +
> + mutex_unlock(>lock);
> +
> + return count;
> +}
> +
>  /*
>   * Table of autorange values - the user will write the value in millidegrees,
>   * and we'll convert it
> @@ -1008,6 +,10 @@ static SENSOR_DEVICE_ATTR_2(temp1_crit, S_IRUGO | 
> S_IWUSR, show_temp, set_temp,
>   THERM, 0);
>  static SENSOR_DEVICE_ATTR_2(temp1_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
>   set_temp, HYSTERSIS, 

Re: [PATCH 2/3] hwmon: (adt7475) fan stall prevention

[Guenter Roeck]

On Tue, May 02, 2017 at 05:45:35PM +1200, Chris Packham wrote:
> By default adt7475 will stop the fans (pwm duty cycle 0%) when the
> temperature drops past Tmin - hysteresis. Some systems want to keep the
> fans moving even when the temperature drops so add new sysfs attributes
> that configure the enhanced acoustics min 1-3 which allows the fans to
> run at the minimum configure pwm duty cycle.
> 
> Signed-off-by: Chris Packham 
> ---
> pwmN_min is a horrible name but I really can't think of anything better.
> I'm biased a little because that is essentially the name of the bits in
> the datasheet. I'm open to suggestions.

pwmX_min is also traditionally the mimimum permitted pwm value,
not a boolean. This would be more appropriate to reflect the PWMmin
register values (0x64 to 0x66). Similar for pwmX_max if you want to
add support for it.
It might make sense to combine pwmX_min==0 with clearing the
respective bit in the REG_ENHANCE_ACOUSTICS[12] register. This way
we would only need one attribute to support both.

Guenter

> 
>  Documentation/hwmon/adt7475 |  5 +
>  drivers/hwmon/adt7475.c | 50 
> +
>  2 files changed, 55 insertions(+)
> 
> diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
> index 0502f2b464e1..85dc9e17bdee 100644
> --- a/Documentation/hwmon/adt7475
> +++ b/Documentation/hwmon/adt7475
> @@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to 
> 255 (full speed).
>  Fan speed may be set to maximum when the temperature sensor associated with
>  the PWM control exceeds temp#_max.
>  
> +At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or
> +at the minimum (i.e. auto_point1_pwm). This can be configured using the
> +pwm[1-*]_min sysfs attribute. A value of 0 means the fans will shut off. A
> +value of 1 means the fans will run at auto_point1_pwm.
> +
>  Notes
>  -
>  
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index ec0c43fbcdce..53f25bda0919 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -79,6 +79,9 @@
>  
>  #define REG_TEMP_TRANGE_BASE 0x5F
>  
> +#define REG_ENHANCE_ACOUSTICS1   0x62
> +#define REG_ENHANCE_ACOUSTICS2   0x63
> +
>  #define REG_PWM_MIN_BASE 0x64
>  
>  #define REG_TEMP_TMIN_BASE   0x67
> @@ -209,6 +212,7 @@ struct adt7475_data {
>   u8 range[3];
>   u8 pwmctl[3];
>   u8 pwmchan[3];
> + u8 enh_acou[2];
>  
>   u8 vid;
>   u8 vrm;
> @@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct 
> device_attribute *attr,
>   data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
>   i2c_smbus_write_byte_data(client, reg,
> data->pwm[sattr->nr][sattr->index]);
> + mutex_unlock(>lock);
> +
> + return count;
> +}
> +
> +
> +static ssize_t show_pwm_min(struct device *dev, struct device_attribute 
> *attr,
> + char *buf)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + u8 mask = BIT(5 + sattr->index);
> +
> + return sprintf(buf, "%d\n", !!(data->enh_acou[0] & mask));
> +}
> +
> +static ssize_t set_pwm_min(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + struct i2c_client *client = to_i2c_client(dev);
> + struct adt7475_data *data = i2c_get_clientdata(client);
> + long val;
> + u8 mask = BIT(5 + sattr->index);
> +
> + if (kstrtol(buf, 10, ))
> + return -EINVAL;
> +
> + mutex_lock(>lock);
> +
> + data->enh_acou[0] &= ~mask;
> + if (val)
> + data->enh_acou[0] |= mask;
> +
> + i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
> +   data->enh_acou[0]);
>  
>   mutex_unlock(>lock);
>  
> @@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, 
> S_IRUGO | S_IWUSR, show_pwm,
>   set_pwm, MIN, 0);
>  static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, 
> show_pwm,
>   set_pwm, MAX, 0);
> +static SENSOR_DEVICE_ATTR_2(pwm1_min, S_IRUGO | S_IWUSR, show_pwm_min,
> + set_pwm_min, 0, 0);
>  static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, 
> INPUT,
>   1);
>  static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
> @@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, 
> S_IRUGO | S_IWUSR, show_pwm,
>   set_pwm, MIN, 1);
>  static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, 
> show_pwm,
>   set_pwm, MAX, 1);
> 

Re: [PATCH 2/2] devicetree: Document the max31760 device binding.

[Guenter Roeck]

On Tue, Apr 11, 2017 at 06:47:28AM -0700, John Muir wrote:
> > On Apr 10, 2017, at 8:42 AM, Rob Herring  wrote:
> > 
> > On Tue, Apr 04, 2017 at 12:20:34PM -0700, John Muir wrote:
> >> +MAX31760 fan controller
> >> +---
> >> +
> >> +This device supports I2C only. Many properties of this device are 
> >> configurable
> >> +thorugh the hwmon interface. See also Documentation/hwmon/max31760.
> > 
> > I really think we need to describe the fans as separate nodes and 
> > preferably with a common binding. This is the second fan controller 
> > binding recently[1].
> > 
> > Features of the "hwmon interface" are not relevant to the binding. 
> > Bindings describe h/w.
> 
> It seems to me that referring to the hwmon interface is only helpful. You are 
> suggesting removing those sentences? If so, can I add a link to the data 
> sheet?
> 

Devicetree properties are supposed to be operating system independent.
Any mention of how access to the device is implemented on a given
operating system is out of scope for this document.

Guenter

> > 
> >> +Optional node properties:
> >> +- maxim,fan1-enabled  - 1 to enable, 0 to disable. Default: 1.
> >> +- maxim,fan2-enabled  - 1 to enable, 0 to disable. Default: 1.
> >> +- maxim,fan1-label- String: Hwmon fan1_label.
> >> +- maxim,fan2-label- String: Hwmon fan2_label.
> > 
> > Perhaps 2 fan sub nodes. reg for fan number, status for enabled, and 
> > label for label.
> 
> OK.
> 
> Right now a fan’s number of pulses and the PWM frequency are configured using 
> the hwmon sysfs interface (which defines standard controls for those), but as 
> those are characteristics of the hardware, should they also be configured via 
> the device tree binding?
> 
> >> +- maxim,pwm-zero-fan-can-fail - 0: Fan failure detection disabled 
> >> when PWM is
> >> +   ramping to 0%.
> >> +1: Fan failure detection enabled for all PWM
> >> +   values.
> >> +Default: 0.
> > 
> > All these can be boolean…
> 
> OK. The only issue I see is when the default is ‘true’ in the device, but 
> I’ll try to avoid that. Sometimes I wish that you could set a boolean to 
> false in DTS files.
> 
> > 
> >> +- maxim,temp1-label   - String: Hwmon temp1_label.
> >> +- maxim,temp2-label   - String: Hwmon temp2_label.
> >> +- maxim,temp2-ideality- Set ideality factor for the remote 
> >> temperature
> >> +sensor. Integer with range 0 to 63,
> >> +representing a multiplication factor of 0.9844
> >> +to 1.0489. Default: 24 (1.0080).
> > 
> > No maxim,temp1-ideality?
> No - the device only lets you set the ideality of the ‘external' temperature 
> sensor. I guess if there is an ideality for the internal temperature sensor, 
> it would be hard-wired as a characteristic of the part that was used.
> 
> > Not sure what to do with these, but perhaps 
> > also as sub-nodes. Surely we have some bindings already for devices with 
> > multiple temp sensors. Don't invent something custom here.
> 
> I’ll look into it.
> 
> What is the best way to distinguish between ‘fan’ and ‘temp’ sub-nodes? Do I 
> require a ‘compatible’ string?
> 
> Thanks!
> 
> John.
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach

[Guenter Roeck]

On 04/04/2017 05:55 AM, Guenter Roeck wrote:

On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:

The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan <ja...@google.com>


Applied.



Follow-up: Sparse complains as follows.

drivers/hwmon/aspeed-pwm-tacho.c:156:14: warning: symbol 'regs' was not 
declared. Should it be static?
drivers/hwmon/aspeed-pwm-tacho.c:324:30: warning: incorrect type in initializer 
(different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:324:30:expected void [noderef] *regs
drivers/hwmon/aspeed-pwm-tacho.c:324:30:got void *context
drivers/hwmon/aspeed-pwm-tacho.c:333:30: warning: incorrect type in initializer 
(different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:333:30:expected void [noderef] *regs
drivers/hwmon/aspeed-pwm-tacho.c:333:30:got void *context
drivers/hwmon/aspeed-pwm-tacho.c:516:25: warning: dubious: !x & !y
drivers/hwmon/aspeed-pwm-tacho.c:793:24: warning: incorrect type in argument 3 
(different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:793:24:expected void *bus_context
drivers/hwmon/aspeed-pwm-tacho.c:793:24:got void [noderef] 
*[assigned] regs

Can you please look into this and send me a follow-up patch ?

156 seems unnecessary/unused, 324, 333, and 793 might need a typecast, 516 is 
really fishy.

Thanks,
Guenter


Thanks,
Guenter


---
 v6
- Corrected odd line breaks
- Changed upto to up to
- Dropped unrelated changes
- Removed struct and used regs pointer directly
- Made groups to be null terminated
- Made correction in calculation of val/raw_data
- Removed else after return
- Removed unnecessary continuation lines

 v5:
- Changed the driver to suit the changes in the device tree documentation

 v4:
- Modified this driver to suit the representation in the devicetree

 v3:
- Only sent out device tree documentation; did not send this driver

 v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes

 Documentation/hwmon/aspeed-pwm-tacho |  22 +
 drivers/hwmon/Kconfig|   9 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c | 846 +++
 4 files changed, 878 insertions(+)
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

diff --git a/Documentation/hwmon/aspeed-pwm-tacho 
b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index ..7cfb34977460
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==
+
+Supported chips:
+ASPEED AST2400/2500
+
+Authors:
+<ja...@google.com>
+
+Description:
+
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+fanX_inputroprovide current fan rotation value in RPM as reported
+by the fan to the device.
+
+pwmXrwget or set PWM fan control value. This is an integer
+value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..757b5b0705bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
   This driver can also be built as a module.  If so, the module
   will be called asb100.

+config SENSORS_ASPEED
+tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+help
+  This driver provides support for ASPEED AST2400/AST2500 PWM
+  and Fan Tacho controllers.
+
+  This driver can also be built as a module. If so, the module
+  will be called aspeed_pwm_tacho.
+
 config SENSORS_ATXP1
 tristate "Attansic ATXP1 VID controller"
 depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475)+= adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC)+= applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCPI)+= scpi-hwmon.o
 obj-$(CONFIG_S

Re: [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach

[Guenter Roeck]

On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:

The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 


Applied.

Thanks,
Guenter


---
 v6
- Corrected odd line breaks
- Changed upto to up to
- Dropped unrelated changes
- Removed struct and used regs pointer directly
- Made groups to be null terminated
- Made correction in calculation of val/raw_data
- Removed else after return
- Removed unnecessary continuation lines

 v5:
- Changed the driver to suit the changes in the device tree documentation

 v4:
- Modified this driver to suit the representation in the devicetree

 v3:
- Only sent out device tree documentation; did not send this driver

 v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes

 Documentation/hwmon/aspeed-pwm-tacho |  22 +
 drivers/hwmon/Kconfig|   9 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c | 846 +++
 4 files changed, 878 insertions(+)
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

diff --git a/Documentation/hwmon/aspeed-pwm-tacho 
b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index ..7cfb34977460
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==
+
+Supported chips:
+   ASPEED AST2400/2500
+
+Authors:
+   
+
+Description:
+
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+fanX_input ro  provide current fan rotation value in RPM as reported
+   by the fan to the device.
+
+pwmX   rw  get or set PWM fan control value. This is an integer
+   value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..757b5b0705bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
  This driver can also be built as a module.  If so, the module
  will be called asb100.

+config SENSORS_ASPEED
+   tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+   help
+ This driver provides support for ASPEED AST2400/AST2500 PWM
+ and Fan Tacho controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
 config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
 obj-$(CONFIG_SENSORS_ASC7621)  += asc7621.o
+obj-$(CONFIG_SENSORS_ASPEED)   += aspeed-pwm-tacho.o
 obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
 obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
 obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
new file mode 100644
index ..29010ad94208
--- /dev/null
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -0,0 +1,846 @@
+/*
+ * Copyright (c) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ASPEED PWM & FAN Tach Register Definition */
+#define ASPEED_PTCR_CTRL   0x00
+#define ASPEED_PTCR_CLK_CTRL   0x04
+#define ASPEED_PTCR_DUTY0_CTRL 0x08
+#define ASPEED_PTCR_DUTY1_CTRL 0x0c
+#define ASPEED_PTCR_TYPEM_CTRL 0x10
+#define ASPEED_PTCR_TYPEM_CTRL10x14
+#define 

Re: [PATCH linux v6 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver

[Guenter Roeck]

On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:

This binding provides interface for adding values related to ASPEED
AST2400/2500 PWM and Fan tach controller support.
The PWM controller can support upto 8 PWM output ports.
The Fan tach controller can support upto 16 tachometer inputs.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 


Applied with Acked-by: From Rob (for v5 with the requested changes made).

Thanks,
Guenter


---
 v6:
- Changed to aspeed,fan-tach-ch

 v5:
- Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
- Removed gpio pin muxing
- Added aspeed vendor prefix for fan-tach-ch
- Changed to fan@0/1
- Changed reg to 32 bits

 v4:
- Used 'reg'

 v3:
- Made the structure more common

 v2:
- Removed '_' in node and property names
- Gave some explanation for the properties used

 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt

diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt 
b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
new file mode 100644
index ..ac0a69ab0755
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -0,0 +1,68 @@
+ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 8 fans supported. Each fan can have one PWM output and
+one/two Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 1.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
+  "aspeed,ast2500-pwm-tacho" for AST2500.
+
+- clocks : a fixed clock providing input clock frequency(PWM
+  and Fan Tach clock)
+
+fan subnode format:
+===
+Under fan subnode there can upto 8 child nodes, with each child node
+representing a fan. If there are 8 fans each fan can have one PWM port and
+one/two Fan tach inputs.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+   integer value in the range 0 to 7 with 0 indicating PWM port A and
+   7 indicating PWM port H.
+
+- aspeed,fan-tach-ch : should specify the Fan tach input channel.
+integer value in the range 0 through 15, with 0 indicating
+   Fan tach channel 0 and 15 indicating Fan tach channel 15.
+   Atleast one Fan tach input channel is required.
+
+Examples:
+
+pwm_tacho_fixed_clk: fixedclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+}
+
+pwm_tacho: pwmtachocontroller@1e786000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x1E786000 0x1000>;
+   compatible = "aspeed,ast2500-pwm-tacho";
+   clocks = <_tacho_fixed_clk>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm0_default _pwm1_default>;
+
+   fan@0 {
+   reg = <0x00>;
+   aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+   };
+
+   fan@1 {
+   reg = <0x01>;
+   aspeed,fan-tach-ch = /bits/ 8 <0x01 0x02>;
+   };
+};
--
2.12.2.715.g7642488e1d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v9 2/5] hwmon: occ: Add sysfs interface

[Guenter Roeck]

On 03/14/2017 01:55 PM, Eddie James wrote:

From: "Edward A. James" 

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

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 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

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d1c863b..580af26 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -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.  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_input - frequency value
+   in_label - sensor id
+temperature:
+   POWER8:
+   temp_input - temperature value
+   temp_label - sensor id
+   POWER9 (in addition to above):
+   temp_type - FRU type
+
+power:
+   POWER8:
+   power_input - power value
+   power_label - sensor id
+   power_average - accumulator
+   power_average_interval - update tag (number of samples in
+   accumulator)
+   POWER9:
+   power_input - power value
+   power_label - sensor id
+   power_average_min - accumulator[0]
+   power_average_max - accumulator[1] (64 bits total)
+   power_average_interval - update tag
+   power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+   POWER8:
+   power_cap - current powercap
+   power_cap_max - max powercap
+   power_cap_min - min powercap
+   power_max - normal powercap
+   power_alarm - user powercap, r/w
+   POWER9:
+   power_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
 -

diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 3ed79a5..67b5367 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..50b20e2
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#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 

Re: [PATCH linux v5 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach

[Guenter Roeck]

On 03/24/2017 11:17 AM, Jaghathiswari Rankappagounder Natarajan wrote:

The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values
are read from the device tree and written to the respective registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the
fan tach rpm value.



Odd line breaks.


Signed-off-by: Jaghathiswari Rankappagounder Natarajan 
---
 v5:
- Changed the driver to suit the changes in the device tree documentation

 v4:
- Modified this driver to suit the representation in the devicetree

 v3:
- Only sent out device tree documentation; did not send this driver

 v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes

 Documentation/hwmon/aspeed-pwm-tacho |  22 +
 drivers/hwmon/Kconfig|  13 +-
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c | 854 +++
 4 files changed, 888 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

diff --git a/Documentation/hwmon/aspeed-pwm-tacho 
b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index ..0e9ec6d5f900
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==
+
+Supported chips:
+   ASPEED AST2400/2500
+
+Authors:
+   
+
+Description:
+
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports upto 16 tachometer inputs.
+

up to


+The driver provides the following sensor accesses in sysfs:
+
+fanX_input ro  provide current fan rotation value in RPM as reported
+   by the fan to the device.
+
+pwmX   rw  get or set PWM fan control value. This is an integer
+   value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..487110f21827 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
  This driver can also be built as a module.  If so, the module
  will be called asb100.

+config SENSORS_ASPEED
+   tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+   help
+ This driver provides support for ASPEED AST2400/AST2500 PWM
+ and Fan Tacho controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
 config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
@@ -952,7 +961,7 @@ config SENSORS_LM70
help
  If you say yes here you get support for the National Semiconductor
  LM70, LM71, LM74 and Texas Instruments TMP121/TMP123 digital tempera-
- ture sensor chips.
+ true sensor chips.


Unrelated. Please drop. Separate patch would be appreciated, of course.



  This driver can also be built as a module.  If so, the module
  will be called lm70.
@@ -1506,7 +1515,7 @@ config SENSORS_ADS7871

 config SENSORS_AMC6821
tristate "Texas Instruments AMC6821"
-   depends on I2C
+   depends on I2C


Unrelated. Please drop.


help
  If you say yes here you get support for the Texas Instruments
  AMC6821 hardware monitoring chips.
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
 obj-$(CONFIG_SENSORS_ASC7621)  += asc7621.o
+obj-$(CONFIG_SENSORS_ASPEED)   += aspeed-pwm-tacho.o
 obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
 obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
 obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
new file mode 100644
index ..2cc34555
--- /dev/null
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -0,0 +1,854 @@
+/*
+ * Copyright (c) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later as
+ * published by the Free Software Foundation.
+ */

Re: [RFC 2/2] hwmon: powernv: Hwmon driver for OCC inband power and temperature sensors

[Guenter Roeck]

On 03/09/2017 05:30 AM, Shilpasri G Bhat wrote:

Hi Guenter,

On 03/09/2017 05:40 PM, Guenter Roeck wrote:

On Thu, Mar 09, 2017 at 05:19:15PM +0530, Shilpasri G Bhat wrote:

Add support to read power and temperature sensors from OCC inband
sensors which are copied to main memory by OCC.



Is this supposed to be an alternative to the submission from
Eddie James ? If so, is there a reason to consider such an
alternative ?



This is not an alternative submission. Eddie James' hwmon OCC driver is to
export the sensors in BMC which is a service processor for POWER{8,9} servers.
This patch adds a hwmon driver in the POWER9 server.



Both are names ...occ... kind of difficult to understand what is what.

Either case, it appears that there are some dependencies to other code
which I was not copied on. that is not very helpful.

Please use the new hwmon API (devm_hwmon_device_register_with_info); this driver
seems to be a perfect candidate. Also, please do not use function macros;
those tend to obfuscate the code and make it hard to understand.
With the new API, such macros should not be necessary.
Couple of additional comments inline.

Thanks,
Guenter


Thanks and Regards,
Shilpa


Thanks,
Guenter


Signed-off-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
CC: Rob Herring <robh...@kernel.org>
CC: Mark Rutland <mark.rutl...@arm.com>
CC: Jean Delvare <jdelv...@suse.com>
CC: Guenter Roeck <li...@roeck-us.net>
CC: Jonathan Corbet <cor...@lwn.net>
CC: devicet...@vger.kernel.org
CC: linux-hwmon@vger.kernel.orgThat
CC: linux-doc@vger.kernel.org
---
 .../devicetree/bindings/hwmon/ibmpowernv-occ.txt   |   4 +
 Documentation/hwmon/ibmpowernv-occ |  24 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/ibmpowernv-occ.c | 302 +
 5 files changed, 342 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt
 create mode 100644 Documentation/hwmon/ibmpowernv-occ
 create mode 100644 drivers/hwmon/ibmpowernv-occ.c

diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt 
b/Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt
new file mode 100644
index 000..d03f744
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt
@@ -0,0 +1,4 @@
+IBM POWERNV OCC inband platform sensors
+
+Required device-tree property:
+- compatible: "ibm,p9-occ-inband-sensor"
diff --git a/Documentation/hwmon/ibmpowernv-occ 
b/Documentation/hwmon/ibmpowernv-occ
new file mode 100644
index 000..151028b
--- /dev/null
+++ b/Documentation/hwmon/ibmpowernv-occ
@@ -0,0 +1,24 @@
+Kernel driver ibmpowernv-occ
+=
+
+Supported systems:
+ * P9 server based on POWERNV platform
+
+Description
+
+
+This driver exports the power and temperature sensors from OCC inband
+sensors on P9 POWERNV platforms.
+
+Sysfs attributes
+
+
+powerX_input   Latest power reading
+powerX_input_highest   Minimum power
+powerX_input_lowestMaximum power
+powerX_label   Sensor name
+
+tempX_inputLatest temperature reading
+tempX_max  Minimum temperature
+tempX_min  Maximum temperature
+tempX_labelSensor name
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0649d53f3..3b1dbb9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -598,6 +598,17 @@ config SENSORS_IBMPOWERNV
  This driver can also be built as a module. If so, the module
  will be called ibmpowernv.

+config SENSORS_IBMPOWERNV_OCC
+   tristate "IBM POWERNV OCC Inband platform sensors"
+   depends on PPC_POWERNV
+   default y
+   help
+ If you say yes here you get support for the temperature/power
+ OCC inband sensors on your PowerNV platform.
+
+ This driver can also be built as a module. If so, the module
+ will be called ibmpowernv-occ.
+
 config SENSORS_IIO_HWMON
tristate "Hwmon driver that uses channels specified via iio maps"
depends on IIO
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5509edf..0da2207 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
 obj-$(CONFIG_SENSORS_IBMAEM)   += ibmaem.o
 obj-$(CONFIG_SENSORS_IBMPEX)   += ibmpex.o
 obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
+obj-$(CONFIG_SENSORS_IBMPOWERNV_OCC)+= ibmpowernv-occ.o
 obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
 obj-$(CONFIG_SENSORS_INA209)   += ina209.o
 obj-$(CONFIG_SENSORS_INA2XX)   += ina2xx.o
diff --git a/drivers/hwmon/ibmpowernv-occ.c b/drivers/hwmon/ibmpowernv-occ.c
new file mode 100644
index 000..97b1bbe
--- /dev/null
+++ b/drivers/hwmon/ibmpowernv-occ.c
@@ -0,0 +1,302 @@
+/*
+ * IBM PowerNV platform O

Re: [PATCH linux v8 2/6] hwmon: occ: Add sysfs interface

[Guenter Roeck]

On 02/14/2017 12:34 PM, Eddie James wrote:

From: "Edward A. James" 

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

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ   |  62 +++
 drivers/hwmon/occ/Makefile|   2 +-
 drivers/hwmon/occ/occ_sysfs.c | 245 ++
 drivers/hwmon/occ/occ_sysfs.h |  25 +
 4 files changed, 333 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d1c863b..580af26 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -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.  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_input - frequency value
+   in_label - sensor id
+temperature:
+   POWER8:
+   temp_input - temperature value
+   temp_label - sensor id
+   POWER9 (in addition to above):
+   temp_type - FRU type
+
+power:
+   POWER8:
+   power_input - power value
+   power_label - sensor id
+   power_average - accumulator
+   power_average_interval - update tag (number of samples in
+   accumulator)
+   POWER9:
+   power_input - power value
+   power_label - sensor id
+   power_average_min - accumulator[0]
+   power_average_max - accumulator[1] (64 bits total)
+   power_average_interval - update tag
+   power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+   POWER8:
+   power_cap - current powercap
+   power_cap_max - max powercap
+   power_cap_min - min powercap
+   power_max - normal powercap
+   power_alarm - user powercap, r/w
+   POWER9:
+   power_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
 -

diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 3ed79a5..67b5367 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o
+obj-$(CONFIG_SENSORS_IBM_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..d6baf8d
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,245 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define OCC_HWMON_NAME_LENGTH  32
+
+struct occ_sysfs {
+   struct device *dev;
+   struct occ *occ;
+
+   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,

Re: [RFC 2/2] hwmon: powernv: Hwmon driver for OCC inband power and temperature sensors

[Guenter Roeck]

On Thu, Mar 09, 2017 at 05:19:15PM +0530, Shilpasri G Bhat wrote:
> Add support to read power and temperature sensors from OCC inband
> sensors which are copied to main memory by OCC.
>

Is this supposed to be an alternative to the submission from 
Eddie James ? If so, is there a reason to consider such an
alternative ?

Thanks,
Guenter

> Signed-off-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
> CC: Rob Herring <robh...@kernel.org>
> CC: Mark Rutland <mark.rutl...@arm.com>
> CC: Jean Delvare <jdelv...@suse.com>
> CC: Guenter Roeck <li...@roeck-us.net>
> CC: Jonathan Corbet <cor...@lwn.net>
> CC: devicet...@vger.kernel.org
> CC: linux-hw...@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> ---
>  .../devicetree/bindings/hwmon/ibmpowernv-occ.txt   |   4 +
>  Documentation/hwmon/ibmpowernv-occ |  24 ++
>  drivers/hwmon/Kconfig  |  11 +
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/ibmpowernv-occ.c | 302 
> +
>  5 files changed, 342 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt
>  create mode 100644 Documentation/hwmon/ibmpowernv-occ
>  create mode 100644 drivers/hwmon/ibmpowernv-occ.c
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt 
> b/Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt
> new file mode 100644
> index 000..d03f744
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv-occ.txt
> @@ -0,0 +1,4 @@
> +IBM POWERNV OCC inband platform sensors
> +
> +Required device-tree property:
> +- compatible: "ibm,p9-occ-inband-sensor"
> diff --git a/Documentation/hwmon/ibmpowernv-occ 
> b/Documentation/hwmon/ibmpowernv-occ
> new file mode 100644
> index 000..151028b
> --- /dev/null
> +++ b/Documentation/hwmon/ibmpowernv-occ
> @@ -0,0 +1,24 @@
> +Kernel driver ibmpowernv-occ
> +=
> +
> +Supported systems:
> + * P9 server based on POWERNV platform
> +
> +Description
> +
> +
> +This driver exports the power and temperature sensors from OCC inband
> +sensors on P9 POWERNV platforms.
> +
> +Sysfs attributes
> +
> +
> +powerX_input Latest power reading
> +powerX_input_highest Minimum power
> +powerX_input_lowest  Maximum power
> +powerX_label Sensor name
> +
> +tempX_input  Latest temperature reading
> +tempX_maxMinimum temperature
> +tempX_minMaximum temperature
> +tempX_label  Sensor name
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0649d53f3..3b1dbb9 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -598,6 +598,17 @@ config SENSORS_IBMPOWERNV
> This driver can also be built as a module. If so, the module
> will be called ibmpowernv.
>  
> +config SENSORS_IBMPOWERNV_OCC
> + tristate "IBM POWERNV OCC Inband platform sensors"
> + depends on PPC_POWERNV
> + default y
> + help
> +   If you say yes here you get support for the temperature/power
> +   OCC inband sensors on your PowerNV platform.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called ibmpowernv-occ.
> +
>  config SENSORS_IIO_HWMON
>   tristate "Hwmon driver that uses channels specified via iio maps"
>   depends on IIO
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 5509edf..0da2207 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -75,6 +75,7 @@ obj-$(CONFIG_SENSORS_I5K_AMB)   += i5k_amb.o
>  obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
>  obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
>  obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
> +obj-$(CONFIG_SENSORS_IBMPOWERNV_OCC)+= ibmpowernv-occ.o
>  obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
>  obj-$(CONFIG_SENSORS_INA209) += ina209.o
>  obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
> diff --git a/drivers/hwmon/ibmpowernv-occ.c b/drivers/hwmon/ibmpowernv-occ.c
> new file mode 100644
> index 000..97b1bbe
> --- /dev/null
> +++ b/drivers/hwmon/ibmpowernv-occ.c
> @@ -0,0 +1,302 @@
> +/*
> + * IBM PowerNV platform OCC inband sensors for temperature/power
> + * Copyright (C) 2017 IBM
> + *
> + * 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.
> + *
> + * This program is d

Re: [PATCH linux v8 0/6] drivers: hwmon: Add On-Chip Controller driver

[Guenter Roeck]

On Thu, Feb 23, 2017 at 04:43:20PM -0600, Edward James wrote:
> Hi Guenter,
> 
> Any thoughts on this patch set? Others welcome to chime in too.
> 
Sorry, I have been busy. Weekend or next week, hopefully.

Guenter

> Thanks,
> Eddie
> 
> Eddie James  wrote on 02/14/2017 02:34:17 PM:
> 
> > From: Eddie James 
> > To: li...@roeck-us.net
> > Cc: devicet...@vger.kernel.org, linux-ker...@vger.kernel.org, linux-
> > hw...@vger.kernel.org, linux-doc@vger.kernel.org, jdelv...@suse.com,
> > cor...@lwn.net, mark.rutl...@arm.com, robh...@kernel.org, wsa@the-
> > dreams.de, and...@aj.id.au, b...@kernel.crashing.org,
> > j...@jms.id.au, Edward James/Austin/IBM@IBMUS
> > Date: 02/14/2017 02:34 PM
> > Subject: [PATCH linux v8 0/6] drivers: hwmon: Add On-Chip Controller
> driver
> >
> > From: "Edward A. James" 
> >
> > This patchset adds a hwmon driver to support the OCC (On-Chip Controller)
> > on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management
> > Controller). The OCC is an embedded processor that provides real time
> > power and thermal monitoring.
> >
> > The driver provides an interface on a BMC to poll OCC sensor data, set
> > user power caps, and perform some basic OCC error handling. It interfaces
> > with userspace through hwmon.
> >
> > The driver is currently functional only for the OCC on POWER8 chips.
> > Communicating with the POWER9 OCC requries FSI support.
> >
> > Since v7:
> >  * change Makefile and Kconfig to build a single module for the driver
> >  * include p9 file in build
> >  * change Kconfig from "PPC" to "IBM"
> >  * remove EXPORT_SYMBOL
> >  * bundle occ_config and occ_ops structures into occ_init_data structure
> >  * few style tweaks suggested by Joel
> >
> > Edward A. James (6):
> >   hwmon: Add core On-Chip Controller support for POWER CPUs
> >   hwmon: occ: Add sysfs interface
> >   hwmon: occ: Add I2C transport implementation for SCOM operations
> >   hwmon: occ: Add callbacks for parsing P8 OCC datastructures
> >   hwmon: occ: Add hwmon implementation for the P8 OCC
> >   hwmon: occ: Add callbacks for parsing P9 OCC datastructures
> >
> >  Documentation/devicetree/bindings/hwmon/occ.txt |  13 +
> >  Documentation/hwmon/occ | 116 +++
> >  MAINTAINERS |   7 +
> >  drivers/hwmon/Kconfig   |   2 +
> >  drivers/hwmon/Makefile  |   1 +
> >  drivers/hwmon/occ/Kconfig   |  39 +++
> >  drivers/hwmon/occ/Makefile  |   5 +
> >  drivers/hwmon/occ/occ.c | 440 +
> > +++
> >  drivers/hwmon/occ/occ.h |  77 +
> >  drivers/hwmon/occ/occ_p8.c  | 256 ++
> >  drivers/hwmon/occ/occ_p8.h  |  25 ++
> >  drivers/hwmon/occ/occ_p8_i2c.c  |  99 ++
> >  drivers/hwmon/occ/occ_p9.c  | 320 +
> >  drivers/hwmon/occ/occ_p9.h  |  25 ++
> >  drivers/hwmon/occ/occ_scom_i2c.c|  69 
> >  drivers/hwmon/occ/occ_scom_i2c.h|  21 ++
> >  drivers/hwmon/occ/occ_sysfs.c   | 245 +
> >  drivers/hwmon/occ/occ_sysfs.h   |  25 ++
> >  drivers/hwmon/occ/scom.h|  42 +++
> >  19 files changed, 1827 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/occ.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/occ.c
> >  create mode 100644 drivers/hwmon/occ/occ.h
> >  create mode 100644 drivers/hwmon/occ/occ_p8.c
> >  create mode 100644 drivers/hwmon/occ/occ_p8.h
> >  create mode 100644 drivers/hwmon/occ/occ_p8_i2c.c
> >  create mode 100644 drivers/hwmon/occ/occ_p9.c
> >  create mode 100644 drivers/hwmon/occ/occ_p9.h
> >  create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
> >  create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
> >  create mode 100644 drivers/hwmon/occ/occ_sysfs.c
> >  create mode 100644 drivers/hwmon/occ/occ_sysfs.h
> >  create mode 100644 drivers/hwmon/occ/scom.h
> >
> > --
> > 1.8.3.1
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: hwmon: Fix typo "Microship" should be "Microchip"

[Guenter Roeck]

On Tue, Feb 21, 2017 at 10:30:47PM +1300, Chris Packham wrote:
> Signed-off-by: Chris Packham 

Applied to -next.

Thanks,
Guenter

> ---
>  Documentation/hwmon/tc654 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
> index 91a2843f5f98..47636a8077b4 100644
> --- a/Documentation/hwmon/tc654
> +++ b/Documentation/hwmon/tc654
> @@ -2,7 +2,7 @@ Kernel driver tc654
>  ===
>  
>  Supported chips:
> -  * Microship TC654 and TC655
> +  * Microchip TC654 and TC655
>  Prefix: 'tc654'
>  Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
>  
> -- 
> 2.11.0.24.ge6920cf
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v7 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures

[Guenter Roeck]

On Mon, Feb 13, 2017 at 11:47:22AM +1030, Andrew Jeffery wrote:
> On Fri, 2017-02-10 at 16:01 +1030, Joel Stanley wrote:
> > > On Wed, Feb 8, 2017 at 9:40 AM,   wrote:
> > > > > From: "Edward A. James" 
> > > 
> > > Add functions to parse the data structures that are specific to the OCC on
> > > the POWER8 processor. These are the sensor data structures, including
> > > temperature, frequency, power, and "caps."
> > > 
> > > > > Signed-off-by: Edward A. James 
> > > > > Signed-off-by: Andrew Jeffery 
> > > ---
> > >  Documentation/hwmon/occ|   9 ++
> > >  drivers/hwmon/occ/occ_p8.c | 248 
> > > +
> > >  drivers/hwmon/occ/occ_p8.h |  30 ++
> > >  3 files changed, 287 insertions(+)
> > >  create mode 100644 drivers/hwmon/occ/occ_p8.c
> > >  create mode 100644 drivers/hwmon/occ/occ_p8.h
> > > 
> > > diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
> > > new file mode 100644
> > > index 000..5c61fc4
> > > --- /dev/null
> > > +++ b/drivers/hwmon/occ/occ_p8.c
> > > +void p8_parse_sensor(u8 *data, void *sensor, int sensor_type, int off,
> > > +int snum)
> > > +{
> > > +   switch (sensor_type) {
> > > +   case FREQ:
> > > +   case TEMP:
> > > +   {
> > > +   struct p8_occ_sensor *os =
> > > +   &(((struct p8_occ_sensor *)sensor)[snum]);
> > > +
> > > +   os->sensor_id = be16_to_cpu(get_unaligned((u16 
> > > *)[off]));
> > > +   os->value = be16_to_cpu(get_unaligned((u16 *)[off + 
> > > 2]));
> > > +   }
> > > +   break;
> > > +   case POWER:
> > > +   {
> > > +   struct p8_power_sensor *ps =
> > > +   &(((struct p8_power_sensor *)sensor)[snum]);
> > > +
> > > +   ps->sensor_id = be16_to_cpu(get_unaligned((u16 
> > > *)[off]));
> > > +   ps->update_tag =
> > > +   be32_to_cpu(get_unaligned((u32 *)[off + 2]));
> > 
> > This might be more readable if you wrote a
> > cast_get_unaliged_be32_to_cpu() macro.
> > 
> > > +   ps->accumulator =
> > > +   be32_to_cpu(get_unaligned((u32 *)[off + 6]));
> > > +   ps->value = be16_to_cpu(get_unaligned((u16 *)[off + 
> > > 10]));
> > > +   }
> > > +   break;
> > > +   case CAPS:
> > > +   {
> > > +const u32 *p8_get_sensor_hwmon_configs()
> > > +{
> > > +   return p8_sensor_hwmon_configs;
> > > +}
> > > +EXPORT_SYMBOL(p8_get_sensor_hwmon_configs);
> > > +
> > > +struct occ *p8_occ_start(struct device *dev, void *bus,
> > > +struct occ_bus_ops *bus_ops)
> > > +{
> > > +   return occ_start(dev, bus, bus_ops, _ops, _config);
> > > +}
> > > +EXPORT_SYMBOL(p8_occ_start);
> > 
> > We don't need to export these symbols; they're not used outside of the
> > OCC module. The same goes for all of the exports you've made in this
> > series.
> 
> Sorry, this was my doing in an attempt to get everything to build as
> modules rather than just built-in. I should have studied
> Documentation/kbuild/modules.txt a bit more.
> 
> > 
> > I suggest we re-architect the drivers so we build all of the objects
> > and link them into one module for each platform, instead of having an
> > occ module and occ-p8/occ-p9 modules and i2c modules that all depend
> > on each other. The Makefile could look like this:
> > 
> > obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += hwmon_occ_p8.o
> > obj-$(CONFIG_SENSORS_PPC_OCC_P9) += hwmon_occ_p9.o
> > 
> > hwmon_occ_p8-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o
> > occ_p8.o p8_occ_i2c.o occ_sysfs.o occ.o
> > hwmon_occ_p9-$(CONFIG_SENSORS_PPC_OCC_P9) += occ_p9.o occ_sysfs.o occ.o
> > 
Please note that the above will still result in separate modules,
one per object file. Is this really what you want ? I don't even
know what happens if an object file is specified twice, so
you may also have to make sure that CONFIG_SENSORS_PPC_OCC_P8_I2C
and CONFIG_SENSORS_PPC_OCC_P9 are either-or configurations.
Again, I am not really sure if that is what you want.

> > And the Kbuild like this:
> > 
> > menuconfig SENSORS_PPC_OCC
> > bool "PPC On-Chip Controller"
> > 
> > if SENSORS_PPC_OCC
> > 
> > config SENSORS_PPC_OCC_P8_I2C
> > bool "POWER8 OCC hwmon support"
> > depends on I2C
> > 
> > config SENSORS_PPC_OCC_P9
> > bool "POWER9 OCC hwmon support"
> > 
If both are bool, ie there won't be any module support,
I don't really see the point of specifying occ_sysfs.o and
occ.o twice above.

> > endif
> 
> Given we can drop the exports that's a much more sensible idea.
> 
Please make sure that both "allmodconfig" and "allyesconfig"
still build after this change.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo 

Re: [PATCH linux v4 2/6] hwmon: occ: Add sysfs interface

[Guenter Roeck]

On 01/26/2017 03:19 PM, eajames@gmail.com wrote:

From: "Edward A. James" 

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

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ   |  62 ++
 drivers/hwmon/occ/Makefile|   2 +-
 drivers/hwmon/occ/occ_sysfs.c | 259 ++
 drivers/hwmon/occ/occ_sysfs.h |  30 +
 4 files changed, 352 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwmon/occ/occ_sysfs.c
 create mode 100644 drivers/hwmon/occ/occ_sysfs.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 79d1642..d0bdf06 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,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.  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_input - frequency value
+   in_label - sensor id
+temperature:
+   POWER8:
+   temp_input - temperature value
+   temp_label - sensor id
+   POWER9 (in addition to above):
+   temp_type - FRU type
+
+power:
+   POWER8:
+   power_input - power value
+   power_label - sensor id
+   power_average - accumulator
+   power_average_interval - update tag (number of samples in
+   accumulator)
+   POWER9:
+   power_input - power value
+   power_label - sensor id
+   power_average_min - accumulator[0]
+   power_average_max - accumulator[1] (64 bits total)
+   power_average_interval - update tag
+   power_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+   POWER8:
+   power_cap - current powercap
+   power_cap_max - max powercap
+   power_cap_min - min powercap
+   power_max - normal powercap
+   power_alarm - user powercap, r/w
+   POWER9:
+   power_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
 -

diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 93cb52f..a6881f9 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 000..ea2aa04
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,259 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2016 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define RESP_RETURN_CMD_INVAL  0x13
+#define OCC_HWMON_NAME_LENGTH  32
+
+struct occ_sysfs {
+   struct device *dev;
+   struct occ 

Re: [PATCH linux v4 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

[Guenter Roeck]

On 01/26/2017 03:19 PM, eajames@gmail.com wrote:

From: "Edward A. James" 

Add core support for polling the OCC for it's sensor data and parsing that
data into sensor-specific information.

Signed-off-by: Edward A. James 
Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/occ|  40 
 MAINTAINERS|   7 +
 drivers/hwmon/Kconfig  |   2 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/occ/Kconfig  |  15 ++
 drivers/hwmon/occ/Makefile |   1 +
 drivers/hwmon/occ/occ.c| 479 +
 drivers/hwmon/occ/occ.h|  80 
 drivers/hwmon/occ/scom.h   |  47 +
 9 files changed, 672 insertions(+)
 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/occ.c
 create mode 100644 drivers/hwmon/occ/occ.h
 create mode 100644 drivers/hwmon/occ/scom.h

diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,40 @@
+Kernel driver occ
+=
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
+
+Please note that the chip must be connected to a POWER8 or POWER9 processor
+(see the BMC - Host Communications section).
+
+Author: Eddie James 
+
+Description
+---
+
+This driver implements support for the OCC (On-Chip Controller) on the IBM
+POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The
+OCC is an embedded processor that provides real time power and thermal
+monitoring.
+
+This driver provides an interface on a BMC to poll OCC sensor data, set user
+power caps, and perform some basic OCC error handling.
+
+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.
+
+BMC - Host Communications
+-
+
+For the POWER8 application, the BMC can communicate with the P8 over I2C bus.
+However, to access the OCC register space, any data transfer must use a SCOM
+operation. SCOM is a procedure to initiate a data transfer, typically of 8
+bytes. SCOMs consist of writing a 32-bit command register and then
+reading/writing two 32-bit data registers. This driver implements these
+SCOM operations over I2C bus in order to communicate with the OCC.
+
+For the POWER9 application, the BMC can communicate with the P9 over FSI bus
+and SBE engine. Once again, SCOM operations are required. This driver will
+implement SCOM ops over FSI/SBE. This will require the FSI driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f0420a..f5d4195 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9112,6 +9112,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/ov7670.c

+ON-CHIP CONTROLLER HWMON DRIVER
+M: Eddie James 
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/occ
+F: drivers/hwmon/occ/
+
 ONENAND FLASH DRIVER
 M: Kyungmin Park 
 L: linux-...@lists.infradead.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 190d270..e80ca81 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1240,6 +1240,8 @@ config SENSORS_NSA320
  This driver can also be built as a module. If so, the module
  will be called nsa320-hwmon.

+source drivers/hwmon/occ/Kconfig
+
 config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2cb7e8..c7ec5d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o

+obj-$(CONFIG_SENSORS_PPC_OCC)  += occ/
 obj-$(CONFIG_PMBUS)+= pmbus/

 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 000..cdb64a7
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,15 @@
+#
+# On Chip Controller configuration
+#
+
+menuconfig SENSORS_PPC_OCC
+   bool "PPC On-Chip Controller"
+   help
+ If you say yes here you get support to monitor Power CPU
+ sensors via the On-Chip Controller (OCC).
+
+ Generally this is used by management controllers such as a BMC
+ on an OpenPower system.
+
+ This driver can also be built as a module. If so, the module
+ will be called occ.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 000..93cb52f
--- /dev/null
+++ b/drivers/hwmon/occ/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SENSORS_PPC_OCC) 

[PATCH] watchdog: Introduce watchdog_stop_on_unregister helper

[Guenter Roeck]

Many watchdog drivers explicitly stop the watchdog when unregistering it.
While it is unclear if this is actually needed (the whatdog should not be
running at that time if it can be stopped), introduce a helper to
explicitly stop the watchdog in the watchdog core when unregistering it.
This helps reducing driver code size while retaining functionality.

Signed-off-by: Guenter Roeck <li...@roeck-us.net>
---
 Documentation/watchdog/watchdog-kernel-api.txt |  6 ++
 drivers/watchdog/watchdog_dev.c|  5 +
 include/linux/watchdog.h   | 10 ++
 3 files changed, 21 insertions(+)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index ea277478982f..9b93953f69cf 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -280,6 +280,12 @@ To disable the watchdog on reboot, the user must call the 
following helper:
 
 static inline void watchdog_stop_on_reboot(struct watchdog_device *wdd);
 
+To disable the watchdog when unregistering the watchdog, the user must call
+the following helper. Note that this will only stop the watchdog if the
+nowayout flag is not set.
+
+static inline void watchdog_stop_on_unregister(struct watchdog_device *wdd);
+
 To change the priority of the restart handler the following helper should be
 used:
 
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 32930a073a12..d5d2bbd8f428 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -987,6 +987,11 @@ static void watchdog_cdev_unregister(struct 
watchdog_device *wdd)
wdd->wd_data = NULL;
mutex_unlock(_data->lock);
 
+   if (watchdog_active(wdd) &&
+   test_bit(WDOG_STOP_ON_UNREGISTER, >status)) {
+   watchdog_stop(wdd);
+   }
+
cancel_delayed_work_sync(_data->work);
 
kref_put(_data->kref, watchdog_core_data_release);
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 35a4d8185b51..b0df1b987d82 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -117,6 +117,7 @@ struct watchdog_device {
 #define WDOG_NO_WAY_OUT1   /* Is 'nowayout' feature set ? 
*/
 #define WDOG_STOP_ON_REBOOT2   /* Should be stopped on reboot */
 #define WDOG_HW_RUNNING3   /* True if HW watchdog running 
*/
+#define WDOG_STOP_ON_UNREGISTER4   /* Should be stopped on 
unregister */
struct list_head deferred;
 };
 
@@ -151,6 +152,15 @@ static inline void watchdog_stop_on_reboot(struct 
watchdog_device *wdd)
set_bit(WDOG_STOP_ON_REBOOT, >status);
 }
 
+/*
+ * Use the following function to stop the watchdog when unregistering the
+ * watchdog
+ */
+static inline void watchdog_stop_on_unregister(struct watchdog_device *wdd)
+{
+   set_bit(WDOG_STOP_ON_UNREGISTER, >status);
+}
+
 /* Use the following function to check if a timeout value is invalid */
 static inline bool watchdog_timeout_invalid(struct watchdog_device *wdd, 
unsigned int t)
 {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v3 2/6] hwmon: occ: Add sysfs interface

[Guenter Roeck]

On Mon, Jan 23, 2017 at 04:01:25PM -0600, Edward James wrote:
> 
> 
> On Sat, Jan 21, 2017 at 12:08 PM, Guenter Roeck <li...@roeck-us.net> wrote:
> > On 01/16/2017 01:13 PM, eajames@gmail.com wrote:
> >>
> >> From: "Edward A. James" <eaja...@us.ibm.com>
> >>
> >> Add a generic mechanism to expose the sensors provided by the OCC in
> >> sysfs.
> >>
> >> Signed-off-by: Edward A. James <eaja...@us.ibm.com>
> >> Signed-off-by: Andrew Jeffery <and...@aj.id.au>
> >> ---
> >>  Documentation/hwmon/occ   |  62 ++
> >>  drivers/hwmon/occ/Makefile|   2 +-
> >>  drivers/hwmon/occ/occ_sysfs.c | 271
> >> ++
> >>  drivers/hwmon/occ/occ_sysfs.h |  44 +++
> >>  4 files changed, 378 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/hwmon/occ/occ_sysfs.c
> >>  create mode 100644 drivers/hwmon/occ/occ_sysfs.h
> >>
> >> diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
> >> index 79d1642..d0bdf06 100644
> >> --- a/Documentation/hwmon/occ
> >> +++ b/Documentation/hwmon/occ
> >> @@ -25,6 +25,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. 
> >> 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_input - frequency value
> >> +   in_label - sensor id
> >> +temperature:
> >> +   POWER8:
> >> +   temp_input - temperature value
> >> +   temp_label - sensor id
> >> +   POWER9 (in addition to above):
> >> +   temp_type - FRU type
> >> +
> >> +power:
> >> +   POWER8:
> >> +   power_input - power value
> >> +   power_label - sensor id
> >> +   power_average - accumulator
> >> +   power_average_interval - update tag (number of
> samples
> >> in
> >> +   accumulator)
> >> +   POWER9:
> >> +   power_input - power value
> >> +   power_label - sensor id
> >> +   power_average_min - accumulator[0]
> >> +   power_average_max - accumulator[1] (64 bits total)
> >> +   power_average_interval - update tag
> >> +   power_reset_history - (function_id | (apss_channel <<
> >> 8)
> >> +
> >> +caps:
> >> +   POWER8:
> >> +   power_cap - current powercap
> >> +   power_cap_max - max powercap
> >> +   power_cap_min - min powercap
> >> +   power_max - normal powercap
> >> +   power_alarm - user powercap, r/w
> >> +   POWER9:
> >> +   power_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
> >>

Re: [PATCH linux v3 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs

[Guenter Roeck]

On Mon, Jan 23, 2017 at 01:28:52PM -0600, Edward James wrote:
> I still just can't get gmail to reply to this. Thanks for the review.
> 
> On Sat, Jan 21, 2017 at 11:49 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> > On 01/16/2017 01:13 PM, eajames@gmail.com wrote:
> >>
> >> From: "Edward A. James" <eaja...@us.ibm.com>
> >>
> >> Add core support for polling the OCC for it's sensor data and parsing
> that
> >> data into sensor-specific information.
> >>
> >> Signed-off-by: Edward A. James <eaja...@us.ibm.com>
> >> Signed-off-by: Andrew Jeffery <and...@aj.id.au>
> >> ---
> >>  Documentation/hwmon/occ|  40 
> >>  MAINTAINERS|   7 +
> >>  drivers/hwmon/Kconfig  |   2 +
> >>  drivers/hwmon/Makefile |   1 +
> >>  drivers/hwmon/occ/Kconfig  |  15 ++
> >>  drivers/hwmon/occ/Makefile |   1 +
> >>  drivers/hwmon/occ/occ.c| 522
> >> +
> >>  drivers/hwmon/occ/occ.h|  81 +++
> >>  drivers/hwmon/occ/scom.h   |  47 
> >>  9 files changed, 716 insertions(+)
> >>  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/occ.c
> >>  create mode 100644 drivers/hwmon/occ/occ.h
> >>  create mode 100644 drivers/hwmon/occ/scom.h
> >>
> >> diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
> >> new file mode 100644
> >> index 000..79d1642
> >> --- /dev/null
> >> +++ b/Documentation/hwmon/occ
> >> @@ -0,0 +1,40 @@
> >> +Kernel driver occ
> >> +=
> >> +
> >> +Supported chips:
> >> + * ASPEED AST2400
> >> + * ASPEED AST2500
> >> +
> >> +Please note that the chip must be connected to a POWER8 or POWER9
> >> processor
> >> +(see the BMC - Host Communications section).
> >> +
> >> +Author: Eddie James <eaja...@us.ibm.com>
> >> +
> >> +Description
> >> +---
> >> +
> >> +This driver implements support for the OCC (On-Chip Controller) on the
> >> IBM
> >> +POWER8 and POWER9 processors, from a BMC (Baseboard Management
> >> Controller). The
> >> +OCC is an embedded processor that provides real time power and thermal
> >> +monitoring.
> >> +
> >> +This driver provides an interface on a BMC to poll OCC sensor data, set
> >> user
> >> +power caps, and perform some basic OCC error handling.
> >> +
> >> +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.
> >> +
> >> +BMC - Host Communications
> >> +-
> >> +
> >> +For the POWER8 application, the BMC can communicate with the P8 over
> I2C
> >> bus.
> >> +However, to access the OCC register space, any data transfer must use a
> >> SCOM
> >> +operation. SCOM is a procedure to initiate a data transfer, typically
> of
> >> 8
> >> +bytes. SCOMs consist of writing a 32-bit command register and then
> >> +reading/writing two 32-bit data registers. This driver implements these
> >> +SCOM operations over I2C bus in order to communicate with the OCC.
> >> +
> >> +For the POWER9 application, the BMC can communicate with the P9 over
> FSI
> >> bus
> >> +and SBE engine. Once again, SCOM operations are required. This driver
> >> will
> >> +implement SCOM ops over FSI/SBE. This will require the FSI driver.
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 5f0420a..f5d4195 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -9112,6 +9112,13 @@ T:   git git://linuxtv.org/media_tree.git
> >>  S: Maintained
> >>  F: drivers/media/i2c/ov7670.c
> >>
> >> +ON-CHIP CONTROLLER HWMON DRIVER
> >> +M: Eddie James <eaja...@us.ibm.com>
> >> +L: linux-hw...@vger.kernel.org
> >> +S: Maintained
> >> +F: Documentation/hwmon/occ
> >> +F: drivers/hwmon/occ/
> >> +
> >>  ONENAND FLASH DRIVER
> >>  M: Kyungmin Park <kyungmin.p...@samsung.com>
> &