linux-kernel - Re: [PATCH v2 3/4] arm64: dts: ti: Add initial support for J784S4 SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <90cbb65b-389e-95b5-26d8-39bc33f88df6@ti.com>
Date:   Wed, 19 Oct 2022 12:26:31 -0500
From:   Andrew Davis <afd@...com>
To:     Apurva Nandan <a-nandan@...com>, Nishanth Menon <nm@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-gpio@...r.kernel.org>
CC:     Hari Nagalla <hnagalla@...com>
Subject: Re: [PATCH v2 3/4] arm64: dts: ti: Add initial support for J784S4 SoC

On 10/14/22 3:23 AM, Apurva Nandan wrote:
> The J784S4 SoC belongs to the K3 Multicore SoC architecture
> platform, providing advanced system integration in automotive,
> ADAS and industrial applications requiring AI at the network edge.
> This SoC extends the K3 Jacinto 7 family of SoCs with focus on
> raising performance and integration while providing interfaces,
> memory architecture and compute performance for multi-sensor, high
> concurrency applications.
> 

[...]

> +
> +		hwspinlock: hwlock@...00000 {
> +			compatible = "ti,am654-hwspinlock";
> +			reg = <0x00 0x30e00000 0x00 0x1000>;
> +			#hwlock-cells = <1>;
> +			status = "disabled";

Why is this disabled? The node is complete and usable.

I do not know if we settled on a set of rules for disabling nodes
by default in the dtsi, I couldn't find one if we did, but how does
this sound,

If a node in a dtsi file is incomplete, or the described hardware
unusable, without additional information provided by board-level
additions, then the node may be disabled. Otherwise it must be
left in the default enabled state.

Without something like that, we will end up with the same problem
we are trying to fix here, but in reverse, one will have to
enable nodes in board files that would not otherwise need to
refrenced. Worse that sounds like a configuration setting, not a
hardware description, so it would not belong in the device tree.

Same for main_ringacc, main_udmap, cpts, and mcu_navss below.

> +		};
> +

[...]

> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/k3.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +/ {
> +

Extra newline not needed.

Andrew

> +	model = "Texas Instruments K3 J784S4 SoC";