linux-kernel - Re: [PATCH v2 1/2] arm64: dts: ti: k3-am65: disable optional peripherals by default

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]

Date:   Wed, 09 Mar 2022 12:10:50 +0100
From:   Matthias Schiffer <matthias.schiffer@...tq-group.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Rob Herring <robh+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Olof Johansson <olof@...om.net>, soc@...nel.org,
        Vignesh Raghavendra <vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>, jan.kiszka@...mens.com,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Nishanth Menon <nm@...com>
Subject: Re: [PATCH v2 1/2] arm64: dts: ti: k3-am65: disable optional
 peripherals by default

On Wed, 2022-03-09 at 11:11 +0200, Tony Lindgren wrote:
> Hi,
> 
> * Matthias Schiffer <matthias.schiffer@...tq-group.com> [220228
> 10:29]:
> > AFAICT, disabling non-operatational devices in the board DTS
> > instead of
> > the SoC DTSI is worse than the alternatives in every way:
> > 
> > - Verbose board DTS: You have to think about all the devices that
> > exist
> > in the SoC, not just the ones you want to use
> > - Adding new nodes without `status = "disabled" to SoC DTSI can
> > potentially cause issues on dependent boards
> > - It doesn't solve the issues that not having `status = "disabled"`
> > in
> > the DTSI is supposed to solve
> 
> My preference is the least amount of tinkering in the dts files
> naturally :) It really does not matter if the extra dts churn is to
> enable or disable devices, it should not be needed at all.
> 
> To summarize, my main point really is the following:
> 
> There should not be any need to tag the SoC internal devices with
> anything
> in the dts files. The device drivers should be able to just deal with
> the
> situation. IMO devices should be tagged with disabled or reserved
> when
> they are not accessible for example because of being used by secure
> mode
> for example. If the the status needs to be set to anything, it really
> is
> a symptom of incomplete handling somewhere.
> 
> Regards,
> 
> Tony

Hi Tony,

while I agree that it would be great if drivers could just detect when
hardware is not available, this is simply not how most drivers work -
when you instantiate the driver via a non-disabled(/reserved/...) DT
node, the driver expects a usable device.

Especially for busses like I2C, there is no way for a driver to
reliably detect whether the bus is usable or not. (There are several
states that can't really be distinguished: Is pinmuxing missing, or
does the device not need any muxing? Is a line low because it is not
actually connected to anything, or is there another master currently
using the bus, or is the bus stuck due to a faulty device?)

Which is why it is the convention for SoC DTSI files disable nodes for
devices that may be unusable. Taking UARTs as an example, a quick grep
for "serial@" nodes in arch/arm/boot/dts/*.dtsi and
arch/arm64/boot/dts/*/*.dtsi shows that the vast majority of these
nodes is disabled by default.

Regards,
Matthias