The secure device(fused) cannot bootup with TPDM_DCC device. So
disable it in DT.

Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p")
Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8775p.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
index 368bcf7c9802..9da62d7c4d27 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
@@ -2440,6 +2440,7 @@ tpdm@4003000 {
 
 			qcom,cmb-element-bits = <32>;
 			qcom,cmb-msrs-num = <32>;
+			status = "disabled";
 
 			out-ports {
 				port {
-- 
2.34.1

On Thu, 19 Dec 2024 10:52:16 +0800, Jie Gan wrote:
> The secure device(fused) cannot bootup with TPDM_DCC device. So
> disable it in DT.
> 
> 

Applied, thanks!

[1/1] arm64: dts: qcom: sa8775p: fix the secure device bootup issue
      commit: 8a6442ec3437083348f32a6159b9a67bf66417bc

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>

On 19.12.2024 3:52 AM, Jie Gan wrote:
> The secure device(fused) cannot bootup with TPDM_DCC device. So
> disable it in DT.
> 
> Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p")
> Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
> ---

I was thinking, is there a QFPROM fuse we could read on both
secure and non-secure devices to determine whether all coresight
components will be accessible, and enable them based on that
information?

Konrad

On 12/20/2024 5:25 AM, Konrad Dybcio wrote:
> On 19.12.2024 3:52 AM, Jie Gan wrote:
>> The secure device(fused) cannot bootup with TPDM_DCC device. So
>> disable it in DT.
>>
>> Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p")
>> Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
>> ---
> 
> I was thinking, is there a QFPROM fuse we could read on both
> secure and non-secure devices to determine whether all coresight
> components will be accessible, and enable them based on that
> information?
> 
There are two known TPDM devices had been disabled on secure device. One 
of these devices is TPDM_DCC. In downstream code, we have an API to 
check the secure status of the device in TPDM's probe function, to avoid 
unintentional enable. The downstream API will check the register that 
controls crash dump functionality in TZ and the crash dump functionality 
is disabled by default on secure devices.

We need to verify if the downstream API is supported by the upstream 
kernel. We plan to upstream a patch to implement this functionality in 
the TPDM driver or any other device's driver that needed the functionality.

For the time being, we need to disable this TPDM device in DT because 
the TPDM_DCC will break the bootup process on secure devices.

> Konrad

Thanks,
Jie

On 20.12.2024 6:51 AM, Jie Gan wrote:
> 
> 
> On 12/20/2024 5:25 AM, Konrad Dybcio wrote:
>> On 19.12.2024 3:52 AM, Jie Gan wrote:
>>> The secure device(fused) cannot bootup with TPDM_DCC device. So
>>> disable it in DT.
>>>
>>> Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p")
>>> Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
>>> ---
>>
>> I was thinking, is there a QFPROM fuse we could read on both
>> secure and non-secure devices to determine whether all coresight
>> components will be accessible, and enable them based on that
>> information?
>>
> There are two known TPDM devices had been disabled on secure device. One of these devices is TPDM_DCC. In downstream code, we have an API to check the secure status of the device in TPDM's probe function, to avoid unintentional enable. The downstream API will check the register that controls crash dump functionality in TZ and the crash dump functionality is disabled by default on secure devices.

That's an "eeeh" type solution, crashdump is a separate thing that may be
enabled independently, and some prod devices from certain vendors actually
do that

> We need to verify if the downstream API is supported by the upstream kernel. We plan to upstream a patch to implement this functionality in the TPDM driver or any other device's driver that needed the functionality.

Please check if there's a coresight-specific fuse instead


> For the time being, we need to disable this TPDM device in DT because the TPDM_DCC will break the bootup process on secure devices.

Yeah, right

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

On 12/23/2024 7:56 PM, Konrad Dybcio wrote:
> On 20.12.2024 6:51 AM, Jie Gan wrote:
>>
>>
>> On 12/20/2024 5:25 AM, Konrad Dybcio wrote:
>>> On 19.12.2024 3:52 AM, Jie Gan wrote:
>>>> The secure device(fused) cannot bootup with TPDM_DCC device. So
>>>> disable it in DT.
>>>>
>>>> Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p")
>>>> Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
>>>> ---
>>>
>>> I was thinking, is there a QFPROM fuse we could read on both
>>> secure and non-secure devices to determine whether all coresight
>>> components will be accessible, and enable them based on that
>>> information?
>>>
>> There are two known TPDM devices had been disabled on secure device. One of these devices is TPDM_DCC. In downstream code, we have an API to check the secure status of the device in TPDM's probe function, to avoid unintentional enable. The downstream API will check the register that controls crash dump functionality in TZ and the crash dump functionality is disabled by default on secure devices.
> 
> That's an "eeeh" type solution, crashdump is a separate thing that may be
> enabled independently, and some prod devices from certain vendors actually
> do that
> 
This solution have been applied because the TPDM_DCC has connection with 
crashdump. But I think you are right, this is not a totally suitable 
solution.


>> We need to verify if the downstream API is supported by the upstream kernel. We plan to upstream a patch to implement this functionality in the TPDM driver or any other device's driver that needed the functionality.
> 
> Please check if there's a coresight-specific fuse instead
I will check it with hardware team.

> 
> 
>> For the time being, we need to disable this TPDM device in DT because the TPDM_DCC will break the bootup process on secure devices.
> 
> Yeah, right
> 
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> Konrad

Thanks,
Jie