Re: [PATCH v1 3/6] arm64: dts: qcom: talos: Add QSPI support

[Viken Dadhaniya]

On 3/25/2026 3:02 PM, Konrad Dybcio wrote:
> On 3/24/26 9:51 PM, Dmitry Baryshkov wrote:
>> On Tue, Mar 24, 2026 at 06:43:20PM +0530, Viken Dadhaniya wrote:
>>> The Talos (QCS615) platform includes a QSPI controller used for accessing
>>> external flash storage. Add the QSPI OPP table, TLMM pinmux entries, and
>>> the QSPI controller node to enable support for this hardware.
>>>
>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@xxxxxxxxxxxxxxxx>
>>> ---
>>>  arch/arm64/boot/dts/qcom/talos.dtsi | 80 +++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 80 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
>>> index 75716b4a58d6..fd727924b8ca 100644
>>> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
>>> @@ -530,6 +530,25 @@ cdsp_smp2p_in: slave-kernel {
>>>  
>>>  	};
>>>  
>>> +	qspi_opp_table: opp-table-qspi {
>>
>> Why is it not defined inside the QSPI device itself?
> 
> The QSPI device has #address-cells = <1>, so we'd get:
> 
> Warning (spi_bus_reg): /soc@0/spi@88dc000/opp-table-qspi: missing or empty reg property
> 
> Konrad

Yes, I am seeing the same warning when the OPP table is placed inline
under the QSPI node.

Given that opp-table nodes are not addressable bus devices and therefore
do not define a reg property, what would be your preferred way to model
this while keeping the DT warning‑free?

Would placing the OPP table as a sibling of the QSPI node (for example
under the same &soc scope) and referencing it via operating-points-v2 be
acceptable in this case, even though there is only a single QSPI instance?

Thanks for your guidance.

Best regards,
Viken