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: <20220507063659.GA6968@amd>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ