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;
Message-ID: <2aa65957-61d5-8e06-5a50-a4750f6dd44b@linaro.org>
Date:   Mon, 17 Jul 2023 09:36:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH 1/7] dt-bindings: soc: qcom: Add qcom-pbs bindings
Content-Language: en-US
To:     Anjelique Melendez <quic_amelende@quicinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc:     Rob Herring <robh@kernel.org>, pavel@ucw.cz, lee@kernel.org,
        thierry.reding@gmail.com, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org, agross@kernel.org, andersson@kernel.org,
        konrad.dybcio@linaro.org, u.kleine-koenig@pengutronix.de,
        linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        linux-pwm@vger.kernel.org
References: <20230621185949.2068-1-quic_amelende@quicinc.com>
 <20230621185949.2068-2-quic_amelende@quicinc.com>
 <20230626135857.GA3118929-robh@kernel.org>
 <2e871e21-a81d-0d7d-993b-9a9d7bd9d962@quicinc.com>
 <e7298704-5a03-0961-90a3-dab4af60c326@linaro.org>
 <32e9a512-fd74-b2f6-6b8a-fefb9ad5912d@quicinc.com>
 <431faa87-d152-5f7a-40fd-8b6fe26f0bb9@linaro.org>
 <71e1f36f-8fd8-9d61-d563-577d4fb54f10@quicinc.com>
 <69c01f0f-4eb0-bb44-a238-5c9ce5beede9@linaro.org>
 <CAA8EJppCSnEg1GjX8CavxRPiiE19JwVAOTspjWJR-OzdQMcu+g@mail.gmail.com>
 <7ecf968b-45b2-c6b7-86a7-8d8caccf5002@linaro.org>
 <511a84a8-ecb4-13bb-2eab-982b19758ba5@quicinc.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <511a84a8-ecb4-13bb-2eab-982b19758ba5@quicinc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 14/07/2023 22:32, Anjelique Melendez wrote:
> 
> 
> On 7/12/2023 1:11 PM, Krzysztof Kozlowski wrote:
>> On 12/07/2023 16:35, Dmitry Baryshkov wrote:
>>>>>> Rob asked you - "Is there more than 1 instance in a PMIC?" - and you did
>>>>>> not answer positively, just mentioned something about drivers in
>>>>>> downstream, which do not matter. So is the answer for that question:
>>>>>> yes, you have two instances of the same PMIC differing by presence of
>>>>>> PBS and other features"?
>>>>>>
>>>>> Sorry that was a misunderstanding on my part.
>>>>> Yes, answer to Rob's question should have been "We have two instances of PMI632,
>>>>> where one instance holds the pbs peripheral and the other holds the lpg
>>>>> peripherals. The child node for pbs is needed so lpg client can access
>>>>> the PMI632 regmap which contains the pbs peripheral."
>>>>
>>>> I guess I miss here something. What is "LPG client"? I don't understand
>>>> why this LPG client needs existence of PBS node, to be able to get the
>>>> regmap.
>>>>
>>>> PBS is a child of PMIC, so it can get regmap from the parent. What's
>>>> more, which DT property passes the regmap from PMIC to LPG client?
>>>
>>> There are some PMICs which claim two SPMI SIDs. For such PMICs, each
>>> SID is a separate device, so it is not directly possible to get the
>>> regmap of the other SID.
>>
>> OK, maybe after implementing all the review changes - including dropping
>> that singleton pattern - this will be clearer. Please send new version
>> and we will discuss it from there.
>>
> Sure, will work on getting that new version sent but I did just have clarifying question.
> When you say "dropping that singleton pattern" are you referring to dropping the 
> PBS node?
> Want to make sure we are all on the same page with what the next version will include :)

I was referring to my comments on driver, that you should not have
file-scope variable and get_pbs_client_device() iterating over global
list. It isn't singleton, actually, but the pattern in coding is very
similar to singleton approach.

Best regards,
Krzysztof