Re: RFC: oftree based setup of composite board devices

On Mon, Feb 15, 2021 at 3:15 AM Frank Rowand [off-list ref] wrote:

On 2/8/21 5:48 PM, Rob Herring wrote:

quoted

On Mon, Feb 8, 2021 at 4:22 PM Enrico Weigelt, metux IT consult
[off-list ref] wrote:

quoted

Hello folks,

here's an RFC for using compiled-in dtb's for initializing board devices
that can't be probed via bus'es or firmware.

I've just been monitoring this thread for several days, hoping that the
discussion would make things more clear for me.

You beat me up to it. I support your comments.

I have to comment to Enrico and others that under overlays for
ACPI-based platforms I meant SSDT overlays, no DT.

Also I have to point out that we have swnode API for the cases where
we need quirks for either ACPI or DT or whatever (not yet present)
firmware quirks.

Disclaimer: I know essentially nothing about ACPI, please excuse improper
naming and misunderstandings on my part.

Why not compile in ACPI data (tables?) instead of devicetree description?

quoted

I'm not convinced compiled in is the mechanism we want.

quoted

Use cases are boards with non-oftree firmware (ACPI, etc) where certain
platform devices can't be directly enumerated via firmware. Traditionally
we had to write board specific drivers that check for board identification
(DMI strings, etc), then initialize the actual devices and their links
(eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT.

This is something I've wanted to see for a while. There's use cases
for DT based systems too. The example I'd like to see supported are
USB serial adapters with downstream serdev, GPIO, I2C, SPI, etc. Then
plug more than one of those in.

My understanding from the past is that the experts (those who understand both
devicetree and ACPI) regard trying to mix devicetree and ACPI in a single
running Linux kernel image is insanity, or at least likely to be confusing,
difficult, and problematic.

From the devicetree side, I expect nightmares for me if devicetree and ACPI
are mixed in a single running kernel image.

quoted

quoted

This patch queue does a bunch of preparations in oftree code, so we can
support multiple fully independent DT's (not using DT overlays). And then
adds a generic driver parses compiled-in fdt blobs, checks for mathing
DMI strings and initializes the devices. As an example, the last patch
adds an alternative implementation for the PC engines APU2/3/4 boa> Disclaimer: I know essentially nothing about ACPI, please excuse improper

rd

quoted

quoted

family based on device tree.

I think there's a couple of approaches we could take. Either support
multiple root nodes as you have done or keep a single root and add
child nodes to them. I think the latter would be less invasive. In the
non-DT cases, we'd just always create an empty skeleton DT. A 3rd
variation on a DT system is we could want to create parent nodes if
they don't exist to attach this DT to so we have a full hierarchy.

I'm not saying which one we should do, just laying out some of the options.

Multiple root nodes and disjoint trees both seem problematic.  Existing
subsystems and drivers expect a single cohesive tree.  Changing that
architecture looks to me to be a painful exercise.

quoted

quoted

The approach can be easily be extended to other kinds of composite devices,
eg. PCI cards or USB dongles.


Yet some drawbacks of the current implementation:

 * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based
   modprobing anyways)

I think we need to use either firmware loading or udev mechanisms to
load the FDTs.

quoted

 * can't reconfigure or attach to devices outside the individual DT's
   (eg. probed by PCI, etc)

Not sure I follow.

Rob

-- 
With Best Regards,
Andy Shevchenko