From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

The binding for this clock controller requires that clock-names are
present. They're not really used by the kernel driver, but they're
marked as required, so someone might have assumed it's done on purpose
(where in reality we try to stay away from that since index-based
references are faster, take up less space and are already widely used)
and referenced it in drivers for another OS.

Hence, do the least painful thing and add the missing entries.

Fixes: 8e266654a2fe ("arm64: dts: qcom: add QCS615 platform")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/talos.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index 75716b4a58d6..6dab0d5dcbb8 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -666,6 +666,9 @@ gcc: clock-controller@100000 {
 			clocks = <&rpmhcc RPMH_CXO_CLK>,
 				 <&rpmhcc RPMH_CXO_CLK_A>,
 				 <&sleep_clk>;
+			clock-names = "bi_tcxo",
+				      "bi_tcxo_ao",
+				      "sleep_clk";
 
 			#clock-cells = <1>;
 			#reset-cells = <1>;

---
base-commit: ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
change-id: 20260126-topic-talos_dt_warn-6596cf638ce9

Best regards,
-- 
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

On Mon, Jan 26, 2026 at 10:45:03AM +0100, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> The binding for this clock controller requires that clock-names are
> present. They're not really used by the kernel driver, but they're
> marked as required, so someone might have assumed it's done on purpose
> (where in reality we try to stay away from that since index-based
> references are faster, take up less space and are already widely used)
> and referenced it in drivers for another OS.
> 
> Hence, do the least painful thing and add the missing entries.

One (me included) would assume that the presense of clock-names imples
that the clocks are fetched according to those names and become very
surprised if they are not. As such I'd suggest fixing the bindings instead.

> 
> Fixes: 8e266654a2fe ("arm64: dts: qcom: add QCS615 platform")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/talos.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 

-- 
With best wishes
Dmitry

On 1/26/26 2:33 PM, Dmitry Baryshkov wrote:
> On Mon, Jan 26, 2026 at 10:45:03AM +0100, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> The binding for this clock controller requires that clock-names are
>> present. They're not really used by the kernel driver, but they're
>> marked as required, so someone might have assumed it's done on purpose
>> (where in reality we try to stay away from that since index-based
>> references are faster, take up less space and are already widely used)
>> and referenced it in drivers for another OS.
>>
>> Hence, do the least painful thing and add the missing entries.
> 
> One (me included) would assume that the presense of clock-names imples
> that the clocks are fetched according to those names and become very
> surprised if they are not. As such I'd suggest fixing the bindings instead.

The reason why I chose otherwise is in the commit message

Let's try to review bindings better next time

Konrad

On Mon, Jan 26, 2026 at 02:46:20PM +0100, Konrad Dybcio wrote:
> On 1/26/26 2:33 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 26, 2026 at 10:45:03AM +0100, Konrad Dybcio wrote:
> >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>
> >> The binding for this clock controller requires that clock-names are
> >> present. They're not really used by the kernel driver, but they're
> >> marked as required, so someone might have assumed it's done on purpose
> >> (where in reality we try to stay away from that since index-based
> >> references are faster, take up less space and are already widely used)
> >> and referenced it in drivers for another OS.
> >>
> >> Hence, do the least painful thing and add the missing entries.
> > 
> > One (me included) would assume that the presense of clock-names imples
> > that the clocks are fetched according to those names and become very
> > surprised if they are not. As such I'd suggest fixing the bindings instead.
> 
> The reason why I chose otherwise is in the commit message

Should we then change the driver to also start using clock-names?

> Let's try to review bindings better next time


-- 
With best wishes
Dmitry

On Mon, Jan 26, 2026 at 07:53:44PM +0200, Dmitry Baryshkov wrote:
> On Mon, Jan 26, 2026 at 02:46:20PM +0100, Konrad Dybcio wrote:
> > On 1/26/26 2:33 PM, Dmitry Baryshkov wrote:
> > > On Mon, Jan 26, 2026 at 10:45:03AM +0100, Konrad Dybcio wrote:
> > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > >>
> > >> The binding for this clock controller requires that clock-names are
> > >> present. They're not really used by the kernel driver, but they're
> > >> marked as required, so someone might have assumed it's done on purpose
> > >> (where in reality we try to stay away from that since index-based
> > >> references are faster, take up less space and are already widely used)
> > >> and referenced it in drivers for another OS.
> > >>
> > >> Hence, do the least painful thing and add the missing entries.
> > > 
> > > One (me included) would assume that the presense of clock-names imples
> > > that the clocks are fetched according to those names and become very
> > > surprised if they are not. As such I'd suggest fixing the bindings instead.
> > 
> > The reason why I chose otherwise is in the commit message
> 
> Should we then change the driver to also start using clock-names?
> 

That's not necessary.

The binding does define that the DeviceTree must contain clock-names,
but it doesn't mandate any implementation to actually consider this
information.

Given that the order of the entries in the "clocks" property is defined
by the binding an implementation can choose to rely on that and ignore
the clock-names.

Regards,
Bjorn

> > Let's try to review bindings better next time
> 
> 
> -- 
> With best wishes
> Dmitry

On Mon, Jan 26, 2026 at 02:42:12PM -0600, Bjorn Andersson wrote:
> On Mon, Jan 26, 2026 at 07:53:44PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Jan 26, 2026 at 02:46:20PM +0100, Konrad Dybcio wrote:
> > > On 1/26/26 2:33 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 26, 2026 at 10:45:03AM +0100, Konrad Dybcio wrote:
> > > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > >>
> > > >> The binding for this clock controller requires that clock-names are
> > > >> present. They're not really used by the kernel driver, but they're
> > > >> marked as required, so someone might have assumed it's done on purpose
> > > >> (where in reality we try to stay away from that since index-based
> > > >> references are faster, take up less space and are already widely used)
> > > >> and referenced it in drivers for another OS.
> > > >>
> > > >> Hence, do the least painful thing and add the missing entries.
> > > > 
> > > > One (me included) would assume that the presense of clock-names imples
> > > > that the clocks are fetched according to those names and become very
> > > > surprised if they are not. As such I'd suggest fixing the bindings instead.
> > > 
> > > The reason why I chose otherwise is in the commit message
> > 
> > Should we then change the driver to also start using clock-names?
> > 
> 
> That's not necessary.
> 
> The binding does define that the DeviceTree must contain clock-names,
> but it doesn't mandate any implementation to actually consider this
> information.

Ack.


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



> 
> Given that the order of the entries in the "clocks" property is defined
> by the binding an implementation can choose to rely on that and ignore
> the clock-names.
> 
> Regards,
> Bjorn
> 
> > > Let's try to review bindings better next time
> > 
> > 
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry