driver for the hardware monitoring chip in the Zyxel NSA320
Subsystems (3)
v3 cover driver for the hardware monitoring chip in the Zyxel NSA320
This patch series adds a driver to support the hardware monitoring MCU that is present in the Zyxel NSA320. It is believed that this is identical to the one used in the NSA325 and some variants of the NSA310.
Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt | 21 +++ Documentation/hwmon/nsa320 | 53 +++++++ arch/arm/boot/dts/kirkwood-nsa320.dts | 13 +- drivers/hwmon/Kconfig | 15 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/nsa320-hwmon.c | 215 ++++++++++++++++++++++++++++ 6 files changed, 316 insertions(+), 2 deletions(-)
---
Changes since v1
Update to reflect linux at roeck-us.netreview comments from Guenter Roeck, mainly changing it to be nsa320, not nsa3xx but also making it return an errno on failure and various other tidy ups.
Changes since v2
Update patch 2/3 based on further review from Guenter Roeck, patches 1/3 and 3/3 are unchanged except for adding Rob's Ack to 1/3
PATCH v3 1/3 hwmon: Define binding for the nsa320-hwmon driver
Define a binding for the hardware monitoring chip present in the Zyxel NSA-320 and some of the other Zyxel NAS devices.
---
Changes for v3, Add Robs Ack
--- .../devicetree/bindings/hwmon/nsa320-mcu.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt new file +21 -0
@@ -0,0 +1,21 @@ +Bindings for the fan / temperature monitor microcontroller used on +the Zyxel NSA 320 and several subsequent models. + +Required properties: +- compatible : "zyxel,nsa320-mcu" +- data-gpios : The GPIO pin connected to the data line on the MCU +- clk-gpios : The GPIO pin connected to the clock line on the MCU +- act-gpios : The GPIO pin connected to the active line on the MCU + +Example: + + hwmon { + compatible = "zyxel,nsa320-mcu"; + pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>; + pinctrl-names = "default"; + + data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; + clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>; + }; +
Signature · 1 line
2.1.4
PATCH v3 2/3 hwmon: Create an NSA320 hardware monitoring driver
In reply to Adam BakerCreate a driver to support the hardware monitoring chip present in the Zyxel NSA320 and some of the other Zyxel NAS devices.
The driver reads fan speed and temperature from a suitably pre-programmed MCU on the device.
---
Changes since v2
Updated based on Guenter Roeck's review,
- return a single value that is result or error from the update function
- use separate show_value routimes for fan and temp
- Added Documentation/hwmon/nsa320-hwmon
--- Documentation/hwmon/nsa320 | 53 +++++++++++ drivers/hwmon/Kconfig | 15 +++ drivers/hwmon/Makefile | 1 + drivers/hwmon/nsa320-hwmon.c | 215 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 284 insertions(+) create mode 100644 Documentation/hwmon/nsa320 create mode 100644 drivers/hwmon/nsa320-hwmon.c
Documentation/hwmon/nsa320 new file +53 -0
@@ -0,0 +1,53 @@ +Kernel driver nsa320_hwmon +========================== + +Supported chips: + * Holtek HT46R065 microcontroller with onboard firmware that configures + it to act as a hardware monitor. + Prefix: 'nsa320' + Addresses scanned: none + Datasheet: Not available, driver was reverse engineered based upon the + Zyxel kernel source + +Author: + Adam Baker <[email protected]> + +Description +----------- + +This chip is known to be used in the Zyxel NSA320 and NSA325 NAS Units and +also in some variants of the NSA310 but the driver has only been tested +on the NSA320. In all of these devices it is connected to the same 3 GPIO +lines which are used to provide chip select, clock and data lines. The +interface behaves similarly to SPI but at much lower speeds than are normally +used for SPI. + +Following each chip select pulse the chip will generate a single 32 bit word +that contains 0x55 as a marker to indicate that data is being read correctly, +followed by an 8 bit fan speed in 100s of RPM and a 16 bit temperature in +tenths of a degree. + + +sysfs-Interface +--------------- + +temp1_input - temperature input +fan1_input - fan speed + +Notes +----- + +The access timings used in the driver are the same as used in the Zyxel +provided kernel. Testing has shown that if the delay between chip select and +the first clock pulse is reduced from 100 ms to just under 10ms then the chip +will not produce any output. If the duration of either phase of the clock +is reduced from 100 us to less than 15 us then data pulses are likely to be +read twice corrupting the output. The above analysis is based upon a sample +of one unit but suggests that the Zyxel provided delay values include a +reasonable tolerance. + +The driver incorporates a limit that it will not check for updated values +faster than once a second. This is because the hardware takes a relatively long +time to read the data from the device and when it does it reads both temp and +fan speed. As the most likely case for two accesses in quick succession is +to read both of these values avoiding a second read delay is desirable.
drivers/hwmon/Kconfig +15 -0
@@ -1186,6 +1186,21 @@ config SENSORS_NCT7904 This driver can also be built as a module. If so, the module will be called nct7904. +config SENSORS_NSA320 + tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors" + depends on GPIOLIB && OF + depends on MACH_KIRKWOOD || COMPILE_TEST + help + If you say yes here you get support for hardware monitoring + for the ZyXEL NSA320 Media Server and other compatible devices + (probably the NSA325 and some NSA310 variants). + + The sensor data is taken from a Holtek HT46R065 microcontroller + connected to GPIO lines. + + This driver can also be built as a module. If so, the module + will be called nsa320-hwmon. + config SENSORS_PCF8591 tristate "Philips PCF8591 ADC/DAC" depends on I2C
drivers/hwmon/Makefile +1 -0
@@ -124,6 +124,7 @@ obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o obj-$(CONFIG_SENSORS_NCT7802) += nct7802.o obj-$(CONFIG_SENSORS_NCT7904) += nct7904.o +obj-$(CONFIG_SENSORS_NSA320) += nsa320-hwmon.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
drivers/hwmon/nsa320-hwmon.c new file +215 -0
215 lines not on this page · raw message
Signature · 1 line
2.1.4
Guenter Roeck
maintainerPATCH v3 2/3 hwmon: Create an NSA320 hardware monitoring driver
Quoted 190 lines · Adam Baker
Create a driver to support the hardware monitoring chip present in the Zyxel NSA320 and some of the other Zyxel NAS devices.
The driver reads fan speed and temperature from a suitably pre-programmed MCU on the device.
Signed-off-by Adam Baker <[email protected]>---
Changes since v2
Updated based on Guenter Roeck's review,
- return a single value that is result or error from the update function
- use separateshow_valueroutimes for fan and temp
- AddedDocumentation/hwmon/nsa320-hwmon--- Documentation/hwmon/nsa320 | 53 +++++++++++ drivers/hwmon/Kconfig | 15 +++ drivers/hwmon/Makefile | 1 + drivers/hwmon/nsa320-hwmon.c | 215 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 284 insertions(+)create mode 100644
Documentation/hwmon/nsa320
create mode 100644drivers/hwmon/nsa320-hwmon.cDocumentation/hwmon/nsa320 new file +53
-0@@ -0,0 +1,53 @@ +Kernel driver nsa320_hwmon +========================== + +Supported chips: + * Holtek HT46R065 microcontroller with onboard firmware that configures + it to act as a hardware monitor. + Prefix: 'nsa320' + Addresses scanned: none + Datasheet: Not available, driver was reverse engineered based upon the + Zyxel kernel source + +Author: + Adam Baker <[email protected]> + +Description +----------- + +This chip is known to be used in the Zyxel NSA320 and NSA325 NAS Units and +also in some variants of the NSA310 but the driver has only been tested +on the NSA320. In all of these devices it is connected to the same 3 GPIO +lines which are used to provide chip select, clock and data lines. The +interface behaves similarly to SPI but at much lower speeds than are normally +used for SPI. + +Following each chip select pulse the chip will generate a single 32 bit word +that contains 0x55 as a marker to indicate that data is being read correctly, +followed by an 8 bit fan speed in 100s of RPM and a 16 bit temperature in +tenths of a degree. + + +sysfs-Interface +--------------- + +temp1_input - temperature input +fan1_input - fan speed + +Notes +----- + +The access timings used in the driver are the same as used in the Zyxel +provided kernel. Testing has shown that if the delay between chip select and +the first clock pulse is reduced from 100 ms to just under 10ms then the chip +will not produce any output. If the duration of either phase of the clock +is reduced from 100 us to less than 15 us then data pulses are likely to be +read twice corrupting the output. The above analysis is based upon a sample +of one unit but suggests that the Zyxel provided delay values include a +reasonable tolerance. + +The driver incorporates a limit that it will not check for updated values +faster than once a second. This is because the hardware takes a relatively long +time to read the data from the device and when it does it reads both temp and +fan speed. As the most likely case for two accesses in quick succession is +to read both of these values avoiding a second read delay is desirable.drivers/hwmon/Kconfig +15
-0@@ -1186,6 +1186,21 @@ config SENSORS_NCT7904 This driver can also be built as a module. If so, the module will be called nct7904. +config SENSORS_NSA320 + tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors" + depends on GPIOLIB && OF + depends on MACH_KIRKWOOD || COMPILE_TEST + help + If you say yes here you get support for hardware monitoring + for the ZyXEL NSA320 Media Server and other compatible devices + (probably the NSA325 and some NSA310 variants). + + The sensor data is taken from a Holtek HT46R065 microcontroller + connected to GPIO lines. + + This driver can also be built as a module. If so, the module + will be called nsa320-hwmon. + config SENSORS_PCF8591 tristate "Philips PCF8591 ADC/DAC" depends on I2Cdrivers/hwmon/Makefile +1
-0@@ -124,6 +124,7 @@ obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o obj-$(CONFIG_SENSORS_NCT7802) += nct7802.o obj-$(CONFIG_SENSORS_NCT7904) += nct7904.o +obj-$(CONFIG_SENSORS_NSA320) += nsa320-hwmon.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PC87427) += pc87427.odrivers/hwmon/nsa320-hwmon.c new file +65
-0@@ -0,0 +1,215 @@ +/* +* drivers/hwmon/nsa320-hwmon.c +* +* ZyXEL NSA320 Media Servers +* hardware monitoring +* +* Copyright (C) 2016 Adam Baker <[email protected]> +* based on a board file driver +* Copyright (C) 2012 Peter Schildmann <[email protected]> +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License v2 as published by the +* Free Software Foundation. +* +* This program is distributed in the hope that it will be useful, but WITHOUT +* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +* more details. +*/ + +#include <linux/bitops.h> +#include <linux/delay.h> +#include <linux/err.h> +#include <linux/gpio/consumer.h> +#include <linux/hwmon.h> +#include <linux/hwmon-sysfs.h> +#include <linux/jiffies.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of.h> +#include <linux/of_device.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> + +#define MAGIC_NUMBER 0x55 + +/* +* The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed +* to perform temperature and fan speed monitoring. It is read by taking +* the active pin low. The 32 bit output word is then clocked onto the +* data line. The MSB of the data word is a magic nuber to indicate it +* has been read correctly, the next byte is the fan speed (in hundreds +* of RPM) and the last two bytes are the temperature (in tenths of a +* degree) +*/ + +struct nsa320_hwmon { +struct mutex update_lock;/* lock GPIO operations */ +unsigned long last_updated;/* jiffies */ +unsigned long mcu_data; +struct gpio_desc *act; +struct gpio_desc *clk; +struct gpio_desc *data; +}; + +enum nsa320_inputs { +NSA3XX_TEMP =0 , +NSA3XX_FAN =1 , +}; + +static const char *const nsa320_input_names[] = { + [NSA3XX_TEMP ] ="System Temperature" , + [NSA3XX_FAN ] ="Chassis Fan" , +}; +
drivers/hwmon/nsa320-hwmon.c line 75
Quoted 10 lines
drivers/hwmon/nsa320-hwmon.c new file +10
-0+/* +* Although this protocol looks similar to SPI the long delay +* between the active (aka chip select) signal and the shorter +* delay between clock pulses are needed for reliable operation. +* The delays provided are taken from the manufacturer kernel, +* testing suggest they probably incorporate a reasonable safety +* margin. (The single device tested became unreliable if the +* delay was reduced to 1/10th of this value.) +*/ +static unsigned long nsa320_hwmon_update (struct device *dev)
Please make this either int or s32.
drivers/hwmon/nsa320-hwmon.c line 77
Quoted 2 lines
drivers/hwmon/nsa320-hwmon.c new file +2
-0+{ +u32 mcu_data;
You can (and should) still use u32 here.
Thanks,
Guenter
PATCH v3 2/3 hwmon: Create an NSA320 hardware monitoring driver
Quoted 14 lines · Guenter Roeck
drivers/hwmon/nsa320-hwmon.c line 75
Quoted 11 lines
drivers/hwmon/nsa320-hwmon.c new file +11
-0+ +/* +* Although this protocol looks similar to SPI the long delay +* between the active (aka chip select) signal and the shorter +* delay between clock pulses are needed for reliable operation. +* The delays provided are taken from the manufacturer kernel, +* testing suggest they probably incorporate a reasonable safety +* margin. (The single device tested became unreliable if the +* delay was reduced to 1/10th of this value.) +*/ +static unsigned long nsa320_hwmon_update (struct device *dev)Please make this either int or s32.
Quoted 5 lines
drivers/hwmon/nsa320-hwmon.c line 77
Quoted 2 lines
drivers/hwmon/nsa320-hwmon.c new file +2
-0+{ +u32 mcu_data;You can (and should) still use u32 here.
I'm a bit puzzled by your reasoning for preferring a signed value for the return value. The only reason I can think of is that the error return value is negative, however the macro to test if it is an error value is not looking at whether the value is negative
#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
Functionally using any of s32, int or unsigned long will make no difference, the mask operations ensure that the top bit can't possibly be set so using a signed type doesn't, in this circumstance, risk an undefined result from the shift operation. The choice of type is therefore a matter of readability rather than function so if you still prefer s32 I'll respin it to use that.
The length does need to be at least 32 bits (to represent the returned data range) and no longer than unsigned long (to avoid breaking IS_ERR_VALUE). Whilst int is 32 bits on the only processor that is expected to use this device that doesn't feel like a good thing to depend upon so s32 seems preferable to int.
Regards
Adam
Guenter Roeck
maintainerPATCH v3 2/3 hwmon: Create an NSA320 hardware monitoring driver
Quoted 23 lines · Adam Baker
Quoted 14 lines · Guenter Roeck
drivers/hwmon/nsa320-hwmon.c line 75
Quoted 11 lines
drivers/hwmon/nsa320-hwmon.c new file +11
-0+ +/* +* Although this protocol looks similar to SPI the long delay +* between the active (aka chip select) signal and the shorter +* delay between clock pulses are needed for reliable operation. +* The delays provided are taken from the manufacturer kernel, +* testing suggest they probably incorporate a reasonable safety +* margin. (The single device tested became unreliable if the +* delay was reduced to 1/10th of this value.) +*/ +static unsigned long nsa320_hwmon_update (struct device *dev)Please make this either int or s32.
Quoted 5 lines
drivers/hwmon/nsa320-hwmon.c line 77
Quoted 2 lines
drivers/hwmon/nsa320-hwmon.c new file +2
-0+{ +u32 mcu_data;You can (and should) still use u32 here.
Quoted 6 lines
I'm a bit puzzled by your reasoning for preferring a signed value for the return value. The only reason I can think of is that the error return value is negative, however the macro to test if it is an error value is not looking at whether the value is negative
#define
IS_ERR_VALUE(x)unlikely((x) >= (unsigned long)-MAX_ERRNO)Functionally using any of s32, int or unsigned long will make no difference, the mask operations ensure that the top bit can't possibly be set so using a signed type doesn't, in this circumstance, risk an undefined result from the shift operation. The choice of type is therefore a matter of readability rather than function so if you still prefer s32 I'll respin it to use that.
IS_ERR_VALUE _only_ works with unsigned long if sizeof(long) = sizeof(int). Someone may at some point in the future not realize this and change the function return value to unsigned int or u32, thinking that an unsigned long is unnecessary, and introduce a bug. Many users of IS_ERR_VALUE in the kernel actually suffer from this problem. I prefer code which is less prone to such unintentionally introduced problems.
I also dislike using unsigned variables to return negative error codes unless there is a really good reason for doing it. Such a reason does not exist here.
Guenter
PATCH v3 3/3 ARM: mvebu: Add the hardware monitor to the NSA320 device tree
In reply to Adam BakerAdd an entry for the hardware monitoring MCU
---
This patch is unchanged from the version Gregory CLEMENT said he would apply once the hwmon maintainers accept 2/2
--- arch/arm/boot/dts/kirkwood-nsa320.dts | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
arch/arm/boot/dts/kirkwood-nsa320.dts +11 -2
@@ -193,10 +193,19 @@ }; }; + hwmon { + compatible = "zyxel,nsa320-mcu"; + pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>; + pinctrl-names = "default"; + + data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; + clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>; + }; + /* The following pins are currently not assigned to a driver, some of them should be configured as inputs. - pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act - &pmx_htp &pmx_vid_b1 + pinctrl-0 = <&pmx_htp &pmx_vid_b1 &pmx_power_resume_data &pmx_power_resume_clk>; */ };
Signature · 1 line
2.1.4