Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp859963pxb; Fri, 28 Jan 2022 11:39:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJyzBMEWQA/fU9xLC6jxBZaFBjgEo9bxmliVNFcNp8eOm7SRWkgRvdHpZI4dNtELcYtSkQ+6 X-Received: by 2002:a17:907:3ea8:: with SMTP id hs40mr8165906ejc.48.1643398750847; Fri, 28 Jan 2022 11:39:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643398750; cv=none; d=google.com; s=arc-20160816; b=nU/QC8PyUiXWBTNUMVNQhI7uRWlu38yHhEHsCRzxqAy2W5vobXAF0IjrmlyKkiWkXQ jL53H/Imqtheb6dILESFQVN00NjXuzqBIgR1OxIry8fLje6LIUpO9iTXvVPJgNBnDDce uJrkWGlYivLsyZNPM8GOvtCRYjVHiXlJuI915rQXGgcMgxQgBIzfSUoMe3ZqOkNSz3zX ECvjCDl1SbwE1u+v/ZHGgJtGWj90ky+gIDkRKG47gZXDunkIMJaJv9EOOMhwbZeBzobC +WSk//KCU/yZ1C4cl1HKiS6cm8OkurXPTFD/sLikj8lH/IYp9+laoYJxzl1TBu3wAkLF 5drw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:user-agent:from :references:in-reply-to:mime-version:dkim-signature; bh=GDZUYkuMWQBBmOo2XxTmMtqXTiUx1YCMjMuFT8hErgI=; b=A1Wdqzngj2x0VEflx7r1SIctEgDPmZow4o9mG4WadRe5ghdCMpnWpoSPLZWVltjhWy oPXfg6tP6rfQRZSEspr5AGC3HKa/9basSPCeYKZCe6qFZp7sQ8ZNrBvCe5mWwq5zi7Uj hEGt5WYDFlP3lN4iLk5tgeyPgWp4MYrGwWt3AC+lRZcynCFSJwgPskHEwR3GN8rdlEZc Ma8bcFt/1+Tx8KsU2Ec80xGIOPaXGPKb+jX+V1JJIlzqw3AJDAlxh6kM3R1pFqo2mwm3 3k3Y2435q0MIN6SpiK5dIgXrNks5pLAF0o6BKeebnmdafLzf4NRQn8zqZa1kIu4Yh71C a6mA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=nwwb4fDu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id q19si3410904ejs.310.2022.01.28.11.38.46; Fri, 28 Jan 2022 11:39:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=nwwb4fDu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S234388AbiA0VQN (ORCPT + 99 others); Thu, 27 Jan 2022 16:16:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231293AbiA0VQL (ORCPT ); Thu, 27 Jan 2022 16:16:11 -0500 Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0A02C061747 for ; Thu, 27 Jan 2022 13:16:11 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id e81so8437709oia.6 for ; Thu, 27 Jan 2022 13:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=GDZUYkuMWQBBmOo2XxTmMtqXTiUx1YCMjMuFT8hErgI=; b=nwwb4fDuAam8HugRq7o7PNevR2WOWA9NCIKlQgWDvUmcTsZwDOAJagX02ZreUo2Kd7 lrZI0xYGyeMV0rC/EenrDhUfiyBLrv1ZM9EK1rPa7CkxWYUfyOI9SZOjIseO4AFUCkZp 9mMllhyXPZgnnGu/KIcdLB4t6MvxXW0eWYEg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=GDZUYkuMWQBBmOo2XxTmMtqXTiUx1YCMjMuFT8hErgI=; b=JWx1B79CeKjQZVnDlWbC1ltGAagj2liqFfboP3pbzaZn2HX0q1mINtWcWCjI9PoVox bDmzWZVLctWAQl+PRxtFVUNJD+Ga6Hdfhqrc5u+KWzLzNcXXO16NS1YGgOdMca633Zmo 25cVc1GI2JMU4CcwGCHyx1xkyVJybhjXDPFjTXwRsEkHHdWnaVtmGfsCfyLhYqxIA1wm lKQ8OBznehR8moyiIVFxATKsvWEE2PAd1XjWnuBOsqNaw19QJqnfEY7lA+tFNa3gX7db b2WFNX17plfMF16VFRP5cMMPl8KUy326n848BFlsmAt7wOECICl+jtD3NPYfe0MGU29P beAg== X-Gm-Message-State: AOAM530C23Tqc6UwN9DzIpRWL/dBBKYxYYUC/YOT7X+CYdRreqmu9LSI dD9sWbgcMRcxiIJhXujf/LSTBd3vgU7zE+No0WinVA== X-Received: by 2002:a05:6808:190f:: with SMTP id bf15mr8219469oib.40.1643318170990; Thu, 27 Jan 2022 13:16:10 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 27 Jan 2022 13:16:10 -0800 MIME-Version: 1.0 In-Reply-To: References: <20220125224422.544381-1-dianders@chromium.org> <20220125144316.v2.5.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid> From: Stephen Boyd User-Agent: alot/0.10 Date: Thu, 27 Jan 2022 13:16:10 -0800 Message-ID: Subject: Re: [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1 To: Bjorn Andersson , Doug Anderson , Viresh Kumar Cc: Konrad Dybcio , kgodara@codeaurora.org, Matthias Kaehlcke , Sibi Sankar , Prasad Malisetty , quic_rjendra@quicinc.com, Andy Gross , Rob Herring , devicetree@vger.kernel.org, linux-arm-msm , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Bjorn Andersson (2022-01-25 19:01:31) > On Tue 25 Jan 15:46 PST 2022, Doug Anderson wrote: > > > Hi, > > > > On Tue, Jan 25, 2022 at 2:58 PM Stephen Boyd wrote: > > > > > > Quoting Douglas Anderson (2022-01-25 14:44:22) > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts > > > > new file mode 100644 > > > > index 000000000000..f95273052da0 > > > > --- /dev/null > > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts > > > > @@ -0,0 +1,313 @@ > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > > > +/* > > > > + * Google Herobrine board device tree source > > > > + * > > > > + * Copyright 2022 Google LLC. > > > > + */ > > > > + > > > > +/dts-v1/; > > > > + > > > > +#include "sc7280-herobrine.dtsi" > > > > + > > > > +/ { > > > > + model = "Google Herobrine (rev1+)"; > > > > + compatible = "google,herobrine", "qcom,sc7280"; > > > > > > Can we stop adding "qcom,sc7280" to the board compatible string? It > > > looks out of place. It's the compatible for the SoC and should really be > > > the compatible for the /soc node. > > > > I don't have any objections, but I feel like this is the type of thing > > I'd like Bjorn to have the final say on. What say you, Bjorn? > > > > One practical case I can think of right away, where this matters is in > cpufreq-dt-plat.c where we blocklist qcom,sc7280. > > I don't know if we rely on this in any other places, but I'm not keen on > seeing a bunch of board-specific compatibles sprinkled throughout the > implementation - it's annoying enough having to add each platform to > these drivers. Looking at sc7180, grep only shows cpufreq-dt-plat.c $ git grep qcom,sc7180\" -- drivers drivers/cpufreq/cpufreq-dt-platdev.c: { .compatible = "qcom,sc7180", }, Simplest solution would be to look at / and /soc for a compatible string. $ git grep -W 'soc[^:]*{' -- arch/arm*/boot/dts/ | grep compatible | grep -v "simple-bus" doesn't show many hits. The first hit is "ti,omap-infra" which is actually inside an soc node, but even then I don't see anything that matches the cpufreq-dt-plat.c lists. ----8<----- diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c index ca1d103ec449..32bfe453f8b4 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -179,25 +179,29 @@ static bool __init cpu0_node_has_opp_v2_prop(void) static int __init cpufreq_dt_platdev_init(void) { struct device_node *np = of_find_node_by_path("/"); + struct device_node *soc_np = of_find_node_by_path("/soc"); const struct of_device_id *match; const void *data = NULL; - if (!np) + if (!np && !soc_np) return -ENODEV; match = of_match_node(allowlist, np); - if (match) { + if (match || (match = of_match_node(allowlist, soc_np))) { data = match->data; goto create_pdev; } - if (cpu0_node_has_opp_v2_prop() && !of_match_node(blocklist, np)) + if (cpu0_node_has_opp_v2_prop() && !of_match_node(blocklist, np) && + !of_match_node(blocklist, soc_np)) goto create_pdev; + of_node_put(soc_np); of_node_put(np); return -ENODEV; create_pdev: + of_node_put(soc_np); of_node_put(np); return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt", -1, data,