Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp479858rwe; Fri, 26 Aug 2022 08:26:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR48FEeeEL0FVAqx9Ip4TFHN08+HS1hbKgN9q82D/XtK4I8wE10hTIebV/xvB7oTkPPfct3B X-Received: by 2002:a05:6402:3711:b0:445:e264:beed with SMTP id ek17-20020a056402371100b00445e264beedmr7198561edb.136.1661527612828; Fri, 26 Aug 2022 08:26:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661527612; cv=none; d=google.com; s=arc-20160816; b=GzjEUgTnaLZ7hoLmb9nVuvzdE3wuhW5xmycthX5g9DG436jwxTQTxTk4GwWy84CSOe R1yeoV0G82adh4+cz/7gLrPv2Ye5Yx/fs5V8ewkKMgPCPQqjnYQuDnvcjSAvlemwdrmy zE1LpO9cbj0mca6X9kmq61QI9YJ5lrbD4hRqtnryxaJ4WCyLLya0XtJDQv8HjKBRS2fD QIw1XoVTg5etrDEecP/DFMgNGl/NFJgeqI3G/TsI1ZxW5to1awD0P3X2dhrVgmR2Lecw 18F+7/KOA85u4SHw9PwmpCd1LwJeOkj0dLapeQ6FLiv4A0my3wDjVHhajsEKVsA+6Eg5 b1Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=49FbH9fhwp8y/uszTeozlNisIKriGJI0rkU4Q43uXpk=; b=ZKQ1XiI9HOb5GxrPhqRq1aclLWPt8rMJ/dTfiykAdI9VQhpOKNEcvRkskjxEBVIXjJ hxha1sbikWbNLZl0xFuxiTAYZlLbz+7y9hTIkRXpaZO3P2ExNzW/32n+0sePZrfiW0Og 6LDh/0t/lInBrzDVhp81WpY2SonfTbCLhdRM/ln7Pm9KHv2KjjisofynbRbU71sCk3hI 4Gna0yF2Wvtx7rJjWFzymRCofaOZHFUCjC6+1Oe5YorGkplfKiw2mVvpWkgLaahM8he3 kqzpt7BcIfIJMfKxCDdylE3dji6WiyKaSIBBhWAhiRi7S+PfgVzlkkWkP3j0RQOdRNtt NWjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=lc87Iq6s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k8-20020a17090627c800b0073c100331cbsi1395770ejc.384.2022.08.26.08.26.26; Fri, 26 Aug 2022 08:26:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=lc87Iq6s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237347AbiHZO5p (ORCPT + 99 others); Fri, 26 Aug 2022 10:57:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230433AbiHZO5j (ORCPT ); Fri, 26 Aug 2022 10:57:39 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CBD7D9D56 for ; Fri, 26 Aug 2022 07:57:38 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id p18so1779529plr.8 for ; Fri, 26 Aug 2022 07:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc; bh=49FbH9fhwp8y/uszTeozlNisIKriGJI0rkU4Q43uXpk=; b=lc87Iq6suxcr08Rewus/FQpCAwb7n6XxXBZs7iuUofU3aOT0hivPtFRxbQ1No/xGTe sJJMfxEhRo/8act27XOdB3lrqDmnmtB8916iQFEW4I1SVa+N4kTFLOAw84KFj91obeMP 8zQl5TNsA3uvR/xK7tJg1VWfg9vnO2Ie1weEk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc; bh=49FbH9fhwp8y/uszTeozlNisIKriGJI0rkU4Q43uXpk=; b=Jnc58BWQKi25icq+XnT3Ho/7yFw2hHt3IZYUG4mL+qHakirUvlRsj11YxR2e9aogTT sDN8f1E08aEwyOaz/sugdosGYUq6dPeWdEsotsEQhUGPnvsBXB7H0l+YrvMARfR0Hn56 SgrSfCFV7XUAt1WVkYeC+T5Gm0cDJ/gmlo36N9yzXoVWtYC7kEELn56oS3CflDcbATII OAHilGETnl2VfO41f5vpKJKoiFyuqO04aQeZLso9RfTxGZp/3bvdHB5bX37htATuYkHj F7X28lC+olAU+LhH5QMJzUkFB30g41bxD/HMXRR07cRY8pBffh1n6QuSPzEDueD4JBpy xmfA== X-Gm-Message-State: ACgBeo27W9pgeXGZQnluLDu+sJTTB5SPmNZZFzfR3e5ZmwWBPGpIpZ/D LykFjYKSKtS8zL9GmXGIVJJaEg== X-Received: by 2002:a17:90a:55:b0:1f7:4513:8cac with SMTP id 21-20020a17090a005500b001f745138cacmr4626092pjb.93.1661525857343; Fri, 26 Aug 2022 07:57:37 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:7487:fdf0:5cfa:b7ab]) by smtp.gmail.com with ESMTPSA id w61-20020a17090a6bc300b001facb7bc1adsm1768424pjj.26.2022.08.26.07.57.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Aug 2022 07:57:36 -0700 (PDT) From: Douglas Anderson To: Viresh Kumar , Nishanth Menon , Stephen Boyd Cc: linux-arm-msm@vger.kernel.org, mka@chromium.org, Douglas Anderson , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH] opp: Expose voltage info in debugfs for OPPs w/out explicit regulators Date: Fri, 26 Aug 2022 07:56:59 -0700 Message-Id: <20220826075655.1.I2e4958048f30c3b44a01e31519092f7d3c9204e4@changeid> X-Mailer: git-send-email 2.37.2.672.g94769d06f0-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On some cpufreq drivers we know the voltage associated with each operating point but there is no explicit Linux "regulator" present. An example is "qcom-cpufreq-hw.c". There the voltage is managed automatically by the hardware but we still associate it with the OPP table so we can do energy calculations for EAS. The OPP framework handles this in general. In _opp_allocate() it can be seen that we always allocate space for one supply even if "regulator_count" is 0. Let's handle this properly in debugfs. NOTE: as a side effect of this a whole bunch of OPPs in the system may get supply-related files exposed in debugfs that are mostly useless (they'll just contain 0). I'd expect this to be OK but it's moderately annoying. It seems better than trying to dynamically create debugfs directories when the voltages are non-zero or adding extra complexity in the code giving a hint to the OPP framework that voltages should be exposed. After this patch, on a sc7180-trogdor class device I can see voltages for the CPU OPPs under /sys/kernel/debug/opp. Fixes: dfbe4678d709 ("PM / OPP: Add infrastructure to manage multiple regulators") Signed-off-by: Douglas Anderson --- drivers/opp/debugfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/opp/debugfs.c b/drivers/opp/debugfs.c index 96a30a032c5f..65234da41063 100644 --- a/drivers/opp/debugfs.c +++ b/drivers/opp/debugfs.c @@ -96,10 +96,11 @@ static void opp_debug_create_supplies(struct dev_pm_opp *opp, struct opp_table *opp_table, struct dentry *pdentry) { + int supply_count = max(opp_table->regulator_count, 1); struct dentry *d; int i; - for (i = 0; i < opp_table->regulator_count; i++) { + for (i = 0; i < supply_count; i++) { char name[15]; snprintf(name, sizeof(name), "supply-%d", i); -- 2.37.2.672.g94769d06f0-goog