Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 11 May 2022 09:17:25 -0700
From:   Bjorn Andersson <bjorn.andersson@linaro.org>
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Thierry Reding <thierry.reding@gmail.com>,
        Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
        Lee Jones <lee.jones@linaro.org>, Luca Weiss <luca@z3ntu.xyz>,
        Doug Anderson <dianders@chromium.org>,
        Rob Herring <robh+dt@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>, linux-leds@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-pwm@vger.kernel.org,
        linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v14 2/2] leds: Add driver for Qualcomm LPG
Message-ID: <YnvhleAI5RW0ZvkV@ripper>
References: <20220303214300.59468-1-bjorn.andersson@linaro.org>
 <20220303214300.59468-2-bjorn.andersson@linaro.org>
 <20220504073009.GC8204@duo.ucw.cz>
 <YnKTAvQc6eDxTl14@ripper>
 <20220506160901.GA1199@bug>
 <YnVMcaRV86jZslhd@ripper>
 <20220507063659.GA6968@amd>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220507063659.GA6968@amd>
Precedence: bulk

On Fri 06 May 23:36 PDT 2022, Pavel Machek wrote:

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

Okay, I didn't understand that the hw_pattern needs to be a subset of
the pattern. I will prepare a patch to require the pattern to include
the zero-time entries as well.

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

I'll read it again and if needed I'll try to clarify the expectations.

Thanks,
Bjorn