linux-kernel - Re: [PATCH v14 2/2] leds: Add driver for Qualcomm LPG

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: <YnVMcaRV86jZslhd@ripper>
Date:   Fri, 6 May 2022 09:27:29 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>,
        Lee Jones <lee.jones@...aro.org>, Luca Weiss <luca@...tu.xyz>,
        Doug Anderson <dianders@...omium.org>,
        Rob Herring <robh+dt@...nel.org>,
        Jonathan Corbet <corbet@....net>, linux-leds@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-pwm@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v14 2/2] leds: Add driver for Qualcomm LPG

On Fri 06 May 09:09 PDT 2022, Pavel Machek wrote:

> Hi!
> 
> > > > +    "255 500 0 500"
> > > > +
> > > > +        ^
> > > > +        |
> > > > +    255 +----+    +----+
> > > > +        |    |    |    |      ...
> > > > +      0 |    +----+    +----
> > > > +        +---------------------->
> > > > +        0    5   10   15     time (100ms)
> > > > +
> > > > +The LPG supports specifying a longer hold-time for the first and last element
> > > > +in the pattern, the so called "low pause" and "high pause".
> > > 
> > > Please see
> > > Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt . This
> > > should really be compatible.
> > 
> > Unfortunately the LPG hardware only supports fixed duration (except for
> > the ability to hold/extend the first and last duration in the pattern)
> > and it also does not support gradual transition between the brightness
> > levels.
> 
> Ok.
> 
> > As such the pattern sequence provided to hw_pattern looks to be the
> > smae, but I don't see that it can be made compatible.
> > 
> > > Can I get either patch to disable pattern infrastructure for now or to
> > > get it compatible?
> > > 
> > 
> > I'd be happy to get this updated to your liking, but this was one of the
> > drivers we discussed when we introduced the pattern trigger and led to
> > the conclusion that we need the ability to do hw-specific patterns.
> > 
> > As such this document provides the hardware specific documentation, as
> > we describe under "hw_pattern" in
> > Documentation/ABI/testing/sysfs-class-led-trigger-pattern.
> > 
> > Please advice on what you would like me to do.
> 
> I'd like you to use same format leds-trigger-pattern describes.
> 
> If someone passes "255 500 0 500", that's requesting gradual transitions and
> your hw can not do that. You return -EINVAL.
> 
> If someone wants that kind of blinking, they need to pass "255 0 255 500 0 0 0 500".
> 

So the section under hw_pattern in sysfs-class-led-trigger-pattern that
says:

"Since different LED hardware can have different semantics of
hardware patterns, each driver is expected to provide its own
description for the hardware patterns in their documentation
file at Documentation/leds/."

That doesn't apply to this piece of hardware & driver?


Or is the sysfs documentation simply not reflecting what has been
decided of how this interface should look like?

Regards,
Bjorn