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

[Matthias Schiffer]

On Wed, 2022-03-09 at 11:11 +0200, Tony Lindgren wrote:
> Hi,
> 
> * Matthias Schiffer <matthias.schiffer at ew.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