From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935356AbcKNIb2 (ORCPT ); Mon, 14 Nov 2016 03:31:28 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:45849 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932297AbcKNIbW (ORCPT ); Mon, 14 Nov 2016 03:31:22 -0500 Date: Mon, 14 Nov 2016 09:31:18 +0100 From: Pavel Machek To: Hans de Goede Cc: Jacek Anaszewski , Tony Lindgren , Jacek Anaszewski , linux-leds@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Darren Hart Subject: Re: PM regression with LED changes in next-20161109 Message-ID: <20161114083118.GC18123@amd> References: <20161110175537.GF27724@atomide.com> <20161110202910.GE28832@amd> <80b645e7-c3fa-8001-d9b1-c3c8c40394fd@gmail.com> <20161111120114.GA1076@amd> <4c31faef-144d-289c-0e32-83e76aff6178@gmail.com> <3eb60c78-d891-27e5-6b7b-a54a5b547a1c@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB" Content-Disposition: inline In-Reply-To: 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 --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >Also, how would we read the > >brightness set by the firmware? We'd have to read brightness > >file, so still two files would have to be opened which is > >a second drawback of this approach. >=20 > No, look carefully at the definition of the read behavior > I plan to put in the ABI doc: >=20 > "Reading this file will return the actual led brightness > when not blinking and no triggers are active; reading this > file will return the brightness used when the led is on > when blinking or triggers are active." That's not sane semantics. Userspace would have to read three files (racy) to find out about triggers etc. It also prevents modelling "hardware-changes-brightness-behind-kernel's-back" as a trigger. > So for e.g. the backlit keyboard case reading this single > file will return the actual brightness of the backlight, > since this does not involve blinking or triggers. Stop obsessing about "ingle file". FDs are pretty cheap. This is sysfs. > >Having no difference in this area between the two approaches > >I'm still in favour of the read-only file for notifying > >brightness changes procured by hardware. >=20 > That brings back the needing 2 fds problem; and does Actually you have turned "2 fds" into "3 fds", as userspace now needs to check for trigger _and_ blinking _and_ actuall brightness. fds are cheap, but that is still not nice design. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlgpdlYACgkQMOfwapXb+vIkYACgtVPOC9Kr1Efm9jsfmzK5tMcY XaoAnjqyKsfaM75+aJJQlBtcf0yHjNRM =QPq+ -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB--