linux-kernel - Re: [PATCH v1 00/28] leds: cleanups and fwnode refcounting bug fixes

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: <YLDOfWuis5MvdxfJ@smile.fi.intel.com>
Date:   Fri, 28 May 2021 14:05:33 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Amireddy Mallikarjuna reddy <mallikarjunax.reddy@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Marek Behún <marek.behun@....cz>,
        Abanoub Sameh <abanoubsameh8@...il.com>,
        Dan Murphy <dmurphy@...com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 00/28] leds: cleanups and fwnode refcounting bug fixes

On Fri, May 28, 2021 at 12:02:54PM +0200, Pavel Machek wrote:
> On Mon 2021-05-17 10:30:08, Andy Shevchenko wrote:
> > On Mon, May 10, 2021 at 12:50:17PM +0300, Andy Shevchenko wrote:
> > > When analyzing the current state of affairs with fwnode reference counting
> > > I found that a lot of core doesn't take it right. Here is a bunch of
> > > corresponding fixes against LED drivers.
> > > 
> > > The series includes some cleanups and a few other fixes grouped by a driver.
> > > 
> > > First two patches are taking care of -ENOTSUPP error code too  prevent its
> > > appearance in the user space.
> > 
> > Pavel, any comments on this bug fix series?
> 
> I took these:

Thanks!

What branch/tree should I rebase the rest on?

> For the "remove depends on OF"... I'd preffer not to take those. We
> don't need to ask the user for configurations that never happen.

What do you mean by this? ACPI is quite a good configuration to make use
of it on the corresponding platforms. By default any discrete LED driver
(in hardware term here) IC should be considered independent from the type
of the platform description. Do you agree? If so, it means that dropping
OF dependency is a right thing to do to allow users of those ICs to be happy
even on ACPI based platforms.

Note, entire IIO subsystem is a good example of this activity. All the sensors
can be used now in ACPI environment without explicit requirement to have an
ACPI ID, although it's highly recommended to acquire for the real products
(not DIY ones).

-- 
With Best Regards,
Andy Shevchenko