public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jean Delvare" <khali@linux-fr.org>
To: adobriyan@mail.ru, aurelien@aurel32.net
Cc: "Greg KH" <greg@kroah.com>, "LKML" <linux-kernel@vger.kernel.org>,
	"LM Sensors" <sensors@Stimpy.netroedge.com>
Subject: Re: [PATCH 2.6] I2C: New chip driver: sis5595
Date: Tue, 1 Feb 2005 12:49:20 +0100 (CET)	[thread overview]
Message-ID: <VJ70nUPw.1107258560.0805790.khali@localhost> (raw)
In-Reply-To: <200502011420.17466.adobriyan@mail.ru>


Hi Alexey,

> Maybe you should call sis5595_update_device() in initialization function
> and get rid of "value" field. It's sole purpose to fill "struct sis5595"
> when it's known that "last_updated" field contains crap.

I assume you meant "valid" field.

Doesn't work. If you discard the "valid" field and call the update
function at init time, you cannot be sure that the update function will
actually do something. It all depends on the jiffies value relative to
last_updated (0 at this point). This is exactly what "valid" is there
for.

An alternative is to add a parameter to the update function, that would
force the update to happen regardless of time consideration. This
doesn't really change anything though, you simply remove a structure
member and replace it with a function parameter. How does it help?

Third possibility would be to initialize "last_updated" to anything
less than jiffies-(HZ+HZ/2) at init time, so as to be sure that the next
update will occur. Is it doable? Or maybe if we initialize
"last_updated" to the max possible jiffies count, it'll have the same
effect. But is it doable?

At any rate, the exact same issue exists in every over existing hardware
monitoring driver. If we change our mind we'll do it for all drivers,
not only this new one (sis5595), so Aurelien's patch is fine with me.

Thanks,
--
Jean Delvare

  reply	other threads:[~2005-02-01 11:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-01 12:20 [PATCH 2.6] I2C: New chip driver: sis5595 Alexey Dobriyan
2005-02-01 11:49 ` Jean Delvare [this message]
2005-02-01 14:12   ` Alexey Dobriyan
2005-02-01 13:52     ` Jean Delvare
2005-02-01 14:43       ` Jean Delvare
2005-02-01 16:57       ` Alexey Dobriyan
2005-02-01 16:42         ` Jean Delvare
2005-02-01 12:14 ` Aurelien Jarno
2005-02-01 16:54   ` Greg KH
2005-02-01 17:00     ` Jean Delvare
2005-02-01 16:55   ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-01-25 22:09 Aurélien Jarno
2005-01-31 18:21 ` Greg KH
2005-02-01 10:11   ` Aurelien Jarno

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=VJ70nUPw.1107258560.0805790.khali@localhost \
    --to=khali@linux-fr.org \
    --cc=adobriyan@mail.ru \
    --cc=aurelien@aurel32.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sensors@Stimpy.netroedge.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox