From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Furquan Shaikh <furquan@chromium.org>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Tony Lindgren <tony@atomide.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Len Brown <lenb@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hanjun Guo <hanjun.guo@linaro.org>,
Will Deacon <will.deacon@arm.com>, Rob Herring <robh@kernel.org>,
Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Adam Thomson <Adam.Thomson.Opensource@diasemi.com>,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
mark.rutland@arm.com
Subject: Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF
Date: Wed, 25 Jan 2017 12:29:55 +0000 [thread overview]
Message-ID: <20170125122955.GA4648@red-moon> (raw)
In-Reply-To: <20170125000641.25520-1-furquan@chromium.org>
[+MarkR]
On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
> Until now, the regulator framework assumed that regulators are being
> passed in using device tree(OF) only. However, with the recent change
> to add ACPI fixed regulator, it is necessary to have all the regulator
> init data and regulation constraints parsing performed for ACPI
> regulators as well. This is important to ensure that drivers can
> properly enable and disable the regulators.
>
> Since regulator properties remain the same across OF and ACPI
> regulators, this series of patches provides common routine for
> obtaining regulation constraints from device tree and ACPI nodes. In
> order to support these common routines, certain device property
> functions had to be exported to make the node parsing logic generic
> across OF and ACPI.
>
> Since the changes in this patch series are cross-system, it will
> require some amount of co-ordination to ensure that it can be applied
> at once.
The DT bindings you are enabling in ACPI through this patch series
clash with the ACPI specifications and its way of handling power
states for devices, which clearly goes against the DSD properties
rules as stated in:
Documentation/acpi/DSD-properties-rules.txt
If the current ACPI bindings (and I mean ACPI specifications not
_PRP0001) are not sufficient to allow firmware to control power
management (and the regulators control that is part of it) through
standard ACPI methods we should request changes to the specifications,
enabling regulator control with ACPI through DT bindings is just a
recipe for disaster.
What's the best course of action should and can be debated, in the
interim on the series:
NAKed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Dmitry Torokhov (3):
> ACPI / property: have acpi_get_next_subnode take fwnode_handle
> device property: introduce fwnode_for_each_child()
> device property: introduce fwnode_get_named_child_node()
>
> Furquan Shaikh (4):
> drivers/regulator: Rename of_map_mode to map_mode in regulator desc
> device property: Export dev_fwnode
> drivers/gpio: Add and export gpiod_lookup[_index]
> drivers/regulator: Initialize regulator init data for ACPI regulators
>
> drivers/acpi/property.c | 8 +-
> drivers/base/property.c | 61 ++++++++---
> drivers/gpio/gpiolib.c | 75 ++++++++++---
> drivers/regulator/Makefile | 2 +-
> drivers/regulator/fixed.c | 100 ++++++-----------
> drivers/regulator/internal.h | 3 +
> drivers/regulator/max77802-regulator.c | 12 +-
> drivers/regulator/of_regulator.c | 156 +-------------------------
> drivers/regulator/qcom_spmi-regulator.c | 2 +-
> drivers/regulator/regulator_props.c | 189 ++++++++++++++++++++++++++++++++
> drivers/regulator/twl-regulator.c | 6 +-
> drivers/regulator/twl6030-regulator.c | 2 +-
> include/linux/acpi.h | 5 +-
> include/linux/fwnode.h | 10 ++
> include/linux/gpio/consumer.h | 21 ++++
> include/linux/property.h | 1 +
> include/linux/regulator/driver.h | 5 +-
> 17 files changed, 386 insertions(+), 272 deletions(-)
> create mode 100644 drivers/regulator/regulator_props.c
>
> --
> 2.11.0.483.g087da7b7c-goog
>
next prev parent reply other threads:[~2017-01-25 12:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 0:06 [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF Furquan Shaikh
2017-01-25 0:06 ` [PATCH 1/7] drivers/regulator: Rename of_map_mode to map_mode in regulator desc Furquan Shaikh
2017-01-25 0:06 ` [PATCH 2/7] ACPI / property: have acpi_get_next_subnode take fwnode_handle Furquan Shaikh
2017-01-25 11:00 ` kbuild test robot
2017-01-25 0:06 ` [PATCH 3/7] device property: introduce fwnode_for_each_child() Furquan Shaikh
2017-01-25 0:06 ` [PATCH 4/7] device property: introduce fwnode_get_named_child_node() Furquan Shaikh
2017-01-25 0:06 ` [PATCH 5/7] device property: Export dev_fwnode Furquan Shaikh
2017-01-25 0:06 ` [PATCH 6/7] drivers/gpio: Add and export gpiod_lookup[_index] Furquan Shaikh
2017-01-25 11:18 ` kbuild test robot
2017-01-26 15:24 ` Linus Walleij
2017-01-25 0:06 ` [PATCH 7/7] drivers/regulator: Initialize regulator init data for ACPI regulators Furquan Shaikh
2017-01-25 12:29 ` Lorenzo Pieralisi [this message]
2017-01-25 12:49 ` [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF Mark Brown
2017-01-25 12:55 ` Rafael J. Wysocki
2017-01-25 16:56 ` Furquan Shaikh
2017-01-25 18:23 ` Mark Rutland
2017-01-25 18:29 ` Mark Brown
2017-01-25 18:34 ` Mark Rutland
2017-01-25 18:49 ` Mark Brown
2017-01-25 19:39 ` Mark Rutland
2017-01-25 18:44 ` Dmitry Torokhov
2017-01-25 19:27 ` Dmitry Torokhov
2017-01-25 20:39 ` Mark Brown
2017-01-25 21:17 ` Dmitry Torokhov
2017-01-25 21:30 ` Mark Brown
2017-01-25 22:05 ` Dmitry Torokhov
2017-01-25 22:25 ` Mark Brown
2017-01-25 21:44 ` Al Stone
2017-01-25 23:27 ` Dmitry Torokhov
2017-01-26 0:15 ` Al Stone
2017-01-26 0:33 ` Dmitry Torokhov
2017-01-26 10:35 ` Rafael J. Wysocki
2017-02-04 16:08 ` Mark Brown
2017-01-25 19:21 ` Lorenzo Pieralisi
2017-01-25 20:40 ` Mark Brown
2017-01-25 18:25 ` Mark Brown
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=20170125122955.GA4648@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=Adam.Thomson.Opensource@diasemi.com \
--cc=broonie@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=furquan@chromium.org \
--cc=gnurou@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hanjun.guo@linaro.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=lenb@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=sathyanarayana.nujella@intel.com \
--cc=tony@atomide.com \
--cc=will.deacon@arm.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).