[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ab00013-0265-4336-bc30-f49492e96424@oss.qualcomm.com>
Date: Thu, 9 Jan 2025 15:10:33 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Stephen Boyd <swboyd@...omium.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, linux-kernel@...r.kernel.org,
patches@...ts.linux.dev, devicetree@...r.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh@...nel.org>, linux-arm-msm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, Arnd Bergmann <arnd@...db.de>,
Conor Dooley <conor+dt@...nel.org>,
Saravana Kannan <saravanak@...gle.com>,
Uwe Kleine-König <u.kleine-koenig@...libre.com>
Subject: Re: [RFC PATCH 6/6] arm64: dts: qcom: sc7180: Add SoC specific
compatible to soc node
On 8.01.2025 2:02 PM, Dmitry Baryshkov wrote:
> On Tue, Jan 07, 2025 at 05:28:43PM -0800, Stephen Boyd wrote:
>> Allow an SoC driver to probe for these devices. Add the SoC specific
>> compatible to the soc node. Leave the original simple-bus compatible in
>> place so that everything keeps working.
>>
>> Cc: Rob Herring <robh@...nel.org>
>> Cc: Bjorn Andersson <andersson@...nel.org>
>> Cc: Konrad Dybcio <konradybcio@...nel.org>
>> Cc: <linux-arm-msm@...r.kernel.org>
>> Signed-off-by: Stephen Boyd <swboyd@...omium.org>
>> ---
>> arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
>> index 76fe314d2ad5..257890a193e6 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
>> @@ -782,7 +782,7 @@ soc: soc@0 {
>> #size-cells = <2>;
>> ranges = <0 0 0 0 0x10 0>;
>> dma-ranges = <0 0 0 0 0x10 0>;
>> - compatible = "simple-bus";
>> + compatible = "qcom,soc-sc7180", "simple-bus";
>
> If the new driver requires this compatible, it will break compatibility
> with older DT files (and it should be avoided).
IIUC the intent here is to provide backwards compatibility through checking
for sth like IS_SOCPM_MANAGED(), sorta like HAS_ACPI_COMPANION(). In that
case, power sequencing would be done by the socpm driver, whereas if it
doesn't hold, the resources would be toggled by the device driver
Konrad
Powered by blists - more mailing lists