On Mon, Jun 28, 2021 at 5:07 PM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > On 23.06.21 16:03, Shravan, S wrote: ... > Over the last decades I had to learn to *never* trust BIOS vendors with > anything more than just starting the kernel, especially not trusting in > ACPI tables. And we certainly cant expect people doing field bios > upgrades anytime soon, in case some bios vendor actually manages to > clean up his dirt and publish some actual fixes. But this is not the issue of ACPI, right? Maybe you should stream the energy to complain and file bugs against vendors who do not know how to cook ACPI? > Seriously, I'd rather try to keep bios out of the loop as much as > possible. And if it is involved, let it describe the hardware precisely > instead of doing whatever magic logic. Isn't it applicable to all firmwares? Have you tried to avoid wireless firmwares (rhetorical question)? My point is that we have to live with that fortunately or unfortunately. > (I need to hold back myself for not starting another rant against ACPI > and bios vendors :p) As I said, look into the root cause, while I admit that the ACPI spec is easy to abuse / misinterpret (in some cases). ... > >>> 3. unclear how userland this should really handle in a generic way > >>> --> how does it know which device to tune ? > > > > [Shravan] Userland will configure these parameters on the specific RF device. > > So the user needs to configure it anyways. Why do we have to have that > acpi stuff in the first place ? If we're already involving a device > specific userland, everything (including the tables) could live entirely > in userland - and we would never ever have to touch bios or kernel > anymore. (remember: bios upgrades are always a total mess). > > >>> by the way, who hat that funny idea putting such information into acpi > >>> in such a weird way ? > >> > >> I believe its source is a Windows driver and Windows "culture", they simply > >> don't give a crap about anything else and Windows is a product-oriented platform > >> (each product is unique even if 99.9% of the hardware and firmware is the same > >> with twenty more products). > > Okay, and why are you guys (Intel) following such insanity, when this is > meant for Linux-based devices like Chrome ? I haven't got it. How do you deduct that it's solely for Chrome? Even I'm puzzled with this Yet Another Not So Portable Idea. And above is my speculation about the roots of it. I can't explain it any other way. > Sorry, but doing something just because thousands of programming minions > in Windoze world (which, from my personal expercience, most of them, at > least on driver and firmware side, I have to consider totally > incompetent) are doing it that way, really is a bad excuse and has > nothing to do with decent engineering. > > So, please, let's throw away that arbitrary acpi junk and engineer a > technically good solution. ACPI has nothing to do with any solution to be "junk". If one doesn't know how to cook it, it doesn't prevent them from cooking it in a better way. -- With Best Regards, Andy Shevchenko
