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;
MIME-Version: 1.0
References: <20220722081146.47262-1-jjhiblot@traphandler.com>
 <20220722081146.47262-3-jjhiblot@traphandler.com> <CAHp75Vdu-EJRRxkK7+TfuE=zEDkJye1QCXSB+cDLrqxuykJjkA@mail.gmail.com>
 <5ba34982-52c7-e41a-fba8-d88d93529e47@traphandler.com> <20220804210412.GA30210@duo.ucw.cz>
 <0663c616-97c8-444c-f390-275fae402453@traphandler.com> <CAHp75Vf1cT81cx38VQ80PbyG9i9xbiegMnQoMWwZEZf+7fWJuQ@mail.gmail.com>
 <5bb9955e-4c2f-ca55-0e77-c082a868371a@traphandler.com> <CAHp75Vc5g0OL6YUY2WsUZA6bovB+sdJE3Bv3SWp-1pRh3kyiow@mail.gmail.com>
In-Reply-To: <CAHp75Vc5g0OL6YUY2WsUZA6bovB+sdJE3Bv3SWp-1pRh3kyiow@mail.gmail.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Fri, 26 Aug 2022 11:11:01 +0200
Message-ID: <CACRpkdYs03HhXNwx3BmzrvNx6biGc1FPEUE2eoc9XZ-9O5M4Rg@mail.gmail.com>
Subject: Re: [RESEND PATCH v6 2/3] leds: Add driver for the TLC5925 LED controller
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Jean-Jacques Hiblot <jjhiblot@traphandler.com>,
        Linus Walleij <linusw@kernel.org>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Linux LED Subsystem <linux-leds@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Aug 24, 2022 at 12:19 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:

> > >> I don't know if this is enough to make a dedicated TLC5925 driver
> > >> desirable in the kernel.
> > > I don't think you have enough justification for a new driver.

One thing to keep in mind is that LEDs are MMI (man-machine-interface)
and designed as such, so small glitches etc are fine as long as they are
not noticeable by human perception...

> After this message I first must withdraw my Rb tag, and turn my voice
> against this driver because of the above. On the contrary we might ask
> the GPIO library for a specific API to have what you do with the
> user's consent of side effects. Linus, Bart, I'm talking of the
> delayed (async) version of gpio_set_multiple(). But personally I think
> it's not so easy to implement in a bugless manner (because we need to
> synchronize it forcibly at any time we call another GPIO API against
> the same chip).

I suppose this can just be a gpio-led using the GPIO driver
underneath?

If the usecase for TLC5925 is such that it is often (as defined by
experienced developers having seen it on boards in the wild) used
as a GPIO expander rather than a pure LED driver, then it is better
to have this in the GPIO subsystem in some or other form.

If it is always just used for LEDs then my first comment about
this being MMI applies I suppose. Or rather, ask the question
from an operator point of view rather than a logic level point of
view. (I think that was Andy's point though.)

I agree that we probably need some generic library to properly handle
the jungle of funny TTL-type constructs that is popping up left and
right for GPIO. Someone should ideally sit down and think about
what is common among these.

Yours,
Linus Walleij