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 17:28:20 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "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 Wed, Feb 24, 2021 at 04:30:42PM +0100, Enrico Weigelt, metux IT consult wrote:
> 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 ?

either.

> 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.

We have quirks all over the place, that's normal and how we handle
broken hardware/bios al the time.

> 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)

I don't know what "things" you are referring to here at all.

> > 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.

I have no idea what you are talking about here, you did not describe a
problem :(

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

I do not understand.

> 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.

I really do not understand the problem, sorry.

greg k-h