diff mbox series

[04/11] arm64: dts: qcom: pm7250b: make SID configurable

Message ID 20230830-fp5-initial-v1-4-5a954519bbad@fairphone.com
State New
Headers show
Series Initial support for the Fairphone 5 smartphone | expand

Commit Message

Luca Weiss Aug. 30, 2023, 9:58 a.m. UTC
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@fairphone.com>
---
 arch/arm64/boot/dts/qcom/pm7250b.dtsi | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

Comments

Dmitry Baryshkov Aug. 31, 2023, 11:33 a.m. UTC | #1
On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
>
> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
> > On 30/08/2023 11:58, 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@fairphone.com>
> > > ---
> > >  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 e8540c36bd99..3514de536baa 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
> > > +#endif
> >
> > Why do you send the same patch as v1, without any reference to previous
> > discussions?
> >
> > You got here feedback already.
> >
> > https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
>
> Hi Krzysztof,
>
> I did mention that original patch in the cover letter of this series.
> I'm definitely aware of the discussion earlier this year there but also
> tried to get an update lately if there's any update with no response.

I think the overall consensus was that my proposal is too complicated
for the DT files.

>
> If you want to block this patch, I'll have to remove pm7250b from the
> device dts, so we'll lose some functionality. Not sure what other
> approaches there could be.
>
> Regards
> Luca
>
> >
> > Best regards,
> > Krzysztof
>
Luca Weiss Sept. 5, 2023, 8:30 a.m. UTC | #2
On Thu Aug 31, 2023 at 2:27 PM CEST, Dmitry Baryshkov wrote:
> On Thu, 31 Aug 2023 at 14:54, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 31/08/2023 13:33, Dmitry Baryshkov wrote:
> > > On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
> > >>
> > >> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
> > >>> On 30/08/2023 11:58, 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@fairphone.com>
> > >>>> ---
> > >>>>  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 e8540c36bd99..3514de536baa 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
> > >>>> +#endif
> > >>>
> > >>> Why do you send the same patch as v1, without any reference to previous
> > >>> discussions?
> > >>>
> > >>> You got here feedback already.
> > >>>
> > >>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
> > >>
> > >> Hi Krzysztof,
> > >>
> > >> I did mention that original patch in the cover letter of this series.
> > >> I'm definitely aware of the discussion earlier this year there but also
> > >> tried to get an update lately if there's any update with no response.
> > >
> > > I think the overall consensus was that my proposal is too complicated
> > > for the DT files.
> >
> > I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
> > customize per address? No.
>
> At the same time, we do keep SoC files separate from the board files.
> Yes, I'm slightly exaggerating here.
>
> I think that for PMIC files it makes sense to extract common parts if
> that eases reuse of the common parts.

Hi all,

what can I do for v2 now?

1. Keep this patch as-is, and keep pm7250b in device dts.

2. Drop pm7250b patch and drop from device dts, until _someone_ figures
out a solution talking to the PMIC on different SID.

3. Something else like copy-pasting pm7250b.dtsi to pm7250-8.dtsi and
changing the SID there, and using that in device dts.

Please let me know what to do.

Regards
Luca

>
> >
> > I definitely do not agree to these ifndef->define. Maybe using just
> > define would work (so drop ifndef->define), because this makes it
> > obvious and fail-safe if included in wrong place... except that it is
> > still not the define we expect. This is not the coding style present in
> > other DTSes.
> >
> > The true problem how these SPMI bindings were created. Requiring SID
> > address in every child is clearly redundant and I think we do not follow
> > such approach anywhere else.
> >
> > Best regards,
> > Krzysztof
> >
Luca Weiss Sept. 11, 2023, 8:34 a.m. UTC | #3
On Tue Sep 5, 2023 at 10:30 AM CEST, Luca Weiss wrote:
> On Thu Aug 31, 2023 at 2:27 PM CEST, Dmitry Baryshkov wrote:
> > On Thu, 31 Aug 2023 at 14:54, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> > >
> > > On 31/08/2023 13:33, Dmitry Baryshkov wrote:
> > > > On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
> > > >>
> > > >> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
> > > >>> On 30/08/2023 11:58, 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@fairphone.com>
> > > >>>> ---
> > > >>>>  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 e8540c36bd99..3514de536baa 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
> > > >>>> +#endif
> > > >>>
> > > >>> Why do you send the same patch as v1, without any reference to previous
> > > >>> discussions?
> > > >>>
> > > >>> You got here feedback already.
> > > >>>
> > > >>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
> > > >>
> > > >> Hi Krzysztof,
> > > >>
> > > >> I did mention that original patch in the cover letter of this series.
> > > >> I'm definitely aware of the discussion earlier this year there but also
> > > >> tried to get an update lately if there's any update with no response.
> > > >
> > > > I think the overall consensus was that my proposal is too complicated
> > > > for the DT files.
> > >
> > > I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
> > > customize per address? No.
> >
> > At the same time, we do keep SoC files separate from the board files.
> > Yes, I'm slightly exaggerating here.
> >
> > I think that for PMIC files it makes sense to extract common parts if
> > that eases reuse of the common parts.
>
> Hi all,
>
> what can I do for v2 now?
>
> 1. Keep this patch as-is, and keep pm7250b in device dts.
>
> 2. Drop pm7250b patch and drop from device dts, until _someone_ figures
> out a solution talking to the PMIC on different SID.
>
> 3. Something else like copy-pasting pm7250b.dtsi to pm7250-8.dtsi and
> changing the SID there, and using that in device dts.
>
> Please let me know what to do.
>
> Regards
> Luca

Hi,

if there's no feedback I'll keep this patch in v2 of this series and we
can continue to discuss there (if necessary).

Regards
Luca

>
> >
> > >
> > > I definitely do not agree to these ifndef->define. Maybe using just
> > > define would work (so drop ifndef->define), because this makes it
> > > obvious and fail-safe if included in wrong place... except that it is
> > > still not the define we expect. This is not the coding style present in
> > > other DTSes.
> > >
> > > The true problem how these SPMI bindings were created. Requiring SID
> > > address in every child is clearly redundant and I think we do not follow
> > > such approach anywhere else.
> > >
> > > Best regards,
> > > Krzysztof
> > >
Krzysztof Kozlowski Sept. 11, 2023, 9:44 a.m. UTC | #4
On 11/09/2023 10:34, Luca Weiss wrote:
> On Tue Sep 5, 2023 at 10:30 AM CEST, Luca Weiss wrote:
>> On Thu Aug 31, 2023 at 2:27 PM CEST, Dmitry Baryshkov wrote:
>>> On Thu, 31 Aug 2023 at 14:54, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 31/08/2023 13:33, Dmitry Baryshkov wrote:
>>>>> On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
>>>>>>
>>>>>> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
>>>>>>> On 30/08/2023 11:58, 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@fairphone.com>
>>>>>>>> ---
>>>>>>>>  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 e8540c36bd99..3514de536baa 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
>>>>>>>> +#endif
>>>>>>>
>>>>>>> Why do you send the same patch as v1, without any reference to previous
>>>>>>> discussions?
>>>>>>>
>>>>>>> You got here feedback already.
>>>>>>>
>>>>>>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
>>>>>>
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> I did mention that original patch in the cover letter of this series.
>>>>>> I'm definitely aware of the discussion earlier this year there but also
>>>>>> tried to get an update lately if there's any update with no response.
>>>>>
>>>>> I think the overall consensus was that my proposal is too complicated
>>>>> for the DT files.
>>>>
>>>> I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
>>>> customize per address? No.
>>>
>>> At the same time, we do keep SoC files separate from the board files.
>>> Yes, I'm slightly exaggerating here.
>>>
>>> I think that for PMIC files it makes sense to extract common parts if
>>> that eases reuse of the common parts.
>>
>> Hi all,
>>
>> what can I do for v2 now?
>>
>> 1. Keep this patch as-is, and keep pm7250b in device dts.

This was NAKed by me. What Qualcomm SoC maintainers decide (or not
decide) about other options, should not cause the wrong solution to be
re-posted...

>>
>> 2. Drop pm7250b patch and drop from device dts, until _someone_ figures
>> out a solution talking to the PMIC on different SID.
>>
>> 3. Something else like copy-pasting pm7250b.dtsi to pm7250-8.dtsi and
>> changing the SID there, and using that in device dts.
>>
>> Please let me know what to do.
>>
>> Regards
>> Luca
> 
> Hi,
> 
> if there's no feedback I'll keep this patch in v2 of this series and we
> can continue to discuss there (if necessary).

Sorry, I still do not agree and there were no arguments convincing me to
change the mind.

I gave you the solution from my perspective. Why do you decided to
ignore it and send it as is?


Best regards,
Krzysztof
Luca Weiss Sept. 11, 2023, 9:59 a.m. UTC | #5
On Mon Sep 11, 2023 at 11:44 AM CEST, Krzysztof Kozlowski wrote:
> On 11/09/2023 10:34, Luca Weiss wrote:
> > On Tue Sep 5, 2023 at 10:30 AM CEST, Luca Weiss wrote:
> >> On Thu Aug 31, 2023 at 2:27 PM CEST, Dmitry Baryshkov wrote:
> >>> On Thu, 31 Aug 2023 at 14:54, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 31/08/2023 13:33, Dmitry Baryshkov wrote:
> >>>>> On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
> >>>>>>
> >>>>>> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
> >>>>>>> On 30/08/2023 11:58, 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@fairphone.com>
> >>>>>>>> ---
> >>>>>>>>  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 e8540c36bd99..3514de536baa 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
> >>>>>>>> +#endif
> >>>>>>>
> >>>>>>> Why do you send the same patch as v1, without any reference to previous
> >>>>>>> discussions?
> >>>>>>>
> >>>>>>> You got here feedback already.
> >>>>>>>
> >>>>>>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
> >>>>>>
> >>>>>> Hi Krzysztof,
> >>>>>>
> >>>>>> I did mention that original patch in the cover letter of this series.
> >>>>>> I'm definitely aware of the discussion earlier this year there but also
> >>>>>> tried to get an update lately if there's any update with no response.
> >>>>>
> >>>>> I think the overall consensus was that my proposal is too complicated
> >>>>> for the DT files.
> >>>>
> >>>> I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
> >>>> customize per address? No.
> >>>
> >>> At the same time, we do keep SoC files separate from the board files.
> >>> Yes, I'm slightly exaggerating here.
> >>>
> >>> I think that for PMIC files it makes sense to extract common parts if
> >>> that eases reuse of the common parts.
> >>
> >> Hi all,
> >>
> >> what can I do for v2 now?
> >>
> >> 1. Keep this patch as-is, and keep pm7250b in device dts.
>
> This was NAKed by me. What Qualcomm SoC maintainers decide (or not
> decide) about other options, should not cause the wrong solution to be
> re-posted...
>
> >>
> >> 2. Drop pm7250b patch and drop from device dts, until _someone_ figures
> >> out a solution talking to the PMIC on different SID.
> >>
> >> 3. Something else like copy-pasting pm7250b.dtsi to pm7250-8.dtsi and
> >> changing the SID there, and using that in device dts.

@Konrad, @Bjorn: Can you give any feedback here what's preferable?
Otherwise I'm just blocked on this series.

> >>
> >> Please let me know what to do.
> >>
> >> Regards
> >> Luca
> > 
> > Hi,
> > 
> > if there's no feedback I'll keep this patch in v2 of this series and we
> > can continue to discuss there (if necessary).
>
> Sorry, I still do not agree and there were no arguments convincing me to
> change the mind.
>
> I gave you the solution from my perspective. Why do you decided to
> ignore it and send it as is?

I get it that you are not final decider for qcom dts changes but it's
quite difficult for someone sending patches to not get any feedback what
other change to replace this is appropriate. I doubt it's a good idea to
just implement some random pm7250-8.dtsi or whatever to potentially
immediately get a response that that way is also bad.

That's why I'm trying to get some info before working on something and
sending it. Hopefully Bjorn or Konrad can add their thoughts above.

Also I don't recall me ever reading a "solution" from your side but
maybe I need to dig through the old emails again.

Regards
Luca

>
>
> Best regards,
> Krzysztof
Krzysztof Kozlowski Sept. 11, 2023, 11:15 a.m. UTC | #6
On 11/09/2023 11:59, Luca Weiss wrote:
> On Mon Sep 11, 2023 at 11:44 AM CEST, Krzysztof Kozlowski wrote:
>> On 11/09/2023 10:34, Luca Weiss wrote:
>>> On Tue Sep 5, 2023 at 10:30 AM CEST, Luca Weiss wrote:
>>>> On Thu Aug 31, 2023 at 2:27 PM CEST, Dmitry Baryshkov wrote:
>>>>> On Thu, 31 Aug 2023 at 14:54, Krzysztof Kozlowski
>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>>
>>>>>> On 31/08/2023 13:33, Dmitry Baryshkov wrote:
>>>>>>> On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
>>>>>>>>
>>>>>>>> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
>>>>>>>>> On 30/08/2023 11:58, 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@fairphone.com>
>>>>>>>>>> ---
>>>>>>>>>>  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 e8540c36bd99..3514de536baa 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
>>>>>>>>>> +#endif
>>>>>>>>>
>>>>>>>>> Why do you send the same patch as v1, without any reference to previous
>>>>>>>>> discussions?
>>>>>>>>>
>>>>>>>>> You got here feedback already.
>>>>>>>>>
>>>>>>>>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
>>>>>>>>
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> I did mention that original patch in the cover letter of this series.
>>>>>>>> I'm definitely aware of the discussion earlier this year there but also
>>>>>>>> tried to get an update lately if there's any update with no response.
>>>>>>>
>>>>>>> I think the overall consensus was that my proposal is too complicated
>>>>>>> for the DT files.
>>>>>>
>>>>>> I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
>>>>>> customize per address? No.
>>>>>
>>>>> At the same time, we do keep SoC files separate from the board files.
>>>>> Yes, I'm slightly exaggerating here.
>>>>>
>>>>> I think that for PMIC files it makes sense to extract common parts if
>>>>> that eases reuse of the common parts.
>>>>
>>>> Hi all,
>>>>
>>>> what can I do for v2 now?
>>>>
>>>> 1. Keep this patch as-is, and keep pm7250b in device dts.
>>
>> This was NAKed by me. What Qualcomm SoC maintainers decide (or not
>> decide) about other options, should not cause the wrong solution to be
>> re-posted...
>>
>>>>
>>>> 2. Drop pm7250b patch and drop from device dts, until _someone_ figures
>>>> out a solution talking to the PMIC on different SID.
>>>>
>>>> 3. Something else like copy-pasting pm7250b.dtsi to pm7250-8.dtsi and
>>>> changing the SID there, and using that in device dts.
> 
> @Konrad, @Bjorn: Can you give any feedback here what's preferable?
> Otherwise I'm just blocked on this series.
> 
>>>>
>>>> Please let me know what to do.
>>>>
>>>> Regards
>>>> Luca
>>>
>>> Hi,
>>>
>>> if there's no feedback I'll keep this patch in v2 of this series and we
>>> can continue to discuss there (if necessary).
>>
>> Sorry, I still do not agree and there were no arguments convincing me to
>> change the mind.
>>
>> I gave you the solution from my perspective. Why do you decided to
>> ignore it and send it as is?
> 
> I get it that you are not final decider for qcom dts changes but it's
> quite difficult for someone sending patches to not get any feedback what
> other change to replace this is appropriate. I doubt it's a good idea to
> just implement some random pm7250-8.dtsi or whatever to potentially
> immediately get a response that that way is also bad.
> 
> That's why I'm trying to get some info before working on something and
> sending it. Hopefully Bjorn or Konrad can add their thoughts above.

I understand, and it is frustrating. If such case happens the solution
in upstream is not sending the same NAKed version but send something else.

> 
> Also I don't recall me ever reading a "solution" from your side but
> maybe I need to dig through the old emails again.

Here:
"I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
customize per address? No."

Dmitry responded that having PMICs extracted help re-using. He is right.
But here you hit the limit of such re-usage.

Best regards,
Krzysztof
Konrad Dybcio Sept. 11, 2023, 11:22 a.m. UTC | #7
On 11.09.2023 13:15, Krzysztof Kozlowski wrote:
> On 11/09/2023 11:59, Luca Weiss wrote:
>> On Mon Sep 11, 2023 at 11:44 AM CEST, Krzysztof Kozlowski wrote:
>>> On 11/09/2023 10:34, Luca Weiss wrote:
>>>> On Tue Sep 5, 2023 at 10:30 AM CEST, Luca Weiss wrote:
>>>>> On Thu Aug 31, 2023 at 2:27 PM CEST, Dmitry Baryshkov wrote:
>>>>>> On Thu, 31 Aug 2023 at 14:54, Krzysztof Kozlowski
>>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>>>
>>>>>>> On 31/08/2023 13:33, Dmitry Baryshkov wrote:
>>>>>>>> On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@fairphone.com> wrote:
>>>>>>>>>
>>>>>>>>> On Wed Aug 30, 2023 at 12:06 PM CEST, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 30/08/2023 11:58, 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@fairphone.com>
>>>>>>>>>>> ---
>>>>>>>>>>>  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 e8540c36bd99..3514de536baa 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
>>>>>>>>>>> +#endif
>>>>>>>>>>
>>>>>>>>>> Why do you send the same patch as v1, without any reference to previous
>>>>>>>>>> discussions?
>>>>>>>>>>
>>>>>>>>>> You got here feedback already.
>>>>>>>>>>
>>>>>>>>>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313d9fe9@linaro.org/
>>>>>>>>>
>>>>>>>>> Hi Krzysztof,
>>>>>>>>>
>>>>>>>>> I did mention that original patch in the cover letter of this series.
>>>>>>>>> I'm definitely aware of the discussion earlier this year there but also
>>>>>>>>> tried to get an update lately if there's any update with no response.
>>>>>>>>
>>>>>>>> I think the overall consensus was that my proposal is too complicated
>>>>>>>> for the DT files.
>>>>>>>
>>>>>>> I proposed to duplicate the entries. Do you keep QUP nodes in DTSI and
>>>>>>> customize per address? No.
>>>>>>
>>>>>> At the same time, we do keep SoC files separate from the board files.
>>>>>> Yes, I'm slightly exaggerating here.
>>>>>>
>>>>>> I think that for PMIC files it makes sense to extract common parts if
>>>>>> that eases reuse of the common parts.
>>>>>
>>>>> Hi all,
>>>>>
>>>>> what can I do for v2 now?
>>>>>
>>>>> 1. Keep this patch as-is, and keep pm7250b in device dts.
>>>
>>> This was NAKed by me. What Qualcomm SoC maintainers decide (or not
>>> decide) about other options, should not cause the wrong solution to be
>>> re-posted...
>>>
>>>>>
>>>>> 2. Drop pm7250b patch and drop from device dts, until _someone_ figures
>>>>> out a solution talking to the PMIC on different SID.
>>>>>
>>>>> 3. Something else like copy-pasting pm7250b.dtsi to pm7250-8.dtsi and
>>>>> changing the SID there, and using that in device dts.
>>
>> @Konrad, @Bjorn: Can you give any feedback here what's preferable?
>> Otherwise I'm just blocked on this series.
I'm sure Krzysztof will disagree, but all of the solutions (which are
either duplicate the dt, add ifdefs or skip adding this pmic) are
equally band-aid-class.. A bright future where this PMIC thing is
handled on the driver side that will hopefully come soon(tm) should
resolve such problems..
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
index e8540c36bd99..3514de536baa 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
+#endif
+
+#ifndef PM7250B_SID1
+	#define PM7250B_SID1 3
+#endif
+
 / {
 	thermal-zones {
 		pm7250b-thermal {
@@ -39,16 +48,16 @@  trip2 {
 };
 
 &spmi_bus {
-	pmic@2 {
+	pmic@PM7250B_SID {
 		compatible = "qcom,pm7250b", "qcom,spmi-pmic";
-		reg = <0x2 SPMI_USID>;
+		reg = <PM7250B_SID SPMI_USID>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 
 		pm7250b_temp: temp-alarm@2400 {
 			compatible = "qcom,spmi-temp-alarm";
 			reg = <0x2400>;
-			interrupts = <0x2 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
+			interrupts = <PM7250B_SID 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
 			io-channels = <&pm7250b_adc ADC5_DIE_TEMP>;
 			io-channel-names = "thermal";
 			#thermal-sensor-cells = <0>;
@@ -60,7 +69,7 @@  pm7250b_adc: adc@3100 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			#io-channel-cells = <1>;
-			interrupts = <0x2 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+			interrupts = <PM7250B_SID 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
 
 			channel@0 {
 				reg = <ADC5_REF_GND>;
@@ -141,7 +150,7 @@  channel@99 {
 		pm7250b_adc_tm: adc-tm@3500 {
 			compatible = "qcom,spmi-adc-tm5";
 			reg = <0x3500>;
-			interrupts = <0x2 0x35 0x0 IRQ_TYPE_EDGE_RISING>;
+			interrupts = <PM7250B_SID 0x35 0x0 IRQ_TYPE_EDGE_RISING>;
 			#thermal-sensor-cells = <1>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -159,9 +168,9 @@  pm7250b_gpios: pinctrl@c000 {
 		};
 	};
 
-	pmic@3 {
+	pmic@PM7250B_SID1 {
 		compatible = "qcom,pm7250b", "qcom,spmi-pmic";
-		reg = <0x3 SPMI_USID>;
+		reg = <PM7250B_SID1 SPMI_USID>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};