Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators
 without constraints
To:     Mark Brown <broonie@kernel.org>
Cc:     linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        Dmitry Osipenko <digetx@gmail.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Lucas Stach <l.stach@pengutronix.de>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        Viresh Kumar <viresh.kumar@linaro.org>, peron.clem@gmail.com,
        Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Rafael Wysocki <rjw@rjwysocki.net>,
        linux-samsung-soc@vger.kernel.org,
        Chanwoo Choi <cw00.choi@samsung.com>,
        Saravana Kannan <saravanak@google.com>
From:   Marek Szyprowski <m.szyprowski@samsung.com>
Message-ID: <2f0e021d-387a-4693-882d-aba66e20dd2b@samsung.com>
Date:   Fri, 5 Jun 2020 15:37:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
        Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20200605102018.GA5413@sirena.org.uk>
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <CGME20200605063729eucas1p288dd9d3acdb62cc86745cb6af5c31fc6@eucas1p2.samsung.com>
        <20200605063724.9030-1-m.szyprowski@samsung.com>
        <20200605102018.GA5413@sirena.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Mark,

On 05.06.2020 12:20, Mark Brown wrote:
> On Fri, Jun 05, 2020 at 08:37:24AM +0200, Marek Szyprowski wrote:
>
>> Balancing of the 'boot-on' coupled regulators must wait until the clients
>> set their constraints, otherwise the balancing code might change the
> No, this is not what boot-on means at all.  It is there for cases where
> we can't read the enable status from the hardware.  Trying to infer
> *anything* about the runtime behaviour from it being present or absent
> is very badly broken.

Okay, what about the 'always-on' property? I don't think that we need 
another property for annotating this behavior, as in my opinion this is 
just an implementation issue on the Linux kernel and regulator 
framework. Alternatively I can drop the property check, but then it 
won't be possible to have a regulator without a consumer, which follows 
the other one (although we still don't have a real use case for it).

If you don't like this idea at all, I will try to move this logic to the 
custom coupler again, although it would mean some code copying.

> Saravana (CCed) was working on some patches which tried to deal with
> some stuff around this for enables using the sync_state() callback.
> Unfortunately there's quite a few problems with the current approach
> (the biggest one from my point of view being that it's implemented so
> that it requires every single consumer of every device on the PMIC to
> come up but there's others at more of an implementation level).
I'm not sure if we really need such complex solution for this...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland