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 72814C6FA89 for ; Fri, 9 Sep 2022 16:51:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231348AbiIIQvt (ORCPT ); Fri, 9 Sep 2022 12:51:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231935AbiIIQvN (ORCPT ); Fri, 9 Sep 2022 12:51:13 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC3EA3D582 for ; Fri, 9 Sep 2022 09:50:51 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p5so2522495ljc.13 for ; Fri, 09 Sep 2022 09:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; 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; bh=O9FowbIs62g6VcoOUNjt1bKmyMiLJOoWtlkCshtX0Fg=; b=HxfxZkCrYWrP5oC/dAO7XCw0lY9M6rHKMudvwSVsQfpO6bWusxC2iZUY2+gi4OXpWw JifIGrWiP4kq1vy0hBAx8QYqpa8LqeEkqtnQj63e/E/Ncx7+QIWkfsL/xgRKpJVv5awB O7q1TIIYjXLqu/seLPO3qOjB7rFZog+yeHdEe88EoKtKrrKVj9kQ20IL6FBcwAGZ3zwL WZangDDIiz75B563jQ2ITB3lxszPM+JvDTQdWqthTOhGqPfaf/ekpTQ49GjsxKCqBy6N gNjZlQ1bsD7ESAacfi5s4RMwMgoWvAXSm7is8Em53Ij3SMnTRLIMt+0DUJZplHB6jHfV lXMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=O9FowbIs62g6VcoOUNjt1bKmyMiLJOoWtlkCshtX0Fg=; b=C/x/nFDbhXI8p0O6LI34946Odozm/C+vQgGcsJfVh3Ba4PNOg7qTCPCOQvLi9heNoR nGQ0HkoeeA8CUtw+Nfqd4USTJ0viyoqz3qY/g8bkcZCaDvM712ge9Un5n6rYSI+KTu0N wO4w8Z6FT4TbAH1HWhKrmovv+zzAqSO82yszNDNwj+aGtjN6FFQkQBCXmHmvknDSgJI8 asSIckEnTi6VcyDtK6MaM84MmPVPLU6lPUj8wjmA9lSRMktS2M8WGfwHOMAhSBqrguFC /+wKDtvFQzQ4SjPiyKKhOciN8ESlkjKVC276PK7eGO5pfwboEAJ1jB4eYGIcLROGFH7v xjRw== X-Gm-Message-State: ACgBeo0QRIUOsSQ45ez1t6ZB4uOWw46CmbQ+FgaUWFi7FaQ1I17cZq+Q TqLAl/P7HAdn5IqdCxPoYndYFQ== X-Google-Smtp-Source: AA6agR7nLZO3mdmBv9Mmtc1qPnXOMQHqwzHQeSIz2JK3SZX4Ex5MDsmolP63sATF1fuETKuLJilslw== X-Received: by 2002:a05:651c:1044:b0:26b:ece0:b1f3 with SMTP id x4-20020a05651c104400b0026bece0b1f3mr100866ljm.526.1662742249694; Fri, 09 Sep 2022 09:50:49 -0700 (PDT) Received: from [192.168.0.21] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id m13-20020a056512358d00b00497ad9ae486sm151829lfr.62.2022.09.09.09.50.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Sep 2022 09:50:49 -0700 (PDT) Message-ID: <2a5fe53e-4bc2-c2f5-44d1-3cb7bd0c71ef@linaro.org> Date: Fri, 9 Sep 2022 18:50:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] regulator: qcom_rpm: Fix circular deferral regression Content-Language: en-US To: Linus Walleij , Liam Girdwood , Mark Brown Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Andy Gross , Bjorn Andersson , Konrad Dybcio , linux-arm-msm@vger.kernel.org References: <20220909112529.239143-1-linus.walleij@linaro.org> From: Krzysztof Kozlowski In-Reply-To: <20220909112529.239143-1-linus.walleij@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/09/2022 13:25, Linus Walleij wrote: > On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator) > does not come up if they are supplied by an SMPS-regulator. This > is not very strange since the regulators are registered in a long > array and the L-regulators are registered before the S-regulators, > and if an L-regulator defers, it will never get around to registering > the S-regulator that it needs. > > See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts: > > pm8058-regulators { > (...) > vdd_l13_l16-supply = <&pm8058_s4>; > (...) > > Ooops. > > Fix this by moving the PM8058 S-regulators first in the array. > > Do the same for the PM8901 S-regulators (though this is currently > not causing any problems with out device trees) so that the pattern > of registration order is the same on all PMnnnn chips. > > Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device") > Cc: stable@vger.kernel.org > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Konrad Dybcio > Cc: linux-arm-msm@vger.kernel.org > Signed-off-by: Linus Walleij > --- > drivers/regulator/qcom_rpm-regulator.c | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/drivers/regulator/qcom_rpm-regulator.c b/drivers/regulator/qcom_rpm-regulator.c > index 7f9d66ac37ff..3c41b71a1f52 100644 > --- a/drivers/regulator/qcom_rpm-regulator.c > +++ b/drivers/regulator/qcom_rpm-regulator.c > @@ -802,6 +802,12 @@ static const struct rpm_regulator_data rpm_pm8018_regulators[] = { > }; > > static const struct rpm_regulator_data rpm_pm8058_regulators[] = { > + { "s0", QCOM_RPM_PM8058_SMPS0, &pm8058_smps, "vdd_s0" }, > + { "s1", QCOM_RPM_PM8058_SMPS1, &pm8058_smps, "vdd_s1" }, > + { "s2", QCOM_RPM_PM8058_SMPS2, &pm8058_smps, "vdd_s2" }, > + { "s3", QCOM_RPM_PM8058_SMPS3, &pm8058_smps, "vdd_s3" }, > + { "s4", QCOM_RPM_PM8058_SMPS4, &pm8058_smps, "vdd_s4" }, > + Would be great to have here a comment like "S-regulators (being used as supplies) must come before the rest". Same also in second table. We like to re-order some things from time to time and no one would think about checking Git history for any issues with it. Best regards, Krzysztof