Re: [PATCH 0/1] [x86] BIOS SAR Driver for M.2 Intel Modems

["Enrico Weigelt, metux IT consult" <lkml@metux.net>]

On 28.06.21 17:04, Andy Shevchenko wrote:

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

It's an issue of the acpi ecosystem. Mostly the fault of individual hw
vendors that invent weird ways to abuse it for things it never had been
designed. We're here talking with some (representative of some) hw
vendor.

By the way: this actually isn't an issue of these specific intel modems
at all, but the mainboards where some of these could plugged into. At
that point I wonder why we don't hear a word from these guys, it would
be their duty.

> Isn't it applicable to all firmwares? Have you tried to avoid wireless
> firmwares (rhetorical question)? 

It depends. Firmware for external controllers (which is loaded by the
kernel) is an entirely different area. I wish we wouldn't need to care
about it, but it's better us doing that of board or bios vendors,
and we have reasonabley well methods to cope with it.

> My point is that we have to live with
> that fortunately or unfortunately.

It seems that the whole thing is still under development (even sounds
like for now only one company using it in their closed devices), so we
might still have the chance to prevent another nightmare.

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

Yes, and it's used for things it wasn't designed for. Actually, I claim
it was a bad idea in the first place - device tree already has been
there and the superior solution when acpi brought upon us. And even
after that, there way plenty time to introduce a hybrid solution to add
in device tree and leave the old acpi stuff as legacy. This actually
would have been pretty easy to do so.

Yes, ACPI received several useful improvements over the time, but still
very incomplete (anything but well thought), and ... voila ... it's even
embedding pieces of device tree, so it becomes somewhat more useful.
(but still in quite weird ways). At that point I really wonder why we're
not directly using DT ?

One of the major problems at this point is board vendors treating vital
information of device / board composition as some kind of black magic,
instead of just giving us a precise description how things are wired up.

> I haven't got it. How do you deduct that it's solely for Chrome? 

He mentioned in one of the mails. At least it sounded that Chrome
devices are currently the only ones that actually use it.

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

I've been referring about this specific way to put it into acpi. Indeed
acpi could be used to do it in a sane way, but this would look very
differently then. I would declare any way of putting this into acpi
functions as junk - a clean solution would be giving a precise
description of the hardware itself, a purely declarative approach,
that is independent of the actual baseband module.


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287