Re: [PATCH 2/2] arm64: tegra: disable Tegra234 sce-fabric node

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 13, 2024 at 12:03:05AM +0000, Ivy Huang wrote:
> From: Sumit Gupta <sumitg@xxxxxxxxxx>
> 
> Access to safety cluster engine (SCE) fabric registers was blocked
> by firewall after the introduction of Functional Safety Island in
> Tegra234. After that, any access by software to SCE registers is
> correctly resulting in the internal bus error. However, when CPUs
> try accessing the SCE-fabric registers to print error info,
> another firewall error occurs as the fabric registers are also
> firewall protected. This results in a second error to be printed.
> Disable the SCE fabric node to avoid printing the misleading error.
> The first error info will be printed by the interrupt from the
> fabric causing the actual access.
> 
> Signed-off-by: Sumit Gupta <sumitg@xxxxxxxxxx>
> Signed-off-by: Ivy Huang <yijuh@xxxxxxxxxx>
> ---
>  arch/arm64/boot/dts/nvidia/tegra234.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> index d08faf6bb505..05a771ab1ed5 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> @@ -3815,7 +3815,7 @@
>  			compatible = "nvidia,tegra234-sce-fabric";
>  			reg = <0x0 0xb600000 0x0 0x40000>;
>  			interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> -			status = "okay";
> +			status = "disabled";
>  		};
>  
>  		rce-fabric@be00000 {

Hm... so what's the purpose of having this here if we can't use it? Are
there cases where we might want to access this? For example, could some
firmware *not* firewall this in some use-case, and would we want to use
this for error reporting in such cases?

I don't have a strong opinion on keeping this while being disabled. It
is a fairly small node, so it doesn't hurt much from that point of view,
but overall this patch seems like it's taking the easy way out.

For example if there's ever a case where we might want to use this, then
there should be some other entity (UEFI?) setting status = "disabled" at
runtime. Or perhaps it should be setting status = "okay" if it is not
firewalled. Generally if there's no mechanism that would ever change
status from "disabled" to "okay" at runtime, there's really no point in
having the node in DT.

Thierry

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux