lkml.org 
[lkml]   [2019]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Should regulator core support parsing OF based fwnode?
    From
    Date

    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

    \
     
     \ /
      Last update: 2019-10-04 15:34    [W:3.169 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site