[PATCH] hwmon: Add driver for VIA CPU core temperature

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jean,

Harald seems to be to busy to answer emails. Can we push my driver upstream?

...juerg


On Sat, Jun 27, 2009 at 11:34 AM, Juerg Haefliger<juergh at gmail.com> wrote:
> Hi Jean,
>
>
>> Hi Harald,
>>
>> On Tue, 9 Jun 2009 16:34:06 +0800, Harald Welte wrote:
>>> This is a driver for the on-die digital temperature sensor of
>>> VIA's recent CPU models.
>>>
>>> Signed-off-by: Harald Welte <HaraldWelte at viatech.com>
>>> ---
>>> ?drivers/hwmon/Kconfig ? ? ? | ? ?8 +
>>> ?drivers/hwmon/Makefile ? ? ?| ? ?1 +
>>> ?drivers/hwmon/via-cputemp.c | ?354 +++++++++++++++++++++++++++++++++++++++++++
>>> ?3 files changed, 363 insertions(+), 0 deletions(-)
>>> ?create mode 100644 drivers/hwmon/via-cputemp.c
>>
>> Interesting. I'm adding Juerg Haefliger in Cc. A few months ago, Juerg
>> submitted a driver named "c7temp" doing basically the same, with
>> mitigated success. I seem to remember that Juerg's driver was also
>> displaying either the VID or Vcore for the CPU. We don't want to have
>> two drivers for the same hardware, so let's merge everything in one
>> driver and push this upstream.
>>
>> Juerg, you were there first, so I'd like to hear you on this. Are there
>> differences between Harald'd driver and yours? Which one should I pick?
>
> Personally I don't care which driver you pick as long as we get one
> into mainline eventually. Just a few comments:
>
> 1) My driver uses the CPUID instruction to read the performance
> registers that contain the temp and voltage data. Harald's driver
> reads MSRs. I don't know if there are any benefits of using one method
> over the other.
>
> 2) If we pick Harald's, it would be nice if his driver can also read
> and export the CPU core voltage.
>
> 3) Quite a few testers of my driver reported 0 temp readings for some
> C7 CPUs. I was never able to figure out why some CPUs return 0 temp
> but I'm guessing it depends on the thermal monitor settings. I'd like
> to understand what is going on and hope Harald can shed some light.
>
> ...juerg
>
>
>> For now, here's a review of Harald's driver:
>>
>>>
>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>> index d73f5f4..e863833 100644
>>> --- a/drivers/hwmon/Kconfig
>>> +++ b/drivers/hwmon/Kconfig
>>> @@ -787,6 +787,14 @@ config SENSORS_THMC50
>>> ? ? ? ? This driver can also be built as a module. ?If so, the module
>>> ? ? ? ? will be called thmc50.
>>>
>>> +config SENSORS_VIA_CPUTEMP
>>> + ? ? tristate "VIA CPU temperature sensor"
>>> + ? ? depends on X86
>>> + ? ? help
>>> + ? ? ? If you say yes here you get support for the temperature
>>> + ? ? ? sensor inside your CPU. Supported all are all known variants
>>> + ? ? ? of the VIA C7 and Nano.
>>> +
>>> ?config SENSORS_VIA686A
>>> ? ? ? tristate "VIA686A"
>>> ? ? ? depends on PCI
>>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>>> index 0ae2698..3edf7fa 100644
>>> --- a/drivers/hwmon/Makefile
>>> +++ b/drivers/hwmon/Makefile
>>> @@ -82,6 +82,7 @@ obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
>>> ?obj-$(CONFIG_SENSORS_SMSC47M1) ? ? ? += smsc47m1.o
>>> ?obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
>>> ?obj-$(CONFIG_SENSORS_THMC50) += thmc50.o
>>> +obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
>>> ?obj-$(CONFIG_SENSORS_VIA686A) ? ? ? ?+= via686a.o
>>> ?obj-$(CONFIG_SENSORS_VT1211) += vt1211.o
>>> ?obj-$(CONFIG_SENSORS_VT8231) += vt8231.o
>>> diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
>>> new file mode 100644
>>> index 0000000..1032355
>>> --- /dev/null
>>> +++ b/drivers/hwmon/via-cputemp.c
>>> @@ -0,0 +1,354 @@
>>> +/*
>>> + * via-cputemp.c - Driver for VIA CPU core temperature monitoring
>>> + * Copyright (C) 2009 VIA Technologies, Inc.
>>> + *
>>> + * based on existing coretemp.c, which is
>>> + *
>>> + * Copyright (C) 2007 Rudolf Marek <r.marek at assembler.cz>
>>> + *
>>> + * 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; version 2 of the License.
>>> + *
>>> + * 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.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> + * 02110-1301 USA.
>>> + */
>>> +
>>> +#include <linux/module.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/init.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/jiffies.h>
>>> +#include <linux/hwmon.h>
>>> +#include <linux/sysfs.h>
>>> +#include <linux/hwmon-sysfs.h>
>>> +#include <linux/err.h>
>>> +#include <linux/mutex.h>
>>> +#include <linux/list.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/cpu.h>
>>> +#include <asm/msr.h>
>>> +#include <asm/processor.h>
>>> +
>>> +#define DRVNAME ? ? ?"via-cputemp"
>>> +
>>> +typedef enum { SHOW_TEMP, SHOW_LABEL, SHOW_NAME } SHOW;
>>
>> No typedef in kernel code please, an enum is enough.
>>
>>> +
>>> +/*
>>> + * Functions declaration
>>> + */
>>> +
>>> +struct via_cputemp_data {
>>> + ? ? struct device *hwmon_dev;
>>> + ? ? const char *name;
>>> + ? ? u32 id;
>>> + ? ? u32 msr;
>>> +};
>>> +
>>> +/*
>>> + * Sysfs stuff
>>> + */
>>> +
>>> +static ssize_t show_name(struct device *dev, struct device_attribute
>>> + ? ? ? ? ? ? ? ? ? ? ? *devattr, char *buf)
>>> +{
>>> + ? ? int ret;
>>> + ? ? struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
>>> + ? ? struct via_cputemp_data *data = dev_get_drvdata(dev);
>>> +
>>> + ? ? if (attr->index == SHOW_NAME)
>>> + ? ? ? ? ? ? ret = sprintf(buf, "%s\n", data->name);
>>> + ? ? else ? ?/* show label */
>>> + ? ? ? ? ? ? ret = sprintf(buf, "Core %d\n", data->id);
>>> + ? ? return ret;
>>> +}
>>> +
>>> +static ssize_t show_temp(struct device *dev,
>>> + ? ? ? ? ? ? ? ? ? ? ?struct device_attribute *devattr, char *buf)
>>> +{
>>> + ? ? struct via_cputemp_data *data = dev_get_drvdata(dev);
>>> + ? ? u32 eax, edx;
>>> + ? ? int err;
>>> +
>>> + ? ? err = rdmsr_safe_on_cpu(data->id, data->msr, &eax, &edx);
>>> + ? ? if (err)
>>> + ? ? ? ? ? ? return -EAGAIN;
>>> +
>>> + ? ? err = sprintf(buf, "%d\n", eax & 0xffffff);
>>> +
>>> + ? ? return err;
>>
>> return sprintf()... would be clearer, as the returned value is never an
>> error in this case.
>>
>> Also note that in theory the result could overflow once multiplied by
>> 1000.
>>
>>> +}
>>> +
>>> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL,
>>> + ? ? ? ? ? ? ? ? ? ? ? SHOW_TEMP);
>>> +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_name, NULL, SHOW_LABEL);
>>> +static SENSOR_DEVICE_ATTR(name, S_IRUGO, show_name, NULL, SHOW_NAME);
>>> +
>>> +static struct attribute *via_cputemp_attributes[] = {
>>> + ? ? &sensor_dev_attr_name.dev_attr.attr,
>>> + ? ? &sensor_dev_attr_temp1_label.dev_attr.attr,
>>> + ? ? &sensor_dev_attr_temp1_input.dev_attr.attr,
>>> + ? ? NULL
>>> +};
>>> +
>>> +static const struct attribute_group via_cputemp_group = {
>>> + ? ? .attrs = via_cputemp_attributes,
>>> +};
>>> +
>>> +static int __devinit via_cputemp_probe(struct platform_device *pdev)
>>> +{
>>> + ? ? struct via_cputemp_data *data;
>>> + ? ? struct cpuinfo_x86 *c = &cpu_data(pdev->id);
>>> + ? ? int err;
>>> + ? ? u32 eax, edx;
>>> +
>>> + ? ? if (!(data = kzalloc(sizeof(struct via_cputemp_data), GFP_KERNEL))) {
>>
>> ERROR: do not use assignment in if condition
>>
>>> + ? ? ? ? ? ? err = -ENOMEM;
>>> + ? ? ? ? ? ? dev_err(&pdev->dev, "Out of memory\n");
>>> + ? ? ? ? ? ? goto exit;
>>> + ? ? }
>>> +
>>> + ? ? data->id = pdev->id;
>>
>> pdev->id is an unsigned int, so shouldn't data->id be too?
>>
>>> + ? ? data->name = "via-cputemp";
>>
>> This must be made "via_cputemp", as dashes aren't accepted in hwmon
>> device names.
>>
>>> +
>>> + ? ? switch (c->x86_model) {
>>> + ? ? case 0xA:
>>> + ? ? ? ? ? ? /* C7 A */
>>> + ? ? case 0xD:
>>> + ? ? ? ? ? ? /* C7 D */
>>> + ? ? ? ? ? ? data->msr = 0x1169;
>>> + ? ? ? ? ? ? break;
>>> + ? ? case 0xF:
>>> + ? ? ? ? ? ? /* Nano */
>>> + ? ? ? ? ? ? data->msr = 0x1423;
>>> + ? ? ? ? ? ? break;
>>> + ? ? default:
>>> + ? ? ? ? ? ? err = -ENODEV;
>>> + ? ? ? ? ? ? goto exit_free;
>>> + ? ? }
>>> +
>>> + ? ? /* test if we can access the TEMPERATURE MSR */
>>> + ? ? err = rdmsr_safe_on_cpu(data->id, data->msr, &eax, &edx);
>>> + ? ? if (err) {
>>
>> In the runtime read function, you handle errors with -EAGAIN, which
>> means transient errors are expected. If such an error happens at
>> registration time, we could see random failures. That's confusing for
>> the user. I believe you should either skip the test at registration
>> (are there really CPU models where it always fails?) or try more than
>> once to rule out temporary failures.
>>
>>> + ? ? ? ? ? ? dev_err(&pdev->dev,
>>> + ? ? ? ? ? ? ? ? ? ? "Unable to access TEMPERATURE MSR, giving up\n");
>>> + ? ? ? ? ? ? goto exit_free;
>>> + ? ? }
>>> +
>>> + ? ? platform_set_drvdata(pdev, data);
>>> +
>>> + ? ? if ((err = sysfs_create_group(&pdev->dev.kobj, &via_cputemp_group)))
>>
>> ERROR: do not use assignment in if condition
>>
>>> + ? ? ? ? ? ? goto exit_free;
>>> +
>>> + ? ? data->hwmon_dev = hwmon_device_register(&pdev->dev);
>>> + ? ? if (IS_ERR(data->hwmon_dev)) {
>>> + ? ? ? ? ? ? err = PTR_ERR(data->hwmon_dev);
>>> + ? ? ? ? ? ? dev_err(&pdev->dev, "Class registration failed (%d)\n",
>>> + ? ? ? ? ? ? ? ? ? ? err);
>>> + ? ? ? ? ? ? goto exit_class;
>>> + ? ? }
>>> +
>>> + ? ? return 0;
>>> +
>>> +exit_class:
>>> + ? ? sysfs_remove_group(&pdev->dev.kobj, &via_cputemp_group);
>>> +exit_free:
>>
>> A platform_set_drvdata(pdev, NULL) would be welcome here.
>>
>>> + ? ? kfree(data);
>>
>> This is a little inconsistent, as the first label refers to the last
>> action that succeeded and the second label refers to the first cleanup
>> step to execute. Renaming exit_class to exit_remove would help.
>>
>>> +exit:
>>> + ? ? return err;
>>> +}
>>> +
>>> +static int __devexit via_cputemp_remove(struct platform_device *pdev)
>>> +{
>>> + ? ? struct via_cputemp_data *data = platform_get_drvdata(pdev);
>>> +
>>> + ? ? hwmon_device_unregister(data->hwmon_dev);
>>> + ? ? sysfs_remove_group(&pdev->dev.kobj, &via_cputemp_group);
>>> + ? ? platform_set_drvdata(pdev, NULL);
>>> + ? ? kfree(data);
>>> + ? ? return 0;
>>> +}
>>> +
>>> +static struct platform_driver via_cputemp_driver = {
>>> + ? ? .driver = {
>>> + ? ? ? ? ? ? .owner = THIS_MODULE,
>>> + ? ? ? ? ? ? .name = DRVNAME,
>>> + ? ? },
>>> + ? ? .probe = via_cputemp_probe,
>>> + ? ? .remove = __devexit_p(via_cputemp_remove),
>>> +};
>>> +
>>> +struct pdev_entry {
>>> + ? ? struct list_head list;
>>> + ? ? struct platform_device *pdev;
>>> + ? ? unsigned int cpu;
>>> +};
>>> +
>>> +static LIST_HEAD(pdev_list);
>>> +static DEFINE_MUTEX(pdev_list_mutex);
>>> +
>>> +static int __cpuinit via_cputemp_device_add(unsigned int cpu)
>>> +{
>>> + ? ? int err;
>>> + ? ? struct platform_device *pdev;
>>> + ? ? struct pdev_entry *pdev_entry;
>>> +
>>> + ? ? pdev = platform_device_alloc(DRVNAME, cpu);
>>> + ? ? if (!pdev) {
>>> + ? ? ? ? ? ? err = -ENOMEM;
>>> + ? ? ? ? ? ? printk(KERN_ERR DRVNAME ": Device allocation failed\n");
>>> + ? ? ? ? ? ? goto exit;
>>> + ? ? }
>>> +
>>> + ? ? pdev_entry = kzalloc(sizeof(struct pdev_entry), GFP_KERNEL);
>>> + ? ? if (!pdev_entry) {
>>> + ? ? ? ? ? ? err = -ENOMEM;
>>> + ? ? ? ? ? ? goto exit_device_put;
>>> + ? ? }
>>> +
>>> + ? ? err = platform_device_add(pdev);
>>> + ? ? if (err) {
>>> + ? ? ? ? ? ? printk(KERN_ERR DRVNAME ": Device addition failed (%d)\n",
>>> + ? ? ? ? ? ? ? ? ? ?err);
>>> + ? ? ? ? ? ? goto exit_device_free;
>>> + ? ? }
>>> +
>>> + ? ? pdev_entry->pdev = pdev;
>>> + ? ? pdev_entry->cpu = cpu;
>>> + ? ? mutex_lock(&pdev_list_mutex);
>>> + ? ? list_add_tail(&pdev_entry->list, &pdev_list);
>>> + ? ? mutex_unlock(&pdev_list_mutex);
>>> +
>>> + ? ? return 0;
>>> +
>>> +exit_device_free:
>>> + ? ? kfree(pdev_entry);
>>> +exit_device_put:
>>> + ? ? platform_device_put(pdev);
>>> +exit:
>>> + ? ? return err;
>>> +}
>>> +
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> +static void via_cputemp_device_remove(unsigned int cpu)
>>> +{
>>> + ? ? struct pdev_entry *p, *n;
>>> + ? ? mutex_lock(&pdev_list_mutex);
>>> + ? ? list_for_each_entry_safe(p, n, &pdev_list, list) {
>>> + ? ? ? ? ? ? if (p->cpu == cpu) {
>>> + ? ? ? ? ? ? ? ? ? ? platform_device_unregister(p->pdev);
>>> + ? ? ? ? ? ? ? ? ? ? list_del(&p->list);
>>> + ? ? ? ? ? ? ? ? ? ? kfree(p);
>>> + ? ? ? ? ? ? }
>>> + ? ? }
>>> + ? ? mutex_unlock(&pdev_list_mutex);
>>> +}
>>> +
>>> +static int __cpuinit via_cputemp_cpu_callback(struct notifier_block *nfb,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?unsigned long action, void *hcpu)
>>> +{
>>> + ? ? unsigned int cpu = (unsigned long) hcpu;
>>> +
>>> + ? ? switch (action) {
>>> + ? ? case CPU_ONLINE:
>>> + ? ? case CPU_DOWN_FAILED:
>>> + ? ? ? ? ? ? via_cputemp_device_add(cpu);
>>> + ? ? ? ? ? ? break;
>>> + ? ? case CPU_DOWN_PREPARE:
>>> + ? ? ? ? ? ? via_cputemp_device_remove(cpu);
>>> + ? ? ? ? ? ? break;
>>> + ? ? }
>>> + ? ? return NOTIFY_OK;
>>> +}
>>> +
>>> +static struct notifier_block via_cputemp_cpu_notifier __refdata = {
>>> + ? ? .notifier_call = via_cputemp_cpu_callback,
>>> +};
>>> +#endif ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* !CONFIG_HOTPLUG_CPU */
>>> +
>>> +static int __init via_cputemp_init(void)
>>> +{
>>> + ? ? int i, err = -ENODEV;
>>
>> err would be better initialized when the error occurs, for consistency.
>>
>>> + ? ? struct pdev_entry *p, *n;
>>> +
>>> + ? ? if (cpu_data(0).x86_vendor != X86_VENDOR_CENTAUR) {
>>> + ? ? ? ? ? ? printk(KERN_DEBUG "not a VIA CPU\n");
>>
>> Missing DRV_NAME.
>>
>>> + ? ? ? ? ? ? goto exit;
>>> + ? ? }
>>> +
>>> + ? ? err = platform_driver_register(&via_cputemp_driver);
>>> + ? ? if (err)
>>> + ? ? ? ? ? ? goto exit;
>>> +
>>> + ? ? for_each_online_cpu(i) {
>>> + ? ? ? ? ? ? struct cpuinfo_x86 *c = &cpu_data(i);
>>> +
>>> + ? ? ? ? ? ? if (c->x86 != 6)
>>> + ? ? ? ? ? ? ? ? ? ? continue;
>>> +
>>> + ? ? ? ? ? ? if (c->x86_model < 0x0a)
>>> + ? ? ? ? ? ? ? ? ? ? continue;
>>> +
>>> + ? ? ? ? ? ? if (c->x86_model > 0x0f) {
>>> + ? ? ? ? ? ? ? ? ? ? printk(KERN_WARNING DRVNAME ": Unknown CPU "
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? "model %x\n", c->x86_model);
>>
>> Please use 0x%x for clarity.
>>
>>> + ? ? ? ? ? ? ? ? ? ? continue;
>>> + ? ? ? ? ? ? }
>>> +
>>> + ? ? ? ? ? ? err = via_cputemp_device_add(i);
>>> + ? ? ? ? ? ? if (err)
>>> + ? ? ? ? ? ? ? ? ? ? goto exit_devices_unreg;
>>> + ? ? }
>>> + ? ? if (list_empty(&pdev_list)) {
>>> + ? ? ? ? ? ? err = -ENODEV;
>>> + ? ? ? ? ? ? goto exit_driver_unreg;
>>> + ? ? }
>>> +
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> + ? ? register_hotcpu_notifier(&via_cputemp_cpu_notifier);
>>> +#endif
>>> + ? ? return 0;
>>> +
>>> +exit_devices_unreg:
>>> + ? ? mutex_lock(&pdev_list_mutex);
>>> + ? ? list_for_each_entry_safe(p, n, &pdev_list, list) {
>>> + ? ? ? ? ? ? platform_device_unregister(p->pdev);
>>> + ? ? ? ? ? ? list_del(&p->list);
>>> + ? ? ? ? ? ? kfree(p);
>>> + ? ? }
>>> + ? ? mutex_unlock(&pdev_list_mutex);
>>> +exit_driver_unreg:
>>> + ? ? platform_driver_unregister(&via_cputemp_driver);
>>> +exit:
>>> + ? ? return err;
>>> +}
>>> +
>>> +static void __exit via_cputemp_exit(void)
>>> +{
>>> + ? ? struct pdev_entry *p, *n;
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> + ? ? unregister_hotcpu_notifier(&via_cputemp_cpu_notifier);
>>> +#endif
>>> + ? ? mutex_lock(&pdev_list_mutex);
>>> + ? ? list_for_each_entry_safe(p, n, &pdev_list, list) {
>>> + ? ? ? ? ? ? platform_device_unregister(p->pdev);
>>> + ? ? ? ? ? ? list_del(&p->list);
>>> + ? ? ? ? ? ? kfree(p);
>>> + ? ? }
>>> + ? ? mutex_unlock(&pdev_list_mutex);
>>> + ? ? platform_driver_unregister(&via_cputemp_driver);
>>> +}
>>> +
>>> +MODULE_AUTHOR("Harald Welte <HaraldWelte at viatech.com>");
>>> +MODULE_DESCRIPTION("VIA CPU temperature monitor");
>>> +MODULE_LICENSE("GPL");
>>> +
>>> +module_init(via_cputemp_init)
>>> +module_exit(via_cputemp_exit)
>>
>> The rest looks OK.
>>
>> --
>> Jean Delvare
>>
>



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux