linux-kernel - Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC LEDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190213233806.GA11867@amd>
Date:   Thu, 14 Feb 2019 00:38:06 +0100
From:   Pavel Machek <pavel@....cz>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Yauhen Kharuzhy <jekhor@...il.com>, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH v2 1/2] leds: Add Intel Cherry Trail Whiskey Cove PMIC
 LEDs

Hi!


> >Agreed.
> >
> >>I believe it would be best to add a custom "mode" attribute
> >>to the led classdev, with "manual" and "on-when-charging"
> >>modes, this would then control bits 0-1 of reg 0x5e1f and
> >>by default these bits should be left as is when the driver
> >>loads.
> >
> >No. This is not first hardware when we have something like this, and
> >we need something generic here.
> >
> >One possibility would be magic "hardware drives this led"
> >trigger. Hmm? (Jacek disliked this idea before, but maybe we can
> >convince him).
> >
> >Generic "is this driven by hardware or not" attribute might be
> >possible, too... but its interaction with triggers/brightness/etc
> >would be confusing.
> 
> In this case the interaction is not that tricky, but it will
> likely be different per led controller, so I do not think that
> we can ever come up with a truely generic solution.
> 
> Basically the charge led has 3 states:
> 
> 1) Off
> 2) On
> 3) On when charging
> 
> And then when on it has 4 patterns:
> 
> 1) Permanently off (so still not really on)
> 2) Permanently on
> 3) Blinking
> 4) Breathing

Ok, so you don't really need to support _both_ off methods.

Still sounds like a normal LED, with special "yoga-charging" and
"yoga-breathing" triggers. (All the normal triggers should still work,
too.)

> These 4 patterns can be selected when on, independent
> of being perma-on or ondemand-on

Yeah, but we don't really want to expose that to userspace.

> >>As for the 0x5e20 settings, I believe another custom
> >>sysfs attribute, called "breathing" would be a good idea to
> >>export the breathing functionality.
> >
> >We have "pattern" trigger that can do this kind of stuff in
> >software. But I'm not sure if this is worth supporting.
> 
> The problem is that any changes made are permanent, they
> survice reboots and the default is Breathing, so we need
> a way to restore that which does not involve removing
> the internal battery of these devices.

Wow. Now that's a broken hardware.

Anyway, in such case I'd propose having rmmod/reboot/poweroff hook
that just sets it to breathing. No need to expose it to userspace.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)