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@xxxxxxxxxx> wrote: >>>>>> >>>>>> On 31/08/2023 13:33, Dmitry Baryshkov wrote: >>>>>>> On Thu, 31 Aug 2023 at 13:13, Luca Weiss <luca.weiss@xxxxxxxxxxxxx> 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@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 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@xxxxxxxxxx/ >>>>>>>> >>>>>>>> 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
