linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: stewart@linux.vnet.ibm.com, j.anaszewski81@gmail.com,
	cooloney@gmail.com, rpurdie@rpsys.net,
	linuxppc-dev@lists.ozlabs.org, linux-leds@vger.kernel.org,
	khandual@linux.vnet.ibm.com
Subject: Re: [PATCH v4 3/3] leds/powernv: Add driver for PowerNV platform
Date: Fri, 26 Jun 2015 10:47:02 +0530	[thread overview]
Message-ID: <558CE04E.6070306@linux.vnet.ibm.com> (raw)
In-Reply-To: <1435194598.3790.32.camel@kernel.crashing.org>

On 06/25/2015 06:39 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2015-04-28 at 15:40 +0530, Vasant Hegde wrote:
> 
>> +Device Tree binding for LEDs on IBM Power Systems
>> +-------------------------------------------------
>> +
>> +The 'led' node under '/ibm,opal' lists service indicators available in the
>> +system and their capabilities.
>> +
>> +led {
>> +	compatible = "ibm,opal-v3-led";
>> +	phandle = <0x1000006b>;
>> +	linux,phandle = <0x1000006b>;
>> +	led-mode = "lightpath";
>> +
>> +	U78C9.001.RST0027-P1-C1 {
>> +		led-types = "identify", "fault";
>> +		led-loc = "descendent";
>> +		phandle = <0x1000006f>;
>> +		linux,phandle = <0x1000006f>;
>> +	};
>> +	...
>> +	...
>> +};

Ben,

> 
> My only issue is that /led should probably have been /leds but afaik
> this is already committed in the FW tree. Vasant, have we done a release
> what that code yet or can we still change this ?

I think we can change OPAL side as we haven't released kernel code... So no
consumer yet.
Will send a patch to skiboot mailing list. lets see

> 
> Also what does led-mode = "lightpath" means ? Can you describe it ?
> Are there alternative values ? I don't see the point myself ...

Yes.. Our system can work in two modes...
   - light path --> Both identify and faults are supported
     typically all low end servers are in this mode
  - guiding light -> Only identify LEDs are supports . no fault indicator
support for individual FRU
     typically high end servers are in this mode.

These modes are static in nature.. meaning we cannot change that during run time...
AFAIK all the PowerNV boxes shipped today are in Light Path mode.. I have added
this, so that in future if they decide to ship system with guiding light mode,
then we don't need to make any changes.


> 
> Don't leave the "linux,phandle" in the description of the binding (nor
> the phandle actually). They are implicit for all nodes, no need to
> clutter the documentation with them.

Sure. Will fix in next version.


> 
>> +Each node under 'led' node describes location code of FRU/Enclosure.
>> +
>> +The properties under each node:
>> +
>> +  led-types : Supported LED types (attention/identify/fault).
>> +
>> +  led-loc   : enclosure/descendent(FRU) location code.
> 
> I don't understand what that means. Please provide a more detailed
> explanation.
> 

This describes the LED location (FRU or enclosure level).. This was added to
identify the component (as FRU leds are overloaded and enclosure level we have
separate LEDs for each component)...


> Is the name of the node the loc code of the FRU ? In that case, how do
> you deal with multiple LEDs on the same FRU without a unit address ?

We use location code + LED type for node. So that we can identify multiple LEDs.

Looking back again, probably we can take out above property as we are not using
that today.

-Vasant

  reply	other threads:[~2015-06-26  5:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 10:09 [PATCH v4 0/3] LED interface for PowerNV platform Vasant Hegde
2015-04-28 10:09 ` [PATCH v4 1/3] powerpc/powernv: Add OPAL interfaces for accessing and modifying system LED states Vasant Hegde
2015-06-25  1:04   ` Benjamin Herrenschmidt
2015-04-28 10:10 ` [PATCH v4 2/3] powerpc/powernv: Create LED platform device Vasant Hegde
2015-06-25  1:05   ` Benjamin Herrenschmidt
2015-04-28 10:10 ` [PATCH v4 3/3] leds/powernv: Add driver for PowerNV platform Vasant Hegde
2015-04-28 10:18   ` Arnd Bergmann
2015-04-30 15:04     ` Vasant Hegde
2015-04-30 14:29   ` Jacek Anaszewski
2015-04-30 15:08     ` Vasant Hegde
2015-06-25  1:09   ` Benjamin Herrenschmidt
2015-06-26  5:17     ` Vasant Hegde [this message]
2015-06-11  6:33 ` [PATCH v4 0/3] LED interface " Vasant Hegde
2015-06-22  8:03   ` Jacek Anaszewski

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=558CE04E.6070306@linux.vnet.ibm.com \
    --to=hegdevasant@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=cooloney@gmail.com \
    --cc=j.anaszewski81@gmail.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rpurdie@rpsys.net \
    --cc=stewart@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).