On 23.06.21 16:03, Shravan, S wrote:
Hi,
[Shravan] This driver is exposing the SAR parameters solely influenced by
the current status of the host platform and is not specific to any RF device.
Hence it is placed at the path (Platform driver).
I'm confused, how could that be not specific to any RF device ? It can
only make sense at all, if we know which device certain settings need to
be applied to. And even finding reasonable settings highly depends on
lots of hardware and environmental specific factors, starting with the
frequencies and modulation types, signal routing on the board, shielding
characteristics of the machine's case, etc, etc.
By the way: why does it have to be some proprietary ACPI call ?
Why not just publishing some table where the kernel can do the lookup ?
And do we have some (simple!) identification of the board/machine, so we
can easily override these bios values when necessary ?
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.
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.
(I need to hold back myself for not starting another rant against ACPI
and bios vendors :p)
2. its unclear for which air interface is the data really retrieved ?
[Shravan] The initial implementation supports parameters received for WWAN.
Subsequently other RF device types (Wifi, BT) will be supported.
We still don't know for which individual interface these parameters
apply to. I've got machines with multiple WWAN interfaces out in the
field.
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 ?
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.
My requirements for such a solution would be:
* the involvement of bios/acpi shall be limited to some exact
identification, or even better, formal description of the hardware.
(like we do w/ device tree) [*1]
* beyond that, there shall be no need to ever do any bios upgrade,
once this data is initially added
* the formal description shall also indentify the which devices are to
be tuned
* the OS shall be in full control of everything, no hidden firmware
magic at all.
* the solution shall be generic enough so it can be directly applied to
*any* similar hardware, no matter what vendor or fw type.
--mtx
[*1] maybe offtopic: I'm actually considering embedding actual DTB into
the bios and leave acpi just as a legacy fallback - yes, seriously.
--
---
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@xxxxxxxxx -- +49-151-27565287
