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]

Date:   Sat, 7 May 2022 08:36:59 +0200
From:   Pavel Machek <pavel@....cz>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
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

Hi!

> > > 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?

It applies: since your hardware can not do arbitrary patterns, you
need description of what kinds of patterns it can do.

But you should still use compatible format, so that pattern that is
valid for hw_pattern file is valid for pattern file, too, and produces
same result.

If you believe documentation implies something else, it may need to be
clarified.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

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