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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b15fd048-8206-4057-a354-07dc14ca15e3@redhat.com>
Date:   Sat, 16 Feb 2019 00:14:09 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>
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,

On 2/15/19 11:31 PM, Jacek Anaszewski wrote:
> On 2/15/19 11:26 PM, Hans de Goede wrote:

<snip>

>> I think that should work fine, which means that we can use the timer and
>> pattern trigger support for the blinking and breathing modes.
>>
>> That still leaves the switching between user and hw-control modes,
>> as discussed the hw-controlled mode could be modelled as a new "hardware"
>> trigger, but then we cannot choose between on/blink/breathing when
>> in hw-controlled mode. As Pavel mentioned, that would require some
>> sort of composed trigger, where we have both the hardware and
>> timer triggers active for example.
>>
>> I think it might be easier to just allow turning on/off the hardware
>> control mode through a special "hardware_control" sysfs attribute and
>> then use the existing timer and pattern triggers for blinking / breathing.
> 
> Pattern trigger exposes pattern file by default and hw_pattern if
> pattern_set/get ops are provided. Writing them enables software and
> hardware pattern respectively.

This is not about software vs hardware pattern.

There are 2 *orthogonal*, separate problems/challenges with this LED controller:

1) It has hardware blinking and breathing, as discussed this can be
controlled through the timer and pattern triggers, so this problem
is solved.

2) It has 2 operating modes:

a) Automatic/hardware controlled, in this mode the LED is turned
off or on (where on can be continues on, blinking or breathing)
by the hardware itself, when in this mode we / userspace is not
in control of the LED

b) Manual/user controlled mode, in this mode we / userspace can
control of the LED.

Currently there is no API in the ledclass to switch a LED from
automatic controlled to user controlled and back, This is what
the proposed hardware trigger was for, to switch to automatic
mode. A problem with this is that we still want to be able
to chose between continues on, blinking or breathing (when on),
configure the max brightness, etc.

Since there cannot be more then 1 trigger active, with the
hardware trigger solution we cannot say we want automatic
control (hardware trigger) and blinking when the automatic
mode says the LED should be on (timer trigger) as that
would mean having 2 triggers active with the hardware
trigger solution.

As such I think the switch between automatic and manual
control would be best exported through a special "hardware_control"
sysfs attribute and then use the existing timer and pattern
triggers for blinking / breathing.

Regards,

Hans