All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH 3/3] hwmon: (i5500_temp) Don't bind to disabled sensors
Date: Wed, 22 Oct 2014 22:53:35 +0000	[thread overview]
Message-ID: <20141022225335.GA20733@roeck-us.net> (raw)
In-Reply-To: <20141022111321.22ab7122@endymion.delvare>

Hi Romain,

On Wed, Oct 22, 2014 at 07:54:49PM +0200, Romain Dolbeau wrote:
> 2014-10-22 18:26 GMT+02:00 Guenter Roeck <linux@roeck-us.net>:
> > Is there really no other register you can use to detect if the sensor is enabled ?
> > How about the TSTIMER register ?
> 
> As far as I can tell (but I'm not an expert), all the documented
> registers display "sane" values, so it's hard to tell apart working

Too bad. I thought that maybe the TSTIMER would have its poweron
value of 0, though the datasheet is a bit confusing in that regard.
It seems to state that the default value is 0 and 200,000 at the
same time.

Maybe it is as simple as VCCTS or TSIREF not connected on the
'failing' board.

Did you check for 'thermal error enable' in the GERRCTL register ?

> and non-working systems. I tried copying the whole register
> space from the working to the non-working system, and it didn't
> help one bit. Seems there's some undocumented initialization
> missing (or the sensor is just not there).
> 
> So among the possibilities I see
> 
> 1) Jean's solution, which I think is the best one. Simply reject
> if TSFSC=0x7F and document why.  In the odd case where a
> cold system won't load, the admin can always load it on a
> warm (literally) system (@reboot in crontab).
> 
> 2) the variability solution. perhaps a tiny bit more reliable, but
> much more complicated (and how much time does it take
> of TSFSC to react to change in TSTHRHI anyway ?)
> 
> 3) depends on some undocumented behavior, such as the
> byte @ 0xE4 seemingly containing (TSTHRTHI-TSFSC).
> 
> 4) the TSTHRCATA register is write-once, and (apparently)
> already written on the "working" system but not on the
> "non-working" system. But that's on a sample of 1 system
> of either kind, so again not very safe.
> 
> I think 1) is still the best solution, because it's simple
> and has no side-effect other than not loading in an hypothetical
> scenario unlikely to happen. 5500-based system are 3 to 4
> generations back, it's unlikely chipset temperature is going
> to be a critical factor where the driver just _must_ load :-)
> 
I thought you were suggesting solution 2) earlier ?

Thanks,
Guenter

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

  parent reply	other threads:[~2014-10-22 22:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22  9:13 [lm-sensors] [PATCH 3/3] hwmon: (i5500_temp) Don't bind to disabled sensors Jean Delvare
2014-10-22  9:25 ` Romain Dolbeau
2014-10-22 16:26 ` Guenter Roeck
2014-10-22 17:54 ` Romain Dolbeau
2014-10-22 22:53 ` Guenter Roeck [this message]
2014-10-23  4:08 ` Guenter Roeck
2014-10-23  6:01 ` Romain Dolbeau
2014-10-23  8:03 ` Jean Delvare
2014-10-23  8:17 ` Romain Dolbeau
2014-10-23  8:44 ` Jean Delvare
2014-10-23 13:15 ` Guenter Roeck
2014-10-23 13:26 ` Jean Delvare
2014-10-23 13:35 ` Romain Dolbeau
2014-10-23 13:43 ` Guenter Roeck

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=20141022225335.GA20733@roeck-us.net \
    --to=linux@roeck-us.net \
    --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.