All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eddie James <eajames@linux.vnet.ibm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, joel@jms.id.au, andrew@aj.id.au,
	jk@ozlabs.org, cbostic@linux.vnet.ibm.com,
	"Edward A. James" <eajames@us.ibm.com>
Subject: Re: [RFC 0/3] drivers/hwmon/pmbus: Use STATUS_WORD and add status sensors
Date: Tue, 8 Aug 2017 11:12:19 -0500	[thread overview]
Message-ID: <9b62b070-28ed-3de6-41f2-6910555bbc4d@linux.vnet.ibm.com> (raw)
In-Reply-To: <7484a66c-4f3c-5d76-7c8a-5992d2c1d3ea@roeck-us.net>



On 08/07/2017 11:00 PM, Guenter Roeck wrote:
> On 08/07/2017 08:25 PM, Eddie James wrote:
>> From: "Edward A. James" <eajames@us.ibm.com>
>>
>> Hi Guenter,
>>
>> I'm looking for some feedback for some extensions to the pmbus core. 
>> We're
>> looking for some additional functionality, particularly with 
>> STATUS_WORD and
>> obtaining raw status data.
>>
>> The first two patches enable the use of the STATUS_WORD register in 
>> the pmbus
>> core. This allows the use of more default alarm/fault attributes for 
>> default
>> pmbus sensors by allowing the use of the higher byte status bits.
>>
>> The third patch adds "status" attributes to each class of hwmon 
>> sensor created
>> by pmbus. For example, in1_status and temp1_status. These will 
>> display the
>> associated raw status register (e.g. STATUS_INPUT and 
>> STATUS_TEMPERATURE). I
>> realize this is not really "normal" for hwmon or pmbus. These are 
>> potentially
>> very useful in hardware diagnostic situations where it might be 
>> impossible
>> to tell the origin of a failure from a simple alarm or fault bit set. 
>> We really
>> want to access the status registers, and for a multi-page pmbus 
>> device, this is
>> pretty tricky from userspace.
>>
>> Please let me know your thoughts,
>> Thanks,
>
> I don't mind providing such data with debugfs, for example, but I 
> don't see
> the point in providing it as part of the ABI. Which, in part, since it 
> requires
> a lot of thought on my side, is part of the reason why I didn't provide
> feedback to your earlier patches yet. Sorry, I've been exceptionally busy
> lately, and non-standard requests tend to end up at the end of the 
> queue :-(.

No problem! Thanks for the quick response on this.

>
> Any reason why debugfs is not sufficient and/or acceptable for your 
> use case ?
> You _are_ talking about diagnostic situations, which seems to be an 
> exact fit
> for debugfs.

Agreed, great idea, I think debugfs will work perfectly. I probably 
should have thought of that sooner...

How about the first two patches in the series? They are unrelated to 
adding any attributes. Mainly I would
like to have the PB_STATUS_INPUT bit available to trigger the default 
boolean alarm attribute, as our hardware doesn't support any limits.

Thanks again,
Eddie

>
> Guenter
>
>>
>> Edward A. James (3):
>>    drivers/hwmon/pmbus: Access word data for STATUS_WORD and use it by
>>      default
>>    drivers/hmwon/pmbus: store STATUS_WORD in status registers
>>    drivers/hwmon/pmbus: Add sensor status to pmbus attributes
>>
>>   drivers/hwmon/pmbus/pmbus_core.c | 153 
>> +++++++++++++++++++++++++++++++++------
>>   1 file changed, 130 insertions(+), 23 deletions(-)
>>
>

  reply	other threads:[~2017-08-08 16:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08  3:25 [RFC 0/3] drivers/hwmon/pmbus: Use STATUS_WORD and add status sensors Eddie James
2017-08-08  3:25 ` [RFC 1/3] drivers/hwmon/pmbus: Access word data for STATUS_WORD and use it by default Eddie James
2017-08-09  1:51   ` [RFC, " Guenter Roeck
2017-08-08  3:25 ` [RFC 2/3] drivers/hmwon/pmbus: store STATUS_WORD in status registers Eddie James
2017-08-09  1:58   ` [RFC,2/3] " Guenter Roeck
2017-08-08  3:25 ` [RFC 3/3] drivers/hwmon/pmbus: Add sensor status to pmbus attributes Eddie James
2017-08-09  2:00   ` [RFC,3/3] " Guenter Roeck
2017-08-08  4:00 ` [RFC 0/3] drivers/hwmon/pmbus: Use STATUS_WORD and add status sensors Guenter Roeck
2017-08-08 16:12   ` Eddie James [this message]
2017-08-08 19:26     ` Christopher Bostic
2017-08-08 20:25       ` Guenter Roeck
2017-08-09  1:51     ` 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=9b62b070-28ed-3de6-41f2-6910555bbc4d@linux.vnet.ibm.com \
    --to=eajames@linux.vnet.ibm.com \
    --cc=andrew@aj.id.au \
    --cc=cbostic@linux.vnet.ibm.com \
    --cc=eajames@us.ibm.com \
    --cc=jk@ozlabs.org \
    --cc=joel@jms.id.au \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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.