Re: [lm-sensors] [PATCH 3/3] Print the status of fault register at

["Ira W. Snyder" <iws@ovro.caltech.edu>]

On Thu, Nov 18, 2010 at 11:50:35AM -0500, Richard Retanubun wrote:
> On 11/18/10 11:22, Ira W. Snyder wrote:
> > On Thu, Nov 18, 2010 at 10:16:27AM -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, dump the contents
> >> of the fault register so that other tools can use it as a forensic
> >> marker to differentiate events that preceeds this boot.
> >> ---
> >> Hi Ira and Jean,
> >>
> >> Not sure if there is a mailing list for hwmon, I did not see it,
> >> the MAINTAINERS file did not help, but git history shows that you two
> >> are the people who are working on this driver in the patch.
> >>
> Hi Ira,
> 
> Thanks for the speedy reply.
> 
> >
> > The mailing list you wanted was lm-sensors@lm-sensors.org.
> Thanks, was not sure, cc-ed now.
> >
> > As for the patch, I think it would be more likely to be accepted with a few changes:
> > - only print the register if certain bits are set
> > - don't print the hex value, print something meaningful
> Sure, but which bits? almost all of them means something to someone depending on how the chip is used.
> This is why I opted to a more "interpretation-neutral" hex-value.
> 
> I also chose "FReg" because some tools may catch the word "Fault" and flag this dump as something scary :)
> 
> I can do basic bit to string mapping using the register names,
> something like (GPIO3, GPIO2, FET, EN, PwrBad, OverCurrent, UnderVoltage, OverVoltage)
> in the case where all the bits are set, is this what you have in mind?
> 
> Also, another feedback I got was to not only print this at device_probe, but also
> save the initial value and display it as a device attribute exposed via sysfs,
> do you have any comments on this approach?
> 
> Btw, in your commit, you cleared the bits because of spurious bits being set at boot,
> does this observation pertain only to the [Over|Under][Current|Voltage] bits
> or does other bits also tends to be spurious? just curious.
> 

I just booted a board and checked: I only saw the "Undervoltage fault
occurred" bit set (the register value was 0x02).

The LTC4215_FAULT register isn't used by the Linux driver at all. How
about doing this instead:

Change the ltc4215_probe() routine to do a read-modify-write of the
LTC4215_FAULT register, like this:

s32 val;
val = i2c_smbus_read_byte_data(client, LTC4215_FAULT);
val &= 0xf0; /* clear spurious power-on faults */
i2c_smbus_write_byte_data(client, LTC4215_FAULT, val);

Since the ltc4215 driver doesn't use the LTC4215_FAULT register at all,
you can use userspace to read the value. Like this:
$ i2cget -f -y 0x0 0x44 3 b
0x00

Of course, you can do this with C code rather than using i2cget: look at
the i2cget source for an example. :)

Ira

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