Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp2428095ybm; Thu, 23 May 2019 17:15:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqyHxLkjoQRMXUW7v8bht5jT87hn7EekhwUTeAjLuuwTno/LkZfdKHmOz1Q3t+tm+DzpNK3e X-Received: by 2002:a63:a709:: with SMTP id d9mr33561815pgf.263.1558656912845; Thu, 23 May 2019 17:15:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558656912; cv=none; d=google.com; s=arc-20160816; b=EjqSF8yZ9rrlwcMcMo4aqxm2j7OcvoUIIY3ferCHyc5n9IEPkeBT+6C1f8uRj/4dM9 +031pspMvzCvkmd0WCbXyxNJYPbaenwMD5v80mj0xIc/TFq338ATjIlP4L/TFryrBZbt Vjw3j6lhLlQ91ygJ6Whg3jvF2uv4sTr2aiQQRjY+Tgs9oR3ofg7lAJ1WhMcyEL314hrF 0tdtZNZ7LiOsTtbo1I3PwdajvBqaBan6y20IPDENzKQuYAwgLZymjtefweHwYF9+wdYd 4CHPheHEWF/IXeRqiPe513/6zlHAG0/uotGMiEMD/voEaHidIo3LFCYuC1o5BftKn1hF vIGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:user-agent:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :message-id:dkim-signature; bh=55+scLPzywd2t6Q9yx3Qo50LoEln+k1CYwGY53WWjzw=; b=X8zJ2rmOtUeHv+HUs5rmZoIGqzb7ame4L/D0inoumfhqdLAHiCNQ6hqKWM+r7UE3uz WIF22WXpjB3kMeNtO8y8bbEbhW2QtmZIKytLj/gtHbD02YnOeiDU/r/1EO0V5FxxLJt2 R8xyNt16LJTyjbHx9DG6bvUald7+Al6tXCKW+WAXHD4721h/rbZgNFbtI0wq79ijbfPM xPMpD1Z/vdslaygZqlHgbByaMXdWsRVlPhGs2toIvXa8UshSo541cbEuTvNQ7rEQM1TJ k2Dj6K5zamt2y4R6dX2ge4pqb8EsEjT1w52HaG3dRJ3+qoc94ASqVBWhO+yUQWsTllgL 0Acg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=EuZua2Uz; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p11si1421715pgf.547.2019.05.23.17.14.51; Thu, 23 May 2019 17:15:12 -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; dkim=pass header.i=@chromium.org header.s=google header.b=EuZua2Uz; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388657AbfEXALo (ORCPT + 99 others); Thu, 23 May 2019 20:11:44 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:35353 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387613AbfEXALn (ORCPT ); Thu, 23 May 2019 20:11:43 -0400 Received: by mail-pf1-f193.google.com with SMTP id d126so1964280pfd.2 for ; Thu, 23 May 2019 17:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:subject:from:cc:to:user-agent:date; bh=55+scLPzywd2t6Q9yx3Qo50LoEln+k1CYwGY53WWjzw=; b=EuZua2Uzj4PFIiNubpucYeny5iInwuYR+P39ZD/rE/lEL2FPFCY4KF7C9r/zE3fIsH NAna6L2IHwMgPHCUgEk1jHwDhX2jy6B+xtoSR35UuQNkV+BJ9+PDF1/9k4oUEPJDSiRo 0KVAjc7QFF/nw0767rfpVHo+EbMTIiMCjvsmE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:subject:from:cc:to :user-agent:date; bh=55+scLPzywd2t6Q9yx3Qo50LoEln+k1CYwGY53WWjzw=; b=dKfUpIB7gJNxiyRY2NWR64jWfIT/ft5dr6OkR0S5jZ3i5bIxfaGFpNwI2sMfj5hMtQ sk1xf/yHOcSfQcGxAE+FiOR6kK7nhwjErQB9oY4crwhLuiASvuNlylg0vyFmOOPV9oft HUrWyJMv1N0JrY+7xBbF0eK6u2rEg0psZSjx+8AIu1maQvwPtAouaNNddxn5FS04DOLe UvcDOIJIRcG++5hHeghHIWOjf0+hWM6mp5jZX6ihiefijc8Ne//bgOgS5k814U16JZdm 8JwIuT5XNrr6VF0hPNqT9lsljpGUg3VoLO2XE2k1MDtLWmBBswTCZVHXZL0O9sbWTU3Y gunQ== X-Gm-Message-State: APjAAAVDy2bQ4P7UmFkR2Hv413v0f4xMC9TuPzJMcon5NFQSqnvMA6O9 ib7nB3RpMp6bCzOKuOxSEHBx/7fGWRaiXA== X-Received: by 2002:aa7:881a:: with SMTP id c26mr102396225pfo.254.1558656702464; Thu, 23 May 2019 17:11:42 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id x18sm597981pfj.17.2019.05.23.17.11.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 23 May 2019 17:11:41 -0700 (PDT) Message-ID: <5ce736bd.1c69fb81.f2410.2b19@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190523195313.24701-1-farosas@linux.ibm.com> <5ce722ac.1c69fb81.b62d2.16d0@mx.google.com> Subject: Re: [PATCH] scripts/gdb: Fix invocation when CONFIG_COMMON_CLK is not set From: Stephen Boyd Cc: "linux-kernel@vger.kernel.org" , Jan Kiszka , Kieran Bingham , Andrew Morton , Jackie Liu To: Fabiano Rosas , Leonard Crestez User-Agent: alot/0.8.1 Date: Thu, 23 May 2019 17:11:40 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Leonard Crestez (2019-05-23 16:09:18) > On 5/24/2019 1:46 AM, Stephen Boyd wrote: > > Quoting Fabiano Rosas (2019-05-23 12:53:11) > >> diff --git a/scripts/gdb/linux/constants.py.in b/scripts/gdb/linux/con= stants.py.in > >> index 1d73083da6cb..2efbec6b6b8d 100644 > >> --- a/scripts/gdb/linux/constants.py.in > >> +++ b/scripts/gdb/linux/constants.py.in > >> @@ -40,7 +40,8 @@ > >> import gdb > >> =20 > >> /* linux/clk-provider.h */ > >> -LX_GDBPARSED(CLK_GET_RATE_NOCACHE) > >> +if IS_BUILTIN(CONFIG_COMMON_CLK): > >> + LX_GDBPARSED(CLK_GET_RATE_NOCACHE) > >> =20 > >=20 > > Why is this LX_GDBPARSED() instead of LX_VALUE()? From what I can tell > > it doesn't need to be runtime evaluated, just assigned to something that > > is macro expanded by CPP. >=20 > Because CLK_GET_RATE_NOCACHE expands to BIT() which expands to a=20 > constant with an UL suffix which python doesn't understand. >=20 > Alternatively we could redefine the BIT macros inside constants.py.in=20 > but using gdb features seemed better. We could even try to strip integer = > literal suffixes with sed. >=20 > Mentioned before: https://lkml.org/lkml/2019/5/3/341 >=20 Ah ok. A comment in the code would have helped me, but o well. I'd still like to apply this change to clk tree so that we can avoid needing to do the IS_BUILTIN check entirely. ----8<---- From: Stephen Boyd Date: Thu, 23 May 2019 17:05:59 -0700 Subject: [PATCH] clk: Remove ifdef for COMMON_CLK in clk-provider.h This ifdef has been there since the beginning of this file, but it doesn't really seem to serve any purpose besides obfuscating the struct definitions and #defines here from compilation units that include it. Let's always expose these function prototypes and struct definitions so that code can inspect clk providers without needing to have CONFIG_COMMON_CLK enabled. Signed-off-by: Stephen Boyd --- include/linux/clk-provider.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index bb6118f79784..3bced2ec9f26 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -9,8 +9,6 @@ #include #include =20 -#ifdef CONFIG_COMMON_CLK - /* * flags used across common struct clk. these flags should only affect the * top-level framework. custom flags for dealing with hardware specifics @@ -1019,5 +1017,4 @@ static inline int of_clk_detect_critical(struct devic= e_node *np, int index, =20 void clk_gate_restore_context(struct clk_hw *hw); =20 -#endif /* CONFIG_COMMON_CLK */ #endif /* CLK_PROVIDER_H */ --=20 Sent by a computer through tubes