From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757945AbcC2Ryr (ORCPT ); Tue, 29 Mar 2016 13:54:47 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:50695 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753352AbcC2Ryq (ORCPT ); Tue, 29 Mar 2016 13:54:46 -0400 Date: Tue, 29 Mar 2016 19:54:42 +0200 From: Pavel Machek To: Sebastian Reichel Cc: Tony Lindgren , =?iso-8859-1?Q?Beno=EEt?= Cousson , Aaro Koskinen , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/7] ARM: dts: Enable N950 keyboard sleep leds by default Message-ID: <20160329175442.GA28516@amd> References: <1457827580-16919-1-git-send-email-sre@kernel.org> <1457827580-16919-5-git-send-email-sre@kernel.org> <20160329105128.GA30184@amd> <20160329145209.GB31858@earth> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329145209.GB31858@earth> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2016-03-29 16:52:09, Sebastian Reichel wrote: > Hi, > > On Tue, Mar 29, 2016 at 12:51:28PM +0200, Pavel Machek wrote: > > For 1-3 in the series, Acked-by: Pavel Machek > > > > > Like the Nokia N900, the N950 has leds to show > > > the state of sys_clkreq and sys_off_mode pins. > > > > > > A detailed description for the LEDs and > > > OMAP's sleep states can be found in Tony's > > > commit for the Nokia N900: > > > > > > c1be2032f66df9e1238bd5bc4ca666de88a62abc > > > > I must say I've seen it on N900, and yes, it is useful, but no, I > > don't think this is right. > > > > This is not a LED. This is a interface that changes meaning of two > > other LEDs. I guess it should go to debugfs somewhere. > > I don't think we should diverge N900 and N950 userspace > APIs in this regard. That's a good argument. But maybe we should move both to debugfs somewhere before we get too much userspace that relies on it... > Actually the correct way would be a custom trigger > for the leds IMHO. I don't know if the led framework > supports per led custom triggers, though. Well, not even custom trigger would make this easy: AFAIK you need to enable this on two LEDs or not at all, so you'd have one trigger _that would need to be shared over two LEDs_. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html