linux-kernel - Re: [RFC PATCH 09/12] drivers: base: reintroduce find

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, 24 Feb 2021 16:30:42 +0100
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     linux-kernel@...r.kernel.org, rafael@...nel.org,
        linus.walleij@...aro.org, bgolaszewski@...libre.com,
        robh+dt@...nel.org, frowand.list@...il.com,
        pantelis.antoniou@...sulko.com, linux-gpio@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [RFC PATCH 09/12] drivers: base: reintroduce find_bus()

On 24.02.21 09:00, Greg KH wrote:

> Have the firmware code do it itself, do nto try to "reach across" like
> this.

By "firmware code" you mean Linux acpi core or the board's bios ?

a) Fixing BIOS would be the cleanest solution, but we cant expect all
    users to do field upgrades. Many of the devices (eg. the customer,
    I've originally wrote the apu board driver for, deployed them in
    really remote locations, sometimes even just reachable by ship,
    heli or horse, litterally)

b) Explicit blacklisting somewhere in apci enumeration code could work,
    but I really hate the idea of such board and bios version specific
    quirks in a place, completely unrelated to the actual board driver.

Actually, I'm also hoping to find a proper way for having those things
in one file per board, in the future. (probably not applicable for
early stuff, or _OSI(Linux), etc)

> And what problem are you really trying to solve here by doing this?

The problem is that *some* bios versions (that came much later, after
pcengines-apuv2 driver went into production) added a few things that
the driver is already doing - different versions doing it differently
(eg. even enumerating gpio connected leds with completely different
names, etc), and still some gpio connected devices missing. Some
versions (just forgot, which one it's been exactly) even enumerate
*some* gpios (and LEDs behind them) as a different device, whose Linux
driver just happens to work. Meanwhile I can't find any reference of
that in the coreboot source, anymore.

As you can see: bios is anything but reliable on that platform.

What I'm trying to achieve: the kernel should behave exactly the
same, no matter what board revision, bios version, kernel version,
etc. (there should be especially no need to have special per-board
quirks in userland, depending on board rev, bios version, kernel
version).

If you've got a better solution, I'll be glad to hear it.

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287