From: Andrew Morton <akpm@linux-foundation.org>
To: djwong@us.ibm.com
Cc: lenb@kernel.org, linux-acpi@vger.kernel.org, rui.zhang@intel.com,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [PATCH v2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters
Date: Mon, 17 Aug 2009 15:05:58 -0700 [thread overview]
Message-ID: <20090817150558.3468426b.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090806204255.GD14694@plum>
On Thu, 6 Aug 2009 13:42:57 -0700
"Darrick J. Wong" <djwong@us.ibm.com> wrote:
> This driver exposes ACPI 4.0 compliant power meters as hardware monitoring
> devices. This second revision of the driver also exports the ACPI string
> info as sysfs attributes, a list of the devices that the meter measures,
> and will send ACPI notifications over the ACPI netlink socket.
>
>
> ...
>
> +static ssize_t set_avg_interval(struct device *dev,
> + struct device_attribute *devattr,
> + const char *buf, size_t count)
> +{
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + struct acpi_power_meter_resource *resource = acpi_dev->driver_data;
> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> + struct acpi_object_list args = { 1, &arg0 };
> + int res;
> + unsigned long temp;
> + unsigned long long data;
> + acpi_status status;
> +
> + res = strict_strtoul(buf, 10, &temp);
> + if (res)
> + return res;
> +
> + if (temp > resource->caps.max_avg_interval ||
> + temp < resource->caps.min_avg_interval)
> + return -EINVAL;
> + arg0.integer.value = temp;
> +
> + mutex_lock(&resource->lock);
> + status = acpi_evaluate_integer(resource->acpi_dev->handle, "_PAI",
> + &args, &data);
> + if (!ACPI_FAILURE(status))
> + resource->avg_interval = temp;
> + mutex_unlock(&resource->lock);
> +
> + if (ACPI_FAILURE(status)) {
> + ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PAI"));
> + return -EINVAL;
> + }
> +
> + if (data)
> + return -EINVAL;
I find this test of `data' inexplicable. Is it just me, or do we need
a comment here?
> + return count;
> +}
> +
>
> ...
>
> +static ssize_t set_cap(struct device *dev, struct device_attribute *devattr,
> + const char *buf, size_t count)
> +{
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + struct acpi_power_meter_resource *resource = acpi_dev->driver_data;
> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> + struct acpi_object_list args = { 1, &arg0 };
> + int res;
> + unsigned long temp;
> + unsigned long long data;
> + acpi_status status;
> +
> + res = strict_strtoul(buf, 10, &temp);
> + if (res)
> + return res;
> +
> + temp /= 1000;
> + if (temp > resource->caps.max_cap || temp < resource->caps.min_cap)
> + return -EINVAL;
> + arg0.integer.value = temp;
> +
> + mutex_lock(&resource->lock);
> + status = acpi_evaluate_integer(resource->acpi_dev->handle, "_SHL",
> + &args, &data);
> + if (!ACPI_FAILURE(status))
> + resource->cap = temp;
> + mutex_unlock(&resource->lock);
> +
> + if (ACPI_FAILURE(status)) {
> + ACPI_EXCEPTION((AE_INFO, status, "Evaluating _SHL"));
> + return -EINVAL;
> + }
> +
> + if (data)
> + return -EINVAL;
ditto.
> + return count;
> +}
> +
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: djwong@us.ibm.com
Cc: lenb@kernel.org, linux-acpi@vger.kernel.org, rui.zhang@intel.com,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [PATCH v2] acpi_power_meter: hwmon driver for ACPI
Date: Mon, 17 Aug 2009 22:05:58 +0000 [thread overview]
Message-ID: <20090817150558.3468426b.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090806204255.GD14694@plum>
On Thu, 6 Aug 2009 13:42:57 -0700
"Darrick J. Wong" <djwong@us.ibm.com> wrote:
> This driver exposes ACPI 4.0 compliant power meters as hardware monitoring
> devices. This second revision of the driver also exports the ACPI string
> info as sysfs attributes, a list of the devices that the meter measures,
> and will send ACPI notifications over the ACPI netlink socket.
>
>
> ...
>
> +static ssize_t set_avg_interval(struct device *dev,
> + struct device_attribute *devattr,
> + const char *buf, size_t count)
> +{
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + struct acpi_power_meter_resource *resource = acpi_dev->driver_data;
> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> + struct acpi_object_list args = { 1, &arg0 };
> + int res;
> + unsigned long temp;
> + unsigned long long data;
> + acpi_status status;
> +
> + res = strict_strtoul(buf, 10, &temp);
> + if (res)
> + return res;
> +
> + if (temp > resource->caps.max_avg_interval ||
> + temp < resource->caps.min_avg_interval)
> + return -EINVAL;
> + arg0.integer.value = temp;
> +
> + mutex_lock(&resource->lock);
> + status = acpi_evaluate_integer(resource->acpi_dev->handle, "_PAI",
> + &args, &data);
> + if (!ACPI_FAILURE(status))
> + resource->avg_interval = temp;
> + mutex_unlock(&resource->lock);
> +
> + if (ACPI_FAILURE(status)) {
> + ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PAI"));
> + return -EINVAL;
> + }
> +
> + if (data)
> + return -EINVAL;
I find this test of `data' inexplicable. Is it just me, or do we need
a comment here?
> + return count;
> +}
> +
>
> ...
>
> +static ssize_t set_cap(struct device *dev, struct device_attribute *devattr,
> + const char *buf, size_t count)
> +{
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + struct acpi_power_meter_resource *resource = acpi_dev->driver_data;
> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> + struct acpi_object_list args = { 1, &arg0 };
> + int res;
> + unsigned long temp;
> + unsigned long long data;
> + acpi_status status;
> +
> + res = strict_strtoul(buf, 10, &temp);
> + if (res)
> + return res;
> +
> + temp /= 1000;
> + if (temp > resource->caps.max_cap || temp < resource->caps.min_cap)
> + return -EINVAL;
> + arg0.integer.value = temp;
> +
> + mutex_lock(&resource->lock);
> + status = acpi_evaluate_integer(resource->acpi_dev->handle, "_SHL",
> + &args, &data);
> + if (!ACPI_FAILURE(status))
> + resource->cap = temp;
> + mutex_unlock(&resource->lock);
> +
> + if (ACPI_FAILURE(status)) {
> + ACPI_EXCEPTION((AE_INFO, status, "Evaluating _SHL"));
> + return -EINVAL;
> + }
> +
> + if (data)
> + return -EINVAL;
ditto.
> + return count;
> +}
> +
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2009-08-17 22:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-25 0:43 [PATCH 0/2] ACPI 4.0 power meter Darrick J. Wong
2009-07-25 0:43 ` [lm-sensors] " Darrick J. Wong
2009-07-25 0:43 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Darrick J. Wong
2009-07-25 0:43 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Darrick J. Wong
2009-08-07 18:09 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Pavel Machek
2009-08-07 18:09 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Pavel Machek
2009-08-08 17:40 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Darrick J. Wong
2009-08-08 17:40 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Darrick J. Wong
2009-08-08 21:48 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Pavel Machek
2009-08-08 21:48 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Pavel Machek
2009-08-10 21:12 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Darrick J. Wong
2009-08-10 21:12 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Darrick J. Wong
2009-08-12 11:56 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Pavel Machek
2009-08-12 11:56 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Pavel Machek
2009-08-18 23:32 ` [PATCH 1/2] hwmon: Enhance the sysfs API for power meters Darrick J. Wong
2009-08-18 23:32 ` [lm-sensors] [PATCH 1/2] hwmon: Enhance the sysfs API for power Darrick J. Wong
2009-07-25 0:43 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Darrick J. Wong
2009-07-25 0:43 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI Darrick J. Wong
2009-07-27 1:44 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters ykzhao
2009-07-27 1:44 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for ykzhao
2009-08-03 20:48 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Darrick J. Wong
2009-08-03 20:48 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for Darrick J. Wong
2009-07-27 6:45 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Zhang Rui
2009-07-27 6:45 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for Zhang Rui
2009-08-03 20:52 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Darrick J. Wong
2009-08-03 20:52 ` Darrick J. Wong
2009-08-03 20:52 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for Darrick J. Wong
2009-07-28 1:25 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Len Brown
2009-07-28 1:25 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for Len Brown
2009-08-03 20:58 ` [PATCH 2/2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Darrick J. Wong
2009-08-03 20:58 ` [lm-sensors] [PATCH 2/2] acpi_power_meter: hwmon driver for Darrick J. Wong
2009-08-06 20:42 ` [PATCH v2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Darrick J. Wong
2009-08-06 20:42 ` [lm-sensors] [PATCH v2] acpi_power_meter: hwmon driver for ACPI 4.0 Darrick J. Wong
2009-08-17 22:05 ` Andrew Morton [this message]
2009-08-17 22:05 ` [lm-sensors] [PATCH v2] acpi_power_meter: hwmon driver for ACPI Andrew Morton
2009-08-18 16:24 ` [PATCH v2] acpi_power_meter: hwmon driver for ACPI 4.0 power meters Darrick J. Wong
2009-08-18 16:24 ` [lm-sensors] [PATCH v2] acpi_power_meter: hwmon driver for ACPI Darrick J. Wong
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=20090817150558.3468426b.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=djwong@us.ibm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=rui.zhang@intel.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.