From: Hans de Goede <hdegoede@redhat.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [RFC] Asus ATK0110 ACPI hwmon driver
Date: Tue, 06 Jan 2009 08:20:35 +0000 [thread overview]
Message-ID: <49631453.4060208@redhat.com> (raw)
In-Reply-To: <20081229205537.GA11072@dreamland.darkstar.lan>
Luca Tettamanti wrote:
> Il Mon, Jan 05, 2009 at 08:00:49PM +0100, Hans de Goede ha scritto:
>> Luca Tettamanti wrote:
>>> Il Sun, Jan 04, 2009 at 11:13:30PM +0100, Hans de Goede ha scritto:
>>>> Luca Tettamanti wrote:
>>>>> It was simpler than I thought: I implemented per-attribute caching since
>>>>> updating all the values may take a long time (here unconnected fans take
>>>>> about 0.5s); the interval between reading is 1s (due to the high latency
>>>>> of the fan sensor it probably makes little sense to lower this value).
>>>> Erm, your current code is not correct (as in will not work under all
>>>> circumstances). Your current code initializes last_updated to 0 for
>>>> all new sensors, and you do not use a valid flag (as the other hwmon
>>>> drivers do).
>>> Ah, I see... how about this:
>> Erm, sorry, but no that won't work. You've a last_updated per sensor, so
>> the valid flag needs to be per sensor too, otherwise you will just hit
>> the possible bug I described with the second sensor read.
>
> Duh, of course...
>
Looks good now :)
So once we can get the acpi_enforce_resources changed, this is good to go in to
the mainline.
I was sortof waiting for Jean Delvare to resurface from the hollidays to get
some input from him on this, but given that the 2.6.29 merge window has already
opened, I think it would be best for us to move forward with this ourselves.
Can you please mail the acpi mailinglist, proposing to make the default strict,
with explanation why?
Some notes which will be worthwhile to make in that mail:
1) I've checked all users of the affected functions and only hwmon superio IC's
and smbus controllers will be affected by this change.
2) This can cause smbus controllers / superIO drivers to not load in 2.6.29,
which could be seen as a regression by some (they would loose monitoring
ability). I consider this not a bug, but a feature, if the firmware claims the
resources we should not touch them. If they really want to live with the
dangers this brings, let them pass in a kernel cmdline option to get the old
wrong behaviour.
Please CC me on the mail :)
Thanks & Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
prev parent reply other threads:[~2009-01-06 8:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-29 20:55 [lm-sensors] [RFC] Asus ATK0110 ACPI hwmon driver Luca Tettamanti
2008-12-30 14:01 ` Gabriel C
2008-12-30 14:09 ` Luca Tettamanti
2008-12-30 14:28 ` Gabriel C
2009-01-01 22:09 ` Hans de Goede
2009-01-01 22:10 ` Hans de Goede
2009-01-04 12:32 ` Hans de Goede
2009-01-04 14:56 ` Iain Paton
2009-01-04 18:08 ` Luca Tettamanti
2009-01-04 19:14 ` Hans de Goede
2009-01-04 21:23 ` Luca Tettamanti
2009-01-04 22:13 ` Hans de Goede
2009-01-05 17:25 ` Luca Tettamanti
2009-01-05 17:26 ` Luca Tettamanti
2009-01-05 18:12 ` Iain Paton
2009-01-05 19:00 ` Hans de Goede
2009-01-05 20:10 ` Luca Tettamanti
2009-01-06 8:20 ` Hans de Goede [this message]
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=49631453.4060208@redhat.com \
--to=hdegoede@redhat.com \
--cc=lm-sensors@vger.kernel.org \
/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.