From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Anderson Subject: Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings Date: Wed, 23 May 2018 08:23:22 -0700 Message-ID: References: <41d5df73ddac772551d2966e0752bb0c357b1ded.1526088081.git.collinsd@codeaurora.org> <869aad59-1cc5-28ef-1fb5-4ef846696c40@codeaurora.org> <20180523082908.GB4828@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180523082908.GB4828@sirena.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Mark Brown Cc: David Collins , Liam Girdwood , Rob Herring , Mark Rutland , linux-arm-msm@vger.kernel.org, Linux ARM , devicetree@vger.kernel.org, LKML , Rajendra Nayak , Stephen Boyd List-Id: linux-arm-msm@vger.kernel.org Hi, On Wed, May 23, 2018 at 1:29 AM, Mark Brown wrote: > It's arguable either way - you could say that the client gets to specify > a safe range at all times or you could say that the machine constraints > should cover all cases where the hardware is idling. Of course RPMh > is missing anything like the machine constraints (as we can see from all > the fixing up of undesirable hard coding we have to do) so it's kind of > pushed towards the first case. OK, fair enough. If others all agree that it's OK to make requests about the voltage of a disabled regulator then I won't stand in the way. I guess it does call into question the whole idea of caching / not sending the voltage until the first enable because it means there's no way for the client to use this feature until they've enabled / disabled the regulator once. If you think of it as invalid to adjust the voltage of a disabled regulator then the caching argument is super clean, but once you say that you should normally be able to do it it feels more like a hacky workaround. ...but I suppose that's what we've got to live with... -Doug