From: Marco Felsch <m.felsch@pengutronix.de>
To: Mark Brown <broonie@kernel.org>
Cc: lgirdwood@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com,
fabio.estevam@nxp.com, Anson.Huang@nxp.com,
kernel@pengutronix.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: pfuze100: add optional pfuze-disable-sw binding
Date: Fri, 13 Jul 2018 10:30:39 +0200 [thread overview]
Message-ID: <20180713083039.4z3ulwtg2ekx5n23@pengutronix.de> (raw)
In-Reply-To: <20180712153121.GF10369@sirena.org.uk>
Hi Mark,
On 18-07-12 16:31, Mark Brown wrote:
> On Thu, Jul 12, 2018 at 01:02:39PM +0200, Marco Felsch wrote:
>
> > +Optional properties:
> > +- pfuze-disable-sw: Disable all unused switch regulators to save power
> > + consumption. Attention, some platforms are using the switch regulators as DDR
> > + ref or supply voltage. Mark these regulators as "regulator-always-on" to skip
> > + disabling these regulators. If not specified, the driver simualtes the
> > + disabling. This means the state of the regulator is set to 'disabled' but the
> > + driver don't disable the regulator.
>
> This is a bit of a confused way of specifying things that depends on the
> Linux implementation, and the property sounds like a double negative
> too. I'd say something like "pfuze-support-disable" and then explicitly
> say that this is a workaround for backwards compatibility.
I can't find the double negative. Anyway your binding sounds better. So
I will use yours. Should we add a vendor prefix too to be clear? I will
also add some more informations to mark it as workaround.
> I'd also recommend changing the implementation patch to just register a
> different version of the desc and ops that just doesn't have the disable
> operation so that the framework knows what's going on. While the
> current implementation works now there's the possibility that at some
> point in the future we might start relying on the disable actually
> having taken effect somehow and will get confused. There's some
> existing drivers that optimize their resume paths if they know power
> wasn't removed.
Okay I will change that too. I didn't know that there are drivers with
optimized resume paths.
Thanks for your feedback.
Regards,
Marco
next prev parent reply other threads:[~2018-07-13 8:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 11:02 [PATCH 0/2] Re-Enable support to disable switch regulators Marco Felsch
2018-07-12 11:02 ` [PATCH 1/2] dt-bindings: pfuze100: add optional pfuze-disable-sw binding Marco Felsch
2018-07-12 15:19 ` Fabio Estevam
2018-07-13 7:58 ` Marco Felsch
2018-07-12 15:31 ` Mark Brown
2018-07-13 8:30 ` Marco Felsch [this message]
2018-07-13 11:50 ` Mark Brown
2018-07-12 11:02 ` [PATCH 2/2] regulator: pfuze100: add support to en-/disable switch regulators Marco Felsch
2018-07-12 15:18 ` Fabio Estevam
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=20180713083039.4z3ulwtg2ekx5n23@pengutronix.de \
--to=m.felsch@pengutronix.de \
--cc=Anson.Huang@nxp.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=kernel@pengutronix.de \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/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).