linux-kernel - Re: RFC: oftree based setup of composite board devices

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:   Fri, 5 Mar 2021 12:29:38 -0600
From:   Rob Herring <robh@...nel.org>
To:     Frank Rowand <frowand.list@...il.com>
Cc:     "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree@...r.kernel.org, Johan Hovold <johan@...nel.org>
Subject: 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:
> > On 15.02.21 02:12, Frank Rowand wrote:
> > 
> >> 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.
> > 
> >>> 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