From: Jean-Jacques Hiblot <jjhiblot@ti.com>
To: Mark Brown <broonie@kernel.org>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: 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?
Date: Fri, 4 Oct 2019 15:33:13 +0200 [thread overview]
Message-ID: <b6318ba5-e76e-dc1c-6921-a702abf6749c@ti.com> (raw)
In-Reply-To: <20191004113942.GB4866@sirena.co.uk>
On 04/10/2019 13:39, Mark Brown wrote:
> 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?
The regulator core accesses consumer->of_node to get a phandle to a
regulator's node. The trouble arises from the fact that the LED core
does not populate of_node anymore, instead it populates fwnode. This
allows the LED core to be agnostic of ACPI or OF to get the properties
of a LED.
IMO it is better to populate both of_node and fwnode in the LED core at
the moment. It has already been fixed this way for the platform driver
[0], MTD [1] and PCI-OF [2].
>
> 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.
Not all LEDs have a regulator to provide the power. The power can be
supplied by the LED controller for example.
[0] f94277af03ead0d3bf2 of/platform: Initialise dev->fwnode appropriately
[1] c176c6d7e932662668 mfd: core: Set fwnode for created devices
[2] 9b099a6c75e4ddceea PCI: OF: Initialize dev->fwnode appropriately
next prev parent reply other threads:[~2019-10-04 13:33 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 ` Should regulator core support parsing OF based fwnode? (was: Re: [PATCH v8 2/5] leds: Add of_led_get() and led_put()) Mark Brown
2019-10-04 13:33 ` Jean-Jacques Hiblot [this message]
2019-10-04 14:40 ` Should regulator core support parsing OF based fwnode? 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=b6318ba5-e76e-dc1c-6921-a702abf6749c@ti.com \
--to=jjhiblot@ti.com \
--cc=broonie@kernel.org \
--cc=daniel.thompson@linaro.org \
--cc=dmurphy@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.anaszewski@gmail.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).