Re: [PATCH v3 13/23] arm64: dts: qcom: x1e80100: Fix ADSP memory base and length

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

On 13/12/2024 16:35, Johan Hovold wrote:
> On Fri, Dec 13, 2024 at 03:54:02PM +0100, Krzysztof Kozlowski wrote:
>> The address space in ADSP PAS (Peripheral Authentication Service)
>> remoteproc node should point to the QDSP PUB address space
>> (QDSP6...SS_PUB): 0x0680_0000 with length of 0x10000.
>>
>> 0x3000_0000, value used so far, is the main region of CDSP and was
>> simply copied from other/older DTS.
>>
>> Correct the base address and length, which also moves the node to
>> different place to keep things sorted by unit address.  The diff looks
>> big, but only the unit address and "reg" property were changed.  This
>> should have no functional impact on Linux users, because PAS loader does
>> not use this address space at all.
>>
>> Fixes: 5f2a9cd4b104 ("arm64: dts: qcom: x1e80100: Add ADSP/CDSP remoteproc nodes")
>> Cc: stable@vger.kernel.org
> 
> Why bother with backporting any of these when there is no functional
> impact?


Not sure, I assumed someone might be using kernel DTS from stable
branches in other projects. Kernel is the source of DTS and stable
kernel has the DTS in both stable and fixed way. If 3rd party project
keeps pulling always latest DTS from latest kernel, they will see so
many ABI breaks and so many incompatibilities (we discussed it in
Vienna) that they will probably curse their approach and say "never
again". Using stable branch DTS could be a solution.

Such 3rd party project might actually use above device nodes in their
drivers. It's just some of Linux kernel drivers which do not use them
(other like PIL seems to use addresses).

Plus DTS is used by 3rd party Linux kernels (out of tree), which while
we do not care in a way of driving our development, but we do consider
them possible users. They also might be relying on stable kernel branch
for this.

Best regards,
Krzysztof