linux-kernel - Re: Should regulator core support parsing OF based fwnode? (was: Re: [PATCH v8 2/5] leds: Add of_led_get() and led

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, 4 Oct 2019 12:39:42 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     Jean-Jacques Hiblot <jjhiblot@...com>,
        Sebastian Reichel <sebastian.reichel@...labora.com>,
        pavel@....cz, robh+dt@...nel.org, mark.rutland@....com,
        lee.jones@...aro.org, daniel.thompson@...aro.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        tomi.valkeinen@...com, dmurphy@...com, linux-leds@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.com>
Subject: Re: Should regulator core support parsing OF based fwnode? (was: Re:
 [PATCH v8 2/5] leds: Add of_led_get() and led_put())

On Thu, Oct 03, 2019 at 10:27:26PM +0200, Jacek Anaszewski wrote:
> On 10/3/19 9:41 PM, Mark Brown wrote:

> > Why would we want to do that?  We'd continue to support only DT systems,
> > just with code that's less obviously DT only and would need to put
> > checks in.  I'm not seeing an upside here.

> For instance few weeks ago we had a patch [0] in the LED core switching
> from using struct device's of_node property to fwnode for conveying
> device property data. And this transition to fwnode property API can be
> observed as a frequent pattern across subsystems.

For most subsystems the intent is to reuse DT bindings on embedded ACPI
systems via _DSD.

> Recently there is an ongoing effort aiming to add generic support for
> handling regulators in the LED core [1], but it turns out to require
> bringing back initialization of of_node property for
> devm_regulator_get_optional() to work properly.

Consumers should just be able to request a regulator without having to
worry about how that's being provided - they should have no knowledge at
all of firmware bindings or platform data for defining this.  If they
do that suggests there's an abstraction issue somewhere, what makes you
think that doing something with of_node is required?

Further, unless you have LEDs that work without power you probably
shouldn't be using _get_optional() for their supply.  That interface is
intended only for supplies that may be physically absent.

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