Re: [RFC PATCH 09/12] drivers: base: reintroduce find_bus()

[Greg KH]

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