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
