From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1788CCA0EC1 for ; Mon, 11 Sep 2023 21:04:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241009AbjIKU4p (ORCPT ); Mon, 11 Sep 2023 16:56:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236719AbjIKLPy (ORCPT ); Mon, 11 Sep 2023 07:15:54 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 727E2E40 for ; Mon, 11 Sep 2023 04:15:47 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-3ff7d73a6feso45340515e9.1 for ; Mon, 11 Sep 2023 04:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1694430946; x=1695035746; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7oYncRXl8MdgOuj5ecatA5YK1hlf20bUpcsVqj8+B7w=; b=iy6Ly+qSIjUUd4/DUtUNVlBHa1u5LTfvhrT/hl4O1wLhMitDehJL8lXvytikvsFVcS H/IAUTW7iN5XWLire2POO6epX+pXGgn4E1jMTwlhTDG8n8FR4auFzhs98SAplSxmp1PF bCbAY+tCpf2+Udd+6x6m1+oZCxZmzbcRVDo1OptZ06DKeRET75y72J2q0sp08bLPoB+k OxnYZYAJotbPiTq/56PeJKOhtcJoOhBkc2b9P1KJDV+DqEW2j0pagLTiXDdOSHI402xq GAc7Vmi75iRRMsaf2Jmorz88gcd2/B4xIT1h+3+/oKVyP66b10KM/HrGpbTDYE+j8qt1 rWiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694430946; x=1695035746; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7oYncRXl8MdgOuj5ecatA5YK1hlf20bUpcsVqj8+B7w=; b=Rcl7t4DlQk5/yAkewlNF9tbdGF+akuQW0Bm4DSl2Qi7PAP3+1941QHYVTs0mzAIfGK y2tSIbTq7iCFbky60Ok6wlMUTXEvveK0EyRtkkvHwXjn/ehLuU8/7uMAuedMDMJ7dFZ/ PSjwckDYYDI3YDyaaawH2d515cKVkjke44uHTH4SMP59NkqRHb6rMFjqvmZRbm2Gsc+C I8+33QOk6Bgn8h+nSOLw8mGHN3MPoCcN2oFVh3JFyV/6J2Z1ZMbO/n4izfKwsdf4br2z quOmM6kV1N9odsZEdLy7nqM86EY7gJSSdupAUUMv0AhiQJTbOaTaz6yGGlAvaiJRChLr q8cQ== X-Gm-Message-State: AOJu0Yzd0osphvu9wHXsEJwKGssJmyMOvmXjbSqDGhgKtRJI/I91InMA 97KL3XUHNtMqkRbGXfoD/Au1hA== X-Google-Smtp-Source: AGHT+IFMPWetHW3X3w0vf7JC2rs7SsnHakGdeLJ9bxL9NSEuCvaDE4Qf7g+s2Jq63JasENDVFi2WvA== X-Received: by 2002:a05:600c:6028:b0:402:f55e:ac11 with SMTP id az40-20020a05600c602800b00402f55eac11mr7826062wmb.20.1694430945795; Mon, 11 Sep 2023 04:15:45 -0700 (PDT) Received: from [192.168.1.20] ([178.197.214.188]) by smtp.gmail.com with ESMTPSA id b13-20020a5d634d000000b0031c5e9c2ed7sm9783914wrw.92.2023.09.11.04.15.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Sep 2023 04:15:45 -0700 (PDT) Message-ID: Date: Mon, 11 Sep 2023 13:15:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 04/11] arm64: dts: qcom: pm7250b: make SID configurable Content-Language: en-US To: Luca Weiss , Dmitry Baryshkov , Bjorn Andersson , Konrad Dybcio Cc: cros-qcom-dts-watchers@chromium.org, Andy Gross , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Srinivas Kandagatla , Linus Walleij , "Rafael J. Wysocki" , Viresh Kumar , ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org References: <20230830-fp5-initial-v1-0-5a954519bbad@fairphone.com> <20230830-fp5-initial-v1-4-5a954519bbad@fairphone.com> <728003b9-db27-fdc0-e761-197a02a38c24@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org 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 >>>>> wrote: >>>>>> >>>>>> On 31/08/2023 13:33, Dmitry Baryshkov wrote: >>>>>>> On Thu, 31 Aug 2023 at 13:13, Luca Weiss 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 >>>>>>>>>> --- >>>>>>>>>> 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 >>>>>>>>>> #include >>>>>>>>>> >>>>>>>>>> +/* 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