linux-kernel - Re: [PATCH 4/4] leds: lm3532: Introduce the lm3532 LED driver

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: <20190403200600.GT49658@atomide.com>
Date:   Wed, 3 Apr 2019 13:06:00 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Sebastian Reichel <sre@...nel.org>
Cc:     Dan Murphy <dmurphy@...com>, robh+dt@...nel.org,
        jacek.anaszewski@...il.com, pavel@....cz, lee.jones@...aro.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH 4/4] leds: lm3532: Introduce the lm3532 LED driver

* Sebastian Reichel <sre@...nel.org> [190329 05:36]:
> Hi,
> 
> On Mon, Mar 25, 2019 at 11:01:18AM -0500, Dan Murphy wrote:
> > On 3/25/19 9:54 AM, Tony Lindgren wrote:
> > > * Dan Murphy <dmurphy@...com> [190325 12:36]:
> > >> On 3/22/19 5:16 PM, Tony Lindgren wrote:
> > >>> I can control the backlight brightness just fine via /sys, and
> > >>> backlight shows up as the trigger in /sys/class/leds/lm3532:backlight,
> > >>> but /sys/class/backlight is empty and looks like drm can't find it.
> > >>>
> > >>> Do I need to enable some additional driver(s) to get this to work
> > >>> with the drm driver?
> > >>>
> > >>
> > >> Can you dump or point to the defconfig?
> > > 
> > > This is just with the omap2plus_defconfig as in the droid4-pending-v5.0
> > > test branch below [0]. That branch has Sebastian's drm patches. The
> > > branch also has the older ti-lmu patches that I reverted for testing
> > > before applying your new series and enabling it in .config.
> > > 
> > > The drm driver (drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c) just
> > > does:
> > > 
> > > backlight = of_parse_phandle(node, "backlight", 0);
> > > ...
> > > 
> > > That should still work the same, right?
> > 
> > Yes it should still work the same.
> > I did not change the node name.
> > So the DRM driver should find the node.
> 
> This will not work, since the next line tries to get it as a
> backlight device, but it's an LED device instead:
> 
> of_find_backlight_by_node(backlight);
> 
> I suppose the backlight device could be instantiated on top
> of the LED device somehow.

Hmm yeah I thought setting the ledtrig-backlight for it
would do the trick. But after thinking about it there might
be some backlight lifecycle issues with that where everything
would need to be torn down for the panel to change the
backlight trigger. I think the panel driver(s) assume the
backlight to always be there at probe time. Well this is
just based on just guessing.. I might be wrong.

I have no issues using of_find_backlight_by_node() like
other panels.

> (sorry for slow responses; I'm quite busy right now)

No problem.

Regards,

Tony