Re: [PATCH v3] Documentation/process/coding-style.rst: space around const
On Tue, Oct 10, 2023 at 02:58:31PM +0200, Max Kellermann wrote: > There are currently no rules on the placement of "const", but a recent > code submission revealed that there is clearly a preference for spaces > around it. > > checkpatch.pl has no check at all for this; though it does sometimes > complain, but only because it erroneously thinks that the "*" (on > local variables) is an unary dereference operator, not a pointer type. > > Current coding style for const pointers-to-pointers: > > "*const*": 2 occurrences > "* const*": 3 > "*const *": 182 > "* const *": 681 > > Just const pointers: > > "*const": 2833 occurrences > "* const": 16615 > > Link: > https://lore.kernel.org/r/264fa39d-aed6-4a54-a085-107997078...@roeck-us.net/ > Link: > https://lore.kernel.org/r/f511170fe61d7e7214a3a062661cf4103980dad6.ca...@perches.com/ > Signed-off-by: Max Kellermann Reviewed-by: Guenter Roeck > --- > V1 -> V2: removed "volatile" on gregkh's request. > V2 -> V3: moved patch changelog below the "---" line > --- > Documentation/process/coding-style.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/process/coding-style.rst > b/Documentation/process/coding-style.rst > index 6db37a46d305..71d62d81e506 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -271,6 +271,17 @@ adjacent to the type name. Examples: > unsigned long long memparse(char *ptr, char **retptr); > char *match_strdup(substring_t *s); > > +Use space around the ``const`` keyword (except when adjacent to > +parentheses). Example: > + > +.. code-block:: c > + > + const void *a; > + void * const b; > + void ** const c; > + void * const * const d; > + int strcmp(const char *a, const char *b); > + > Use one space around (on each side of) most binary and ternary operators, > such as any of these:: > > -- > 2.39.2 >
Re: [PATCH 04/16] watchdog: remove ks8695 driver
On Fri, Aug 09, 2019 at 10:27:32PM +0200, Arnd Bergmann wrote: > The platform is getting removed, so there are no remaining > users of this driver. > > Signed-off-by: Arnd Bergmann Acked-by: Guenter Roeck Please let me know if this should be applied through the watchdog tree. For now I'll assume it will be applied together with the rest of the series. > --- > .../watchdog/watchdog-parameters.rst | 9 - > drivers/watchdog/Kconfig | 7 - > drivers/watchdog/Makefile | 1 - > drivers/watchdog/ks8695_wdt.c | 319 -- > 4 files changed, 336 deletions(-) > delete mode 100644 drivers/watchdog/ks8695_wdt.c > > diff --git a/Documentation/watchdog/watchdog-parameters.rst > b/Documentation/watchdog/watchdog-parameters.rst > index a3985cc5aeda..226aba56f704 100644 > --- a/Documentation/watchdog/watchdog-parameters.rst > +++ b/Documentation/watchdog/watchdog-parameters.rst > @@ -301,15 +301,6 @@ ixp4xx_wdt: > > - > > -ks8695_wdt: > -wdt_time: > - Watchdog time in seconds. (default=5) > -nowayout: > - Watchdog cannot be stopped once started > - (default=kernel config parameter) > - > -- > - > machzwd: > nowayout: > Watchdog cannot be stopped once started > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 8188963a405b..e631f1ae303a 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -477,13 +477,6 @@ config IXP4XX_WATCHDOG > > Say N if you are unsure. > > -config KS8695_WATCHDOG > - tristate "KS8695 watchdog" > - depends on ARCH_KS8695 > - help > - Watchdog timer embedded into KS8695 processor. This will reboot your > - system when the timeout is reached. > - > config HAVE_S3C2410_WATCHDOG > bool > help > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 7caa920e7e60..85f55ec76f8d 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -49,7 +49,6 @@ obj-$(CONFIG_21285_WATCHDOG) += wdt285.o > obj-$(CONFIG_977_WATCHDOG) += wdt977.o > obj-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o > obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o > -obj-$(CONFIG_KS8695_WATCHDOG) += ks8695_wdt.o > obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o > obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o > obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o > diff --git a/drivers/watchdog/ks8695_wdt.c b/drivers/watchdog/ks8695_wdt.c > deleted file mode 100644 > index 1550ce3c5702.. > --- a/drivers/watchdog/ks8695_wdt.c > +++ /dev/null > @@ -1,319 +0,0 @@ > -// SPDX-License-Identifier: GPL-2.0-only > -/* > - * Watchdog driver for Kendin/Micrel KS8695. > - * > - * (C) 2007 Andrew Victor > - */ > - > -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#define KS8695_TMR_OFFSET(0xF + 0xE400) > -#define KS8695_TMR_VA(KS8695_IO_VA + KS8695_TMR_OFFSET) > - > -/* > - * Timer registers > - */ > -#define KS8695_TMCON (0x00) /* Timer Control Register */ > -#define KS8695_T0TC (0x08) /* Timer 0 Timeout Count > Register */ > -#define TMCON_T0EN (1 << 0)/* Timer 0 Enable */ > - > -/* Timer0 Timeout Counter Register */ > -#define T0TC_WATCHDOG(0xff) /* Enable watchdog mode > */ > - > -#define WDT_DEFAULT_TIME 5 /* seconds */ > -#define WDT_MAX_TIME 171 /* seconds */ > - > -static int wdt_time = WDT_DEFAULT_TIME; > -static bool nowayout = WATCHDOG_NOWAYOUT; > - > -module_param(wdt_time, int, 0); > -MODULE_PARM_DESC(wdt_time, "Watchdog time in seconds. (default=" > - __MODULE_STRING(WDT_DEFAULT_TIME) ")"); > - > -#ifdef CONFIG_WATCHDOG_NOWAYOUT > -module_param(nowayout, bool, 0); > -MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started > (default=" > - __MODULE_STRING(WATCHDOG_NOWAYOUT) ")"); > -#endif > - > - > -static unsigned long ks8695wdt_busy; > -static DEFINE_SPINLOCK(ks8695_lock); > - > -/* . > */ > - > -/* > - * Disable the watchdog. > - */ > -stat
Re: [PATCH 06/16] watchdog: remove w90x900 driver
On Fri, Aug 09, 2019 at 10:27:34PM +0200, Arnd Bergmann wrote: > The ARM w90x900 platform is getting removed, so this driver is obsolete > > Signed-off-by: Arnd Bergmann Acked-by: Guenter Roeck > --- > .../watchdog/watchdog-parameters.rst | 10 - > drivers/watchdog/Kconfig | 9 - > drivers/watchdog/Makefile | 1 - > drivers/watchdog/nuc900_wdt.c | 302 -- > 4 files changed, 322 deletions(-) > delete mode 100644 drivers/watchdog/nuc900_wdt.c > > diff --git a/Documentation/watchdog/watchdog-parameters.rst > b/Documentation/watchdog/watchdog-parameters.rst > index 226aba56f704..223c99361a30 100644 > --- a/Documentation/watchdog/watchdog-parameters.rst > +++ b/Documentation/watchdog/watchdog-parameters.rst > @@ -366,16 +366,6 @@ nic7018_wdt: > > - > > -nuc900_wdt: > -heartbeat: > - Watchdog heartbeats in seconds. > - (default = 15) > -nowayout: > - Watchdog cannot be stopped once started > - (default=kernel config parameter) > - > -- > - > omap_wdt: > timer_margin: > initial watchdog timeout (in seconds) > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index e631f1ae303a..0e64f501ef30 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -655,15 +655,6 @@ config STMP3XXX_RTC_WATCHDOG > To compile this driver as a module, choose M here: the > module will be called stmp3xxx_rtc_wdt. > > -config NUC900_WATCHDOG > - tristate "Nuvoton NUC900 watchdog" > - depends on ARCH_W90X900 || COMPILE_TEST > - help > - Say Y here if to include support for the watchdog timer > - for the Nuvoton NUC900 series SoCs. > - To compile this driver as a module, choose M here: the > - module will be called nuc900_wdt. > - > config TS4800_WATCHDOG > tristate "TS-4800 Watchdog" > depends on HAS_IOMEM && OF > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 85f55ec76f8d..b5a0aed537af 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -63,7 +63,6 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o > obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o > obj-$(CONFIG_NPCM7XX_WATCHDOG) += npcm_wdt.o > obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o > -obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o > obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o > obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o > obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o > diff --git a/drivers/watchdog/nuc900_wdt.c b/drivers/watchdog/nuc900_wdt.c > deleted file mode 100644 > index db124cebe838.. > --- a/drivers/watchdog/nuc900_wdt.c > +++ /dev/null > @@ -1,302 +0,0 @@ > -// SPDX-License-Identifier: GPL-2.0-only > -/* > - * Copyright (c) 2009 Nuvoton technology corporation. > - * > - * Wan ZongShun > - */ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#define REG_WTCR 0x1c > -#define WTCLK(0x01 << 10) > -#define WTE (0x01 << 7) /*wdt enable*/ > -#define WTIS (0x03 << 4) > -#define WTIF (0x01 << 3) > -#define WTRF (0x01 << 2) > -#define WTRE (0x01 << 1) > -#define WTR (0x01 << 0) > -/* > - * The watchdog time interval can be calculated via following formula: > - * WTIS real time interval (formula) > - * 0x00 ((2^ 14 ) * ((external crystal freq) / 256))seconds > - * 0x01 ((2^ 16 ) * ((external crystal freq) / 256))seconds > - * 0x02 ((2^ 18 ) * ((external crystal freq) / 256))seconds > - * 0x03 ((2^ 20 ) * ((external crystal freq) / 256))seconds > - * > - * The external crystal freq is 15Mhz in the nuc900 evaluation board. > - * So 0x00 = +-0.28 seconds, 0x01 = +-1.12 seconds, 0x02 = +-4.48 seconds, > - * 0x03 = +- 16.92 seconds.. > - */ > -#define WDT_HW_TIMEOUT 0x02 > -#define WDT_TIMEOUT (HZ/2) > -#define WDT_HEARTBEAT15 > - > -static int heartbeat = WDT_HEARTBEAT; > -module_param(heartbeat, int, 0); > -MODULE_PARM_DESC(heartbeat, "Watchdog heartbeats in seconds. " > - "(default = " __MODULE_STRING(WDT_HEARTBEA
Re: [PATCH 04/16] watchdog: remove ks8695 driver
On Sat, Aug 10, 2019 at 10:37:14AM +0200, Arnd Bergmann wrote: > On Fri, Aug 9, 2019 at 10:42 PM Guenter Roeck wrote: > > > > On Fri, Aug 09, 2019 at 10:27:32PM +0200, Arnd Bergmann wrote: > > > The platform is getting removed, so there are no remaining > > > users of this driver. > > > > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Guenter Roeck > > > > Please let me know if this should be applied through the watchdog tree. > > For now I'll assume it will be applied together with the rest of the > > series. > > For this series, my preference is that you apply the patches through > the subsystem tree as there are no dependencies. > Ok, I added both patches to my tree. Thanks, Guenter
Re: [PATCH v3 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On 8/11/19 7:53 PM, John Wang wrote:
Add the driver to monitor Inspur Power System power supplies
with hwmon over pmbus.
This driver adds sysfs attributes for additional power supply data,
including vendor, model, part_number, serial number,
firmware revision, hardware revision, and psu mode(active/standby).
Signed-off-by: John Wang
---
v3:
- Sort kconfig/makefile entries alphabetically
- Remove unnecessary initialization
- Use ATTRIBUTE_GROUPS instead of expanding directly
- Use memscan to avoid reimplementation
v2:
- Fix typos in commit message
- Invert Christmas tree
- Configure device with sysfs attrs, not debugfs entries
- Fix errno in fw_version_read, ENODATA to EPROTO
- Change the print format of fw-version
- Use sysfs_streq instead of strcmp("xxx" "\n", "xxx")
- Document sysfs attributes
---
Documentation/hwmon/inspur-ipsps1.rst | 79 +
drivers/hwmon/pmbus/Kconfig | 9 +
drivers/hwmon/pmbus/Makefile | 41 ++---
drivers/hwmon/pmbus/inspur-ipsps.c| 226 ++
4 files changed, 335 insertions(+), 20 deletions(-)
create mode 100644 Documentation/hwmon/inspur-ipsps1.rst
create mode 100644 drivers/hwmon/pmbus/inspur-ipsps.c
diff --git a/Documentation/hwmon/inspur-ipsps1.rst
b/Documentation/hwmon/inspur-ipsps1.rst
new file mode 100644
index ..aa19f0ccc8b0
--- /dev/null
+++ b/Documentation/hwmon/inspur-ipsps1.rst
@@ -0,0 +1,79 @@
+Kernel driver inspur-ipsps1
+===
+
+Supported chips:
+
+ * Inspur Power System power supply unit
+
+Author: John Wang
+
+Description
+---
+
+This driver supports Inspur Power System 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_input Measured input current
+curr1_label "iin"
+curr1_max Maximum current
+curr1_max_alarm Current high alarm
+curr2_inputMeasured output current in mA.
+curr2_label"iout1"
+curr2_crit Critical maximum current
+curr2_crit_alarmCurrent critical high alarm
+curr2_max Maximum current
+curr2_max_alarm Current high alarm
+
+fan1_alarm Fan 1 warning.
+fan1_fault Fan 1 fault.
+fan1_input Fan 1 speed in RPM.
+
+in1_alarm Input voltage under-voltage alarm.
+in1_input Measured input voltage in mV.
+in1_label "vin"
+in2_input Measured output voltage in mV.
+in2_label "vout1"
+in2_lcrit Critical minimum output voltage
+in2_lcrit_alarm Output voltage critical low alarm
+in2_max Maximum output voltage
+in2_max_alarm Output voltage high alarm
+in2_min Minimum output voltage
+in2_min_alarm Output voltage low alarm
+
+power1_alarm Input fault or alarm.
+power1_input Measured input power in uW.
+power1_label "pin"
+power1_max Input power limit
+power2_max_alarm Output power high alarm
+power2_max Output power limit
+power2_input Measured output power in uW.
+power2_label "pout"
+
+temp[1-3]_inputMeasured temperature
+temp[1-2]_max Maximum temperature
+temp[1-3]_max_alarmTemperature high alarm
+
+vendor Manufacturer name
+model Product model
+part_number Product part number
+serial_number Product serial number
+fw_version Firmware version
+hw_version Hardware version
+modeWork mode. Can be set to active or
+standby, when set to standby, PSU will
+automatically switch between standby
+and redundancy mode.
+=== ==
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 30751eb9550a..2370fce6e816 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -46,6 +46,15 @@ config SENSORS_IBM_CFFPS
This driver can also be built as a module. If so, the module will
be called ibm-cffps.
+config SENSORS_INSPUR_IPSPS
+ tristate "INSPUR Power System Power Supply"
+ help
+ If you say yes here you get hardware monitoring support for the INSPUR
+ Power System power supply.
+
+ This driver can also be built as a module. If so, the module will
+ be called inspur-ipsps.
+
config SENSORS_IR35221
tristate "Inf
Re: [PATCH v3 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On Mon, Aug 12, 2019 at 12:48:34PM +0800, John Wang wrote: > > So I should > > 1. Add SENSOR_INSPUR_IPSPS to the end of the file > 2. Add SENSOR_INSPUR_IPSPS in alphabetical order, without additional tab > 3. other suggestions > I would suggest 2). Just use a space before += instead of a tab. Guenter
Re: [PATCH v4 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On Thu, Aug 15, 2019 at 06:43:52PM +, Vijay Khemka wrote:
>
>
> On 8/13/19, 1:36 AM, "openbmc on behalf of John Wang"
> wangz...@inspur.com> wrote:
>
> Add the driver to monitor Inspur Power System power supplies
> with hwmon over pmbus.
>
> This driver adds sysfs attributes for additional power supply data,
> including vendor, model, part_number, serial number,
> firmware revision, hardware revision, and psu mode(active/standby).
>
> Signed-off-by: John Wang
> ---
> v4:
> - Remove the additional tabs in the Makefile
> - Rebased on 5.3-rc4, not 5.2
> v3:
> - Sort kconfig/makefile entries alphabetically
> - Remove unnecessary initialization
> - Use ATTRIBUTE_GROUPS instead of expanding directly
> - Use memscan to avoid reimplementation
> v2:
> - Fix typos in commit message
> - Invert Christmas tree
> - Configure device with sysfs attrs, not debugfs entries
> - Fix errno in fw_version_read, ENODATA to EPROTO
> - Change the print format of fw-version
> - Use sysfs_streq instead of strcmp("xxx" "\n", "xxx")
> - Document sysfs attributes
> ---
> Documentation/hwmon/inspur-ipsps1.rst | 79 +
> drivers/hwmon/pmbus/Kconfig | 9 +
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/inspur-ipsps.c| 226 ++
> 4 files changed, 315 insertions(+)
> create mode 100644 Documentation/hwmon/inspur-ipsps1.rst
> create mode 100644 drivers/hwmon/pmbus/inspur-ipsps.c
>
> diff --git a/Documentation/hwmon/inspur-ipsps1.rst
> b/Documentation/hwmon/inspur-ipsps1.rst
> new file mode 100644
> index ..aa19f0ccc8b0
> --- /dev/null
> +++ b/Documentation/hwmon/inspur-ipsps1.rst
> @@ -0,0 +1,79 @@
> +Kernel driver inspur-ipsps1
> +===
> +
> +Supported chips:
> +
> + * Inspur Power System power supply unit
> +
> +Author: John Wang
> +
> +Description
> +---
> +
> +This driver supports Inspur Power System 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_input Measured input current
> +curr1_label "iin"
> +curr1_max Maximum current
> +curr1_max_alarm Current high alarm
> +curr2_input Measured output current in mA.
> +curr2_label "iout1"
> +curr2_crit Critical maximum current
> +curr2_crit_alarmCurrent critical high alarm
> +curr2_max Maximum current
> +curr2_max_alarm Current high alarm
> +
> Please align above details.
> +fan1_alarm Fan 1 warning.
> +fan1_fault Fan 1 fault.
> +fan1_input Fan 1 speed in RPM.
> +
> +in1_alarmInput voltage under-voltage alarm.
> +in1_inputMeasured input voltage in mV.
> +in1_label"vin"
> +in2_inputMeasured output voltage in mV.
> +in2_label"vout1"
> +in2_lcrit Critical minimum output voltage
> +in2_lcrit_alarm Output voltage critical low alarm
> +in2_max Maximum output voltage
> +in2_max_alarm Output voltage high alarm
> +in2_min Minimum output voltage
> +in2_min_alarm Output voltage low alarm
> +
> +power1_alarm Input fault or alarm.
> +power1_input Measured input power in uW.
> +power1_label "pin"
> +power1_max Input power limit
> +power2_max_alarm Output power high alarm
> +power2_max Output power limit
> +power2_input Measured output power in uW.
> +power2_label "pout"
> +
> Same alignment issue in description.
> +temp[1-3]_input Measured temperature
> +temp[1-2]_maxMaximum temperature
> +temp[1-3]_max_alarm Temperature high alarm
> +
> +vendor Manufacturer name
> +model Product model
> +part_number Product part number
> +serial_number Product serial number
> +fw_version Firmware version
> +hw_version Hardware version
> +modeWork mode. Can be set to active
Re: [PATCH v4 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On 8/15/19 7:44 PM, John Wang wrote:
On Fri, Aug 16, 2019 at 3:41 AM Guenter Roeck wrote:
On Thu, Aug 15, 2019 at 06:43:52PM +, Vijay Khemka wrote:
On 8/13/19, 1:36 AM, "openbmc on behalf of John Wang"
wrote:
Add the driver to monitor Inspur Power System power supplies
with hwmon over pmbus.
This driver adds sysfs attributes for additional power supply data,
including vendor, model, part_number, serial number,
firmware revision, hardware revision, and psu mode(active/standby).
Signed-off-by: John Wang
---
v4:
- Remove the additional tabs in the Makefile
- Rebased on 5.3-rc4, not 5.2
v3:
- Sort kconfig/makefile entries alphabetically
- Remove unnecessary initialization
- Use ATTRIBUTE_GROUPS instead of expanding directly
- Use memscan to avoid reimplementation
v2:
- Fix typos in commit message
- Invert Christmas tree
- Configure device with sysfs attrs, not debugfs entries
- Fix errno in fw_version_read, ENODATA to EPROTO
- Change the print format of fw-version
- Use sysfs_streq instead of strcmp("xxx" "\n", "xxx")
- Document sysfs attributes
---
Documentation/hwmon/inspur-ipsps1.rst | 79 +
drivers/hwmon/pmbus/Kconfig | 9 +
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/inspur-ipsps.c| 226 ++
4 files changed, 315 insertions(+)
create mode 100644 Documentation/hwmon/inspur-ipsps1.rst
create mode 100644 drivers/hwmon/pmbus/inspur-ipsps.c
diff --git a/Documentation/hwmon/inspur-ipsps1.rst
b/Documentation/hwmon/inspur-ipsps1.rst
new file mode 100644
index ..aa19f0ccc8b0
--- /dev/null
+++ b/Documentation/hwmon/inspur-ipsps1.rst
@@ -0,0 +1,79 @@
+Kernel driver inspur-ipsps1
+===
+
+Supported chips:
+
+ * Inspur Power System power supply unit
+
+Author: John Wang
+
+Description
+---
+
+This driver supports Inspur Power System 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_input Measured input current
+curr1_label "iin"
+curr1_max Maximum current
+curr1_max_alarm Current high alarm
+curr2_input Measured output current in mA.
+curr2_label "iout1"
+curr2_crit Critical maximum current
+curr2_crit_alarmCurrent critical high alarm
+curr2_max Maximum current
+curr2_max_alarm Current high alarm
+
Please align above details.
Sorry for the mix of table and space
+fan1_alarm Fan 1 warning.
+fan1_fault Fan 1 fault.
+fan1_input Fan 1 speed in RPM.
+
+in1_alarmInput voltage under-voltage alarm.
+in1_inputMeasured input voltage in mV.
+in1_label"vin"
+in2_inputMeasured output voltage in mV.
+in2_label"vout1"
+in2_lcrit Critical minimum output voltage
+in2_lcrit_alarm Output voltage critical low alarm
+in2_max Maximum output voltage
+in2_max_alarm Output voltage high alarm
+in2_min Minimum output voltage
+in2_min_alarm Output voltage low alarm
+
+power1_alarm Input fault or alarm.
+power1_input Measured input power in uW.
+power1_label "pin"
+power1_max Input power limit
+power2_max_alarm Output power high alarm
+power2_max Output power limit
+power2_input Measured output power in uW.
+power2_label "pout"
+
Same alignment issue in description.
will fix.
+temp[1-3]_input Measured temperature
+temp[1-2]_maxMaximum temperature
+temp[1-3]_max_alarm Temperature high alarm
+
+vendor Manufacturer name
+model Product model
+part_number Product part number
+serial_number Product serial number
+fw_version Firmware version
+hw_ve
Re: [PATCH v5 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On Fri, Aug 16, 2019 at 04:01:05PM +, Vijay Khemka wrote:
>
>
> On 8/16/19, 3:20 AM, "openbmc on behalf of John Wang"
> wangz...@inspur.com> wrote:
>
> Add the driver to monitor Inspur Power System power supplies
> with hwmon over pmbus.
>
> This driver adds sysfs attributes for additional power supply data,
> including vendor, model, part_number, serial number,
> firmware revision, hardware revision, and psu mode(active/standby).
>
> Signed-off-by: John Wang
> ---
> v5:
> - Align sysfs attrs description in inspur-ipsps1.rst
> (Use tab instead of space to sperate names and values)
> v4:
> - Remove the additional tabs in the Makefile
> - Rebased on 5.3-rc4, not 5.2
> v3:
> - Sort kconfig/makefile entries alphabetically
> - Remove unnecessary initialization
> - Use ATTRIBUTE_GROUPS instead of expanding directly
> - Use memscan to avoid reimplementation
> v2:
> - Fix typos in commit message
> - Invert Christmas tree
> - Configure device with sysfs attrs, not debugfs entries
> - Fix errno in fw_version_read, ENODATA to EPROTO
> - Change the print format of fw-version
> - Use sysfs_streq instead of strcmp("xxx" "\n", "xxx")
> - Document sysfs attributes
> ---
> Documentation/hwmon/inspur-ipsps1.rst | 79 +
> drivers/hwmon/pmbus/Kconfig | 9 +
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/inspur-ipsps.c| 226 ++
> 4 files changed, 315 insertions(+)
> create mode 100644 Documentation/hwmon/inspur-ipsps1.rst
> create mode 100644 drivers/hwmon/pmbus/inspur-ipsps.c
>
> diff --git a/Documentation/hwmon/inspur-ipsps1.rst
> b/Documentation/hwmon/inspur-ipsps1.rst
> new file mode 100644
> index ..2b871ae3448f
> --- /dev/null
> +++ b/Documentation/hwmon/inspur-ipsps1.rst
> @@ -0,0 +1,79 @@
> +Kernel driver inspur-ipsps1
> +===
> +
> +Supported chips:
> +
> + * Inspur Power System power supply unit
> +
> +Author: John Wang
> +
> +Description
> +---
> +
> +This driver supports Inspur Power System 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_input Measured input current
> +curr1_label "iin"
> +curr1_maxMaximum current
> +curr1_max_alarm Current high alarm
> +curr2_input Measured output current in mA.
> +curr2_label "iout1"
> +curr2_crit Critical maximum current
> +curr2_crit_alarm Current critical high alarm
> +curr2_maxMaximum current
> +curr2_max_alarm Current high alarm
> +
> +fan1_alarm Fan 1 warning.
> +fan1_fault Fan 1 fault.
> +fan1_input Fan 1 speed in RPM.
> +
> +in1_alarmInput voltage under-voltage alarm.
> +in1_inputMeasured input voltage in mV.
> +in1_label"vin"
> +in2_inputMeasured output voltage in mV.
> +in2_label"vout1"
> +in2_lcritCritical minimum output voltage
> +in2_lcrit_alarm Output voltage critical low alarm
> +in2_max Maximum output voltage
> +in2_max_alarmOutput voltage high alarm
> +in2_min Minimum output voltage
> +in2_min_alarmOutput voltage low alarm
> +
> +power1_alarm Input fault or alarm.
> +power1_input Measured input power in uW.
> +power1_label "pin"
> +power1_max Input power limit
> +power2_max_alarm Output power high alarm
> +power2_max Output power limit
> +power2_input Measured output power in uW.
> +power2_label "pout"
> +
> +temp[1-3]_input Measured temperature
> +temp[1-2]_maxMaximum temperature
> +temp[1-3]_max_alarm Temperature high alarm
> +
> +vendor Manufacturer name
> +modelProduct model
> +part_number Product part number
> +serial_numberProduct serial number
> +fw_version Firmware version
> +hw_version
Re: [PATCH v5 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On 8/18/19 7:20 PM, Joel Stanley wrote:
On Fri, 16 Aug 2019 at 10:19, John Wang wrote:
Add the driver to monitor Inspur Power System power supplies
with hwmon over pmbus.
This driver adds sysfs attributes for additional power supply data,
including vendor, model, part_number, serial number,
firmware revision, hardware revision, and psu mode(active/standby).
Signed-off-by: John Wang
+static const struct i2c_device_id ipsps_id[] = {
+ { "inspur_ipsps1", 0 },
Convention would be to use "ipsps" here, instead of "vendor_device"?
ipsps1, but good catch.
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, ipsps_id);
+
+static const struct of_device_id ipsps_of_match[] = {
+ { .compatible = "inspur,ipsps1" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ipsps_of_match);
Do we need the of match table? I thought the match on the device name
from the i2c table would be enough. I will defer to Guenter here
though.
Strictly speaking it is unnecessary, but it is kind of customary to have it.
The automatic detection also only works if the i2c device ID would be "ipsps1",
without vendor ID embedded.
I would recomment to have both, but name the i2c device "ipsps1" as you
suggested,
for consistency.
I'll also have to check if we need of_match_ptr below in the assignment of
of_match_table. Probably not, but it would save a few bytes if CONFIG_OF
is not enabled.
Thanks,
Guenter
Assuming the device tables are okay:
Reviewed-by: Joel Stanley
Cheers,
Joel
+
+static struct i2c_driver ipsps_driver = {
+ .driver = {
+ .name = "inspur-ipsps",
+ .of_match_table = ipsps_of_match,
+ },
+ .probe = ipsps_probe,
+ .remove = pmbus_do_remove,
+ .id_table = ipsps_id,
+};
Re: [PATCH v6 2/2] hwmon: pmbus: Add Inspur Power System power supply driver
On Mon, Aug 19, 2019 at 05:15:09PM +0800, John Wang wrote:
> Add the driver to monitor Inspur Power System power supplies
> with hwmon over pmbus.
>
> This driver adds sysfs attributes for additional power supply data,
> including vendor, model, part_number, serial number,
> firmware revision, hardware revision, and psu mode(active/standby).
>
> Signed-off-by: John Wang
> Reviewed-by: Joel Stanley
Applied to hwmon-next.
Thanks,
Guenter
> ---
> v6:
> - Name i2c device as ipsps1
> - Use of_match_ptr to save a few bytes if CONFIG_OF
> is not enabled :)
> v5:
> - Align sysfs attrs description in inspur-ipsps1.rst
> (Use tab instead of space to sperate names and values)
> v4:
> - Remove the additional tabs in the Makefile
> - Rebased on 5.3-rc4, not 5.2
> v3:
> - Sort kconfig/makefile entries alphabetically
> - Remove unnecessary initialization
> - Use ATTRIBUTE_GROUPS instead of expanding directly
> - Use memscan to avoid reimplementation
> v2:
> - Fix typos in commit message
> - Invert Christmas tree
> - Configure device with sysfs attrs, not debugfs entries
> - Fix errno in fw_version_read, ENODATA to EPROTO
> - Change the print format of fw-version
> - Use sysfs_streq instead of strcmp("xxx" "\n", "xxx")
> - Document sysfs attributes
> ---
> Documentation/hwmon/inspur-ipsps1.rst | 79 +
> drivers/hwmon/pmbus/Kconfig | 9 +
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/inspur-ipsps.c| 228 ++
> 4 files changed, 317 insertions(+)
> create mode 100644 Documentation/hwmon/inspur-ipsps1.rst
> create mode 100644 drivers/hwmon/pmbus/inspur-ipsps.c
>
> diff --git a/Documentation/hwmon/inspur-ipsps1.rst
> b/Documentation/hwmon/inspur-ipsps1.rst
> new file mode 100644
> index ..2b871ae3448f
> --- /dev/null
> +++ b/Documentation/hwmon/inspur-ipsps1.rst
> @@ -0,0 +1,79 @@
> +Kernel driver inspur-ipsps1
> +===
> +
> +Supported chips:
> +
> + * Inspur Power System power supply unit
> +
> +Author: John Wang
> +
> +Description
> +---
> +
> +This driver supports Inspur Power System 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_input Measured input current
> +curr1_label "iin"
> +curr1_maxMaximum current
> +curr1_max_alarm Current high alarm
> +curr2_input Measured output current in mA.
> +curr2_label "iout1"
> +curr2_crit Critical maximum current
> +curr2_crit_alarm Current critical high alarm
> +curr2_maxMaximum current
> +curr2_max_alarm Current high alarm
> +
> +fan1_alarm Fan 1 warning.
> +fan1_fault Fan 1 fault.
> +fan1_input Fan 1 speed in RPM.
> +
> +in1_alarmInput voltage under-voltage alarm.
> +in1_inputMeasured input voltage in mV.
> +in1_label"vin"
> +in2_inputMeasured output voltage in mV.
> +in2_label"vout1"
> +in2_lcritCritical minimum output voltage
> +in2_lcrit_alarm Output voltage critical low alarm
> +in2_max Maximum output voltage
> +in2_max_alarmOutput voltage high alarm
> +in2_min Minimum output voltage
> +in2_min_alarmOutput voltage low alarm
> +
> +power1_alarm Input fault or alarm.
> +power1_input Measured input power in uW.
> +power1_label "pin"
> +power1_max Input power limit
> +power2_max_alarm Output power high alarm
> +power2_max Output power limit
> +power2_input Measured output power in uW.
> +power2_label "pout"
> +
> +temp[1-3]_input Measured temperature
> +temp[1-2]_maxMaximum temperature
> +temp[1-3]_max_alarm Temperature high alarm
> +
> +vendor Manufacturer name
> +modelProduct model
> +part_number Product part number
> +serial_numberProduct serial number
> +fw_version Firmware version
> +hw_version Hardware version
> +mode Work mode. Can be set to active or
> + standby, when set to standby, PSU will
> + automatically switch between standby
> + and redundancy mode.
> +===
> ==
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index b6588483fae1..d6
Re: [PATCH] k10temp: update documentation
On Thu, Sep 19, 2019 at 11:25:03AM +0200, Lukas Zapletal wrote: > It's been a while since the k10temp documentation has been updated. > There are new CPU families supported as well as Tdie temp was added. > This patch adds all missing families which I was able to find from git > history and provides more info about Tctl vs Tdie exported temps. > > Signed-off-by: Lukas Zapletal Your patch does not apply to the curent mainline kernel. What is the parent branch ? > --- > Documentation/hwmon/k10temp.rst | 19 +-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > >Addresses scanned: PCI space > @@ -110,3 +116,12 @@ The maximum value for Tctl is available in the > file temp1_max. > If the BIOS has enabled hardware temperature control, the threshold at > which the processor will throttle itself to avoid damage is available in > temp1_crit and temp1_crit_hyst. > + > +On some AMD CPUs, there is a difference between the die temperature (Tdie) > and > +the reported temperature (Tctl). Tdie is the real measured temperature, and > +Tctl is used for fan control. While Tctl is always available as temp1_input, > +the driver exports Tdie temperature as temp2_input for those CPUs which > support > +it. > + > +Models from 17h family report relative temperature, the driver aims to > +compensate and report the real temperature. > > diff --git a/Documentation/hwmon/k10temp.rst b/Documentation/hwmon/k10temp.rst > index 12a86ba17de9..bb2d0a02dc45 100644 > --- a/Documentation/hwmon/k10temp.rst > +++ b/Documentation/hwmon/k10temp.rst > @@ -1,7 +1,7 @@ > Kernel driver k10temp > = > > -Supported chips: > +Although the driver is named k10temp, it supports wide range of AMD CPUs: The above does not add any value. Many drivers support more than one chip, but are named after the first supported chip. Please drop this change. Guenter > > * AMD Family 10h processors: > > @@ -21,10 +21,16 @@ Supported chips: > > * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) > > -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", > "Kaveri", "Carrizo" > +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", > "Kaveri", "Carrizo", "Stoney Ridge", "Bristol Ridge" > > * AMD Family 16h processors: "Kabini", "Mullins" > > +* AMD Family 17h processors: "Zen", "Zen 2" > + > +* AMD Family 18h processors: "Hygon Dhyana" > + > +* AMD Family 19h processors: "Zen 3" > + >Prefix: 'k10temp'
Re: [PATCH] k10temp: update documentation
On Sun, Sep 22, 2019 at 08:25:40PM +0200, Lukas Zapletal wrote: > > Your patch does not apply to the curent mainline kernel. > > What is the parent branch ? > > Oh well, this is my first contribution. I used Greg's staging tree > which I found in a first contributor tutorial on web. I will rebase, > let me know which branch do I need to pick. Thanks. Mainline should be fine. Guenter
Re: [PATCH] k10temp: update documentation
On Mon, Sep 23, 2019 at 09:10:52AM +0200, Lukas Zapletal wrote: > It's been a while since the k10temp documentation has been updated. > There are new CPU families supported as well as Tdie temp was added. > This patch adds all missing families which I was able to find from git > history and provides more info about Tctl vs Tdie exported temps. > > Signed-off-by: Lukas Zapletal > --- > Documentation/hwmon/k10temp.rst | 19 +-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/Documentation/hwmon/k10temp.rst b/Documentation/hwmon/k10temp.rst > index 12a86ba17de9..bb2d0a02dc45 100644 > --- a/Documentation/hwmon/k10temp.rst > +++ b/Documentation/hwmon/k10temp.rst > @@ -1,7 +1,7 @@ > Kernel driver k10temp > = > > -Supported chips: > +Although the driver is named k10temp, it supports wide range of AMD CPUs: > I did ask to drop the above, and I won't accept the patch as-is. Many hwmon (and other) drivers are named after one chip but support many, it would be quite pointless to state that in each driver's documentation, and I won't get it started. Guenter
Re: [PATCH RESEND] k10temp: update docs and add temp2_input info
On Mon, Sep 23, 2019 at 12:59:31PM +0200, Lukas Zapletal wrote: > It's been a while since the k10temp documentation has been updated. > There are new CPU families supported as well as Tdie temp was added. > This patch adds all missing families which I was able to find from git > history and provides more info about Tctl vs Tdie exported temps. > > Signed-off-by: Lukas Zapletal Applied. Thanks, Guenter > --- > Documentation/hwmon/k10temp.rst | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/Documentation/hwmon/k10temp.rst b/Documentation/hwmon/k10temp.rst > index 12a86ba17de9..fc9d2a5ad57d 100644 > --- a/Documentation/hwmon/k10temp.rst > +++ b/Documentation/hwmon/k10temp.rst > @@ -21,10 +21,16 @@ Supported chips: > > * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) > > -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", > "Carrizo" > +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", > "Carrizo", "Stoney Ridge", "Bristol Ridge" > > * AMD Family 16h processors: "Kabini", "Mullins" > > +* AMD Family 17h processors: "Zen", "Zen 2" > + > +* AMD Family 18h processors: "Hygon Dhyana" > + > +* AMD Family 19h processors: "Zen 3" > + >Prefix: 'k10temp' > >Addresses scanned: PCI space > @@ -110,3 +116,12 @@ The maximum value for Tctl is available in the file > temp1_max. > If the BIOS has enabled hardware temperature control, the threshold at > which the processor will throttle itself to avoid damage is available in > temp1_crit and temp1_crit_hyst. > + > +On some AMD CPUs, there is a difference between the die temperature (Tdie) > and > +the reported temperature (Tctl). Tdie is the real measured temperature, and > +Tctl is used for fan control. While Tctl is always available as temp1_input, > +the driver exports Tdie temperature as temp2_input for those CPUs which > support > +it. > + > +Models from 17h family report relative temperature, the driver aims to > +compensate and report the real temperature.
Re: [PATCH 1/3] hwmon: Fix HWMON_P_MIN_ALARM mask
On Tue, Sep 24, 2019 at 02:49:43PM +0200, Nuno Sá wrote:
> Both HWMON_P_MIN_ALARM and HWMON_P_MAX_ALARM were using
> BIT(hwmon_power_max_alarm).
>
> Fixes: aa7f29b07c870 ("hwmon: Add support for power min, lcrit, min_alarm and
> lcrit_alarm")
> CC:
> Signed-off-by: Nuno Sá
Applied.
Thanks,
Guenter
> ---
> include/linux/hwmon.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
> index 04c36b7a61dd..72579168189d 100644
> --- a/include/linux/hwmon.h
> +++ b/include/linux/hwmon.h
> @@ -235,7 +235,7 @@ enum hwmon_power_attributes {
> #define HWMON_P_LABELBIT(hwmon_power_label)
> #define HWMON_P_ALARMBIT(hwmon_power_alarm)
> #define HWMON_P_CAP_ALARMBIT(hwmon_power_cap_alarm)
> -#define HWMON_P_MIN_ALARMBIT(hwmon_power_max_alarm)
> +#define HWMON_P_MIN_ALARMBIT(hwmon_power_min_alarm)
> #define HWMON_P_MAX_ALARMBIT(hwmon_power_max_alarm)
> #define HWMON_P_LCRIT_ALARM BIT(hwmon_power_lcrit_alarm)
> #define HWMON_P_CRIT_ALARM BIT(hwmon_power_crit_alarm)
Re: [PATCH 1/3] docs: fix some broken references
On Tue, Sep 24, 2019 at 10:01:28AM -0300, Mauro Carvalho Chehab wrote: > There are a number of documentation files that got moved or > renamed. update their references. > > Signed-off-by: Mauro Carvalho Chehab > Acked-by: Shannon Nelson > --- > Documentation/devicetree/bindings/cpu/cpu-topology.txt| 2 +- > Documentation/devicetree/bindings/timer/ingenic,tcu.txt | 2 +- > Documentation/driver-api/gpio/driver.rst | 2 +- > Documentation/hwmon/inspur-ipsps1.rst | 2 +- For hwmon: Acked-by: Guenter Roeck > Documentation/mips/ingenic-tcu.rst| 2 +- > Documentation/networking/device_drivers/mellanox/mlx5.rst | 2 +- > MAINTAINERS | 2 +- > drivers/net/ethernet/faraday/ftgmac100.c | 2 +- > drivers/net/ethernet/pensando/ionic/ionic_if.h| 4 ++-- > fs/cifs/cifsfs.c | 2 +- > 10 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/Documentation/devicetree/bindings/cpu/cpu-topology.txt > b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > index 99918189403c..9bd530a35d14 100644 > --- a/Documentation/devicetree/bindings/cpu/cpu-topology.txt > +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt > @@ -549,5 +549,5 @@ Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system) > [2] Devicetree NUMA binding description > Documentation/devicetree/bindings/numa.txt > [3] RISC-V Linux kernel documentation > -Documentation/devicetree/bindings/riscv/cpus.txt > +Documentation/devicetree/bindings/riscv/cpus.yaml > [4] https://www.devicetree.org/specifications/ > diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt > b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt > index 5a4b9ddd9470..7f6fe20503f5 100644 > --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt > +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt > @@ -2,7 +2,7 @@ Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings > == > > For a description of the TCU hardware and drivers, have a look at > -Documentation/mips/ingenic-tcu.txt. > +Documentation/mips/ingenic-tcu.rst. > > Required properties: > > diff --git a/Documentation/driver-api/gpio/driver.rst > b/Documentation/driver-api/gpio/driver.rst > index 3fdb32422f8a..9076cc76d5bf 100644 > --- a/Documentation/driver-api/gpio/driver.rst > +++ b/Documentation/driver-api/gpio/driver.rst > @@ -493,7 +493,7 @@ available but we try to move away from this: >gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ >callbacks, so the callbacks need to embed the gpio_chip in its state >container and obtain a pointer to the container using container_of(). > - (See Documentation/driver-model/design-patterns.txt) > + (See Documentation/driver-api/driver-model/design-patterns.rst) > > - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a > gpiochip, >as discussed above regarding different types of cascaded irqchips. The > diff --git a/Documentation/hwmon/inspur-ipsps1.rst > b/Documentation/hwmon/inspur-ipsps1.rst > index 2b871ae3448f..ed32a65c30e1 100644 > --- a/Documentation/hwmon/inspur-ipsps1.rst > +++ b/Documentation/hwmon/inspur-ipsps1.rst > @@ -17,7 +17,7 @@ Usage Notes > --- > > This driver does not auto-detect devices. You will have to instantiate the > -devices explicitly. Please see Documentation/i2c/instantiating-devices for > +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst > for > details. > > Sysfs entries > diff --git a/Documentation/mips/ingenic-tcu.rst > b/Documentation/mips/ingenic-tcu.rst > index c4ef4c45aade..c5a646b14450 100644 > --- a/Documentation/mips/ingenic-tcu.rst > +++ b/Documentation/mips/ingenic-tcu.rst > @@ -68,4 +68,4 @@ and frameworks can be controlled from the same registers, > all of these > drivers access their registers through the same regmap. > > For more information regarding the devicetree bindings of the TCU drivers, > -have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt. > +have a look at Documentation/devicetree/bindings/timer/ingenic,tcu.txt. > diff --git a/Documentation/networking/device_drivers/mellanox/mlx5.rst > b/Documentation/networking/device_drivers/mellanox/mlx5.rst > index d071c6b49e1f..a74422058351 100644 > --- a/Documentation/networking/device_drivers/mellanox/mlx5.rst > +++ b/Documentation/networking/device_drivers/mellanox/mlx5.rst > @@ -258,7 +258,7 @@ mlx5 tracepoints > > > mlx5 driver provides internal tr
Re: [PATCH 2/3] hwmon: Add support for ltc2947
On Tue, Sep 24, 2019 at 02:49:44PM +0200, Nuno Sá wrote: > The ltc2947 is a high precision power and energy monitor with an > internal sense resistor supporting up to +/- 30A. Three internal no > Latency ADCs ensure accurate measurement of voltage and current, while > high-bandwidth analog multiplication of voltage and current provides > accurate power measurement in a wide range of applications. Internal or > external clocking options enable precise charge and energy measurements. > > Signed-off-by: Nuno Sá > --- > Documentation/hwmon/ltc2947.rst | 110 +++ > MAINTAINERS | 10 + > drivers/hwmon/Kconfig | 27 + > drivers/hwmon/Makefile |3 + > drivers/hwmon/ltc2947-core.c| 1421 +++ > drivers/hwmon/ltc2947-i2c.c | 49 ++ > drivers/hwmon/ltc2947-spi.c | 50 ++ > drivers/hwmon/ltc2947.h | 12 + > 8 files changed, 1682 insertions(+) > create mode 100644 Documentation/hwmon/ltc2947.rst > create mode 100644 drivers/hwmon/ltc2947-core.c > create mode 100644 drivers/hwmon/ltc2947-i2c.c > create mode 100644 drivers/hwmon/ltc2947-spi.c > create mode 100644 drivers/hwmon/ltc2947.h > > diff --git a/Documentation/hwmon/ltc2947.rst b/Documentation/hwmon/ltc2947.rst > new file mode 100644 > index ..2dcf7487076d > --- /dev/null > +++ b/Documentation/hwmon/ltc2947.rst > @@ -0,0 +1,110 @@ > +Kernel drivers ltc2947-i2c and ltc2947-spi > += > + > +Supported chips: > + * Analog Devices LTC2947 > +Prefix: 'ltc2947' > +Addresses scanned: - > +Datasheet: > + > https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf > + > +Author: Nuno Sa > + > +Description > +___ > + > +The LTC2947 is a high precision power and energy monitor that measures > current, > +voltage, power, temperature, charge and energy. The device supports both SPI > +and I2C depending on the chip configuration. > +The device also measures accumulated quantities as energy. It has two banks > of > +register's to read/set energy related values. These banks can be configured > +independently to have setups like: energy1 accumulates always and enrgy2 only > +accumulates if current is positive (to check battery charging efficiency for > +example). The device also supports a GPIO pin that can be configured as > output > +to control a fan as a function of measured temperature. Then, the GPIO > becomes > +active as soon as a temperature reading is higher than a defined threshold. > The > +temp2 channel is used to control this thresholds and to read the respective > +alarms. > + > +Sysfs entries > +_ > + > +The following attributes are supported. Limits are read-write, reset_history > +is write-only and all the other attributes are read-only. > + > +in0_inputVP-VM voltage (mV). > +in0_min Undervoltage threshold > +in0_max Overvoltage threshold > +in0_lowest Lowest measured voltage > +in0_highest Highest measured voltage > +in0_reset_historyWrite 1 to reset in1 history > +in0_min_alarmUndervoltage alarm > +in0_max_alarmOvervoltage alarm > +in0_faultFault value This is a non-standard attribute. What exactly does it reflect ? > +in0_labelChannel label (VP-VM) > + > +in1_inputDVCC voltage (mV) > +in1_min Undervoltage threshold > +in1_max Overvoltage threshold > +in1_lowest Lowest measured voltage > +in1_highest Highest measured voltage > +in1_reset_historyWrite 1 to reset in2 history > +in1_min_alarmUndervoltage alarm > +in1_max_alarmOvervoltage alarm > +in1_faultFault value > +in1_labelChannel label (DVCC) > + > +curr1_input IP-IM Sense current (mA) > +curr1_minUndercurrent threshold > +curr1_maxOvercurrent threshold > +curr1_lowest Lowest measured current > +curr1_highestHighest measured current > +curr1_reset_history Write 1 to reset curr1 history > +curr1_min_alarm Undercurrent alarm > +curr1_max_alarm Overcurrent alarm > +curr1_fault Fault value > +curr1_label Channel label (IP-IM) > + > +power1_input Power (in uW) > +power1_min Low power threshold > +power1_max High power threshold > +power1_input_lowest Historical minimum power use > +power1_input_highest Historical maximum power use > +power1_reset_history Write 1 to reset power1 history > +power1_min_alarm Low power alarm > +power1_max_alarm High power alarm > +power1_fault Fault value > +power1_label Channel label (Power) > + > +temp1_input Chip Temperature (in milliC) > +temp1_minLow temperature threshold > +temp1_maxHigh temperature thresho
Re: [PATCH 2/3] hwmon: Add support for ltc2947
On Fri, Oct 04, 2019 at 07:45:07AM +, Sa, Nuno wrote:
[ ... ]
> > > +static int ltc2947_val_read(struct ltc2947_data *st, const u8 reg,
> > > + const u8 page, const size_t size, s64 *val)
> > > +{
> > > + int ret;
> > > + u64 __val = 0;
> > > +
> > > + mutex_lock(&st->lock);
> > > +
On a side note, suspend code is supposed to be atomic,
If this lock is held, the process or thread holding it
will likely stall suspend since it won't run.
At the very least, this would have to be a trylock,
with suspend failing if the lock can not be acquired.
> > > + if (st->reset) {
> > > + mutex_unlock(&st->lock);
> > > + return -EPERM;
> >
> > Not sure what the error here should be, but EPERM is not correct.
> >
> > Under which conditions would this function be called while in
> > suspend ?
>
> Honestly, this is more like a sanity check. I'm not sure if we can get
> here in suspend mode. Don't userland apps can still run in suspend? I
> guess so but I'm not 100% sure on this. Do you have any recommendation
> for the error here?
>
Sorry, I won't accept "just in case" code.
Having said that, please inform yourself how suspend works. Userland code
has to be stopped before any hardware can be disabled. Similar, hardware
has to be re-enabled before userland code can resume.
Otherwise the kernel would crash all over the place. In many cases,
disabling the hardware means that trying to access hardware registers
will cause an acess fault.
[...]
> > > +
> > > +static struct attribute *ltc2947_attrs[] = {
> > > + &sensor_dev_attr_in0_fault.dev_attr.attr,
> > > + &sensor_dev_attr_in1_fault.dev_attr.attr,
> > > + &sensor_dev_attr_curr1_fault.dev_attr.attr,
> > > + &sensor_dev_attr_temp1_fault.dev_attr.attr,
> > > + &sensor_dev_attr_power1_input.dev_attr.attr,
> > > + &sensor_dev_attr_power1_max.dev_attr.attr,
> > > + &sensor_dev_attr_power1_min.dev_attr.attr,
> > > + &sensor_dev_attr_power1_input_highest.dev_attr.attr,
> > > + &sensor_dev_attr_power1_input_lowest.dev_attr.attr,
> > > + &sensor_dev_attr_power1_fault.dev_attr.attr,
> > > + &sensor_dev_attr_energy1_input.dev_attr.attr,
> > > + &sensor_dev_attr_energy1_max.dev_attr.attr,
> > > + &sensor_dev_attr_energy1_min.dev_attr.attr,
> > > + &sensor_dev_attr_energy1_max_alarm.dev_attr.attr,
> > > + &sensor_dev_attr_energy1_min_alarm.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_input.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_max.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_min.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_max_alarm.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_min_alarm.dev_attr.attr,
> > > + &sensor_dev_attr_energy1_overflow_alarm.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_overflow_alarm.dev_attr.attr,
>
> These overflow attributes are kind of an alarm for the energy ones. It
> tells that the energy registers are about to overflow. I guess that
> some application can easily find out the maximum values supported on
> these registers and implement whatever logic they want in the app
> itself. So, if you prefer I can just drop this ones?
>
I understand the overflow use case. However, the mere presence
of min/max attributes for energy attributes suggests that this
is not the min/max use case for hwmon attributes. There is no "minimum"
or "maximum" energy for an accumulating value. Such attributes
only make sense in an application abler to measure available
energy (eg a battery controller). I'll have to read the chip
specification to understand the intended use case.
> > > + &sensor_dev_attr_energy1_fault.dev_attr.attr,
> > > + &sensor_dev_attr_energy2_fault.dev_attr.attr,
> >
> > Some of those are non-standard attributes. You'll have
> > to explain each in detail, especially why it makes sense
> > to provide such attributes to the user and why you can't
> > use standard attributes instead. Also, for the _fault
> > attributes, I don't entirely see the point. If the fault bit
> > is set, ADC readings are not valid because supply voltage
> > is low. This means that ADC register reads will be invalid.
> > What is the point of having a non-standard attribute - which
> > likely will be ignored - instead of returning an error when
> > an attempt is made to read an ADC value ?
>
> I was also not sure on this *_fault attributes. They are there to tell
> that the readings are invalid. Now that I think about it, I'm not sure
> if it even makes sense to return error if this bit is set. The part is
> in continuous mode so, it might happen that we have the fault bit set
> for a short time but afterwards things go normal and the bit will still
> be set until we read it. So my point is, we might be returning error
> for a conversion that happened way before our current reading. Any
> suggestion here? Would you be fine if I just drop this attributes?
>
It sounds like "fault" means something like "one of the past readings
was wrong, but I don't know which one and I don't know if the wrong
value was ever read b
Re: [PATCH 2/3] hwmon: Add support for ltc2947
On 10/7/19 5:25 AM, Sa, Nuno wrote:
On Fri, 2019-10-04 at 08:06 -0700, Guenter Roeck wrote:
On Fri, Oct 04, 2019 at 07:45:07AM +, Sa, Nuno wrote:
[ ... ]
+static int ltc2947_val_read(struct ltc2947_data *st, const u8
reg,
+ const u8 page, const size_t size,
s64 *val)
+{
+ int ret;
+ u64 __val = 0;
+
+ mutex_lock(&st->lock);
+
On a side note, suspend code is supposed to be atomic,
If this lock is held, the process or thread holding it
will likely stall suspend since it won't run.
At the very least, this would have to be a trylock,
with suspend failing if the lock can not be acquired.
Got it. Even more, Now I don't see the point of having the mutex in the
PM callbacks (though I saw other drivers doing this). As you said, at
the very least the trylock should be used since a frozen task might
have the mutex locked. Either way, I will drop both the flag and the
call to mutex_* functions is suspend()/resume().
+ if (st->reset) {
+ mutex_unlock(&st->lock);
+ return -EPERM;
Not sure what the error here should be, but EPERM is not correct.
Under which conditions would this function be called while in
suspend ?
Honestly, this is more like a sanity check. I'm not sure if we can
get
here in suspend mode. Don't userland apps can still run in suspend?
I
guess so but I'm not 100% sure on this. Do you have any
recommendation
for the error here?
Sorry, I won't accept "just in case" code.
Having said that, please inform yourself how suspend works. Userland
code
has to be stopped before any hardware can be disabled. Similar,
hardware
has to be re-enabled before userland code can resume.
Otherwise the kernel would crash all over the place. In many cases,
disabling the hardware means that trying to access hardware registers
will cause an acess fault.
Yes, you are right. I did checked the suspend code and all userland
tasks and kthreads are stopped before the suspend() callback is called
for the HW devices.
[...]
+
+static struct attribute *ltc2947_attrs[] = {
+ &sensor_dev_attr_in0_fault.dev_attr.attr,
+ &sensor_dev_attr_in1_fault.dev_attr.attr,
+ &sensor_dev_attr_curr1_fault.dev_attr.attr,
+ &sensor_dev_attr_temp1_fault.dev_attr.attr,
+ &sensor_dev_attr_power1_input.dev_attr.attr,
+ &sensor_dev_attr_power1_max.dev_attr.attr,
+ &sensor_dev_attr_power1_min.dev_attr.attr,
+ &sensor_dev_attr_power1_input_highest.dev_attr.attr,
+ &sensor_dev_attr_power1_input_lowest.dev_attr.attr,
+ &sensor_dev_attr_power1_fault.dev_attr.attr,
+ &sensor_dev_attr_energy1_input.dev_attr.attr,
+ &sensor_dev_attr_energy1_max.dev_attr.attr,
+ &sensor_dev_attr_energy1_min.dev_attr.attr,
+ &sensor_dev_attr_energy1_max_alarm.dev_attr.attr,
+ &sensor_dev_attr_energy1_min_alarm.dev_attr.attr,
+ &sensor_dev_attr_energy2_input.dev_attr.attr,
+ &sensor_dev_attr_energy2_max.dev_attr.attr,
+ &sensor_dev_attr_energy2_min.dev_attr.attr,
+ &sensor_dev_attr_energy2_max_alarm.dev_attr.attr,
+ &sensor_dev_attr_energy2_min_alarm.dev_attr.attr,
+ &sensor_dev_attr_energy1_overflow_alarm.dev_attr.attr,
+ &sensor_dev_attr_energy2_overflow_alarm.dev_attr.attr,
These overflow attributes are kind of an alarm for the energy ones.
It
tells that the energy registers are about to overflow. I guess that
some application can easily find out the maximum values supported
on
these registers and implement whatever logic they want in the app
itself. So, if you prefer I can just drop this ones?
I understand the overflow use case. However, the mere presence
of min/max attributes for energy attributes suggests that this
is not the min/max use case for hwmon attributes. There is no
"minimum"
or "maximum" energy for an accumulating value. Such attributes
only make sense in an application abler to measure available
energy (eg a battery controller). I'll have to read the chip
specification to understand the intended use case.
Should I just drop the overflow attributes? I think the part can be
used to check battery charging efficiency for example (though I guess
we would need to also support the Charge register's).
If chip is (or can be) used as charger, it should register as such.
Note my question was the energy limit attributes, not the overflow
attributes.
+ &sensor_dev_attr_energy1_fault.dev_attr.attr,
+ &sensor_dev_attr_energy2_fault.dev_attr.attr,
Some of those are non-standard attributes. You'll have
to explain each in detail, especially why it makes sense
to provide such attributes to the user and why you can't
use standard attributes instead. Also, for the _fault
attributes, I don't entirely see the point. If the fault bit
is
Re: [PATCH] hwmon: docs: Extend inspur-ipsps1 title underline
On 10/6/19 7:36 PM, Adam Zerella wrote: Sphinx is generating a build warning as the title underline of this file is too short. Signed-off-by: Adam Zerella Applied. Thanks, Guenter --- Documentation/hwmon/inspur-ipsps1.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/hwmon/inspur-ipsps1.rst b/Documentation/hwmon/inspur-ipsps1.rst index 2b871ae3448f..292c0c26bdd1 100644 --- a/Documentation/hwmon/inspur-ipsps1.rst +++ b/Documentation/hwmon/inspur-ipsps1.rst @@ -1,5 +1,5 @@ Kernel driver inspur-ipsps1 -=== +=== Supported chips:
Re: [PATCH 2/3] hwmon: Add support for ltc2947
On Thu, Oct 10, 2019 at 07:13:06AM +, Sa, Nuno wrote: > > Quoting the reply I had: > > "As the LTC2947 is bi-directional, the most likely use for the Min/Max > Energy thresholds are for monitoring a battery being charged or > discharged. > A limit could be set based around the battery's storage capacity so > that the battery is protected from being overcharging or fully > drained." > > So, I'm not sure if this is a valid use case for hwmon subsystem. I'm > aware there's also the power subsystem. So let me know what do you > prefer here. Should I just report energyX_input attributes? Or can we > keep the min/max? > This isn't really a hwmon use case. Having such min/max attributes would just be confusing. Guenter
Re: [PATCH v2 1/2] hwmon: Add support for ltc2947
On Fri, Oct 11, 2019 at 01:48:52PM +0200, Nuno Sá wrote: > The ltc2947 is a high precision power and energy monitor with an > internal sense resistor supporting up to +/- 30A. Three internal no > Latency ADCs ensure accurate measurement of voltage and current, while > high-bandwidth analog multiplication of voltage and current provides > accurate power measurement in a wide range of applications. Internal or > external clocking options enable precise charge and energy measurements. > > Signed-off-by: Nuno Sá Almost perfect; just some if/else cleanup required. Thanks, Guenter > --- > Changes in v2: > * Add #include ; > * Aemove unneeded dev_err() messages; > * Drop reset flag and calls to mutex_* in resume()/suspend() code; > * Drop fault, overflow, energy max/min and energy alarms attributes; > * Use standard attributes for power; > * Remove unused macros; > * Adjust min/max values per datasheet (on clamp_val() calls); > * Set power max/min on setup(). > > Documentation/hwmon/ltc2947.rst | 93 +++ > MAINTAINERS | 10 + > drivers/hwmon/Kconfig | 27 + > drivers/hwmon/Makefile |3 + > drivers/hwmon/ltc2947-core.c| 1191 +++ > drivers/hwmon/ltc2947-i2c.c | 49 ++ > drivers/hwmon/ltc2947-spi.c | 50 ++ > drivers/hwmon/ltc2947.h | 12 + > 8 files changed, 1435 insertions(+) > create mode 100644 Documentation/hwmon/ltc2947.rst > create mode 100644 drivers/hwmon/ltc2947-core.c > create mode 100644 drivers/hwmon/ltc2947-i2c.c > create mode 100644 drivers/hwmon/ltc2947-spi.c > create mode 100644 drivers/hwmon/ltc2947.h > > diff --git a/Documentation/hwmon/ltc2947.rst b/Documentation/hwmon/ltc2947.rst > new file mode 100644 > index ..05df19775fb3 > --- /dev/null > +++ b/Documentation/hwmon/ltc2947.rst > @@ -0,0 +1,93 @@ > +Kernel drivers ltc2947-i2c and ltc2947-spi > += > + > +Supported chips: > + * Analog Devices LTC2947 > +Prefix: 'ltc2947' > +Addresses scanned: - > +Datasheet: > + > https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2947.pdf > + > +Author: Nuno Sa > + > +Description > +___ > + > +The LTC2947 is a high precision power and energy monitor that measures > current, > +voltage, power, temperature, charge and energy. The device supports both SPI > +and I2C depending on the chip configuration. > +The device also measures accumulated quantities as energy. It has two banks > of > +register's to read/set energy related values. These banks can be configured > +independently to have setups like: energy1 accumulates always and enrgy2 only > +accumulates if current is positive (to check battery charging efficiency for > +example). The device also supports a GPIO pin that can be configured as > output > +to control a fan as a function of measured temperature. Then, the GPIO > becomes > +active as soon as a temperature reading is higher than a defined threshold. > The > +temp2 channel is used to control this thresholds and to read the respective > +alarms. > + > +Sysfs entries > +_ > + > +The following attributes are supported. Limits are read-write, reset_history > +is write-only and all the other attributes are read-only. > + > +in0_inputVP-VM voltage (mV). > +in0_min Undervoltage threshold > +in0_max Overvoltage threshold > +in0_lowest Lowest measured voltage > +in0_highest Highest measured voltage > +in0_reset_historyWrite 1 to reset in1 history > +in0_min_alarmUndervoltage alarm > +in0_max_alarmOvervoltage alarm > +in0_labelChannel label (VP-VM) > + > +in1_inputDVCC voltage (mV) > +in1_min Undervoltage threshold > +in1_max Overvoltage threshold > +in1_lowest Lowest measured voltage > +in1_highest Highest measured voltage > +in1_reset_historyWrite 1 to reset in2 history > +in1_min_alarmUndervoltage alarm > +in1_max_alarmOvervoltage alarm > +in1_labelChannel label (DVCC) > + > +curr1_input IP-IM Sense current (mA) > +curr1_minUndercurrent threshold > +curr1_maxOvercurrent threshold > +curr1_lowest Lowest measured current > +curr1_highestHighest measured current > +curr1_reset_history Write 1 to reset curr1 history > +curr1_min_alarm Undercurrent alarm > +curr1_max_alarm Overcurrent alarm > +curr1_label Channel label (IP-IM) > + > +power1_input Power (in uW) > +power1_min Low power threshold > +power1_max High power threshold > +power1_input_lowest Historical minimum power use > +power1_input_highest Historical maximum power use > +power1_reset_history Write 1 to reset power1 history > +power1_min_alarm Low power
Re: [PATCH] hwmon: (ina3221) Add summation feature support
On Wed, Oct 16, 2019 at 04:57:02PM -0700, Nicolin Chen wrote:
> This patch implements the summation feature of INA3221, mainly the
> SCC (enabling) and SF (warning flag) bits of MASK_ENABLE register,
> INA3221_SHUNT_SUM (summation of shunt voltages) register, and the
> INA3221_CRIT_SUM (its critical alert setting) register.
>
> Although the summation feature allows user to select which channels
> to be added to the result, as an initial support, this patch simply
> selects all channels by default, with one only condition: all shunt
> resistor values need to be the same. This is because the summation
> of current channels can be only accurately calculated, using shunt
> voltage sum register, if all shunt resistors are equivalent.
>
> Signed-off-by: Nicolin Chen
> ---
>
> Hi Guenter,
>
> I know my previous questions haven't been answered yet, so nodes
> for enabling bits aren't decided completely. But this patch only
> adds voltage and its current, and we had a conclusion for these
> two already last time. So I think we may add them first. Thanks!
>
I don't really like the term "summation", as it is the process of
summing things up, not the result. I'll change "summation of" in
the documentation to "sum of" and apply the patch.
Thanks,
Guenter
> Documentation/hwmon/ina3221.rst | 12 +++
> drivers/hwmon/ina3221.c | 163 +++-
> 2 files changed, 153 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/hwmon/ina3221.rst b/Documentation/hwmon/ina3221.rst
> index f6007ae8f4e2..bf9051339dec 100644
> --- a/Documentation/hwmon/ina3221.rst
> +++ b/Documentation/hwmon/ina3221.rst
> @@ -41,6 +41,18 @@ curr[123]_max Warning alert current(mA) setting,
> activates the
> average is above this value.
> curr[123]_max_alarm Warning alert current limit exceeded
> in[456]_input Shunt voltage(uV) for channels 1, 2, and 3
> respectively
> +in7_input Summation of shunt voltage(uV) channels
> +in7_label Channel label for summation of shunt voltage
> +curr4_input Summation of current(mA) measurement channels,
> +(only available when all channels use the same
> resistor
> +value for their shunt resistors)
> +curr4_crit Critical alert current(mA) setting for summation of
> +current measurement, activates the corresponding
> alarm
> +when the respective current is above this value
> +(only effective when all channels use the same
> resistor
> +value for their shunt resistors)
> +curr4_crit_alarmCritical alert current limit exceeded for summation
> of
> +current measurements.
> samples Number of samples using in the averaging mode.
>
> Supports the list of number of samples:
> diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
> index 0037e2bdacd6..0a60d7513037 100644
> --- a/drivers/hwmon/ina3221.c
> +++ b/drivers/hwmon/ina3221.c
> @@ -31,6 +31,8 @@
> #define INA3221_WARN20x0a
> #define INA3221_CRIT30x0b
> #define INA3221_WARN30x0c
> +#define INA3221_SHUNT_SUM0x0d
> +#define INA3221_CRIT_SUM 0x0e
> #define INA3221_MASK_ENABLE 0x0f
>
> #define INA3221_CONFIG_MODE_MASK GENMASK(2, 0)
> @@ -50,6 +52,8 @@
> #define INA3221_CONFIG_CHs_EN_MASK GENMASK(14, 12)
> #define INA3221_CONFIG_CHx_EN(x) BIT(14 - (x))
>
> +#define INA3221_MASK_ENABLE_SCC_MASK GENMASK(14, 12)
> +
> #define INA3221_CONFIG_DEFAULT 0x7127
> #define INA3221_RSHUNT_DEFAULT 1
>
> @@ -60,9 +64,11 @@ enum ina3221_fields {
> /* Status Flags */
> F_CVRF,
>
> - /* Alert Flags */
> + /* Warning Flags */
> F_WF3, F_WF2, F_WF1,
> - F_CF3, F_CF2, F_CF1,
> +
> + /* Alert Flags: SF is the summation-alert flag */
> + F_SF, F_CF3, F_CF2, F_CF1,
>
> /* sentinel */
> F_MAX_FIELDS
> @@ -75,6 +81,7 @@ static const struct reg_field ina3221_reg_fields[] = {
> [F_WF3] = REG_FIELD(INA3221_MASK_ENABLE, 3, 3),
> [F_WF2] = REG_FIELD(INA3221_MASK_ENABLE, 4, 4),
> [F_WF1] = REG_FIELD(INA3221_MASK_ENABLE, 5, 5),
> + [F_SF] = REG_FIELD(INA3221_MASK_ENABLE, 6, 6),
> [F_CF3] = REG_FIELD(INA3221_MASK_ENABLE, 7, 7),
> [F_CF2] = REG_FIELD(INA3221_MASK_ENABLE, 8, 8),
> [F_CF1] = REG_FIELD(INA3221_MASK_ENABLE, 9, 9),
> @@ -107,6 +114,7 @@ struct ina3221_input {
> * @inputs: Array of channel input source specific structures
> * @lock: mutex lock to serialize sysfs attribute accesses
> * @reg_config: Register value of INA3221_CONFIG
> + * @summation_shunt_resistor: equivalent shunt resistor value for summation
> * @single_shot: running in single-shot operating mode
>
Re: [PATCH 1/2] hwmon: pmbus: Add Infineon PXE1610 VR driver
On 5/29/19 3:35 PM, Vijay Khemka wrote:
Added pmbus driver for the new device Infineon pxe1610
voltage regulator. It also supports similar family device
PXE1110 and PXM1310.
Signed-off-by: Vijay Khemka
---
drivers/hwmon/pmbus/Kconfig | 9 +++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/pxe1610.c | 119 ++
3 files changed, 129 insertions(+)
create mode 100644 drivers/hwmon/pmbus/pxe1610.c
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 30751eb9550a..338ef9b5a395 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -154,6 +154,15 @@ config SENSORS_MAX8688
This driver can also be built as a module. If so, the module will
be called max8688.
+config SENSORS_PXE1610
+ tristate "Infineon PXE1610"
+ help
+ If you say yes here you get hardware monitoring support for Infineon
+ PXE1610.
+
+ This driver can also be built as a module. If so, the module will
+ be called pxe1610.
+
config SENSORS_TPS40422
tristate "TI TPS40422"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 2219b9300316..b0fbd017a91a 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -18,6 +18,7 @@ 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_PXE1610) += pxe1610.o
obj-$(CONFIG_SENSORS_TPS40422)+= tps40422.o
obj-$(CONFIG_SENSORS_TPS53679)+= tps53679.o
obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
diff --git a/drivers/hwmon/pmbus/pxe1610.c b/drivers/hwmon/pmbus/pxe1610.c
new file mode 100644
index ..01e267944df5
--- /dev/null
+++ b/drivers/hwmon/pmbus/pxe1610.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hardware monitoring driver for Infineon PXE1610
+ *
+ * Copyright (c) 2019 Facebook Inc
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "pmbus.h"
+
+/*
+ * Identify chip parameters.
+ */
+static int pxe1610_identify(struct i2c_client *client,
+ struct pmbus_driver_info *info)
Please align continuation lines with '('.
+{
+ if (pmbus_check_byte_register(client, 0, PMBUS_VOUT_MODE)) {
+ int vout_mode;
+
+ vout_mode = pmbus_read_byte_data(client, 0, PMBUS_VOUT_MODE);
pmbus_read_byte_data() can return an error. Calling pmbus_check_byte_register()
doesn't really add any value here, since the second call can still fail,
which needs to be checked.
+ switch (vout_mode & 0x1f) {
+ case 1:
+ info->vrm_version = vr12;
+ break;
Alignment is off.
+ case 2:
+ info->vrm_version = vr13;
+ break;
Same here.
+ default:
+ return -ENODEV;
+ }
+ }
+ return 0;
+}
+
+static int pxe1610_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ struct pmbus_driver_info *info;
+ u8 buf[I2C_SMBUS_BLOCK_MAX];
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter,
+I2C_FUNC_SMBUS_READ_BYTE_DATA
+ | I2C_FUNC_SMBUS_READ_WORD_DATA
+ | I2C_FUNC_SMBUS_READ_BLOCK_DATA))
+ return -ENODEV;
+
+ /* By default this device doesn't boot to page 0, so set page 0
+* to access all pmbus registers.
+*/
Please use standard multi-line comments.
+ i2c_smbus_write_byte_data(client, 0, 0);
+
Please use the PMBUS_PAGE command definition.
I wonder if it would make sense to initialize currpage in the core to an
unreasonable
number for multi-page chips, but I guess that is a different question.
+ /* Read Manufacturer id */
+ ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read PMBUS_MFR_ID\n");
+ return ret;
+ }
+ if (ret != 2 || strncmp(buf, "XP", strlen("XP"))) {
The strlen() is really unnecessary here. Just use 2 (and a define
for it if you like).
+ dev_err(&client->dev, "MFR_ID unrecognised\n");
unrecognized. Oh well, turns out unrecognised is the British spelling and
just as valid, so feel free to keep it if you like.
+ return -ENODEV;
+ }
+
+ info = devm_kzalloc(&client->dev, sizeof(struct pmbus_driver_info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->format[PSC_VOLTAGE_IN] = linear;
+ info->format[PSC_VOLTAGE_OUT] = vid;
+ info->format[PSC_CURRENT_IN] = linear;
+ info->format[PS
Re: [PATCH 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
On 5/29/19 3:35 PM, Vijay Khemka wrote: Added support for Infenion PXE1610 driver Signed-off-by: Vijay Khemka --- Documentation/hwmon/pxe1610 | 84 + 1 file changed, 84 insertions(+) create mode 100644 Documentation/hwmon/pxe1610 diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610 new file mode 100644 index ..b5c83edf027a --- /dev/null +++ b/Documentation/hwmon/pxe1610 @@ -0,0 +1,84 @@ +Kernel driver pxe1610 += + +Supported chips: + * Infinion PXE1610 +Prefix: 'pxe1610' +Addresses scanned: - +Datasheet: Datasheet is not publicly available. + + * Infinion PXE1110 +Prefix: 'pxe1110' +Addresses scanned: - +Datasheet: Datasheet is not publicly available. + + * Infinion PXM1310 +Prefix: 'pxm1310' +Addresses scanned: - +Datasheet: Datasheet is not publicly available. + +Author: Vijay Khemka + + +Description +--- + +PXE1610 is a Multi-rail/Multiphase Digital Controllers and +it is compliant to Intel VR13 DC-DC converter specifications. + And the others ? + +Usage Notes +--- + +This driver can be enabled with kernel config CONFIG_SENSORS_PXE1610 +set to 'y' or 'm'(for module). + The above does not really add value. +This driver does not probe for PMBus devices. You will have +to instantiate devices explicitly. + +Example: the following commands will load the driver for an PXE1610 +at address 0x70 on I2C bus #4: + +# modprobe pxe1610 +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device + +It can also be instantiated by declaring in device tree if it is +built as a kernel not as a module. + I assume you mean "built into the kernel". Why would devicetree based instantiation not work if the driver is built as module ? + +Sysfs attributes + + +curr1_label"iin" +curr1_inputMeasured input current +curr1_alarmCurrent high alarm + +curr[2-4]_label"iout[1-3]" +curr[2-4]_inputMeasured output current +curr[2-4]_crit Critical maximum current +curr[2-4]_crit_alarm Current critical high alarm + +in1_label "vin" +in1_input Measured input voltage +in1_crit Critical maximum input voltage +in1_crit_alarm Input voltage critical high alarm + +in[2-4]_label "vout[1-3]" +in[2-4]_input Measured output voltage +in[2-4]_lcrit Critical minimum output voltage +in[2-4]_lcrit_alarmOutput voltage critical low alarm +in[2-4]_crit Critical maximum output voltage +in[2-4]_crit_alarm Output voltage critical high alarm + +power1_label "pin" +power1_input Measured input power +power1_alarm Input power high alarm + +power[2-4]_label "pout[1-3]" +power[2-4]_input Measured output power + +temp[1-3]_inputMeasured temperature +temp[1-3]_crit Critical high temperature +temp[1-3]_crit_alarm Chip temperature critical high alarm +temp[1-3]_max Maximum temperature +temp[1-3]_max_alarmChip temperature high alarm
Re: [PATCH 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
On Thu, May 30, 2019 at 06:51:52PM +, Vijay Khemka wrote: > > > On 5/29/19, 6:05 PM, "Guenter Roeck" li...@roeck-us.net> wrote: > > On 5/29/19 3:35 PM, Vijay Khemka wrote: > > Added support for Infenion PXE1610 driver > > > > Signed-off-by: Vijay Khemka > > --- > > Documentation/hwmon/pxe1610 | 84 + > > 1 file changed, 84 insertions(+) > > create mode 100644 Documentation/hwmon/pxe1610 > > > > diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610 > > new file mode 100644 > > index ..b5c83edf027a > > --- /dev/null > > +++ b/Documentation/hwmon/pxe1610 > > @@ -0,0 +1,84 @@ > > +Kernel driver pxe1610 > > += > > + > > +Supported chips: > > + * Infinion PXE1610 > > +Prefix: 'pxe1610' > > +Addresses scanned: - > > +Datasheet: Datasheet is not publicly available. > > + > > + * Infinion PXE1110 > > +Prefix: 'pxe1110' > > +Addresses scanned: - > > +Datasheet: Datasheet is not publicly available. > > + > > + * Infinion PXM1310 > > +Prefix: 'pxm1310' > > +Addresses scanned: - > > +Datasheet: Datasheet is not publicly available. > > + > > +Author: Vijay Khemka > > + > > + > > +Description > > +--- > > + > > +PXE1610 is a Multi-rail/Multiphase Digital Controllers and > > +it is compliant to Intel VR13 DC-DC converter specifications. > > + > > And the others ? > This supports VR12 as well and I don't see this controller supports any other > VR versions. > The point here is that there is no description of the other controllers. > > + > > +Usage Notes > > +--- > > + > > +This driver can be enabled with kernel config CONFIG_SENSORS_PXE1610 > > +set to 'y' or 'm'(for module). > > + > The above does not really add value. > Ok, I will remove it. > > > +This driver does not probe for PMBus devices. You will have > > +to instantiate devices explicitly. > > + > > +Example: the following commands will load the driver for an PXE1610 > > +at address 0x70 on I2C bus #4: > > + > > +# modprobe pxe1610 > > +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device > > + > > +It can also be instantiated by declaring in device tree if it is > > +built as a kernel not as a module. > > + > > I assume you mean "built into the kernel". > Why would devicetree based instantiation not work if the driver is built > as module ? > Will correct statement here. > > > + > > +Sysfs attributes > > + > > + > > +curr1_label"iin" > > +curr1_inputMeasured input current > > +curr1_alarmCurrent high alarm > > + > > +curr[2-4]_label"iout[1-3]" > > +curr[2-4]_inputMeasured output current > > +curr[2-4]_crit Critical maximum current > > +curr[2-4]_crit_alarm Current critical high alarm > > + > > +in1_label "vin" > > +in1_input Measured input voltage > > +in1_crit Critical maximum input voltage > > +in1_crit_alarm Input voltage critical high alarm > > + > > +in[2-4]_label "vout[1-3]" > > +in[2-4]_input Measured output voltage > > +in[2-4]_lcrit Critical minimum output voltage > > +in[2-4]_lcrit_alarmOutput voltage critical low alarm > > +in[2-4]_crit Critical maximum output voltage > > +in[2-4]_crit_alarm Output voltage critical high alarm > > + > > +power1_label "pin" > > +power1_input Measured input power > > +power1_alarm Input power high alarm > > + > > +power[2-4]_label "pout[1-3]" > > +power[2-4]_input Measured output power > > + > > +temp[1-3]_inputMeasured temperature > > +temp[1-3]_crit Critical high temperature > > +temp[1-3]_crit_alarm Chip temperature critical high alarm > > +temp[1-3]_max Maximum temperature > > +temp[1-3]_max_alarmChip temperature high alarm > > > > >
Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman wrote: > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote: > > Hey Greg, > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n", > > > > + data->misc.name); > > > > > > No need to be noisy, if all goes well, your code should be quiet. > > > > > > > I sometimes wonder about this being noise or not, so I will slightly > > hijack this thread for this discussion. > > > > >From a kernel developer point-of-view, or even from a platform > > developer or user with a debugging hat point-of-view, having > > a "device created" or "device registered" message is often very useful. > > For you, yes. For someone with 3 devices attached to their system, > it is not, and causes booting to take longer than it should be. > > > In fact, I wish people would do this more often, so I don't have to > > deal with dynamic debug, or hack my way: > > > > diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c > > index 4589631798c9..473549b26bb2 100644 > > --- a/drivers/media/i2c/ov5647.c > > +++ b/drivers/media/i2c/ov5647.c > > @@ -603,7 +603,7 @@ static int ov5647_probe(struct i2c_client *client, > > if (ret < 0) > > goto error; > > > > - dev_dbg(dev, "OmniVision OV5647 camera driver probed\n"); > > + dev_info(dev, "OmniVision OV5647 camera driver probed\n"); > > return 0; > > error: > > media_entity_cleanup(&sd->entity); > > > > In some subsystems, it's even a behavior I'm more or less relying on: > > > > $ git grep v4l2_info.*registered drivers/media/ | wc -l > > 26 > > > > And on the downsides, I can't find much. It's just one little line, > > that is not even noticed unless you have logging turned on. > > Its better to be quiet, which is why the "default driver registration" > macros do not have any printk messages in them. When converting drivers > over to it, we made the boot process much more sane, don't try to go and > add messages for no good reason back in please. > > dynamic debugging can be enabled on a module and line-by-line basis, > even from the boot command line. So if you need debugging, you can > always ask someone to just reboot or unload/load the module and get the > message that way. > Can we by any chance make this an official policy ? I am kind of tired having to argue about this over and over again. Thanks, Guenter
Re: [PATCH v2 1/2] hwmon: pmbus: Add Infineon PXE1610 VR driver
On Thu, May 30, 2019 at 04:11:56PM -0700, Vijay Khemka wrote:
> Added pmbus driver for the new device Infineon pxe1610
> voltage regulator. It also supports similar family device
> PXE1110 and PXM1310.
>
> Signed-off-by: Vijay Khemka
Applied.
Thanks,
Guenter
> ---
> Changes in v2:
> incorporated all the feedback from Guenter Roeck
>
> drivers/hwmon/pmbus/Kconfig | 9 +++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/pxe1610.c | 139 ++
> 3 files changed, 149 insertions(+)
> create mode 100644 drivers/hwmon/pmbus/pxe1610.c
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 30751eb9550a..338ef9b5a395 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -154,6 +154,15 @@ config SENSORS_MAX8688
> This driver can also be built as a module. If so, the module will
> be called max8688.
>
> +config SENSORS_PXE1610
> + tristate "Infineon PXE1610"
> + help
> + If you say yes here you get hardware monitoring support for Infineon
> + PXE1610.
> +
> + This driver can also be built as a module. If so, the module will
> + be called pxe1610.
> +
> config SENSORS_TPS40422
> tristate "TI TPS40422"
> help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 2219b9300316..b0fbd017a91a 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -18,6 +18,7 @@ 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_PXE1610)+= pxe1610.o
> obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
> obj-$(CONFIG_SENSORS_TPS53679) += tps53679.o
> obj-$(CONFIG_SENSORS_UCD9000)+= ucd9000.o
> diff --git a/drivers/hwmon/pmbus/pxe1610.c b/drivers/hwmon/pmbus/pxe1610.c
> new file mode 100644
> index ..ebe3f023f840
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/pxe1610.c
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Hardware monitoring driver for Infineon PXE1610
> + *
> + * Copyright (c) 2019 Facebook Inc
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "pmbus.h"
> +
> +#define PXE1610_NUM_PAGES 3
> +
> +/* Identify chip parameters. */
> +static int pxe1610_identify(struct i2c_client *client,
> + struct pmbus_driver_info *info)
> +{
> + if (pmbus_check_byte_register(client, 0, PMBUS_VOUT_MODE)) {
> + u8 vout_mode;
> + int ret;
> +
> + /* Read the register with VOUT scaling value.*/
> + ret = pmbus_read_byte_data(client, 0, PMBUS_VOUT_MODE);
> + if (ret < 0)
> + return ret;
> +
> + vout_mode = ret & GENMASK(4, 0);
> +
> + switch (vout_mode) {
> + case 1:
> + info->vrm_version = vr12;
> + break;
> + case 2:
> + info->vrm_version = vr13;
> + break;
> + default:
> + return -ENODEV;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static struct pmbus_driver_info pxe1610_info = {
> + .pages = PXE1610_NUM_PAGES,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_VOLTAGE_OUT] = vid,
> + .format[PSC_CURRENT_IN] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .format[PSC_POWER] = linear,
> + .func[0] = PMBUS_HAVE_VIN
> + | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
> + | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
> + | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
> + | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
> + | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
> + .func[1] = PMBUS_HAVE_VIN
> + | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
> + | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
> + | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
> + | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT
> + | PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
> + .func[2] = PMBUS_HAVE_VIN
> + | PMBUS_HAVE_VOUT | PMBUS_HAVE_IIN
> + | PMBUS_HAVE_IOUT | PMBUS_HAVE_PIN
> + | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
> + | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STA
Re: [PATCH v2 2/2] Docs: hwmon: pmbus: Add PXE1610 driver
On Thu, May 30, 2019 at 04:11:57PM -0700, Vijay Khemka wrote: > Added support for Infenion PXE1610 driver > Applied, after fixing s/Infenion/Infineon/ s/Infinion/Infineon/ Guenter > Signed-off-by: Vijay Khemka > --- > Changes in v2: > incorporated all the feedback from Guenter Roeck > > Documentation/hwmon/pxe1610 | 90 + > 1 file changed, 90 insertions(+) > create mode 100644 Documentation/hwmon/pxe1610 > > diff --git a/Documentation/hwmon/pxe1610 b/Documentation/hwmon/pxe1610 > new file mode 100644 > index ..24825db8736f > --- /dev/null > +++ b/Documentation/hwmon/pxe1610 > @@ -0,0 +1,90 @@ > +Kernel driver pxe1610 > += > + > +Supported chips: > + * Infinion PXE1610 > +Prefix: 'pxe1610' > +Addresses scanned: - > +Datasheet: Datasheet is not publicly available. > + > + * Infinion PXE1110 > +Prefix: 'pxe1110' > +Addresses scanned: - > +Datasheet: Datasheet is not publicly available. > + > + * Infinion PXM1310 > +Prefix: 'pxm1310' > +Addresses scanned: - > +Datasheet: Datasheet is not publicly available. > + > +Author: Vijay Khemka > + > + > +Description > +--- > + > +PXE1610/PXE1110 are Multi-rail/Multiphase Digital Controllers > +and compliant to > + -- Intel VR13 DC-DC converter specifications. > + -- Intel SVID protocol. > +Used for Vcore power regulation for Intel VR13 based microprocessors > + -- Servers, Workstations, and High-end desktops > + > +PXM1310 is a Multi-rail Controllers and it is compliant to > + -- Intel VR13 DC-DC converter specifications. > + -- Intel SVID protocol. > +Used for DDR3/DDR4 Memory power regulation for Intel VR13 and > +IMVP8 based systems > + > + > +Usage Notes > +--- > + > +This driver does not probe for PMBus devices. You will have > +to instantiate devices explicitly. > + > +Example: the following commands will load the driver for an PXE1610 > +at address 0x70 on I2C bus #4: > + > +# modprobe pxe1610 > +# echo pxe1610 0x70 > /sys/bus/i2c/devices/i2c-4/new_device > + > +It can also be instantiated by declaring in device tree > + > + > +Sysfs attributes > + > + > +curr1_label "iin" > +curr1_input Measured input current > +curr1_alarm Current high alarm > + > +curr[2-4]_label "iout[1-3]" > +curr[2-4]_input Measured output current > +curr[2-4]_crit Critical maximum current > +curr[2-4]_crit_alarm Current critical high alarm > + > +in1_label"vin" > +in1_inputMeasured input voltage > +in1_crit Critical maximum input voltage > +in1_crit_alarm Input voltage critical high alarm > + > +in[2-4]_label"vout[1-3]" > +in[2-4]_inputMeasured output voltage > +in[2-4]_lcritCritical minimum output voltage > +in[2-4]_lcrit_alarm Output voltage critical low alarm > +in[2-4]_crit Critical maximum output voltage > +in[2-4]_crit_alarm Output voltage critical high alarm > + > +power1_label "pin" > +power1_input Measured input power > +power1_alarm Input power high alarm > + > +power[2-4]_label "pout[1-3]" > +power[2-4]_input Measured output power > + > +temp[1-3]_input Measured temperature > +temp[1-3]_crit Critical high temperature > +temp[1-3]_crit_alarm Chip temperature critical high alarm > +temp[1-3]_maxMaximum temperature > +temp[1-3]_max_alarm Chip temperature high alarm
Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
On Wed, Jun 05, 2019 at 02:06:44PM +, Rasmus Villemoes wrote: > When the watchdog device is not open by userspace, the kernel takes > care of pinging it. When the open_timeout feature is in use, we should > ensure that the hardware fires close to open_timeout seconds after the > kernel has assumed responsibility for the device. > > To do this, simply reuse the logic that is already in place for > ensuring the same thing when userspace is responsible for regularly > pinging the device: > > - When watchdog_active(wdd), this patch doesn't change anything. > > - When !watchdoc_active(wdd), the "virtual timeout" should be taken to s/watchdoc_active/watchdog_active/ otherwise Reviewed-by: Guenter Roeck > be ->open_deadline". When the open_timeout feature is not used or the > device has been opened at least once, ->open_deadline is KTIME_MAX, > and the arithmetic ends up returning keepalive_interval as we used to. > > This has been tested on a Wandboard with various combinations of > open_timeout and timeout-sec properties for the on-board watchdog by > booting with 'init=/bin/sh', timestamping the lines on the serial > console, and comparing the timestamp of the 'imx2-wdt 20bc000.wdog: > timeout nnn sec' line with the timestamp of the 'U-Boot SPL ...' > line (which appears just after reset). > > Suggested-by: Guenter Roeck > Signed-off-by: Rasmus Villemoes > --- > drivers/watchdog/watchdog_dev.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c > index 334b810db2cf..edfb884044e0 100644 > --- a/drivers/watchdog/watchdog_dev.c > +++ b/drivers/watchdog/watchdog_dev.c > @@ -133,14 +133,15 @@ static ktime_t watchdog_next_keepalive(struct > watchdog_device *wdd) > ktime_t virt_timeout; > unsigned int hw_heartbeat_ms; > > - virt_timeout = ktime_add(wd_data->last_keepalive, > - ms_to_ktime(timeout_ms)); > + if (watchdog_active(wdd)) > + virt_timeout = ktime_add(wd_data->last_keepalive, > + ms_to_ktime(timeout_ms)); > + else > + virt_timeout = wd_data->open_deadline; > + > hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms); > keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2); > > - if (!watchdog_active(wdd)) > - return keepalive_interval; > - > /* >* To ensure that the watchdog times out wdd->timeout seconds >* after the most recent ping from userspace, the last
Re: [PATCH v10 1/3] watchdog: introduce watchdog.open_timeout commandline parameter
On Wed, Jun 05, 2019 at 02:06:41PM +, 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.
>
> A value of 0 (the default) means infinite timeout, preserving the
> current behaviour.
>
> 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, ...).
>
> There is already handle_boot_enabled serving a similar purpose. However,
> such a binary choice is unsuitable if the hardware watchdog cannot be
> programmed by the bootloader to provide a timeout long enough for
> userspace to get up and running. Many of the embedded devices we see use
> external (gpio-triggered) watchdogs with a fixed timeout of the order of
> 1-2 seconds.
>
> The open timeout only applies for the first open from
> userspace. Should userspace need to close the watchdog device, with
> the intention of re-opening it shortly, the application can emulate
> the open timeout feature by combining the nowayout feature with an
> appropriate WDIOC_SETTIMEOUT immediately prior to closing the device.
>
> Signed-off-by: Rasmus Villemoes
Reviewed-by: Guenter Roeck
> ---
> .../watchdog/watchdog-parameters.txt | 8 +
> drivers/watchdog/watchdog_dev.c | 36 ++-
> 2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt
> b/Documentation/watchdog/watchdog-parameters.txt
> index 0b88e333f9e1..32d3606caa65 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 seconds, for which the watchdog framework will take care of pinging
> +a running 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 252a7c7b6592..e4b51db48f0e 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -69,6 +69,7 @@ struct watchdog_core_data {
> struct mutex lock;
> ktime_t last_keepalive;
> ktime_t last_hw_keepalive;
> + ktime_t open_deadline;
> struct hrtimer timer;
> struct kthread_work work;
> unsigned long status; /* Internal status bits */
> @@ -87,6 +88,19 @@ static struct kthread_worker *watchdog_kworker;
> 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)
> +{
> + return ktime_after(ktime_get(), data->open_deadline);
> +}
> +
> +static void watchdog_set_open_deadline(struct watchdog_core_data *data)
> +{
> + data->open_deadline = open_timeout ?
> + ktime_get() + ktime_set(open_timeout, 0) : KTIME_MAX;
> +}
> +
> static inline bool watchdog_need_worker(struct watchdog_device *wdd)
> {
> /* All variables in milli-seconds */
> @@ -211,7 +225,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 kthread_work *work)
> @@ -824,6 +844,15 @@ static int watchdog_open(struct inode *inode, struct
> file *file)
> if (!hw_running)
> kref_get(&wd_data->kref);
&g
Re: [PATCH v10 2/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT
On Wed, Jun 05, 2019 at 02:06:43PM +, 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
Reviewed-by: Guenter Roeck
> ---
> Documentation/watchdog/watchdog-parameters.txt | 8
> drivers/watchdog/Kconfig | 9 +
> drivers/watchdog/watchdog_dev.c| 5 +++--
> 3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt
> b/Documentation/watchdog/watchdog-parameters.txt
> index 32d3606caa65..ec919dc895ff 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -11,10 +11,10 @@ modules.
> The watchdog core parameter watchdog.open_timeout is the maximum time,
> in seconds, for which the watchdog framework will take care of pinging
> a running 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.
> +/dev/watchdogN device. 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 ffe754539f5a..a8bd621e12f8 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -58,6 +58,15 @@ config WATCHDOG_HANDLE_BOOT_ENABLED
> the watchdog on its own. Thus if your userspace does not start fast
> enough your device will reboot.
>
> +config WATCHDOG_OPEN_TIMEOUT
> + int "Timeout value for opening watchdog device"
> + default 0
> + help
> + The maximum time, in seconds, 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".
> +
> config WATCHDOG_SYSFS
> bool "Read different watchdog information through sysfs"
> help
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index e4b51db48f0e..334b810db2cf 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -88,7 +88,7 @@ static struct kthread_worker *watchdog_kworker;
> static bool handle_boot_enabled =
> IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
>
> -static unsigned open_timeout;
> +static unsigned open_timeout = CONFIG_WATCHDOG_OPEN_TIMEOUT;
>
> static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
> {
> @@ -1214,4 +1214,5 @@ MODULE_PARM_DESC(handle_boot_enabled,
>
> module_param(open_timeout, uint, 0644);
> MODULE_PARM_DESC(open_timeout,
> - "Maximum time (in seconds, 0 means infinity) for userspace to take over
> a running watchdog (default=0)");
> + "Maximum time (in seconds, 0 means infinity) for userspace to take over
> a running watchdog (default="
> + __MODULE_STRING(CONFIG_WATCHDOG_OPEN_TIMEOUT) ")");
Re: [PATCH v3 30/33] docs: watchdog: convert docs to ReST and rename to *.rst
On Sat, Jun 08, 2019 at 11:27:20PM -0300, Mauro Carvalho Chehab wrote:
> Convert those documents and prepare them to be part of the kernel
> API book, as most of the stuff there are related to the
> Kernel interfaces.
>
> Still, in the future, it would make sense to split the docs,
> as some of the stuff is clearly focused on sysadmin tasks.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Cc: Mauro Carvalho Chehab ,
> linux-ker...@vger.kernel.org, Jonathan Corbet
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Guenter Roeck
> ---
> .../admin-guide/kernel-parameters.txt | 2 +-
> Documentation/kernel-per-CPU-kthreads.txt | 2 +-
> txt => convert_drivers_to_kernel_api.rst} | 109 +--
> .../watchdog/{hpwdt.txt => hpwdt.rst} | 25 +-
> Documentation/watchdog/index.rst | 25 +
> .../watchdog/{mlx-wdt.txt => mlx-wdt.rst} | 24 +-
> .../{pcwd-watchdog.txt => pcwd-watchdog.rst} | 13 +-
> .../{watchdog-api.txt => watchdog-api.rst}| 76 +-
> ...kernel-api.txt => watchdog-kernel-api.rst} | 91 ++-
> ...parameters.txt => watchdog-parameters.rst} | 672 +-
> .../{watchdog-pm.txt => watchdog-pm.rst} | 3 +
> Documentation/watchdog/{wdt.txt => wdt.rst} | 31 +-
> MAINTAINERS | 2 +-
> drivers/watchdog/Kconfig | 6 +-
> drivers/watchdog/smsc37b787_wdt.c | 2 +-
> 15 files changed, 767 insertions(+), 316 deletions(-)
> rename Documentation/watchdog/{convert_drivers_to_kernel_api.txt =>
> convert_drivers_to_kernel_api.rst} (75%)
> rename Documentation/watchdog/{hpwdt.txt => hpwdt.rst} (79%)
> create mode 100644 Documentation/watchdog/index.rst
> rename Documentation/watchdog/{mlx-wdt.txt => mlx-wdt.rst} (78%)
> rename Documentation/watchdog/{pcwd-watchdog.txt => pcwd-watchdog.rst} (89%)
> rename Documentation/watchdog/{watchdog-api.txt => watchdog-api.rst} (80%)
> rename Documentation/watchdog/{watchdog-kernel-api.txt =>
> watchdog-kernel-api.rst} (90%)
> rename Documentation/watchdog/{watchdog-parameters.txt =>
> watchdog-parameters.rst} (42%)
> rename Documentation/watchdog/{watchdog-pm.txt => watchdog-pm.rst} (92%)
> rename Documentation/watchdog/{wdt.txt => wdt.rst} (68%)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 0092a453f7dc..3d072ca532bb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5182,7 +5182,7 @@
> Default: 3 = cyan.
>
> watchdog timers [HW,WDT] For information on watchdog timers,
> - see Documentation/watchdog/watchdog-parameters.txt
> + see Documentation/watchdog/watchdog-parameters.rst
> or other driver-specific files in the
> Documentation/watchdog/ directory.
>
> diff --git a/Documentation/kernel-per-CPU-kthreads.txt
> b/Documentation/kernel-per-CPU-kthreads.txt
> index 23b0c8b20cd1..5623b9916411 100644
> --- a/Documentation/kernel-per-CPU-kthreads.txt
> +++ b/Documentation/kernel-per-CPU-kthreads.txt
> @@ -348,7 +348,7 @@ To reduce its OS jitter, do at least one of the following:
> 2. Boot with "nosoftlockup=0", which will also prevent these kthreads
> from being created. Other related watchdog and softlockup boot
> parameters may be found in
> Documentation/admin-guide/kernel-parameters.rst
> - and Documentation/watchdog/watchdog-parameters.txt.
> + and Documentation/watchdog/watchdog-parameters.rst.
> 3. Echo a zero to /proc/sys/kernel/watchdog to disable the
> watchdog timer.
> 4. Echo a large number of /proc/sys/kernel/watchdog_thresh in
> diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.txt
> b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
> similarity index 75%
> rename from Documentation/watchdog/convert_drivers_to_kernel_api.txt
> rename to Documentation/watchdog/convert_drivers_to_kernel_api.rst
> index 9fffb2958d13..dd934cc08e40 100644
> --- a/Documentation/watchdog/convert_drivers_to_kernel_api.txt
> +++ b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
> @@ -1,6 +1,8 @@
> +=
&
Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
On 6/14/19 1:41 AM, Rasmus Villemoes wrote: On 07/06/2019 20.38, Guenter Roeck wrote: On Wed, Jun 05, 2019 at 02:06:44PM +, Rasmus Villemoes wrote: When the watchdog device is not open by userspace, the kernel takes care of pinging it. When the open_timeout feature is in use, we should ensure that the hardware fires close to open_timeout seconds after the kernel has assumed responsibility for the device. To do this, simply reuse the logic that is already in place for ensuring the same thing when userspace is responsible for regularly pinging the device: - When watchdog_active(wdd), this patch doesn't change anything. - When !watchdoc_active(wdd), the "virtual timeout" should be taken to s/watchdoc_active/watchdog_active/ otherwise Reviewed-by: Guenter Roeck Thanks! Wim, can you fix up if/when applying, or do you prefer I resend? I made the change when applying the patch to my watchdog-next branch, and Wim usually picks up patches from there, so we should be good. Thanks, Guenter
Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
On 01/06/2017 02:17 PM, Edward James wrote:
[ ... ]
> +}
> +
> +static DEVICE_ATTR(online, S_IWUSR | S_IRUGO, show_occ_online,
> + store_occ_online);
> +
> +struct occ_sysfs *occ_sysfs_start(struct device *dev, struct occ *occ,
> + struct occ_sysfs_config *config)
> +{
> + struct occ_sysfs *hwmon = devm_kzalloc(dev, sizeof(struct occ_sysfs),
> + GFP_KERNEL);
> + int rc;
> +
> + if (!hwmon)
> + return ERR_PTR(-ENOMEM);
> +
> + hwmon->occ = occ;
> + hwmon->num_caps_fields = config->num_caps_fields;
> + hwmon->caps_names = config->caps_names;
> +
> + dev_set_drvdata(dev, hwmon);
> +
> + rc = device_create_file(dev, &dev_attr_online);
> + if (rc)
> + return ERR_PTR(rc);
> +
> + return hwmon;
> +}
> +EXPORT_SYMBOL(occ_sysfs_start);
> +
> +int occ_sysfs_stop(struct device *dev, struct occ_sysfs *driver)
> +{
> + if (driver->dev) {
> + occ_remove_hwmon_attrs(driver);
> + hwmon_device_unregister(driver->dev);
> + }
> +
> + device_remove_file(driver->dev, &dev_attr_online);
> +
> + devm_kfree(dev, driver);
Thw point of using devm_ functions is not to require remove/free functions.
Something is completely wrong here if you need that call.
Overall, this is architectually completely wrong. One does not register
or instantiate drivers based on writing into sysfs attributes. Please
reconsider your approach.
We had some trouble designing this driver because the BMC only has
access to the OCC once the processor is powered on. This will happen
sometime after the BMC boots (this driver runs only on the BMC). With
no access to the OCC, we don't know what sensors are present on the
system without a large static enumeration. Also any sysfs files created
before we have OCC access won't be able to return any data.
Instead of the "online" attribute, what do you think about using the
"bind"/"unbind" API to probe the device from user space once the system
is powered on? All the hwmon registration would take place in the probe
function, it would just occur some time after boot.
A more common approach would be to have a platform driver. That platform
driver would need a means to detect if the OCC is up and running, and
instantiate everything else once it is.
A trigger from user space is problematic because there is no guarantee
that the OCC is really up (or that it even exists).
An alternative might be to have the hwmon driver poll for the OCC,
but that would be a bit more difficult and might require a kernel thread
or maybe asynchronous probing.
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 linux 2/6] hwmon: occ: Add sysfs interface
On Tue, Jan 10, 2017 at 11:41:44AM -0600, Benjamin Herrenschmidt wrote: > On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote: > > > Instead of the "online" attribute, what do you think about using the > > > "bind"/"unbind" API to probe the device from user space once the system > > > is powered on? All the hwmon registration would take place in the probe > > > function, it would just occur some time after boot. > > > > > > > A more common approach would be to have a platform driver. That platform > > driver would need a means to detect if the OCC is up and running, and > > instantiate everything else once it is. > > > > A trigger from user space is problematic because there is no guarantee > > that the OCC is really up (or that it even exists). > > > > An alternative might be to have the hwmon driver poll for the OCC, > > but that would be a bit more difficult and might require a kernel thread > > or maybe asynchronous probing. > > Hi Guenter ! > > I'm not sure I agree with you here ;-) > > I'm don't know how much background you got (I missed the beginning of > the discussion) but basically this driver runs on the BMC (system > controller) of the POWER9 server, the OCC is inside the POWER9 chip > itself. > > So the presence/power state of the OCC doesn't depend on the BMC > platform kernel code. The BMC userspace controls power up and down to the > POWER9, and thus it's the one to know whether the remote is up. > > If we were to create a "platform driver", all it would do is get input > from userspace exactly like that sysfs file :-) > > So if you don't like the sysfs file that registers/de-registers, which > I sort-of understand, it's a bit of a hack (though a rather efficient > one), I think the bind/unbind approach makes sense. However, I wonder > whether the simplest and most efficient (remember this BMC has a really > slow CPU) is an "online" file sysfs file, though rather than > registering/de-registering the hwmon it would simply make it stop > accessing the HW (and return some known "offline" values). > I don't like that too much either; it still looks like a hack. How about using bind/unbind then ? 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] watchdog: introduce watchdog.open_timeout commandline parameter
On Mon, Jan 09, 2017 at 04:02:32PM +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 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 e21850e..2ae0fdf 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,
> +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 21809e4..8bc9f24 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);
> +
> +static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
> +{
> + if (!open_timeout)
> + return false;
> + return time_is_before_jiffies(data->open_deadline);
Doesn't this return true if the time is _before_ the open deadline ?
Should it be time_is_after_jiffies() ?
> +}
> +
> +static void watchdog_set_open_deadline(struct watchdog_core_data *data)
> +{
> + data->open_deadline = jiffies + msecs_to_jiffies(open_timeout);
The open deadline as defined applies to the time after the device was
instantiated, not to the time since boot. Would it be better to make it
"time since boot" ?
Also, are you sure about using milli-seconds (instead of seconds) ?
I can not really imagine a situation where this would be needed
(especially and even more so in the context of using "time after
instantiating").
Thanks,
Guenter
> +}
> +
> 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_d
Re: [PATCH v4 2/3] watchdog: introduce watchdog.open_timeout commandline parameter
On 01/11/2017 12:11 AM, Rasmus Villemoes wrote:
On 2017-01-10 19:08, Guenter Roeck wrote:
On Mon, Jan 09, 2017 at 04:02:32PM +0100, Rasmus Villemoes wrote:
+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);
Doesn't this return true if the time is _before_ the open deadline ?
Should it be time_is_after_jiffies() ?
Yes, time_is_before_jiffies(foo) means foo < jiffies, and that is what we want
when we're querying whether we've passed the deadline.
So you want the function to return true if the timeout has _not_ expired ?
+}
+
+static void watchdog_set_open_deadline(struct watchdog_core_data *data)
+{
+data->open_deadline = jiffies + msecs_to_jiffies(open_timeout);
The open deadline as defined applies to the time after the device was
instantiated, not to the time since boot. Would it be better to make it
"time since boot" ?
I don't have a strong opinion on that, but two small things made me do it this
way: (1) In case a hardware watchdog
is somehow hotplugged long after boot and userspace is supposed to detect that
and start feeding it, it wouldn't make
sense for the framework not to take care of it for a while. (2) The
open_timeout also applies to the case where the
userspace app gracefully closes the watchdog device (e.g. because it's been
instructed to restart to load a new configuration
or whatnot) but the hardware cannot be stopped. In that case, the framework
also takes over, and the same logic as after boot should apply
- if the app fails to come up again, the framework should not feed the dog
indefinitely, but OTOH it clearly doesn't make sense to have a boot-time based
deadline.
[ Can you try to work with line wraps ? ]
Uuh, no. I didn't realize that you apply that case to the "userspace app
gracefully
closes the watchdog device" case as well. This is clearly a separate use case.
Looks like there are now three use cases for 'open timeout'.
- time after boot
- timer after loading the watchdog device
- time after closing watchdog device and before reopening it
I would have thought the first use case is the important one, and the other
ones are,
at best, secondary. Given that, we are clearly not there yet. This will require
input
from others on the semantics.
Thanks,
Guenter
Also, are you sure about using milli-seconds (instead of seconds) ?
I can not really imagine a situation where this would be needed
(especially and even more so in the context of using "time after
instantiating").
I went back and forth on this. I did milli-seconds because that should cover
more use cases. Yes, wanting an open timeout of .7 seconds with 1.0 seconds
being unacceptable is unusual, but I know of some customers with very strict
requirements. Also, even if one cannot make userspace start that fast, one can
boot with a somewhat generous open_timeout and then write 700 to
/sys/module/watchdog/parameters/open_timeout for use in case (2) above.
Thanks,
Rasmus
--
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 v2 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC
On 01/11/2017 10:10 AM, eajames@gmail.com wrote:
From: "Edward A. James"
Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
well as probe the entire driver from the I2C bus. I2C is the communication
method between the BMC and the P8 OCC.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/devicetree/bindings/hwmon/occ.txt | 13 +++
drivers/hwmon/occ/Kconfig | 14 +++
drivers/hwmon/occ/Makefile | 1 +
drivers/hwmon/occ/p8_occ_i2c.c | 123
4 files changed, 151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
diff --git a/Documentation/devicetree/bindings/hwmon/occ.txt
b/Documentation/devicetree/bindings/hwmon/occ.txt
new file mode 100644
index 000..b0d2b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/occ.txt
@@ -0,0 +1,13 @@
+HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
+
+Required properties:
+ - compatible: must be "ibm,p8-occ-i2c"
+ - reg: physical address
+
+Example:
+i2c3: i2c-bus@100 {
+ occ@50 {
+ compatible = "ibm,p8-occ-i2c";
+ reg = <0x50>;
+ };
+};
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
index cdb64a7..3a5188f 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -13,3 +13,17 @@ menuconfig SENSORS_PPC_OCC
This driver can also be built as a module. If so, the module
will be called occ.
+
+if SENSORS_PPC_OCC
+
+config SENSORS_PPC_OCC_P8_I2C
+ tristate "POWER8 OCC hwmon support"
+ depends on I2C
+ help
+Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
+exposing temperature, frequency and power measurements.
+
+This driver can also be built as a module. If so, the module will be
+called p8-occ-i2c.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index a6881f9..9294b58 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o occ_p8.o p8_occ_i2c.o
diff --git a/drivers/hwmon/occ/p8_occ_i2c.c b/drivers/hwmon/occ/p8_occ_i2c.c
new file mode 100644
index 000..4515c68
--- /dev/null
+++ b/drivers/hwmon/occ/p8_occ_i2c.c
@@ -0,0 +1,123 @@
+/*
+ * p8_occ_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * 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
For all patches: alphabetic order, please.
+
+#include "scom.h"
+#include "occ_scom_i2c.h"
+#include "occ_p8.h"
+#include "occ_sysfs.h"
+
+#define P8_OCC_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ /* P8 i2c slave requires address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_getscom(bus, address, data);
+}
+
+int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ /* P8 i2c slave requires address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static struct occ_bus_ops p8_bus_ops = {
+ .getscom = p8_i2c_getscom,
+ .putscom = p8_i2c_putscom,
+};
+
+static int p8_occ_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct occ *occ;
+ struct occ_sysfs *hwmon;
+ const u32 *sensor_hwmon_configs = p8_get_sensor_hwmon_configs();
+
+ occ = p8_occ_start(&client->dev, client, &p8_bus_ops);
+ if (IS_ERR(occ))
+ return PTR_ERR(occ);
+
+ hwmon = occ_sysfs_start(&client->dev, occ, sensor_hwmon_configs,
+ P8_OCC_I2C_NAME);
+ if (IS_ERR(hwmon))
+ return PTR_ERR(hwmon);
+
+ i2c_set_clientdata(client, occ);
This maps to
dev_set_drvdata(&client->dev, occ);
and code in occ_sysfs_start() does the same, writing a reference to the hwmon
device.
+
+ return 0;
+}
+
+static int p8_occ_remove(struct i2c_client *client)
+{
+ struct occ *occ = i2c_get_clientdata(client);
+
+ return p8_occ_stop(occ);
+}
+
+/* used by old-style board info. */
+static const struct i2c_devi
Re: [PATCH linux v2 2/6] hwmon: occ: Add sysfs interface
On 01/11/2017 10:10 AM, 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 | 274 ++ drivers/hwmon/occ/occ_sysfs.h | 44 +++ 4 files changed, 381 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..e846b0c --- /dev/null +++ b/drivers/hwmon/occ/occ_sysfs.c @@ -0,0 +1,274 @@ +/* + * 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 + Again, for all patches: alphabetic order, please. +#include "occ.h" +#include "occ_sysfs.h" + +#define RESP_RETURN_CMD_INVAL 0x13 + +static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type, + u
Re: [PATCH linux v2 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC
On 01/11/2017 10:10 AM, eajames@gmail.com wrote:
From: "Edward A. James"
Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
well as probe the entire driver from the I2C bus. I2C is the communication
method between the BMC and the P8 OCC.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
Documentation/devicetree/bindings/hwmon/occ.txt | 13 +++
drivers/hwmon/occ/Kconfig | 14 +++
drivers/hwmon/occ/Makefile | 1 +
drivers/hwmon/occ/p8_occ_i2c.c | 123
4 files changed, 151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
diff --git a/Documentation/devicetree/bindings/hwmon/occ.txt
b/Documentation/devicetree/bindings/hwmon/occ.txt
new file mode 100644
index 000..b0d2b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/occ.txt
@@ -0,0 +1,13 @@
+HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
+
+Required properties:
+ - compatible: must be "ibm,p8-occ-i2c"
+ - reg: physical address
+
+Example:
+i2c3: i2c-bus@100 {
+ occ@50 {
+ compatible = "ibm,p8-occ-i2c";
+ reg = <0x50>;
+ };
+};
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
index cdb64a7..3a5188f 100644
--- a/drivers/hwmon/occ/Kconfig
+++ b/drivers/hwmon/occ/Kconfig
@@ -13,3 +13,17 @@ menuconfig SENSORS_PPC_OCC
This driver can also be built as a module. If so, the module
will be called occ.
+
+if SENSORS_PPC_OCC
+
+config SENSORS_PPC_OCC_P8_I2C
+ tristate "POWER8 OCC hwmon support"
+ depends on I2C
+ help
+Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
+exposing temperature, frequency and power measurements.
+
+This driver can also be built as a module. If so, the module will be
+called p8-occ-i2c.
+
+endif
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index a6881f9..9294b58 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
+obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o occ_p8.o p8_occ_i2c.o
diff --git a/drivers/hwmon/occ/p8_occ_i2c.c b/drivers/hwmon/occ/p8_occ_i2c.c
new file mode 100644
index 000..4515c68
--- /dev/null
+++ b/drivers/hwmon/occ/p8_occ_i2c.c
@@ -0,0 +1,123 @@
+/*
+ * p8_occ_i2c.c - hwmon OCC driver
+ *
+ * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
+ *
+ * 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 "scom.h"
+#include "occ_scom_i2c.h"
+#include "occ_p8.h"
+#include "occ_sysfs.h"
+
+#define P8_OCC_I2C_NAME"p8-occ-i2c"
+
+int p8_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ /* P8 i2c slave requires address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_getscom(bus, address, data);
+}
+
+int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ /* P8 i2c slave requires address to be shifted by 1 */
+ address = address << 1;
+
+ return occ_i2c_putscom(bus, address, data0, data1);
+}
+
+static struct occ_bus_ops p8_bus_ops = {
+ .getscom = p8_i2c_getscom,
+ .putscom = p8_i2c_putscom,
+};
+
+static int p8_occ_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct occ *occ;
+ struct occ_sysfs *hwmon;
+ const u32 *sensor_hwmon_configs = p8_get_sensor_hwmon_configs();
+
+ occ = p8_occ_start(&client->dev, client, &p8_bus_ops);
+ if (IS_ERR(occ))
+ return PTR_ERR(occ);
+
+ hwmon = occ_sysfs_start(&client->dev, occ, sensor_hwmon_configs,
+ P8_OCC_I2C_NAME);
+ if (IS_ERR(hwmon))
+ return PTR_ERR(hwmon);
+
+ i2c_set_clientdata(client, occ);
+
You might do the set_clientdata() call before the registration, and use
return PTR_ERR_OR_ZERO(hwmon). You'll need to drop the call to dev_set_drvdata()
in occ_sysfs_start() for that to work.
+ return 0;
+}
+
+static int p8_occ_remove(struct i2c_client *client)
+{
+ struct occ *occ = i2c_get_clientdata(client);
+
+ return p8_occ_stop(occ);
That stops occ first, then removes the hwmon driver registration. It
Re: [PATCH linux v2 0/6] drivers: hwmon: Add On-Chip Controller driver
On 01/11/2017 10:10 AM, eajames@gmail.com wrote: 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. Overall looks pretty good. There is the 0day hiccup (was that solved ?) and a few comments I made separately. It might make sense to add someone from IBM as maintainer. Thanks, Guenter 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 | 114 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 29 ++ drivers/hwmon/occ/Makefile | 2 + drivers/hwmon/occ/occ.c | 533 drivers/hwmon/occ/occ.h | 83 drivers/hwmon/occ/occ_p8.c | 254 +++ drivers/hwmon/occ/occ_p8.h | 31 ++ drivers/hwmon/occ/occ_p9.c | 314 ++ drivers/hwmon/occ/occ_p9.h | 31 ++ drivers/hwmon/occ/occ_scom_i2c.c| 73 drivers/hwmon/occ/occ_scom_i2c.h| 26 ++ drivers/hwmon/occ/occ_sysfs.c | 274 drivers/hwmon/occ/occ_sysfs.h | 44 ++ drivers/hwmon/occ/p8_occ_i2c.c | 123 ++ drivers/hwmon/occ/scom.h| 47 +++ 18 files changed, 1994 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_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/p8_occ_i2c.c create mode 100644 drivers/hwmon/occ/scom.h -- 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 v1 2/2] drivers: hwmon: hwmon driver for ASPEED AST2400/2500 PWM and Fan tach controller
On 01/09/2017 01:59 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. PWM clock types M, N and 0 are three types just to have three independent PWM sources. 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 --- Documentation/hwmon/aspeed-pwm-tacho | 22 + drivers/hwmon/Kconfig| 9 + drivers/hwmon/Makefile | 1 + drivers/hwmon/aspeed-pwm-tacho.c | 884 +++ 4 files changed, 916 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 ..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. + +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 ..93eb3be2e506 --- /dev/null +++ b/drivers/hwmon/aspeed-pwm-tacho.c @@ -0,0 +1,884 @@ +/* + * 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 + +/* 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 ASPEED_PTCR_TYPEN_CTRL 0x18 +#define ASPEED_PTCR_TYPEN_CTRL10x1c +#define ASPEED_PTCR_TACH_SOURCE0x20 +#define ASPEED_PTCR_TRIGGER0x28 +#define ASPEED_PTCR_RESULT 0x2c +#define ASPEED_PTCR_INTR_CTRL 0x30 +#define ASPEED_PTCR_INTR_STS 0x34 +#define ASPEED_PTCR_TYPEM_LIMIT0x38 +#define ASPEED_PTCR_TYPEN_LIMIT0x3C +#define ASPEED_PTCR_CTRL_EXT 0x40 +#define ASPEED_PTCR_CLK_CTRL_EXT 0x44 +#define ASPEED_PTCR_DUTY2_CTRL 0x48 +#define ASPEED_PTCR_DUTY3_CTRL 0x4c +#define ASPEED_PTCR_TYPEO_CTRL 0x50 +#define ASPEED_PTCR_TYPEO_CTRL10x54 +#define ASPEED_PTCR_TACH_SOURCE_EXT0x60 +#define ASPEED_PTCR_TYPEO_LIMIT0x78 + +/* ASPEED_PTCR_CTRL : 0x00 - General C
Re: [PATCH linux v3 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
On 01/16/2017 01:13 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| 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 + +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) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..3089762 --- /dev/n
Re: [PATCH linux v3 2/6] hwmon: occ: Add sysfs interface
On 01/16/2017 01:13 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 | 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
+ 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..2f20c40
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,271 @@
+/*
+ * 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
+
+static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ int rc = 0;
Re: [PATCH linux v3 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
On 01/16/2017 01:13 PM, eajames@gmail.com wrote:
From: "Edward A. James"
Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use SCOM
operations in order to access the OCC register space.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
drivers/hwmon/occ/occ_scom_i2c.c | 72
drivers/hwmon/occ/occ_scom_i2c.h | 26 +++
2 files changed, 98 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..8b4ca13
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,72 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * 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 "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ ssize_t rc;
+ u64 buf;
+ struct i2c_client *client = bus;
+
+ rc = i2c_master_send(client, (const char *)&address, sizeof(u32));
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u32))
+ return -EIO;
+
+ rc = i2c_master_recv(client, (char *)&buf, sizeof(u64));
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u64))
+ return -EIO;
+
+ *data = be64_to_cpu(buf);
+
+ return 0;
+}
+EXPORT_SYMBOL(occ_i2c_getscom);
+
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ u32 buf[3];
+ ssize_t rc;
+ struct i2c_client *client = bus;
+
+ buf[0] = address;
+ buf[1] = data1;
+ buf[2] = data0;
+
Receive data is converted from be64 to host byte order, transmit data is sent
as-is.
Yet, if I recall correctly, some of the calling code passes in constants. Are
you sure
this works on both little and big endian systems ?
+ rc = i2c_master_send(client, (const char *)buf, sizeof(u32) * 3);
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u32) * 3)
+ return -EIO;
+
+ return 0;
+}
+EXPORT_SYMBOL(occ_i2c_putscom);
+
+MODULE_AUTHOR("Eddie James ");
+MODULE_DESCRIPTION("I2C OCC SCOM transport");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_scom_i2c.h b/drivers/hwmon/occ/occ_scom_i2c.h
new file mode 100644
index 000..945739c
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,26 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * 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.
+ */
+
+#ifndef __OCC_SCOM_I2C_H__
+#define __OCC_SCOM_I2C_H__
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data);
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1);
+
+#endif /* __OCC_SCOM_I2C_H__ */
--
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 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures
On 01/16/2017 01:13 PM, eajames@gmail.com 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 | 247 +
drivers/hwmon/occ/occ_p8.h | 30 ++
3 files changed, 286 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_p8.c
create mode 100644 drivers/hwmon/occ/occ_p8.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index d0bdf06..143951e 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,15 @@ 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.
+The format for the POWER8 OCC sensor data can be found in the P8 OCC
+specification:
+github.com/open-power/docs/blob/master/occ/OCC_OpenPwr_FW_Interfaces.pdf
+This document provides the details of the OCC sensors: power, frequency,
+temperature, and caps. These sensor formats are specific to the POWER8 OCC. A
+number of data structures, such as command format, response headers, and the
+like, are also defined in this specification, and are common to both POWER8 and
+POWER9 OCCs.
+
sysfs Entries
-
diff --git a/drivers/hwmon/occ/occ_p8.c b/drivers/hwmon/occ/occ_p8.c
new file mode 100644
index 000..32215ed
--- /dev/null
+++ b/drivers/hwmon/occ/occ_p8.c
@@ -0,0 +1,247 @@
+/*
+ * occ_p8.c - OCC hwmon driver
+ *
+ * This file contains the Power8-specific methods and data structures for
+ * the OCC hwmon driver.
+ *
+ * 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 "occ.h"
+#include "occ_p8.h"
+
+/* P8 OCC sensor data format */
+struct p8_occ_sensor {
+ u16 sensor_id;
+ u16 value;
+};
+
+struct p8_power_sensor {
+ u16 sensor_id;
+ u32 update_tag;
+ u32 accumulator;
+ u16 value;
+};
+
+struct p8_caps_sensor {
+ u16 curr_powercap;
+ u16 curr_powerreading;
+ u16 norm_powercap;
+ u16 max_powercap;
+ u16 min_powercap;
+ u16 user_powerlimit;
+};
+
+static const u32 p8_sensor_hwmon_configs[MAX_OCC_SENSOR_TYPE] = {
+ HWMON_I_INPUT | HWMON_I_LABEL, /* freq: value | label */
+ HWMON_T_INPUT | HWMON_T_LABEL, /* temp: value | label */
+ /* power: value | label | accumulator | update_tag */
+ HWMON_P_INPUT | HWMON_P_LABEL | HWMON_P_AVERAGE |
+ HWMON_P_AVERAGE_INTERVAL,
+ /* caps: curr | max | min | norm | user */
+ HWMON_P_CAP | HWMON_P_CAP_MAX | HWMON_P_CAP_MIN | HWMON_P_MAX |
+ HWMON_P_ALARM,
+};
+
+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 *)&data[off]));
+ os->value = be16_to_cpu(get_unaligned((u16 *)&data[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 *)&data[off]));
+ ps->update_tag =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 2]));
+ ps->accumulator =
+ be32_to_cpu(get_unaligned((u32 *)&data[off + 6]));
+ ps->value = be16_to_cpu(get_unaligned((u16 *)&data[off + 10]));
+ }
+ break;
+ case CAPS:
+ {
+ struct p8_caps_sensor *cs =
+ &(((struct p8_caps_sensor *)sensor)[snum]);
+
+ cs->curr_powercap =
+ be16_to_cpu(get_unaligned((u16 *)&data[off]));
+ cs->curr_powerreading =
+ be16_to_cpu(get_unaligned((u16 *)&data[off + 2]));
+ cs->norm_powercap =
+ be16_to_cpu(get_unaligned((u16 *)&data[off + 4]));
+
Re: [PATCH 1/2] hwmon: (lm70) Utilize dev_warn instead of pr_warn
On 01/21/2017 11:20 AM, Florian Fainelli wrote: We have a device reference, utilize it instead of pr_warn(). Signed-off-by: Florian Fainelli --- Applied to -next. 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 2/2] hwmon: (lm70) Add support for TI TMP122/124
On 01/21/2017 11:20 AM, Florian Fainelli wrote:
Add support for Texas Instruments TMP122/124 which are nearly identical to
their TMP121/123 except that they also support programmable temperature
thresholds.
Signed-off-by: Florian Fainelli
Applied to -next.
Any plans to add support for the thresholds ?
Thanks,
Guenter
---
Documentation/devicetree/bindings/hwmon/lm70.txt | 1 +
Documentation/hwmon/lm70 | 8 ++--
drivers/hwmon/lm70.c | 9 -
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/lm70.txt
b/Documentation/devicetree/bindings/hwmon/lm70.txt
index e7fd921aa4f1..ea417a0d32af 100644
--- a/Documentation/devicetree/bindings/hwmon/lm70.txt
+++ b/Documentation/devicetree/bindings/hwmon/lm70.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: one of
"ti,lm70"
"ti,tmp121"
+ "ti,tmp122"
"ti,lm71"
"ti,lm74"
diff --git a/Documentation/hwmon/lm70 b/Documentation/hwmon/lm70
index 1bb2db440671..c3a1f2ea017d 100644
--- a/Documentation/hwmon/lm70
+++ b/Documentation/hwmon/lm70
@@ -6,6 +6,8 @@ Supported chips:
Datasheet: http://www.national.com/pf/LM/LM70.html
* Texas Instruments TMP121/TMP123
Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
+ * Texas Instruments TMP122/TMP124
+Information: http://www.ti.com/product/tmp122
* National Semiconductor LM71
Datasheet: http://www.ti.com/product/LM71
* National Semiconductor LM74
@@ -35,8 +37,10 @@ As a real (in-tree) example of this "SPI protocol driver"
interfacing
with a "SPI master controller driver", see drivers/spi/spi_lm70llp.c
and its associated documentation.
-The LM74 and TMP121/TMP123 are very similar; main difference is 13-bit
-temperature data (0.0625 degrees celsius resolution).
+The LM74 and TMP121/TMP122/TMP123/TMP124 are very similar; main difference is
+13-bit temperature data (0.0625 degrees celsius resolution).
+
+The TMP122/TMP124 also feature configurable temperature thresholds.
The LM71 is also very similar; main difference is 14-bit temperature
data (0.03125 degrees celsius resolution).
diff --git a/drivers/hwmon/lm70.c b/drivers/hwmon/lm70.c
index 52c5cdd00448..543556dc563b 100644
--- a/drivers/hwmon/lm70.c
+++ b/drivers/hwmon/lm70.c
@@ -46,6 +46,7 @@
#define LM70_CHIP_TMP121 1 /* TI TMP121/TMP123 */
#define LM70_CHIP_LM71 2 /* NS LM71 */
#define LM70_CHIP_LM74 3 /* NS LM74 */
+#define LM70_CHIP_TMP122 4 /* TI TMP122/TMP124 */
struct lm70 {
struct spi_device *spi;
@@ -92,7 +93,7 @@ static ssize_t temp1_input_show(struct device *dev,
* Celsius.
* So it's equivalent to multiplying by 0.25 * 1000 = 250.
*
-* LM74 and TMP121/TMP123:
+* LM74 and TMP121/TMP122/TMP123/TMP124:
* 13 bits of 2's complement data, discard LSB 3 bits,
* resolution 0.0625 degrees celsius.
*
@@ -106,6 +107,7 @@ static ssize_t temp1_input_show(struct device *dev,
break;
case LM70_CHIP_TMP121:
+ case LM70_CHIP_TMP122:
case LM70_CHIP_LM74:
val = ((int)raw / 8) * 625 / 10;
break;
@@ -143,6 +145,10 @@ static const struct of_device_id lm70_of_ids[] = {
.data = (void *) LM70_CHIP_TMP121,
},
{
+ .compatible = "ti,tmp122",
+ .data = (void *) LM70_CHIP_TMP122,
+ },
+ {
.compatible = "ti,lm71",
.data = (void *) LM70_CHIP_LM71,
},
@@ -191,6 +197,7 @@ static int lm70_probe(struct spi_device *spi)
static const struct spi_device_id lm70_ids[] = {
{ "lm70", LM70_CHIP_LM70 },
{ "tmp121", LM70_CHIP_TMP121 },
+ { "tmp122", LM70_CHIP_TMP122 },
{ "lm71", LM70_CHIP_LM71 },
{ "lm74", LM70_CHIP_LM74 },
{ },
--
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/2] hwmon: (lm70) Add support for TI TMP122/124
On 01/21/2017 03:11 PM, Florian Fainelli wrote: On January 21, 2017 12:25:21 PM PST, Guenter Roeck wrote: On 01/21/2017 11:20 AM, Florian Fainelli wrote: Add support for Texas Instruments TMP122/124 which are nearly identical to their TMP121/123 except that they also support programmable temperature thresholds. Signed-off-by: Florian Fainelli Applied to -next. Thanks was fast, thanks! Lucky you, the patches caught up with me me while I was going through the backlog. Any plans to add support for the thresholds ? Yes, as mentioned in the cover letter, need to get SPI_3WIRE working with the SPI controller (spi-ep93xx) to verify the thresholds do work. Guess the hint is that one should read the cover letter :-) 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] hwmon: (lm70) Utilize dev_warn instead of pr_warn
On 01/22/2017 10:43 PM, Joe Perches wrote:
On Sat, 2017-01-21 at 11:20 -0800, Florian Fainelli wrote:
We have a device reference, utilize it instead of pr_warn().
There is at least one more hwmon to convert in applesmc.c
Perhaps a coccinelle script?
Two questions for Julia Lawall:
o is there a better way to do this than repeat the blocks
one for each replacement
o can struct device * dev be made an arbitrary identifier
Definitely yes here; otherwise you only catch the ones named 'dev'.
Did you try "identifier dev;" ?
The type of fn is irrelevant; you don't need to specify it.
There is also the case where 'struct device *dev' is a local variable
fn(...) {
...
struct device *dev = e;
<...
...>
}
or when it isn't but is still available
fn (..., struct \(platform_device\|i2c_device\|spi_device\) *pdev, ...) {
}
$ cat dev_printk.cocci
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_emerg(
+ dev_emerg(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_crit(
+ dev_crit(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_alert(
+ dev_alert(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_err(
+ dev_err(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_notice(
+ dev_notice(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_warn(
+ dev_warn(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_info(
+ dev_info(dev,
...);
...>
}
@@
identifier fn;
type T;
@@
T fn ( ..., struct device * dev, ... ) {
<...
- pr_debug(
+ dev_dbg(dev,
...);
...>
}
--
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 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
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 wrote: > > On 01/16/2017 01:13 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| 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 > >> + > >> +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/driv
Re: [PATCH linux v3 2/6] hwmon: occ: Add sysfs interface
On Mon, Jan 23, 2017 at 04:01:25PM -0600, Edward James wrote: > > > On Sat, Jan 21, 2017 at 12:08 PM, Guenter Roeck wrote: > > On 01/16/2017 01:13 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 | 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 > >> + update_interval - read or write the minimum interval for polling > >> the > >&
[PATCH] watchdog: Introduce watchdog_stop_on_unregister helper
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
---
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(&wd_data->lock);
+ if (watchdog_active(wdd) &&
+ test_bit(WDOG_STOP_ON_UNREGISTER, &wdd->status)) {
+ watchdog_stop(wdd);
+ }
+
cancel_delayed_work_sync(&wd_data->work);
kref_put(&wd_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, &wdd->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, &wdd->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 v4 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
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) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..3b233d8 --- /dev
Re: [PATCH linux v4 2/6] hwmon: occ: Add sysfs interface
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 *occ;
+
+ char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
Re: [PATCH linux v5 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
On 01/31/2017 07:43 AM, eaja...@linux.vnet.ibm.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| 470 + drivers/hwmon/occ/occ.h| 80 drivers/hwmon/occ/scom.h | 47 + 9 files changed, 663 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 5f10c28..193a13b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9128,6 +9128,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) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..cb9f916 ---
Re: [PATCH linux v7 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures
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
> > > *)&data[off]));
> > > + os->value = be16_to_cpu(get_unaligned((u16 *)&data[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
> > > *)&data[off]));
> > > + ps->update_tag =
> > > + be32_to_cpu(get_unaligned((u32 *)&data[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 *)&data[off + 6]));
> > > + ps->value = be16_to_cpu(get_unaligned((u16 *)&data[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, &p8_ops, &p8_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 info at http://vger.kernel.org/majordomo-info.ht
Re: [PATCH] docs: hwmon: Fix typo "Microship" should be "Microchip"
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 v8 0/6] drivers: hwmon: Add On-Chip Controller driver
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: [RFC 2/2] hwmon: powernv: Hwmon driver for OCC inband power and temperature sensors
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 > CC: Rob Herring > CC: Mark Rutland > CC: Jean Delvare > CC: Guenter Roeck > CC: Jonathan Corbet > 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 distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS
Re: [PATCH linux v8 2/6] hwmon: occ: Add sysfs interface
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,
+ u32 attr, int channel, long *va
Re: [RFC 2/2] hwmon: powernv: Hwmon driver for OCC inband power and temperature sensors
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
CC: Rob Herring
CC: Mark Rutland
CC: Jean Delvare
CC: Guenter Roeck
CC: Jonathan Corbet
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 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 o
Re: [PATCH linux v5 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
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. + */ + +#include +#include +#include +
Re: [PATCH linux v9 2/5] hwmon: occ: Add sysfs interface
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 occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+
Re: [PATCH linux v6 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver
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 = <&pwm_tacho_fixed_clk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_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 v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
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 ASPEED_PTCR_TYPEN_CTRL 0x18 +#define ASPE
Re: [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
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 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: + + +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_SENSORS_ASC7621)+= asc7621.o +obj-$(CONFI
Re: [PATCH 2/2] devicetree: Document the max31760 device binding.
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 2/3] hwmon: (adt7475) fan stall prevention
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(&data->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, &val))
> + return -EINVAL;
> +
> + mutex_lock(&data->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(&data->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);
> +static SENSOR_DEVI
Re: [RFC PATCH 3/3] hwmon: (adt7475) temperature smoothing
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, &val))
> + 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(&data->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(&data->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, 0);
> +static SENSOR
Re: [RFC PATCH v2 2/3] hwmon: (adt7475) fan stall prevention
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(&data->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, &val))
> + return -EINVAL;
> +
> + mutex_lock(&data->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(&data->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);
> s
Re: [RFC PATCH v2 3/3] hwmon: (adt7475) temperature smoothing
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, &val))
> + 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(&data->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(&data->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 SENSOR_DEVICE_ATTR_2(temp2_crit,
Re: [PATCH v3 2/4] hwmon: (adt7475) fan stall prevention
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(&data->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, &val))
+ return -EINVAL;
+
+ mutex_lock(&data->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(&data->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 SENSOR_DEVICE_ATTR_2(pwm3_auto_point1_pwm, S_IRUGO
| S
Re: [PATCH v3 3/4] hwmon: (adt7475) temperature smoothing
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
---
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.
Changes in v3:
- change enh_acou to enh_acoustics
- simplify show_temp_st()
Documentation/hwmon/adt7475 | 4 ++
drivers/hwmon/adt7475.c | 93 +
2 files changed, 97 insertions(+)
diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 3990bae60e78..e82b24ec4b07 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_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 4d6c625fec70..f7322330789c 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -526,6 +526,90 @@ 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:
+ val = data->enh_acoustics[1] & 0xf;
+ break;
+ default:
+ return -EINVAL;
This will never happen and, if it does, would indicate a bug, not invalid input.
I kind of dislike dead code; it just bloats the kernel. Please either use
default: for or together with case 2:, or make it if/else.
+ }
+
+ 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, &val))
+ 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;
Is this correct ? It associates
temp1_smoothing -> remote 1
temp2_smoothing -> remote 2
temp3_smoothing -> local
which, unless I am missing something, doesn't match temp1/2/3.
+ default:
+ return -EINVAL;
Same as above.
+ }
+
+ if (val > 0) {
+ val = find_closest_descending(val, ad7475_st_map,
+ ARRAY_SIZE(ad7475_st_map));
+ val |= 0x8;
+ }
+
+ mutex_lock(&data->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(&data->lock);
+
+ return count;
+}
+
/*
* Table of autorange values - the user will write the value in millidegrees,
* and we'll convert it
@@ -1008,6 +1092,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, HYS
Re: [PATCH v3 3/4] hwmon: (adt7475) temperature smoothing
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 --- 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 v4 1/3] hwmon: (adt7475) fan stall prevention
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(&data->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, &val))
+ return -EINVAL;
+
+ mutex_lock(&data->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(&data->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 SENSOR_DEVICE_ATTR_2(pwm3_freq, S_IRUG
Re: [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing
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, &val))
+ 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(&data->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(&data->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,
+ set_temp_st, 0, 0);
static S
Re: [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing
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: [kbuild-all] [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing
On 05/16/2017 09:39 PM, Ye Xiaolong wrote:
On 05/17, Chris Packham wrote:
On 17/05/17 15:09, Ye Xiaolong wrote:
On 05/16, 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.
Hi,
0day bot applied your patchset on top of commit 6eaaea1 ("hwmon: (pmbus) Add client
driver for IR35221"),
is it wrong or you have some prerequisite patches?
Thanks for the info, seems we need to improve the kbuild bot by pulling the
latest tree before applying new patches.
No worries. I don't mind the occasional false positive. Better a false positive
than a missed bug.
Guenter
Thanks,
Xiaolong
Looks like it's missing
https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?h=hwmon-next&id=bbb4dd0ff
which was part of the series but was applied after v3 so I didn't send
it out with v4.
--
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: [kbuild-all] [PATCH v4 2/3] hwmon: (adt7475) temperature smoothing
On 05/17/2017 08:05 PM, Ye Xiaolong wrote:
On 05/16, Guenter Roeck wrote:
0day bot applied your patchset on top of commit 6eaaea1 ("hwmon: (pmbus) Add client
driver for IR35221"),
is it wrong or you have some prerequisite patches?
Thanks for the info, seems we need to improve the kbuild bot by pulling the
latest tree before applying new patches.
No worries. I don't mind the occasional false positive. Better a false positive
than a missed bug.
Just curiosity, I noticed you committed the missing patch bbb4dd0fff ("hwmon:
(adt7475) replace find_nearest() with find_closest()") at May 14, did you push
it to git.kernel.org immediately or sometime after that? Since 0day makes
mirror based on repos in git.kernel.org in this case.
I don't recall, sorry. Most likely I didn't push it immediately.
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 0/5] hwmon: move include files out of include/linux/i2c
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 v5 0/3] watchdog: allow setting deadline for opening /dev/watchdogN
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 v5 2/3] watchdog: introduce watchdog.open_timeout commandline parameter
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 v3] hwmon: Add support for MAX31785 intelligent fan controller
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 max6697. +config SENSORS_MAX31785 + tristate "Maxim MAX31785 sensor chip
Re: [PATCH v6 0/3] watchdog: allow setting deadline for opening /dev/watchdogN
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
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 v3] hwmon: Add support for MAX31785 intelligent fan controller
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 > > > 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
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 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. 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: [v6, 2/3] watchdog: introduce watchdog.open_timeout commandline parameter
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: [v6,3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT
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: [v3, 02/12] Documentation: ABI: Add occ-hwmon driver sysfs documentation
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 http://vger.kernel.org/majordomo-info.html
Re: [v3, 09/12] hwmon (occ): Add sensor attributes and register hwmon device
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,10/12] hwmon (occ): Add non-hwmon attributes
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[] = {
> + &sensor_dev_attr_occ_master.dev_attr.attr,
> + &sensor_dev_attr_occ_active.dev_attr.attr,
> + &sensor_dev_attr_occ_dvfs_ot.dev_attr.attr,
> + &sensor_dev_attr_occ_dvfs_power.dev_attr.attr,
> + &sensor_dev_attr_occ_mem_throttle.dev_attr.attr,
> + &sensor_dev_attr_occ_quick_drop.dev_attr.attr,
> + &sensor_dev_attr_occ_status.dev_attr.attr,
> + &sensor_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(&occ->bus_dev->kobj, &occ_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(&occ->bus_dev->kobj, &occ_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/hwmo
Re: [PATCH 1/2] watchdog: introduce watchdog.open_timeout commandline parameter
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 bool watchdog_need_worker(struct watchdog_device
Re: [PATCH 1/2] watchdog: introduce watchdog.open_timeout commandline parameter
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: [v6,1/4] pmbus (core): Add fan control support
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: [v6,2/4] pmbus (max31785): Add fan control
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 1:
> +
Re: [v6,3/4] pmbus (core): Add virtual page config bit
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
