Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Benjamin Bara <bbara93@gmail.com>
To:     broonie@kernel.org
Cc:     DLG-Adam.Ward.opensource@dm.renesas.com, bbara93@gmail.com,
        benjamin.bara@skidata.com, lgirdwood@gmail.com,
        linux-kernel@vger.kernel.org, mazziesaccount@gmail.com,
        support.opensource@diasemi.com
Subject: Re: [PATCH RFC 1/2] regulator: introduce regulator monitoring constraints
Date:   Thu, 20 Apr 2023 16:30:45 +0200
Message-Id: <20230420143045.541253-1-bbara93@gmail.com>
In-Reply-To: <3eb854e2-8631-4f4e-aa00-d06236967f54@sirena.org.uk>
References: <3eb854e2-8631-4f4e-aa00-d06236967f54@sirena.org.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Thanks for the feedback!

On Thu, 20 Apr 2023 at 14:17, Mark Brown <broonie@kernel.org> wrote:
> Are these constraints (ie, board specific limits) or are these more
> just properties of the regulator device?  It does feel useful to
> factor out this stuff, but it's not clear to me that these are things
> that should be configured on a per board basis.

These are actually properties of the regulator device. However, the
properties are only "active" if the voltage monitoring is wanted, which
is currently a per-board decision. Not sure if there might be reasons to
not activate it.


> These all sound like things where the regulator device is simply not
> going to support having monitoring enabled when doing the relevant
> actions no matter what situation we're in.  If that's the case we
> should just have the regulator driver set things up.

I think this would be feasible if the driver decides whether monitoring
is on or off (which might be a way to go). I think if the decision is
done per-board, it might simplify things to have the whole "should I
turn the monitor off now?" overhead not duplicated in every driver that
supports monitoring. What do you think?


> For the modes might it be clearer to mark a set of modes as not
> supporting monitoring?  I think that's the intended effect here.

Yes, that's true. I will change that.

Thanks and best regards,
Benjamin