Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3519217ybl; Mon, 12 Aug 2019 01:43:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTvbdeizQ7KP938kC1V9OhsxkyxxVjXtQ90iWbNV9HJYHYEjzQeAor7mfsKlCTJU+fPxGf X-Received: by 2002:aa7:9e0a:: with SMTP id y10mr10836217pfq.93.1565599417531; Mon, 12 Aug 2019 01:43:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565599417; cv=none; d=google.com; s=arc-20160816; b=dT9U180iSAvB29UAL9HR01W7rigaNqMG/jZ3yhfP4kHRG1fUGANid/tZfV7mrz6Qni 50gQJX7/hjQ4C/1k60nVTiC2+Ns8zIz2+lEbvec2Gzri515Oo7FM05wToJgho3ghThlc gOjxB+7nHR+9q3ocqW75J0nWe5qPCl1fpOtQFXb/m40Dfk1ap1QjA7m5clQt5DUOb6hG ZB9a9B5m/16TTeqf4SkEFk8W5d3SZwOpGscLAGNbyTdhRh9pdBG2dYcB5EyEs2EghRtn MpIjDy/4wdJ7EbcBgSMJYcBojaDGP5+Fmzdj0EAa3yXlVDGwrnaf5dSo5QE5AkR+Q+mK 4F6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=7cWlpK7j41c9mgbhQ5iWiejkSakbVWB0+iv800Llrg8=; b=hGTZ2M1Qy7Wff8Sjzm/o/qx57QIRCzWfQMzzivPp5lbHSAIolprDLIojNnWs3z2njb o/boxfKWoRSrdbMsFgxAmaBohPNY0xrW1CawIOgpq333tbq7LgoDiVBKEWa1Cjvi70lA g2+eevdSdIUDE29tzEuXb6NVvwyEuRGCkfKYF7ouJFEGco4kC+h9l+vklkX9JkrHahH0 VIIoN9jDQFK30HAcTYAmm1KNMuotu0be2zSt4N2rzEBzj0yuZJeRtz47AhjX9npWXOVT 0E4duaSVKEsC9y4PbDomniy22Gsbm+XFjs4YXRSEG34S/Zsh68dCZRNhrEW1SrRaeVaZ d5Cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y12si67736249pfg.260.2019.08.12.01.43.22; Mon, 12 Aug 2019 01:43:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727225AbfHLImt (ORCPT + 99 others); Mon, 12 Aug 2019 04:42:49 -0400 Received: from foss.arm.com ([217.140.110.172]:45220 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727207AbfHLIms (ORCPT ); Mon, 12 Aug 2019 04:42:48 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1F2E8174E; Mon, 12 Aug 2019 01:42:48 -0700 (PDT) Received: from queper01-lin.cambridge.arm.com (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1C7733F718; Mon, 12 Aug 2019 01:42:46 -0700 (PDT) From: Quentin Perret To: edubezval@gmail.com, rui.zhang@intel.com, javi.merino@kernel.org, viresh.kumar@linaro.org, amit.kachhap@gmail.com, rjw@rjwysocki.net, catalin.marinas@arm.com, will@kernel.org, daniel.lezcano@linaro.org Cc: dietmar.eggemann@arm.com, ionela.voinescu@arm.com, mka@chromium.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, quentin.perret@arm.com Subject: [PATCH v7 2/4] PM / EM: Declare EM data types unconditionally Date: Mon, 12 Aug 2019 09:42:33 +0100 Message-Id: <20190812084235.21440-3-quentin.perret@arm.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190812084235.21440-1-quentin.perret@arm.com> References: <20190812084235.21440-1-quentin.perret@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The structs representing capacity states and performance domains of an Energy Model are currently only defined for CONFIG_ENERGY_MODEL=y. That makes it hard for code outside PM_EM to manipulate those structures without a lot of ifdefery or stubbed accessors. So, move the declaration of the two structs outside of the CONFIG_ENERGY_MODEL ifdef. The client code (e.g. EAS or thermal) always checks the return of em_cpu_get() before using it, so the exising code is still safe to use as-is. Reported-by: kbuild test robot Signed-off-by: Quentin Perret --- include/linux/energy_model.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h index 73f8c3cb9588..d249b88a4d5a 100644 --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -9,7 +9,6 @@ #include #include -#ifdef CONFIG_ENERGY_MODEL /** * em_cap_state - Capacity state of a performance domain * @frequency: The CPU frequency in KHz, for consistency with CPUFreq @@ -40,6 +39,7 @@ struct em_perf_domain { unsigned long cpus[0]; }; +#ifdef CONFIG_ENERGY_MODEL #define EM_CPU_MAX_POWER 0xFFFF struct em_data_callback { @@ -160,7 +160,6 @@ static inline int em_pd_nr_cap_states(struct em_perf_domain *pd) } #else -struct em_perf_domain {}; struct em_data_callback {}; #define EM_DATA_CB(_active_power_cb) { } -- 2.22.0