linux-kernel - Re: [PATCH 1/2] leds: Add flag to keep trigger always

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: <20190930172743.GA2409822@kroah.com>
Date:   Mon, 30 Sep 2019 19:27:43 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Pavel Machek <pavel@...x.de>,
        Guru Das Srinagesh <gurus@...eaurora.org>
Cc:     linux-leds@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Dan Murphy <dmurphy@...com>, linux-kernel@...r.kernel.org,
        Subbaraman Narayanamurthy <subbaram@...eaurora.org>
Subject: Re: [PATCH 1/2] leds: Add flag to keep trigger always

On Mon, Sep 30, 2019 at 07:22:39PM +0200, Pavel Machek wrote:
> On Mon 2019-09-30 15:39:02, Greg KH wrote:
> > On Sat, Aug 10, 2019 at 09:13:22AM +0200, Pavel Machek wrote:
> > > On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
> > > > From: Subbaraman Narayanamurthy <subbaram@...eaurora.org>
> > > > 
> > > > Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers
> > > > on brightness set") removes the trigger on an LED class device when
> > > > brightness is set to 0. However, there are some LED class devices which
> > > > need the trigger not to be removed. In a use case like camera flash,
> > > > camera flash driver passes in a trigger device to LED class driver. If
> > > > the trigger is removed when the brightness is set to 0, this will affect
> > > > the clients using those triggers. Hence add a flag to always keep the
> > > > trigger even when brightness is set to 0.
> > > 
> > > No.
> > > 
> > > Yes, it would affect those clients. Don't do it, then. It is
> > > root-only operation.
> > 
> > I don't understand.  The original commit broke userspace operations.
> > Shouldn't it be reverted, or fixed this way in order to have userspace
> > work properly again?
> 
> So, what it is exactly that is not working? :-). Yes, root can
> disconnect LED from v4l2 interface; he can also connect it
> back. Documentation says that happens.
> 
> Yes, root can do stupid things.
> 
> Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd
> prefer we did not apply it in 2008, but...

Ah, my fault, I thought this was a new commit.

Guru, what are you doing here that this is required all of a sudden?  No
other kernel seems to need these changes, what is different in your
Android userspace that requires this patch series?

thanks,

greg k-h