Re: [RFC PATCH 09/12] drivers: base: reintroduce find_bus()
From: Greg KH
Date: Wed Feb 24 2021 - 11:31:58 EST
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