Re: [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1
From: Bjorn Andersson <hidden>
Date: 2022-01-31 16:41:53
Also in:
linux-arm-msm, lkml
On Thu 27 Jan 15:16 CST 2022, Stephen Boyd wrote:
Quoting Bjorn Andersson (2022-01-25 19:01:31)quoted
On Tue 25 Jan 15:46 PST 2022, Doug Anderson wrote:quoted
Hi, On Tue, Jan 25, 2022 at 2:58 PM Stephen Boyd [off-list ref] wrote:quoted
Quoting Douglas Anderson (2022-01-25 14:44:22)quoted
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
Good, then we handle all other platform specifics in drivers using platform-specific compatibles.
$ 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.You mean that / would contain the device's compatible and /soc the soc's compatible? I'm afraid I don't see how this would help you - you still need the compatible in the dts, just now in two places. Either we leave it as is - which follows my interpretation of what the DT spec says - or we (and the DT maitainers) agree that it shouldn't be there (because this dtb won't run on any random qcom,sc7180 anyways) at all. Regards, Bjorn
quoted hunk ↗ jump to hunk
$ 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.cb/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,