From: minwoo.im.dev@gmail.com (Minwoo Im)
Subject: [PATCH v3 2/3] nvme: add thermal zone devices
Date: Thu, 30 May 2019 00:15:18 +0900 [thread overview]
Message-ID: <20190529151517.GC28274@minwooim-desktop> (raw)
In-Reply-To: <1558888143-5121-3-git-send-email-akinobu.mita@gmail.com>
> +/**
> + * nvme_thermal_zones_register() - register nvme thermal zone devices
> + * @ctrl: controller instance
> + *
> + * This function creates up to nine thermal zone devices for all implemented
> + * temperature sensors including the composite temperature.
> + * Each thermal zone device provides a single trip point temperature that is
> + * associated with an over temperature threshold.
> + */
> +static int nvme_thermal_zones_register(struct nvme_ctrl *ctrl)
> +{
> + struct nvme_smart_log *log;
> + int ret;
> + int i;
> +
> + log = kzalloc(sizeof(*log), GFP_KERNEL);
> + if (!log)
> + return 0; /* non-fatal error */
Do we need to print something like warning here? If kzalloc() fails, it
would be good to be distinguished between the nvme failure and internal
failure like this.
> +
> + ret = nvme_get_log(ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0,
> + log, sizeof(*log), 0);
> + if (ret) {
> + dev_err(ctrl->device, "Failed to get SMART log: %d\n", ret);
> + /* If the device provided a response, then it's non-fatal */
> + if (ret > 0)
> + ret = 0;
It seems like that nvme_init_identify() is just check the internal error
which is in negative value now as you have posted. Why don't we just
return the value of "ret" itself without updating it to 0 ?
> + goto free_log;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(ctrl->tzdev); i++) {
> + struct thermal_zone_device *tzdev;
> + int temp;
> +
> + if (i)
> + temp = le16_to_cpu(log->temp_sensor[i - 1]);
> + else
> + temp = get_unaligned_le16(log->temperature);
> +
> + /*
> + * All implemented temperature sensors report a non-zero value
> + * in temperature sensor fields in the smart log page.
> + */
> + if (!temp)
> + continue;
> + if (ctrl->tzdev[i])
> + continue;
> +
> + tzdev = nvme_thermal_zone_register(ctrl, i);
> + if (!IS_ERR(tzdev))
> + ctrl->tzdev[i] = tzdev;
> + }
> +
> +free_log:
> + kfree(log);
> +
> + return ret;
> +}
> +
> +/**
> + * nvme_thermal_zones_unregister() - unregister nvme thermal zone devices
> + * @ctrl: controller instance
> + *
> + * This function removes the registered thermal zone devices and symlinks.
> + */
> +static void nvme_thermal_zones_unregister(struct nvme_ctrl *ctrl)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctrl->tzdev); i++) {
> + struct thermal_zone_device *tzdev = ctrl->tzdev[i];
> + char name[20];
Simple query here :)
If we are not going to allow the name of link exceed the length of its
own device name like nvmeX_tempY, then can we THERMAL_NAME_LENGTH macro
here? If the name of link is not exactly about the device name itself,
then it's fine. What do you think about it ?
WARNING: multiple messages have this Message-ID (diff)
From: Minwoo Im <minwoo.im.dev@gmail.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-nvme@lists.infradead.org, linux-pm@vger.kernel.org,
Zhang Rui <rui.zhang@intel.com>,
Eduardo Valentin <edubezval@gmail.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Keith Busch <keith.busch@intel.com>, Jens Axboe <axboe@fb.com>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Kenneth Heitke <kenneth.heitke@intel.com>,
Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Subject: Re: [PATCH v3 2/3] nvme: add thermal zone devices
Date: Thu, 30 May 2019 00:15:18 +0900 [thread overview]
Message-ID: <20190529151517.GC28274@minwooim-desktop> (raw)
In-Reply-To: <1558888143-5121-3-git-send-email-akinobu.mita@gmail.com>
> +/**
> + * nvme_thermal_zones_register() - register nvme thermal zone devices
> + * @ctrl: controller instance
> + *
> + * This function creates up to nine thermal zone devices for all implemented
> + * temperature sensors including the composite temperature.
> + * Each thermal zone device provides a single trip point temperature that is
> + * associated with an over temperature threshold.
> + */
> +static int nvme_thermal_zones_register(struct nvme_ctrl *ctrl)
> +{
> + struct nvme_smart_log *log;
> + int ret;
> + int i;
> +
> + log = kzalloc(sizeof(*log), GFP_KERNEL);
> + if (!log)
> + return 0; /* non-fatal error */
Do we need to print something like warning here? If kzalloc() fails, it
would be good to be distinguished between the nvme failure and internal
failure like this.
> +
> + ret = nvme_get_log(ctrl, NVME_NSID_ALL, NVME_LOG_SMART, 0,
> + log, sizeof(*log), 0);
> + if (ret) {
> + dev_err(ctrl->device, "Failed to get SMART log: %d\n", ret);
> + /* If the device provided a response, then it's non-fatal */
> + if (ret > 0)
> + ret = 0;
It seems like that nvme_init_identify() is just check the internal error
which is in negative value now as you have posted. Why don't we just
return the value of "ret" itself without updating it to 0 ?
> + goto free_log;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(ctrl->tzdev); i++) {
> + struct thermal_zone_device *tzdev;
> + int temp;
> +
> + if (i)
> + temp = le16_to_cpu(log->temp_sensor[i - 1]);
> + else
> + temp = get_unaligned_le16(log->temperature);
> +
> + /*
> + * All implemented temperature sensors report a non-zero value
> + * in temperature sensor fields in the smart log page.
> + */
> + if (!temp)
> + continue;
> + if (ctrl->tzdev[i])
> + continue;
> +
> + tzdev = nvme_thermal_zone_register(ctrl, i);
> + if (!IS_ERR(tzdev))
> + ctrl->tzdev[i] = tzdev;
> + }
> +
> +free_log:
> + kfree(log);
> +
> + return ret;
> +}
> +
> +/**
> + * nvme_thermal_zones_unregister() - unregister nvme thermal zone devices
> + * @ctrl: controller instance
> + *
> + * This function removes the registered thermal zone devices and symlinks.
> + */
> +static void nvme_thermal_zones_unregister(struct nvme_ctrl *ctrl)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctrl->tzdev); i++) {
> + struct thermal_zone_device *tzdev = ctrl->tzdev[i];
> + char name[20];
Simple query here :)
If we are not going to allow the name of link exceed the length of its
own device name like nvmeX_tempY, then can we THERMAL_NAME_LENGTH macro
here? If the name of link is not exactly about the device name itself,
then it's fine. What do you think about it ?
next prev parent reply other threads:[~2019-05-29 15:15 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-26 16:29 [PATCH v3 0/3] nvme: add thermal zone devices Akinobu Mita
2019-05-26 16:29 ` Akinobu Mita
2019-05-26 16:29 ` [PATCH v3 1/3] nvme: Export get and set features Akinobu Mita
2019-05-26 16:29 ` Akinobu Mita
2019-05-26 16:45 ` Chaitanya Kulkarni
2019-05-26 16:45 ` Chaitanya Kulkarni
2019-05-29 15:19 ` Minwoo Im
2019-05-29 15:19 ` Minwoo Im
2019-05-26 16:29 ` [PATCH v3 2/3] nvme: add thermal zone devices Akinobu Mita
2019-05-26 16:29 ` Akinobu Mita
2019-05-29 15:15 ` Minwoo Im [this message]
2019-05-29 15:15 ` Minwoo Im
2019-05-29 16:47 ` Akinobu Mita
2019-05-29 16:47 ` Akinobu Mita
2019-05-30 10:18 ` Minwoo Im
2019-05-30 10:18 ` Minwoo Im
2019-06-01 9:02 ` Christoph Hellwig
2019-06-01 9:02 ` Christoph Hellwig
2019-06-02 13:19 ` Akinobu Mita
2019-06-02 13:19 ` Akinobu Mita
2019-06-04 7:31 ` Christoph Hellwig
2019-06-04 7:31 ` Christoph Hellwig
2019-06-05 15:42 ` Akinobu Mita
2019-06-05 15:42 ` Akinobu Mita
2019-06-03 2:36 ` Eduardo Valentin
2019-06-03 2:36 ` Eduardo Valentin
2019-06-03 15:20 ` Akinobu Mita
2019-06-03 15:20 ` Akinobu Mita
2019-06-06 4:05 ` Eduardo Valentin
2019-06-06 4:05 ` Eduardo Valentin
2019-06-07 15:21 ` Akinobu Mita
2019-06-07 15:21 ` Akinobu Mita
2019-05-26 16:29 ` [PATCH v3 3/3] nvme: notify thermal framework when temperature threshold events occur Akinobu Mita
2019-05-26 16:29 ` Akinobu Mita
2019-06-01 9:03 ` Christoph Hellwig
2019-06-01 9:03 ` Christoph Hellwig
2019-06-02 13:46 ` Akinobu Mita
2019-06-02 13:46 ` Akinobu Mita
2019-06-04 7:32 ` Christoph Hellwig
2019-06-04 7:32 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190529151517.GC28274@minwooim-desktop \
--to=minwoo.im.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.