Re: [PATCH 2/2] arm64: dts: qcom: pm7250b: make SID configurable

[Krzysztof Kozlowski]

On 10/05/2023 10:34, Luca Weiss wrote:
> On Wed May 10, 2023 at 10:07 AM CEST, Dmitry Baryshkov wrote:
>> On Wed, 10 May 2023 at 09:55, Krzysztof Kozlowski
>> <krzysztof.kozlowski@xxxxxxxxxx> wrote:
>>>
>>> On 10/05/2023 08:47, Luca Weiss wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On Fri Apr 7, 2023 at 10:27 AM CEST, Krzysztof Kozlowski wrote:
>>>>> On 07/04/2023 09:45, Luca Weiss wrote:
>>>>>> Like other Qualcomm PMICs the PM7250B can be used on different addresses
>>>>>> on the SPMI bus. Use similar defines like the PMK8350 to make this
>>>>>> possible.
>>>>>>
>>>>>> Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
>>>>>> ---
>>>>>>  arch/arm64/boot/dts/qcom/pm7250b.dtsi | 23 ++++++++++++++++-------
>>>>>>  1 file changed, 16 insertions(+), 7 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
>>>>>> index daa6f1d30efa..eeb476edc79a 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
>>>>>> @@ -7,6 +7,15 @@
>>>>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>  #include <dt-bindings/spmi/spmi.h>
>>>>>>
>>>>>> +/* This PMIC can be configured to be at different SIDs */
>>>>>> +#ifndef PM7250B_SID
>>>>>> +   #define PM7250B_SID 2
>>>>>
>>>>> Drop indentation, although anyway I am against this. Please don't bring
>>>>> new patterns of this at least till we settle previous discussion.
>>>>>
>>>>> https://lore.kernel.org/linux-arm-msm/46658cbb-fff5-e98b-fdad-88fa683a9c75@xxxxxxxxxx/
>>>>
>>>> What's the outcome of the discussion? For this PMIC it's totally enough
>>>> to have the SID configurable like in this patch, I don't think this PMIC
>>>> will be included twice in a board - at least I'm not aware of such a
>>>> configuration.
>>>
>>> We did not reach consensus and I still disagree with complex macros or
>>> macros depending on order of inclusion.
>>
>> I still think we should find a way to parametrise PMIC dtsi, however I
>> agree with Krzysztof that complex CPP is not a way to go.
> 
> What about the macro already used in-tree and proposed with this patch?
> I wouldn't say this is a "complex macro" since it's just a single number
> being replaced in a few places.

Are you talking about the macro to which I responded: "or macros
depending on order of inclusion." or something else?

Best regards,
Krzysztof