From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stewart Smith Subject: Re: [PATCH 2/2] leds/powernv: Add driver for PowerNV platform Date: Thu, 19 Mar 2015 14:35:32 -0700 Message-ID: References: <20150308110558.3759.72635.stgit@localhost.localdomain> <20150308111435.3759.75840.stgit@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from e37.co.us.ibm.com ([32.97.110.158]:38943 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734AbbCTCx0 (ORCPT ); Thu, 19 Mar 2015 22:53:26 -0400 Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 19 Mar 2015 20:53:25 -0600 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 2950D3E4003F for ; Thu, 19 Mar 2015 20:53:23 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2K2rDFp34603150 for ; Thu, 19 Mar 2015 19:53:13 -0700 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2K2rLHf026818 for ; Thu, 19 Mar 2015 20:53:22 -0600 In-Reply-To: <20150308111435.3759.75840.stgit@localhost.localdomain> Sender: linux-leds-owner@vger.kernel.org List-Id: linux-leds@vger.kernel.org To: Vasant Hegde , linuxppc-dev@lists.ozlabs.org, linux-leds@vger.kernel.org Cc: cooloney@gmail.com, rpurdie@rpsys.net, khandual@linux.vnet.ibm.com Vasant Hegde writes: > From: Anshuman Khandual > > This patch implements LED driver for PowerNV platform using the existing > generic LED class framework. It registers classdev structures for all > individual LEDs detected on the system through LED specific device tree > nodes. Device tree nodes specify what all kind of LEDs present on the > same location code. It registers LED classdev structure for each of them. > > The platform level implementation of LED get and set state has been > achieved through OPAL calls. These calls are made available for the > driver by exporting from architecture specific codes. > > As per the LED class framework, the 'brightness_set' function should not > sleep. Hence these functions have been implemented through global work > queue tasks which might sleep on OPAL async call completion. > > All the system LEDs can be found in the same regular path /sys/class/leds/. > There are two different kind of LEDs present for the same location code, > one being the identify indicator and other one being the fault indicator. > We don't use LED colors. Hence our LEDs have names in this format. > > : > > Any positive brightness value would turn on the LED and a zero value > would turn off the LED. The driver will return LED_FULL (255) for any > turned on LED and LED_OFF for any turned off LED. > > Signed-off-by: Anshuman Khandual > Signed-off-by: Vasant Hegde Acked-by: Stewart Smith Tested-by: Stewart Smith (well, it boots, interacts with firmware. I didn't go and look at the LEDs themselves).