Re: RFC: oftree based setup of composite board devices

On Wed, Feb 24, 2021 at 05:14:10PM -0600, Frank Rowand wrote:

On 2/24/21 7:00 AM, Enrico Weigelt, metux IT consult wrote:

quoted

On 15.02.21 02:12, Frank Rowand wrote:

quoted

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

The problem is a bit more complex than it might seem.

Let's take the APU2/37/4 boards as an example. They've got some aux
devices, eg. some gpio controller, and some things (leds, keys, reset
lines, etc) attached to it.

Now we've got lots of different bios versions in the field,
enumerating only some of the devices. For example, older ones didn't
even contain the gpio, later ones added just gpio, other ones just
added LEDs (with different names than the Linux driver already mainlined
and field-deployed at that time), but still other lines unhandled, etc, etc. etc.

A big mess :( And I can't ask everybody to do bios uprade on devices far
out in the field (litterally open field, sometimes offshore, ...). So, I
need a usable solution, that's also maintainable, w/o testing each
single combination of board, bios, etc. IOW: without relying on bios
(except for board identification)

OTOH, I'm also looking for a solution get rid writing those kind of
relatively huge board drivers, that pretty are much like old fashioned
board files from pre-DT times - just made up of lots of tables and
a few trivial register-something calls. Sounds pretty much like the
original use case of oftree.

The primary difference between classic oftree and this scanario:
* this is additional to existing platform information, which is
  incomplete or even incorrect (and that can't be fixed)
* extra carrier boards that are detected by other means, but no
  enumeration of the devices on it.

quoted

quoted

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.

Since you have persisted, a more referenced and emphatic "no" to mixing ACPI
and devicetree:

  https://elinux.org/Device_Tree_Linux#mixing_devicetree_and_ACPI

The 'no' is for mixing the 2. Despite the no, it's been happening 
anyways. That's mostly been the reusing DT bindings in ACPI tables. I 
won't review such bindings if I realize that's what they are, but 
usually that's not evident.

This is a bit different I think where both ACPI and DT are used, but 
they are totally disjoint. I don't have any issue with that. Why would 
we want to force 2 different firmware descriptions for something 
otherwise independent of the base system's firmware. Maybe that's not 
exactly the case here, but the same changes to the DT code are needed 
(unless you have a better solution for my example than multiple roots). 
If someone wants to implement the changes that align with what I want, 
then I don't really care what their motivation is.

Rob