All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] hwmon: fix common race conditions,
Date: Mon, 14 Apr 2008 14:29:56 +0000	[thread overview]
Message-ID: <48036A64.4080406@hhs.nl> (raw)
In-Reply-To: <20080406180721.GN27659@mars.solarsys.private>

Jean Delvare wrote:
> On Fri, 11 Apr 2008 09:18:24 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> I don't like the current approach either. In fact it seems that every
>>> new developer finds it odd at first, and in the end we only keep doing
>>> it because it has been so from the beginning of the lm-sensors project.
>>> The fact is that our drivers would perform much better if we did not
>>> repeatedly read from registers which aren't supposed to change. Some
>>> drivers mitigate the performance penalty by reading from these
>>> registers less frequently, but then it somewhat misses the original
>>> point of always reflecting the current register state.
>>>
>>> But on the other hand, anything that helps spot conflicts with ACPI or
>>> SMM is welcome, as these issues can be very hard to investigate - in
>>> particular for SMBus-based chips or chips with index/data pair I/O port
>>> access, where simultaneous access can result in data corruption. Thomas
>>> Renninger and myself proposed something that should help for ACPI in
>>> some cases but Linus rejected our approach. Removing the extra reads
>>> from our drivers would be one less way to spot that kind of problem. Of
>>> course we can look at the registers directly using i2cdump or isadump
>>> in most cases, but users are less likely to do that, while they usually
>>> do notice when limits change mysteriously.
>>>
>>> So all in all I have to admit that I don't really know what to do.
>>> Maybe the extra reads should be made a compilation-time or (probably
>>> better) a run-time option, so we leave the decision to the user?
>> I think given the slowness of reading these registers (esp in the i2c / smbus 
>> case) making it an option is a good idea, I think we should combine this with 
>> when this option is activated (it should be default off) actually checking if 
>> things were changed and if so complain.
>>
>> Then when we suspect faulplay by acpi/smm we can ask the user to turn on the 
>> option.
>>
>> Does that sound like a plan?
> 
> Fine with me, as long as this is a run-time option and not a build-time
> option. Rebuilding a kernel module is not an option for many users.
> 

Yes it should definitely be a runtime option, even one which can changed 
through sysfs.

So now I guess its time for everyone to start writing patches for the drivers 
they maintain to implement this. I'll start working on patches for my hwmon 
drivers as time permits (iow it may take a while, as I'm awefully busy lately).

Regards,

Hans


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

      parent reply	other threads:[~2008-04-14 14:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-06 18:07 [lm-sensors] [PATCH] hwmon: fix common race conditions, batch 2 Mark M. Hoffman
2008-04-07  5:49 ` Hans de Goede
2008-04-07 13:35 ` Jean Delvare
2008-04-07 15:13 ` Jean Delvare
2008-04-07 20:04 ` Hans de Goede
2008-04-09  9:42 ` Jean Delvare
2008-04-11  7:18 ` Hans de Goede
2008-04-11  9:29 ` [lm-sensors] [PATCH] hwmon: fix common race conditions, Jean Delvare
2008-04-14 14:29 ` 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=48036A64.4080406@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --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.