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 EC075C83F10 for ; Thu, 31 Aug 2023 12:32:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345520AbjHaMcn (ORCPT ); Thu, 31 Aug 2023 08:32:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235106AbjHaMcm (ORCPT ); Thu, 31 Aug 2023 08:32:42 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0656CFE for ; Thu, 31 Aug 2023 05:32:38 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-9a2185bd83cso88783966b.0 for ; Thu, 31 Aug 2023 05:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1693485157; x=1694089957; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Cj4e69HAaMOOdlvr+WIWTnSbaYlLGaoLGvsHESxOroI=; b=t80J9iBsHgwc38mPwyXOf6kIGe08KqFyxVERI58fPPJoQ20bgP12GYKTPg8X2jQw0U yY+0fJVSLNhf1/skaoCvFWhiv80HuXbeZH7ePs1TS/aTJuB/xcaK8DPYZhJnHRd5dCbu JGvsWNPFeWZv/SwFM7BD3O6n+oco8yQmp3PYzEWJJf6PzSUpyqsNeDteJtEj645o3gHO Ld4HDDbTSyhKgze3fRNpZI+6/S1FtLa9poO5lXspbLJBcqJmje/PzslEFYaZiJlghK9/ WLQrZ3xWM3+5WhHI8sx+au4F3Q7nMVQf/Ir097g72WjnYgnWTcTXupC3RI/dZSG4QB80 85aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693485157; x=1694089957; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Cj4e69HAaMOOdlvr+WIWTnSbaYlLGaoLGvsHESxOroI=; b=X1BsXn2zRtLZAIsw/byBftwM3s89u7jse/wWM/EuPtELOXiU7iN/UEw98HhTNk/Ml3 n2xt2wZ1hYbkbdPBY6+fhU/T6/Y8XUI8PVBk7T5r3zZHRGfundPy8g+uVsFzxQCyqwvJ +/ktDut3Kaj3hxXc51ZEHlgz7rsQuMJJyYcUcJ3fRQyL6Vr8MK2n7Xf7Pk+xaVWbzGLd TkcFPD6RqilM51ZljHbUl1ayLTxuQ6jfxdssZYIw1Z4pynYu6INS9Q00NPx64MSzuChI 13ha5wm1nMEU8cTC+B3nd0rK4EjRvxVE6lPcT8b4ZxnSxhHolyfoXRIVlJ6bxWNu9k28 bc7g== X-Gm-Message-State: AOJu0Yy2imEe53f4vE0ZB712ELpbmwoVbLkZrXcq6NJC2DRcE3x3FXnH lDSa5c5gkBdCSYOPS1KYqzF41Q== X-Google-Smtp-Source: AGHT+IHyE5BVYp70Ll+vKcK9XwzMnRGpWsl9jIQBoASbYwV/rC/46WZgUGOARkhdfkh5OQgp6z9Qug== X-Received: by 2002:a17:907:75f6:b0:988:9b29:5653 with SMTP id jz22-20020a17090775f600b009889b295653mr3326856ejc.77.1693485157385; Thu, 31 Aug 2023 05:32:37 -0700 (PDT) Received: from localhost (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id g3-20020a170906594300b0099cf44adf2csm703919ejr.46.2023.08.31.05.32.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 05:32:37 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 31 Aug 2023 14:32:35 +0200 Message-Id: Cc: , "Andy Gross" , "Bjorn Andersson" , "Konrad Dybcio" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Srinivas Kandagatla" , "Linus Walleij" , "Rafael J. Wysocki" , "Viresh Kumar" , <~postmarketos/upstreaming@lists.sr.ht>, , , , , , Subject: Re: [PATCH 04/11] arm64: dts: qcom: pm7250b: make SID configurable From: "Luca Weiss" To: "Krzysztof Kozlowski" , "Dmitry Baryshkov" X-Mailer: aerc 0.15.2 References: <20230830-fp5-initial-v1-0-5a954519bbad@fairphone.com> <20230830-fp5-initial-v1-4-5a954519bbad@fairphone.com> <728003b9-db27-fdc0-e761-197a02a38c24@linaro.org> In-Reply-To: <728003b9-db27-fdc0-e761-197a02a38c24@linaro.org> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu Aug 31, 2023 at 1:54 PM CEST, Krzysztof Kozlowski wrote: > On 31/08/2023 13:33, Dmitry Baryshkov wrote: > > On Thu, 31 Aug 2023 at 13:13, Luca Weiss wro= te: > >> > >> 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 addre= sses > >>>> 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 previo= us > >>> discussions? > >>> > >>> You got here feedback already. > >>> > >>> https://lore.kernel.org/linux-arm-msm/f52524da-719b-790f-ad2c-0c3f313= d9fe9@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 als= o > >> tried to get an update lately if there's any update with no response. > >=20 > > I think the overall consensus was that my proposal is too complicated > > for the DT files. > > I proposed to duplicate the entries. If you mean creating a pm7250b-8.dtsi with pm7250b copy-pasted but the SID changed from 2 & 3 to 8 & 9, I can do that if that's the way forward. If this was done, I'd also say then that pm7250b.dtsi should be renamed to e.g. pm7250b-2.dtsi since it's currently sitting on SID 2 & 3. > Do you keep QUP nodes in DTSI and customize per address? No. > > 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. I really don't mind either way, I'd just like to have some way for now. > > 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. Is this something that could be fixed long term? Especially since Qualcomm is reconfiguring PMICs on different addresses nowadays maybe there's more or a push to do this? Regards Luca > > Best regards, > Krzysztof