From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pali =?utf-8?B?Um9ow6Fy?= Subject: Re: [PATCH v6 1/4] leds: class: Add new optional brightness_hw_changed attribute Date: Thu, 26 Jan 2017 09:33:44 +0100 Message-ID: <20170126083338.GA6085@pali> References: <20170125161130.5424-1-hdegoede@redhat.com> <20170125161130.5424-2-hdegoede@redhat.com> <20170125164936.GE7936@pali> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: platform-driver-x86-owner@vger.kernel.org To: Jacek Anaszewski Cc: Hans de Goede , Pavel Machek , Darren Hart , Henrique de Moraes Holschuh , linux-leds@vger.kernel.org, platform-driver-x86@vger.kernel.org List-Id: linux-leds@vger.kernel.org On Wednesday 25 January 2017 22:35:53 Jacek Anaszewski wrote: > On 01/25/2017 05:49 PM, Pali Rohár wrote: > > On Wednesday 25 January 2017 17:11:27 Hans de Goede wrote: > >> Some LEDs may have their brightness level changed autonomously > >> (outside of kernel control) by hardware / firmware. This commit > >> adds support for an optional brightness_hw_changed attribute to > >> signal such changes to userspace (if a driver can detect them): > >> > >> What: /sys/class/leds//brightness_hw_changed > >> Date: January 2017 > >> KernelVersion: 4.11 > >> Description: > >> Last hardware set brightness level for this LED. Some LEDs > >> may be changed autonomously by hardware/firmware. Only LEDs > >> where this happens and the driver can detect this, will > >> have this file. > >> > >> This file supports poll() to detect when the hardware > >> changes the brightness. > >> > >> Reading this file will return the last brightness level set > >> by the hardware, this may be different from the current > >> brightness. In which situation this attribute may be different? I think some information should be present in this description... > >> Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to > >> their flags field and call led_classdev_notify_brightness_hw_changed() > >> with the hardware set brightness when they detect a hardware / firmware > >> triggered brightness change. > >> > >> Signed-off-by: Hans de Goede > > > > Just speculation: What about using name 'actual_brightness'? It provides > > same output on read as actual_brightness from /sys/class/backlight/. > > This name is ambiguous. Propagating it to the LED subsystem only because > it exists in backlight is not sufficient argument IMHO. I thought that having same name could help userspace and also to have consistency between similar subsystems. But ok, that was just my speculation. I have just one small suggestion in current name "brightness_hw_changed". As it provides regular read() capability I would suggest to not indicate "activity" (changed) in name... -- Pali Rohár pali.rohar@gmail.com