* [PATCH] nvme: Add hardware monitoring support
@ 2019-10-28 2:41 ` Guenter Roeck
0 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2019-10-28 2:41 UTC (permalink / raw)
To: Keith Busch
Cc: Chris Healy, Jens Axboe, Christoph Hellwig, Sagi Grimberg,
linux-kernel, linux-nvme, Guenter Roeck
nvme devices report temperature information in the controller information
(for limits) and in the smart log. Currently, the only means to retrieve
this information is the nvme command line interface, which requires
super-user privileges.
At the same time, it would be desirable to use NVME temperature information
for thermal control.
This patch adds support to read NVME temperatures from the kernel using the
hwmon API and adds temperature zones for NVME drives. The thermal subsystem
can use this information to set thermal policies, and userspace can access
it using libsensors and/or the "sensors" command.
Example output from the "sensors" command:
nvme0-pci-0100
Adapter: PCI adapter
Composite: +39.0°C (high = +85.0°C, crit = +85.0°C)
Sensor 1: +39.0°C
Sensor 2: +41.0°C
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/nvme/host/Kconfig | 10 +++
drivers/nvme/host/Makefile | 1 +
drivers/nvme/host/core.c | 5 ++
drivers/nvme/host/nvme-hwmon.c | 160 +++++++++++++++++++++++++++++++++
drivers/nvme/host/nvme.h | 8 ++
5 files changed, 184 insertions(+)
create mode 100644 drivers/nvme/host/nvme-hwmon.c
diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
index 2b36f052bfb9..aeb49e16e386 100644
--- a/drivers/nvme/host/Kconfig
+++ b/drivers/nvme/host/Kconfig
@@ -23,6 +23,16 @@ config NVME_MULTIPATH
/dev/nvmeXnY device will show up for each NVMe namespaces,
even if it is accessible through multiple controllers.
+config NVME_HWMON
+ bool "NVME hardware monitoring"
+ depends on (NVME_CORE=y && HWMON=y) || (NVME_CORE=m && HWMON)
+ help
+ This provides support for NVME hardware monitoring. If enabled,
+ a hardware monitoring device will be created for each NVME drive
+ in the system.
+
+ If unsure, say N.
+
config NVME_FABRICS
tristate
diff --git a/drivers/nvme/host/Makefile b/drivers/nvme/host/Makefile
index 8a4b671c5f0c..03de4797a877 100644
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@ -14,6 +14,7 @@ nvme-core-$(CONFIG_TRACING) += trace.o
nvme-core-$(CONFIG_NVME_MULTIPATH) += multipath.o
nvme-core-$(CONFIG_NVM) += lightnvm.o
nvme-core-$(CONFIG_FAULT_INJECTION_DEBUG_FS) += fault_inject.o
+nvme-core-$(CONFIG_NVME_HWMON) += nvme-hwmon.o
nvme-y += pci.o
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index fa7ba09dca77..fc1d4b146717 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2796,6 +2796,9 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
ctrl->oncs = le16_to_cpu(id->oncs);
ctrl->mtfa = le16_to_cpu(id->mtfa);
ctrl->oaes = le32_to_cpu(id->oaes);
+ ctrl->wctemp = le16_to_cpu(id->wctemp);
+ ctrl->cctemp = le16_to_cpu(id->cctemp);
+
atomic_set(&ctrl->abort_limit, id->acl + 1);
ctrl->vwc = id->vwc;
if (id->mdts)
@@ -2897,6 +2900,8 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
ctrl->identified = true;
+ nvme_hwmon_init(ctrl);
+
return 0;
out_free:
diff --git a/drivers/nvme/host/nvme-hwmon.c b/drivers/nvme/host/nvme-hwmon.c
new file mode 100644
index 000000000000..f19098bc3228
--- /dev/null
+++ b/drivers/nvme/host/nvme-hwmon.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NVM Express hardware monitoring support
+ * Copyright (c) 2019, Guenter Roeck
+ */
+
+#include <linux/hwmon.h>
+
+#include "nvme.h"
+
+struct nvme_hwmon_data {
+ struct nvme_ctrl *ctrl;
+ struct nvme_smart_log log;
+};
+
+static int nvme_hwmon_get_smart_log(struct nvme_hwmon_data *data)
+{
+ return nvme_get_log(data->ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0,
+ &data->log, sizeof(data->log), 0);
+}
+
+static int nvme_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct nvme_hwmon_data *data = dev_get_drvdata(dev);
+ struct nvme_smart_log *log = &data->log;
+ int err;
+ int temp;
+
+ err = nvme_hwmon_get_smart_log(data);
+ if (err)
+ return err < 0 ? err : -EPROTO;
+
+ switch (attr) {
+ case hwmon_temp_max:
+ *val = (data->ctrl->wctemp - 273) * 1000;
+ break;
+ case hwmon_temp_crit:
+ *val = (data->ctrl->cctemp - 273) * 1000;
+ break;
+ case hwmon_temp_input:
+ if (!channel)
+ temp = le16_to_cpup((__le16 *)log->temperature);
+ else
+ temp = le16_to_cpu(log->temp_sensor[channel - 1]);
+ *val = (temp - 273) * 1000;
+ break;
+ case hwmon_temp_crit_alarm:
+ *val = !!(log->critical_warning & NVME_SMART_CRIT_TEMPERATURE);
+ break;
+ default:
+ err = -EOPNOTSUPP;
+ break;
+ }
+ return err;
+}
+
+static const char * const nvme_hwmon_sensor_names[] = {
+ "Composite",
+ "Sensor 1",
+ "Sensor 2",
+ "Sensor 3",
+ "Sensor 4",
+ "Sensor 5",
+ "Sensor 6",
+ "Sensor 7",
+ "Sensor 8",
+};
+
+static int nvme_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, const char **str)
+{
+ *str = nvme_hwmon_sensor_names[channel];
+ return 0;
+}
+
+static umode_t nvme_hwmon_is_visible(const void *_data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct nvme_hwmon_data *data = _data;
+
+ switch (attr) {
+ case hwmon_temp_crit:
+ if (!channel && data->ctrl->cctemp)
+ return 0444;
+ break;
+ case hwmon_temp_max:
+ if (!channel && data->ctrl->wctemp)
+ return 0444;
+ break;
+ case hwmon_temp_crit_alarm:
+ if (!channel)
+ return 0444;
+ break;
+ case hwmon_temp_input:
+ case hwmon_temp_label:
+ if (!channel || data->log.temp_sensor[channel - 1])
+ return 0444;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+static const struct hwmon_channel_info *nvme_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
+ HWMON_CHANNEL_INFO(temp,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
+ HWMON_T_LABEL | HWMON_T_CRIT_ALARM,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL),
+ NULL
+};
+
+static const struct hwmon_ops nvme_hwmon_ops = {
+ .is_visible = nvme_hwmon_is_visible,
+ .read = nvme_hwmon_read,
+ .read_string = nvme_hwmon_read_string,
+};
+
+static const struct hwmon_chip_info nvme_hwmon_chip_info = {
+ .ops = &nvme_hwmon_ops,
+ .info = nvme_hwmon_info,
+};
+
+void nvme_hwmon_init(struct nvme_ctrl *ctrl)
+{
+ struct device *dev = ctrl->device;
+ struct nvme_hwmon_data *data;
+ struct device *hwmon;
+ int err;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return;
+
+ data->ctrl = ctrl;
+
+ err = nvme_hwmon_get_smart_log(data);
+ if (err) {
+ dev_warn(dev, "Failed to read smart log (error %d)\n", err);
+ return;
+ }
+
+ hwmon = devm_hwmon_device_register_with_info(dev, dev_name(dev),
+ data,
+ &nvme_hwmon_chip_info,
+ NULL);
+ if (IS_ERR(hwmon))
+ dev_warn(dev, "Failed to instantiate hwmon device\n");
+}
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 22e8401352c2..e6460c1216bc 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -231,6 +231,8 @@ struct nvme_ctrl {
u16 kas;
u8 npss;
u8 apsta;
+ u16 wctemp;
+ u16 cctemp;
u32 oaes;
u32 aen_result;
u32 ctratt;
@@ -652,4 +654,10 @@ static inline struct nvme_ns *nvme_get_ns_from_dev(struct device *dev)
return dev_to_disk(dev)->private_data;
}
+#if IS_ENABLED(CONFIG_NVME_HWMON)
+void nvme_hwmon_init(struct nvme_ctrl *ctrl);
+#else
+static inline void nvme_hwmon_init(struct nvme_ctrl *ctrl) { }
+#endif
+
#endif /* _NVME_H */
--
2.17.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] nvme: Add hardware monitoring support
@ 2019-10-28 2:41 ` Guenter Roeck
0 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2019-10-28 2:41 UTC (permalink / raw)
To: Keith Busch
Cc: Sagi Grimberg, linux-kernel, linux-nvme, Jens Axboe, Chris Healy,
Christoph Hellwig, Guenter Roeck
nvme devices report temperature information in the controller information
(for limits) and in the smart log. Currently, the only means to retrieve
this information is the nvme command line interface, which requires
super-user privileges.
At the same time, it would be desirable to use NVME temperature information
for thermal control.
This patch adds support to read NVME temperatures from the kernel using the
hwmon API and adds temperature zones for NVME drives. The thermal subsystem
can use this information to set thermal policies, and userspace can access
it using libsensors and/or the "sensors" command.
Example output from the "sensors" command:
nvme0-pci-0100
Adapter: PCI adapter
Composite: +39.0°C (high = +85.0°C, crit = +85.0°C)
Sensor 1: +39.0°C
Sensor 2: +41.0°C
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/nvme/host/Kconfig | 10 +++
drivers/nvme/host/Makefile | 1 +
drivers/nvme/host/core.c | 5 ++
drivers/nvme/host/nvme-hwmon.c | 160 +++++++++++++++++++++++++++++++++
drivers/nvme/host/nvme.h | 8 ++
5 files changed, 184 insertions(+)
create mode 100644 drivers/nvme/host/nvme-hwmon.c
diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
index 2b36f052bfb9..aeb49e16e386 100644
--- a/drivers/nvme/host/Kconfig
+++ b/drivers/nvme/host/Kconfig
@@ -23,6 +23,16 @@ config NVME_MULTIPATH
/dev/nvmeXnY device will show up for each NVMe namespaces,
even if it is accessible through multiple controllers.
+config NVME_HWMON
+ bool "NVME hardware monitoring"
+ depends on (NVME_CORE=y && HWMON=y) || (NVME_CORE=m && HWMON)
+ help
+ This provides support for NVME hardware monitoring. If enabled,
+ a hardware monitoring device will be created for each NVME drive
+ in the system.
+
+ If unsure, say N.
+
config NVME_FABRICS
tristate
diff --git a/drivers/nvme/host/Makefile b/drivers/nvme/host/Makefile
index 8a4b671c5f0c..03de4797a877 100644
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@ -14,6 +14,7 @@ nvme-core-$(CONFIG_TRACING) += trace.o
nvme-core-$(CONFIG_NVME_MULTIPATH) += multipath.o
nvme-core-$(CONFIG_NVM) += lightnvm.o
nvme-core-$(CONFIG_FAULT_INJECTION_DEBUG_FS) += fault_inject.o
+nvme-core-$(CONFIG_NVME_HWMON) += nvme-hwmon.o
nvme-y += pci.o
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index fa7ba09dca77..fc1d4b146717 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2796,6 +2796,9 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
ctrl->oncs = le16_to_cpu(id->oncs);
ctrl->mtfa = le16_to_cpu(id->mtfa);
ctrl->oaes = le32_to_cpu(id->oaes);
+ ctrl->wctemp = le16_to_cpu(id->wctemp);
+ ctrl->cctemp = le16_to_cpu(id->cctemp);
+
atomic_set(&ctrl->abort_limit, id->acl + 1);
ctrl->vwc = id->vwc;
if (id->mdts)
@@ -2897,6 +2900,8 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
ctrl->identified = true;
+ nvme_hwmon_init(ctrl);
+
return 0;
out_free:
diff --git a/drivers/nvme/host/nvme-hwmon.c b/drivers/nvme/host/nvme-hwmon.c
new file mode 100644
index 000000000000..f19098bc3228
--- /dev/null
+++ b/drivers/nvme/host/nvme-hwmon.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NVM Express hardware monitoring support
+ * Copyright (c) 2019, Guenter Roeck
+ */
+
+#include <linux/hwmon.h>
+
+#include "nvme.h"
+
+struct nvme_hwmon_data {
+ struct nvme_ctrl *ctrl;
+ struct nvme_smart_log log;
+};
+
+static int nvme_hwmon_get_smart_log(struct nvme_hwmon_data *data)
+{
+ return nvme_get_log(data->ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0,
+ &data->log, sizeof(data->log), 0);
+}
+
+static int nvme_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct nvme_hwmon_data *data = dev_get_drvdata(dev);
+ struct nvme_smart_log *log = &data->log;
+ int err;
+ int temp;
+
+ err = nvme_hwmon_get_smart_log(data);
+ if (err)
+ return err < 0 ? err : -EPROTO;
+
+ switch (attr) {
+ case hwmon_temp_max:
+ *val = (data->ctrl->wctemp - 273) * 1000;
+ break;
+ case hwmon_temp_crit:
+ *val = (data->ctrl->cctemp - 273) * 1000;
+ break;
+ case hwmon_temp_input:
+ if (!channel)
+ temp = le16_to_cpup((__le16 *)log->temperature);
+ else
+ temp = le16_to_cpu(log->temp_sensor[channel - 1]);
+ *val = (temp - 273) * 1000;
+ break;
+ case hwmon_temp_crit_alarm:
+ *val = !!(log->critical_warning & NVME_SMART_CRIT_TEMPERATURE);
+ break;
+ default:
+ err = -EOPNOTSUPP;
+ break;
+ }
+ return err;
+}
+
+static const char * const nvme_hwmon_sensor_names[] = {
+ "Composite",
+ "Sensor 1",
+ "Sensor 2",
+ "Sensor 3",
+ "Sensor 4",
+ "Sensor 5",
+ "Sensor 6",
+ "Sensor 7",
+ "Sensor 8",
+};
+
+static int nvme_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, const char **str)
+{
+ *str = nvme_hwmon_sensor_names[channel];
+ return 0;
+}
+
+static umode_t nvme_hwmon_is_visible(const void *_data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct nvme_hwmon_data *data = _data;
+
+ switch (attr) {
+ case hwmon_temp_crit:
+ if (!channel && data->ctrl->cctemp)
+ return 0444;
+ break;
+ case hwmon_temp_max:
+ if (!channel && data->ctrl->wctemp)
+ return 0444;
+ break;
+ case hwmon_temp_crit_alarm:
+ if (!channel)
+ return 0444;
+ break;
+ case hwmon_temp_input:
+ case hwmon_temp_label:
+ if (!channel || data->log.temp_sensor[channel - 1])
+ return 0444;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+static const struct hwmon_channel_info *nvme_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
+ HWMON_CHANNEL_INFO(temp,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
+ HWMON_T_LABEL | HWMON_T_CRIT_ALARM,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL),
+ NULL
+};
+
+static const struct hwmon_ops nvme_hwmon_ops = {
+ .is_visible = nvme_hwmon_is_visible,
+ .read = nvme_hwmon_read,
+ .read_string = nvme_hwmon_read_string,
+};
+
+static const struct hwmon_chip_info nvme_hwmon_chip_info = {
+ .ops = &nvme_hwmon_ops,
+ .info = nvme_hwmon_info,
+};
+
+void nvme_hwmon_init(struct nvme_ctrl *ctrl)
+{
+ struct device *dev = ctrl->device;
+ struct nvme_hwmon_data *data;
+ struct device *hwmon;
+ int err;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return;
+
+ data->ctrl = ctrl;
+
+ err = nvme_hwmon_get_smart_log(data);
+ if (err) {
+ dev_warn(dev, "Failed to read smart log (error %d)\n", err);
+ return;
+ }
+
+ hwmon = devm_hwmon_device_register_with_info(dev, dev_name(dev),
+ data,
+ &nvme_hwmon_chip_info,
+ NULL);
+ if (IS_ERR(hwmon))
+ dev_warn(dev, "Failed to instantiate hwmon device\n");
+}
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 22e8401352c2..e6460c1216bc 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -231,6 +231,8 @@ struct nvme_ctrl {
u16 kas;
u8 npss;
u8 apsta;
+ u16 wctemp;
+ u16 cctemp;
u32 oaes;
u32 aen_result;
u32 ctratt;
@@ -652,4 +654,10 @@ static inline struct nvme_ns *nvme_get_ns_from_dev(struct device *dev)
return dev_to_disk(dev)->private_data;
}
+#if IS_ENABLED(CONFIG_NVME_HWMON)
+void nvme_hwmon_init(struct nvme_ctrl *ctrl);
+#else
+static inline void nvme_hwmon_init(struct nvme_ctrl *ctrl) { }
+#endif
+
#endif /* _NVME_H */
--
2.17.1
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
2019-10-28 2:41 ` Guenter Roeck
@ 2019-10-28 7:39 ` Christoph Hellwig
-1 siblings, 0 replies; 10+ messages in thread
From: Christoph Hellwig @ 2019-10-28 7:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: Keith Busch, Chris Healy, Jens Axboe, Christoph Hellwig,
Sagi Grimberg, linux-kernel, linux-nvme, Akinobu Mita, linux-pm
On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote:
> nvme devices report temperature information in the controller information
> (for limits) and in the smart log. Currently, the only means to retrieve
> this information is the nvme command line interface, which requires
> super-user privileges.
>
> At the same time, it would be desirable to use NVME temperature information
> for thermal control.
>
> This patch adds support to read NVME temperatures from the kernel using the
> hwmon API and adds temperature zones for NVME drives. The thermal subsystem
> can use this information to set thermal policies, and userspace can access
> it using libsensors and/or the "sensors" command.
So these reported values seem to generate some interest. Adding Akinobu
Mita who also planned to wire them up to the thermal framework. I don't
really know either upper layer so I'm not sure which is the right one,
but with this just like with the previous series I am quite worried that
we add a lot of kernel boilerplate code for information people can
trivially get using nvme-cli.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
@ 2019-10-28 7:39 ` Christoph Hellwig
0 siblings, 0 replies; 10+ messages in thread
From: Christoph Hellwig @ 2019-10-28 7:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: Sagi Grimberg, linux-pm, linux-kernel, linux-nvme, Akinobu Mita,
Jens Axboe, Chris Healy, Keith Busch, Christoph Hellwig
On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote:
> nvme devices report temperature information in the controller information
> (for limits) and in the smart log. Currently, the only means to retrieve
> this information is the nvme command line interface, which requires
> super-user privileges.
>
> At the same time, it would be desirable to use NVME temperature information
> for thermal control.
>
> This patch adds support to read NVME temperatures from the kernel using the
> hwmon API and adds temperature zones for NVME drives. The thermal subsystem
> can use this information to set thermal policies, and userspace can access
> it using libsensors and/or the "sensors" command.
So these reported values seem to generate some interest. Adding Akinobu
Mita who also planned to wire them up to the thermal framework. I don't
really know either upper layer so I'm not sure which is the right one,
but with this just like with the previous series I am quite worried that
we add a lot of kernel boilerplate code for information people can
trivially get using nvme-cli.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
2019-10-28 7:39 ` Christoph Hellwig
@ 2019-10-28 8:08 ` Keith Busch
-1 siblings, 0 replies; 10+ messages in thread
From: Keith Busch @ 2019-10-28 8:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Guenter Roeck, Chris Healy, Jens Axboe, Sagi Grimberg,
linux-kernel, linux-nvme, Akinobu Mita, linux-pm
On Mon, Oct 28, 2019 at 08:39:53AM +0100, Christoph Hellwig wrote:
> On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote:
> > nvme devices report temperature information in the controller information
> > (for limits) and in the smart log. Currently, the only means to retrieve
> > this information is the nvme command line interface, which requires
> > super-user privileges.
> >
> > At the same time, it would be desirable to use NVME temperature information
> > for thermal control.
> >
> > This patch adds support to read NVME temperatures from the kernel using the
> > hwmon API and adds temperature zones for NVME drives. The thermal subsystem
> > can use this information to set thermal policies, and userspace can access
> > it using libsensors and/or the "sensors" command.
>
> So these reported values seem to generate some interest. Adding Akinobu
> Mita who also planned to wire them up to the thermal framework. I don't
> really know either upper layer so I'm not sure which is the right one,
> but with this just like with the previous series I am quite worried that
> we add a lot of kernel boilerplate code for information people can
> trivially get using nvme-cli.
I think it's nvme-cli requires root, where this conveniently doesn't
need those elevated rights.
I'm not familiar with either upper level framework either; my only review
comment for this patch is to use devm_kfree() for the error cases.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
@ 2019-10-28 8:08 ` Keith Busch
0 siblings, 0 replies; 10+ messages in thread
From: Keith Busch @ 2019-10-28 8:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sagi Grimberg, linux-pm, linux-kernel, linux-nvme, Akinobu Mita,
Jens Axboe, Chris Healy, Guenter Roeck
On Mon, Oct 28, 2019 at 08:39:53AM +0100, Christoph Hellwig wrote:
> On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote:
> > nvme devices report temperature information in the controller information
> > (for limits) and in the smart log. Currently, the only means to retrieve
> > this information is the nvme command line interface, which requires
> > super-user privileges.
> >
> > At the same time, it would be desirable to use NVME temperature information
> > for thermal control.
> >
> > This patch adds support to read NVME temperatures from the kernel using the
> > hwmon API and adds temperature zones for NVME drives. The thermal subsystem
> > can use this information to set thermal policies, and userspace can access
> > it using libsensors and/or the "sensors" command.
>
> So these reported values seem to generate some interest. Adding Akinobu
> Mita who also planned to wire them up to the thermal framework. I don't
> really know either upper layer so I'm not sure which is the right one,
> but with this just like with the previous series I am quite worried that
> we add a lot of kernel boilerplate code for information people can
> trivially get using nvme-cli.
I think it's nvme-cli requires root, where this conveniently doesn't
need those elevated rights.
I'm not familiar with either upper level framework either; my only review
comment for this patch is to use devm_kfree() for the error cases.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
2019-10-28 8:08 ` Keith Busch
@ 2019-10-28 13:27 ` Guenter Roeck
-1 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2019-10-28 13:27 UTC (permalink / raw)
To: Keith Busch, Christoph Hellwig
Cc: Chris Healy, Jens Axboe, Sagi Grimberg, linux-kernel, linux-nvme,
Akinobu Mita, linux-pm
On 10/28/19 1:08 AM, Keith Busch wrote:
> On Mon, Oct 28, 2019 at 08:39:53AM +0100, Christoph Hellwig wrote:
>> On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote:
>>> nvme devices report temperature information in the controller information
>>> (for limits) and in the smart log. Currently, the only means to retrieve
>>> this information is the nvme command line interface, which requires
>>> super-user privileges.
>>>
>>> At the same time, it would be desirable to use NVME temperature information
>>> for thermal control.
>>>
>>> This patch adds support to read NVME temperatures from the kernel using the
>>> hwmon API and adds temperature zones for NVME drives. The thermal subsystem
>>> can use this information to set thermal policies, and userspace can access
>>> it using libsensors and/or the "sensors" command.
>>
>> So these reported values seem to generate some interest. Adding Akinobu
>> Mita who also planned to wire them up to the thermal framework. I don't
>> really know either upper layer so I'm not sure which is the right one,
>> but with this just like with the previous series I am quite worried that
>> we add a lot of kernel boilerplate code for information people can
>> trivially get using nvme-cli.
> > I think it's nvme-cli requires root, where this conveniently doesn't
> need those elevated rights.
>
The other point here is the thermal framework. One can not wire that up
through userspace, and even if it was possible to do it, that would defeat
the idea of having the thermal subsystem in the kernel running on its own,
without requiring userspace attention.
> I'm not familiar with either upper level framework either; my only review
> comment for this patch is to use devm_kfree() for the error cases.
>
Makes sense. I'll address that in v2.
Guenter
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
@ 2019-10-28 13:27 ` Guenter Roeck
0 siblings, 0 replies; 10+ messages in thread
From: Guenter Roeck @ 2019-10-28 13:27 UTC (permalink / raw)
To: Keith Busch, Christoph Hellwig
Cc: Sagi Grimberg, linux-pm, linux-kernel, linux-nvme, Akinobu Mita,
Jens Axboe, Chris Healy
On 10/28/19 1:08 AM, Keith Busch wrote:
> On Mon, Oct 28, 2019 at 08:39:53AM +0100, Christoph Hellwig wrote:
>> On Sun, Oct 27, 2019 at 07:41:56PM -0700, Guenter Roeck wrote:
>>> nvme devices report temperature information in the controller information
>>> (for limits) and in the smart log. Currently, the only means to retrieve
>>> this information is the nvme command line interface, which requires
>>> super-user privileges.
>>>
>>> At the same time, it would be desirable to use NVME temperature information
>>> for thermal control.
>>>
>>> This patch adds support to read NVME temperatures from the kernel using the
>>> hwmon API and adds temperature zones for NVME drives. The thermal subsystem
>>> can use this information to set thermal policies, and userspace can access
>>> it using libsensors and/or the "sensors" command.
>>
>> So these reported values seem to generate some interest. Adding Akinobu
>> Mita who also planned to wire them up to the thermal framework. I don't
>> really know either upper layer so I'm not sure which is the right one,
>> but with this just like with the previous series I am quite worried that
>> we add a lot of kernel boilerplate code for information people can
>> trivially get using nvme-cli.
> > I think it's nvme-cli requires root, where this conveniently doesn't
> need those elevated rights.
>
The other point here is the thermal framework. One can not wire that up
through userspace, and even if it was possible to do it, that would defeat
the idea of having the thermal subsystem in the kernel running on its own,
without requiring userspace attention.
> I'm not familiar with either upper level framework either; my only review
> comment for this patch is to use devm_kfree() for the error cases.
>
Makes sense. I'll address that in v2.
Guenter
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
2019-10-28 2:41 ` Guenter Roeck
@ 2019-10-28 18:01 ` Andrey Smirnov
-1 siblings, 0 replies; 10+ messages in thread
From: Andrey Smirnov @ 2019-10-28 18:01 UTC (permalink / raw)
To: Guenter Roeck
Cc: Keith Busch, Chris Healy, Jens Axboe, Christoph Hellwig,
Sagi Grimberg, linux-kernel, linux-nvme
On Mon, Oct 28, 2019 at 7:04 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> nvme devices report temperature information in the controller information
> (for limits) and in the smart log. Currently, the only means to retrieve
> this information is the nvme command line interface, which requires
> super-user privileges.
>
> At the same time, it would be desirable to use NVME temperature information
> for thermal control.
>
> This patch adds support to read NVME temperatures from the kernel using the
> hwmon API and adds temperature zones for NVME drives. The thermal subsystem
> can use this information to set thermal policies, and userspace can access
> it using libsensors and/or the "sensors" command.
>
> Example output from the "sensors" command:
>
> nvme0-pci-0100
> Adapter: PCI adapter
> Composite: +39.0°C (high = +85.0°C, crit = +85.0°C)
> Sensor 1: +39.0°C
> Sensor 2: +41.0°C
>
Tried this on ZII i.MX8MQ Ultra Zest Board with NVMe device attached.
Seems to work as advertised, so:
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/nvme/host/Kconfig | 10 +++
> drivers/nvme/host/Makefile | 1 +
> drivers/nvme/host/core.c | 5 ++
> drivers/nvme/host/nvme-hwmon.c | 160 +++++++++++++++++++++++++++++++++
> drivers/nvme/host/nvme.h | 8 ++
> 5 files changed, 184 insertions(+)
> create mode 100644 drivers/nvme/host/nvme-hwmon.c
>
> diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
> index 2b36f052bfb9..aeb49e16e386 100644
> --- a/drivers/nvme/host/Kconfig
> +++ b/drivers/nvme/host/Kconfig
> @@ -23,6 +23,16 @@ config NVME_MULTIPATH
> /dev/nvmeXnY device will show up for each NVMe namespaces,
> even if it is accessible through multiple controllers.
>
> +config NVME_HWMON
> + bool "NVME hardware monitoring"
> + depends on (NVME_CORE=y && HWMON=y) || (NVME_CORE=m && HWMON)
> + help
> + This provides support for NVME hardware monitoring. If enabled,
> + a hardware monitoring device will be created for each NVME drive
> + in the system.
> +
> + If unsure, say N.
> +
> config NVME_FABRICS
> tristate
>
> diff --git a/drivers/nvme/host/Makefile b/drivers/nvme/host/Makefile
> index 8a4b671c5f0c..03de4797a877 100644
> --- a/drivers/nvme/host/Makefile
> +++ b/drivers/nvme/host/Makefile
> @@ -14,6 +14,7 @@ nvme-core-$(CONFIG_TRACING) += trace.o
> nvme-core-$(CONFIG_NVME_MULTIPATH) += multipath.o
> nvme-core-$(CONFIG_NVM) += lightnvm.o
> nvme-core-$(CONFIG_FAULT_INJECTION_DEBUG_FS) += fault_inject.o
> +nvme-core-$(CONFIG_NVME_HWMON) += nvme-hwmon.o
>
> nvme-y += pci.o
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index fa7ba09dca77..fc1d4b146717 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2796,6 +2796,9 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
> ctrl->oncs = le16_to_cpu(id->oncs);
> ctrl->mtfa = le16_to_cpu(id->mtfa);
> ctrl->oaes = le32_to_cpu(id->oaes);
> + ctrl->wctemp = le16_to_cpu(id->wctemp);
> + ctrl->cctemp = le16_to_cpu(id->cctemp);
> +
> atomic_set(&ctrl->abort_limit, id->acl + 1);
> ctrl->vwc = id->vwc;
> if (id->mdts)
> @@ -2897,6 +2900,8 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
>
> ctrl->identified = true;
>
> + nvme_hwmon_init(ctrl);
> +
> return 0;
>
> out_free:
> diff --git a/drivers/nvme/host/nvme-hwmon.c b/drivers/nvme/host/nvme-hwmon.c
> new file mode 100644
> index 000000000000..f19098bc3228
> --- /dev/null
> +++ b/drivers/nvme/host/nvme-hwmon.c
> @@ -0,0 +1,160 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * NVM Express hardware monitoring support
> + * Copyright (c) 2019, Guenter Roeck
> + */
> +
> +#include <linux/hwmon.h>
> +
> +#include "nvme.h"
> +
> +struct nvme_hwmon_data {
> + struct nvme_ctrl *ctrl;
> + struct nvme_smart_log log;
> +};
> +
> +static int nvme_hwmon_get_smart_log(struct nvme_hwmon_data *data)
> +{
> + return nvme_get_log(data->ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0,
> + &data->log, sizeof(data->log), 0);
> +}
> +
> +static int nvme_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct nvme_hwmon_data *data = dev_get_drvdata(dev);
> + struct nvme_smart_log *log = &data->log;
> + int err;
> + int temp;
> +
> + err = nvme_hwmon_get_smart_log(data);
> + if (err)
> + return err < 0 ? err : -EPROTO;
> +
> + switch (attr) {
> + case hwmon_temp_max:
> + *val = (data->ctrl->wctemp - 273) * 1000;
> + break;
> + case hwmon_temp_crit:
> + *val = (data->ctrl->cctemp - 273) * 1000;
> + break;
> + case hwmon_temp_input:
> + if (!channel)
> + temp = le16_to_cpup((__le16 *)log->temperature);
> + else
> + temp = le16_to_cpu(log->temp_sensor[channel - 1]);
> + *val = (temp - 273) * 1000;
> + break;
> + case hwmon_temp_crit_alarm:
> + *val = !!(log->critical_warning & NVME_SMART_CRIT_TEMPERATURE);
> + break;
> + default:
> + err = -EOPNOTSUPP;
> + break;
> + }
> + return err;
> +}
> +
> +static const char * const nvme_hwmon_sensor_names[] = {
> + "Composite",
> + "Sensor 1",
> + "Sensor 2",
> + "Sensor 3",
> + "Sensor 4",
> + "Sensor 5",
> + "Sensor 6",
> + "Sensor 7",
> + "Sensor 8",
> +};
> +
> +static int nvme_hwmon_read_string(struct device *dev,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel, const char **str)
> +{
> + *str = nvme_hwmon_sensor_names[channel];
> + return 0;
> +}
> +
> +static umode_t nvme_hwmon_is_visible(const void *_data,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + const struct nvme_hwmon_data *data = _data;
> +
> + switch (attr) {
> + case hwmon_temp_crit:
> + if (!channel && data->ctrl->cctemp)
> + return 0444;
> + break;
> + case hwmon_temp_max:
> + if (!channel && data->ctrl->wctemp)
> + return 0444;
> + break;
> + case hwmon_temp_crit_alarm:
> + if (!channel)
> + return 0444;
> + break;
> + case hwmon_temp_input:
> + case hwmon_temp_label:
> + if (!channel || data->log.temp_sensor[channel - 1])
> + return 0444;
> + break;
> + default:
> + break;
> + }
> + return 0;
> +}
> +
> +static const struct hwmon_channel_info *nvme_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
> + HWMON_CHANNEL_INFO(temp,
> + HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
> + HWMON_T_LABEL | HWMON_T_CRIT_ALARM,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL),
> + NULL
> +};
> +
> +static const struct hwmon_ops nvme_hwmon_ops = {
> + .is_visible = nvme_hwmon_is_visible,
> + .read = nvme_hwmon_read,
> + .read_string = nvme_hwmon_read_string,
> +};
> +
> +static const struct hwmon_chip_info nvme_hwmon_chip_info = {
> + .ops = &nvme_hwmon_ops,
> + .info = nvme_hwmon_info,
> +};
> +
> +void nvme_hwmon_init(struct nvme_ctrl *ctrl)
> +{
> + struct device *dev = ctrl->device;
> + struct nvme_hwmon_data *data;
> + struct device *hwmon;
> + int err;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return;
> +
> + data->ctrl = ctrl;
> +
> + err = nvme_hwmon_get_smart_log(data);
> + if (err) {
> + dev_warn(dev, "Failed to read smart log (error %d)\n", err);
> + return;
> + }
> +
> + hwmon = devm_hwmon_device_register_with_info(dev, dev_name(dev),
> + data,
> + &nvme_hwmon_chip_info,
> + NULL);
> + if (IS_ERR(hwmon))
> + dev_warn(dev, "Failed to instantiate hwmon device\n");
> +}
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 22e8401352c2..e6460c1216bc 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -231,6 +231,8 @@ struct nvme_ctrl {
> u16 kas;
> u8 npss;
> u8 apsta;
> + u16 wctemp;
> + u16 cctemp;
> u32 oaes;
> u32 aen_result;
> u32 ctratt;
> @@ -652,4 +654,10 @@ static inline struct nvme_ns *nvme_get_ns_from_dev(struct device *dev)
> return dev_to_disk(dev)->private_data;
> }
>
> +#if IS_ENABLED(CONFIG_NVME_HWMON)
> +void nvme_hwmon_init(struct nvme_ctrl *ctrl);
> +#else
> +static inline void nvme_hwmon_init(struct nvme_ctrl *ctrl) { }
> +#endif
> +
> #endif /* _NVME_H */
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] nvme: Add hardware monitoring support
@ 2019-10-28 18:01 ` Andrey Smirnov
0 siblings, 0 replies; 10+ messages in thread
From: Andrey Smirnov @ 2019-10-28 18:01 UTC (permalink / raw)
To: Guenter Roeck
Cc: Sagi Grimberg, linux-kernel, linux-nvme, Jens Axboe, Chris Healy,
Keith Busch, Christoph Hellwig
On Mon, Oct 28, 2019 at 7:04 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> nvme devices report temperature information in the controller information
> (for limits) and in the smart log. Currently, the only means to retrieve
> this information is the nvme command line interface, which requires
> super-user privileges.
>
> At the same time, it would be desirable to use NVME temperature information
> for thermal control.
>
> This patch adds support to read NVME temperatures from the kernel using the
> hwmon API and adds temperature zones for NVME drives. The thermal subsystem
> can use this information to set thermal policies, and userspace can access
> it using libsensors and/or the "sensors" command.
>
> Example output from the "sensors" command:
>
> nvme0-pci-0100
> Adapter: PCI adapter
> Composite: +39.0°C (high = +85.0°C, crit = +85.0°C)
> Sensor 1: +39.0°C
> Sensor 2: +41.0°C
>
Tried this on ZII i.MX8MQ Ultra Zest Board with NVMe device attached.
Seems to work as advertised, so:
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/nvme/host/Kconfig | 10 +++
> drivers/nvme/host/Makefile | 1 +
> drivers/nvme/host/core.c | 5 ++
> drivers/nvme/host/nvme-hwmon.c | 160 +++++++++++++++++++++++++++++++++
> drivers/nvme/host/nvme.h | 8 ++
> 5 files changed, 184 insertions(+)
> create mode 100644 drivers/nvme/host/nvme-hwmon.c
>
> diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
> index 2b36f052bfb9..aeb49e16e386 100644
> --- a/drivers/nvme/host/Kconfig
> +++ b/drivers/nvme/host/Kconfig
> @@ -23,6 +23,16 @@ config NVME_MULTIPATH
> /dev/nvmeXnY device will show up for each NVMe namespaces,
> even if it is accessible through multiple controllers.
>
> +config NVME_HWMON
> + bool "NVME hardware monitoring"
> + depends on (NVME_CORE=y && HWMON=y) || (NVME_CORE=m && HWMON)
> + help
> + This provides support for NVME hardware monitoring. If enabled,
> + a hardware monitoring device will be created for each NVME drive
> + in the system.
> +
> + If unsure, say N.
> +
> config NVME_FABRICS
> tristate
>
> diff --git a/drivers/nvme/host/Makefile b/drivers/nvme/host/Makefile
> index 8a4b671c5f0c..03de4797a877 100644
> --- a/drivers/nvme/host/Makefile
> +++ b/drivers/nvme/host/Makefile
> @@ -14,6 +14,7 @@ nvme-core-$(CONFIG_TRACING) += trace.o
> nvme-core-$(CONFIG_NVME_MULTIPATH) += multipath.o
> nvme-core-$(CONFIG_NVM) += lightnvm.o
> nvme-core-$(CONFIG_FAULT_INJECTION_DEBUG_FS) += fault_inject.o
> +nvme-core-$(CONFIG_NVME_HWMON) += nvme-hwmon.o
>
> nvme-y += pci.o
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index fa7ba09dca77..fc1d4b146717 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2796,6 +2796,9 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
> ctrl->oncs = le16_to_cpu(id->oncs);
> ctrl->mtfa = le16_to_cpu(id->mtfa);
> ctrl->oaes = le32_to_cpu(id->oaes);
> + ctrl->wctemp = le16_to_cpu(id->wctemp);
> + ctrl->cctemp = le16_to_cpu(id->cctemp);
> +
> atomic_set(&ctrl->abort_limit, id->acl + 1);
> ctrl->vwc = id->vwc;
> if (id->mdts)
> @@ -2897,6 +2900,8 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
>
> ctrl->identified = true;
>
> + nvme_hwmon_init(ctrl);
> +
> return 0;
>
> out_free:
> diff --git a/drivers/nvme/host/nvme-hwmon.c b/drivers/nvme/host/nvme-hwmon.c
> new file mode 100644
> index 000000000000..f19098bc3228
> --- /dev/null
> +++ b/drivers/nvme/host/nvme-hwmon.c
> @@ -0,0 +1,160 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * NVM Express hardware monitoring support
> + * Copyright (c) 2019, Guenter Roeck
> + */
> +
> +#include <linux/hwmon.h>
> +
> +#include "nvme.h"
> +
> +struct nvme_hwmon_data {
> + struct nvme_ctrl *ctrl;
> + struct nvme_smart_log log;
> +};
> +
> +static int nvme_hwmon_get_smart_log(struct nvme_hwmon_data *data)
> +{
> + return nvme_get_log(data->ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0,
> + &data->log, sizeof(data->log), 0);
> +}
> +
> +static int nvme_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct nvme_hwmon_data *data = dev_get_drvdata(dev);
> + struct nvme_smart_log *log = &data->log;
> + int err;
> + int temp;
> +
> + err = nvme_hwmon_get_smart_log(data);
> + if (err)
> + return err < 0 ? err : -EPROTO;
> +
> + switch (attr) {
> + case hwmon_temp_max:
> + *val = (data->ctrl->wctemp - 273) * 1000;
> + break;
> + case hwmon_temp_crit:
> + *val = (data->ctrl->cctemp - 273) * 1000;
> + break;
> + case hwmon_temp_input:
> + if (!channel)
> + temp = le16_to_cpup((__le16 *)log->temperature);
> + else
> + temp = le16_to_cpu(log->temp_sensor[channel - 1]);
> + *val = (temp - 273) * 1000;
> + break;
> + case hwmon_temp_crit_alarm:
> + *val = !!(log->critical_warning & NVME_SMART_CRIT_TEMPERATURE);
> + break;
> + default:
> + err = -EOPNOTSUPP;
> + break;
> + }
> + return err;
> +}
> +
> +static const char * const nvme_hwmon_sensor_names[] = {
> + "Composite",
> + "Sensor 1",
> + "Sensor 2",
> + "Sensor 3",
> + "Sensor 4",
> + "Sensor 5",
> + "Sensor 6",
> + "Sensor 7",
> + "Sensor 8",
> +};
> +
> +static int nvme_hwmon_read_string(struct device *dev,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel, const char **str)
> +{
> + *str = nvme_hwmon_sensor_names[channel];
> + return 0;
> +}
> +
> +static umode_t nvme_hwmon_is_visible(const void *_data,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + const struct nvme_hwmon_data *data = _data;
> +
> + switch (attr) {
> + case hwmon_temp_crit:
> + if (!channel && data->ctrl->cctemp)
> + return 0444;
> + break;
> + case hwmon_temp_max:
> + if (!channel && data->ctrl->wctemp)
> + return 0444;
> + break;
> + case hwmon_temp_crit_alarm:
> + if (!channel)
> + return 0444;
> + break;
> + case hwmon_temp_input:
> + case hwmon_temp_label:
> + if (!channel || data->log.temp_sensor[channel - 1])
> + return 0444;
> + break;
> + default:
> + break;
> + }
> + return 0;
> +}
> +
> +static const struct hwmon_channel_info *nvme_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
> + HWMON_CHANNEL_INFO(temp,
> + HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
> + HWMON_T_LABEL | HWMON_T_CRIT_ALARM,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL,
> + HWMON_T_INPUT | HWMON_T_LABEL),
> + NULL
> +};
> +
> +static const struct hwmon_ops nvme_hwmon_ops = {
> + .is_visible = nvme_hwmon_is_visible,
> + .read = nvme_hwmon_read,
> + .read_string = nvme_hwmon_read_string,
> +};
> +
> +static const struct hwmon_chip_info nvme_hwmon_chip_info = {
> + .ops = &nvme_hwmon_ops,
> + .info = nvme_hwmon_info,
> +};
> +
> +void nvme_hwmon_init(struct nvme_ctrl *ctrl)
> +{
> + struct device *dev = ctrl->device;
> + struct nvme_hwmon_data *data;
> + struct device *hwmon;
> + int err;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return;
> +
> + data->ctrl = ctrl;
> +
> + err = nvme_hwmon_get_smart_log(data);
> + if (err) {
> + dev_warn(dev, "Failed to read smart log (error %d)\n", err);
> + return;
> + }
> +
> + hwmon = devm_hwmon_device_register_with_info(dev, dev_name(dev),
> + data,
> + &nvme_hwmon_chip_info,
> + NULL);
> + if (IS_ERR(hwmon))
> + dev_warn(dev, "Failed to instantiate hwmon device\n");
> +}
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 22e8401352c2..e6460c1216bc 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -231,6 +231,8 @@ struct nvme_ctrl {
> u16 kas;
> u8 npss;
> u8 apsta;
> + u16 wctemp;
> + u16 cctemp;
> u32 oaes;
> u32 aen_result;
> u32 ctratt;
> @@ -652,4 +654,10 @@ static inline struct nvme_ns *nvme_get_ns_from_dev(struct device *dev)
> return dev_to_disk(dev)->private_data;
> }
>
> +#if IS_ENABLED(CONFIG_NVME_HWMON)
> +void nvme_hwmon_init(struct nvme_ctrl *ctrl);
> +#else
> +static inline void nvme_hwmon_init(struct nvme_ctrl *ctrl) { }
> +#endif
> +
> #endif /* _NVME_H */
> --
> 2.17.1
>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-10-28 18:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-28 2:41 [PATCH] nvme: Add hardware monitoring support Guenter Roeck
2019-10-28 2:41 ` Guenter Roeck
2019-10-28 7:39 ` Christoph Hellwig
2019-10-28 7:39 ` Christoph Hellwig
2019-10-28 8:08 ` Keith Busch
2019-10-28 8:08 ` Keith Busch
2019-10-28 13:27 ` Guenter Roeck
2019-10-28 13:27 ` Guenter Roeck
2019-10-28 18:01 ` Andrey Smirnov
2019-10-28 18:01 ` Andrey Smirnov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.