All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [RFC] [PATCH v2] ltc4215: Save the fault register
Date: Thu, 18 Nov 2010 20:31:52 +0000	[thread overview]
Message-ID: <20101118203152.GA27904@ericsson.com> (raw)
In-Reply-To: <1290110595-29227-1-git-send-email-RichardRetanubun@RuggedCom.com>

On Thu, Nov 18, 2010 at 03:03:15PM -0500, Richard Retanubun wrote:
> Some bits in the fault register can be useful to differentiate
> between a planned reset (reboot) or an unplanned reset (pwr-loss).
> The EN bit can be used for this detection when a board's planned
> reboot action toggles the EN bit and cuts the regulated voltage
> (but keeping the hotswap device alive), meanwhile an unplanned
> reset (pwr-loss) will not have the EN bit set because even the
> hotswap device got powered off.
> 
> So, before clearing the fault register at boot, save the contents
> of the fault register so that other tools can use it as a forensic
> marker to differentiate events that preceeds this boot.
> 
> One proposed method to make this information available is via
> sysfs device attributes.
> ---
> Hi Ira & Guenter,
> 
> Wow, thanks for the lively discussions, I never expected this corner
> of the kernel to be so actively monitored :)
> 
> Here is the proposed V2 of the patch, allowing the values to be
> accessed via sysfs.
> 
> Now, to answer/comment on your feeback so far:
> 
> [Guenter]
> * This violates sysfs abi: 
> Well, is this not a living document/spec? Maybe my choice of path/variable
> does not map well into the existing abi, but this is not to say it cannot be
> extended, no? (I must admit I am a bit unaware of all the rules/convention of the ABI)
> 
We don't change the sysfs ABI without good reason. Sure, it is a living document,
and I have extended it myself several times. But that doesn't mean we change it easily.

[ ... ]
> 
> So here is v2; I realize this have little hope of mainlining,
> I know its an ugly hack on the sysfs ABI, if someone have an
> idea of a better sysfs path to pick, do let me know.
> 

and the "ugly hack", as you admit yourself, makes this a NACK, without even looking
at the code.

Guenter

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

      reply	other threads:[~2010-11-18 20:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-18 20:03 [lm-sensors] [RFC] [PATCH v2] ltc4215: Save the fault register at Richard Retanubun
2010-11-18 20:31 ` Guenter Roeck [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=20101118203152.GA27904@ericsson.com \
    --to=guenter.roeck@ericsson.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.