linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	pavel@ucw.cz, robh+dt@kernel.org, mark.rutland@arm.com,
	lee.jones@linaro.org, daniel.thompson@linaro.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	tomi.valkeinen@ti.com, dmurphy@ti.com,
	linux-leds@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.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())
Date: Fri, 4 Oct 2019 12:39:42 +0100	[thread overview]
Message-ID: <20191004113942.GB4866@sirena.co.uk> (raw)
In-Reply-To: <a9f668f9-ad26-4e18-178a-8403b8b3b1db@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2019-10-04 11:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03  8:28 [PATCH v8 0/5] Add a generic driver for LED-based backlight Jean-Jacques Hiblot
2019-10-03  8:28 ` [PATCH v8 1/5] leds: populate the device's of_node when possible Jean-Jacques Hiblot
2019-10-04 21:08   ` Jacek Anaszewski
2019-10-03  8:28 ` [PATCH v8 2/5] leds: Add of_led_get() and led_put() Jean-Jacques Hiblot
2019-10-03 10:42   ` Sebastian Reichel
2019-10-03 12:47     ` Jean-Jacques Hiblot
2019-10-03 17:43       ` Jacek Anaszewski
2019-10-03 18:35         ` Mark Brown
2019-10-03 19:21           ` Jacek Anaszewski
2019-10-03 19:41             ` Mark Brown
2019-10-03 20:27               ` Should regulator core support parsing OF based fwnode? (was: Re: [PATCH v8 2/5] leds: Add of_led_get() and led_put()) Jacek Anaszewski
2019-10-04 10:12                 ` Should regulator core support parsing OF based fwnode? Jean-Jacques Hiblot
2019-10-04 11:39                 ` Mark Brown [this message]
2019-10-04 13:33                   ` Jean-Jacques Hiblot
2019-10-04 14:40                     ` Mark Brown
2019-10-04 15:13                       ` Jean-Jacques Hiblot
2019-10-04 15:58                         ` Mark Brown
2019-10-04 16:12                           ` Jean-Jacques Hiblot
2019-10-04 17:42                             ` Mark Brown
2019-10-04 20:55                               ` Jacek Anaszewski
2019-10-03  8:28 ` [PATCH v8 3/5] leds: Add managed API to get a LED from a device driver Jean-Jacques Hiblot
2019-10-03 10:47   ` Sebastian Reichel
2019-10-03  8:28 ` [PATCH v8 4/5] dt-bindings: backlight: Add led-backlight binding Jean-Jacques Hiblot
2019-10-03 11:17   ` Sebastian Reichel
2019-10-03  8:28 ` [PATCH v8 5/5] backlight: add led-backlight driver Jean-Jacques Hiblot
2019-10-03 11:47   ` Sebastian Reichel
2019-10-03 17:23     ` Jean-Jacques Hiblot
2019-10-03 11:40 ` [PATCH v8 0/5] Add a generic driver for LED-based backlight Lee Jones
2019-10-08 19:55   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191004113942.GB4866@sirena.co.uk \
    --to=broonie@kernel.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dmurphy@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=jjhiblot@ti.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).