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]

Date:   Fri, 28 May 2021 22:34:10 +0200
From:   Pavel Machek <pavel@....cz>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
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

Hi!

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

git@...olite.kernel.org:pub/scm/linux/kernel/git/pavel/linux-leds.git
for-next would do the trick.

As would linux-next, I guess. This area should not be changing.

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

The drivers are independend, I guess. But I'm also very sure you will
not find some of the chips in a ACPI based machine. el15203000 is such
example.

I don't want people configuring for normal PCs to be asked if they
want el15203000 support.

If you know particular chip is present in ACPI-based machine, I'm okay
with removing the dependency.

(Maybe some of these chould depend on ARM || COMPILE_TEST instead?)

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

Well. I'm not sure that is good step forward. It will result in
useless questions being asked.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

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