archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <>
To: "Enrico Weigelt, metux IT consult" <>,
	Shravan S <>,,
Subject: Re: [PATCH V3 1/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem
Date: Wed, 1 Mar 2023 16:09:47 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Enrico,

On 2/17/23 21:27, Enrico Weigelt, metux IT consult wrote:
> On 02.08.21 10:59, Hans de Goede wrote:
> <snip>
>> The driver itself does not limit the tx strength, it only provides information
>> which is used by other software to determine the max safe tx strength, please
>> update the description to reflect this.
> Also missing specification of the actual meaning of this data, and how
> to calculate max safe tx from that.
> I hightly doubt we want proprietary / largely undocumented userland
> abi's in the kernel. The general rule for userland abi is that once
> introduced, shouldn't get any breaking changes, and should be applicable
> to all devices of the same class (independent from hw vendor/model)

This driver has long since been merged and AFAIK is being used
in production now, so this ship has long sailed since.

One remark which I do have here is that this implementation is
actually one of the least bad implementation of the whole SAR
stuff where WWAN modems dynamically adjust there tx power based
on if part of a humanbody is near the antenna or not.

This is all shrouded in secrecy and related to certification
processes in several countries. The way this specific driver /
interface works is that we simply have:

1) Kernel reads human-presence sensor info through standardized
ACPI interface (contents is unknown, but the interface for getting
the blob with readings is standard)

2. ModemManager reads human-presence sensor info from kernel
and sends this to the modem as part of the normal command stream
between ModemManager and the modem. ModemManager needs to be
in the loop here since it owns the interface to the modem.

This is much better then what some other WWAN modem vendors
have been trying to push where the process involves not only
mystery firmware APIs, but also a closed-source userspace process
to manage the dynamic SAR bits. So Intel's implementation where
all we need to do is to proxy between the BIOS/EC firmware and
the modem (because the EC cannot talk directly to the modem)
is actually pretty decent (compared to the other stuff).



  parent reply	other threads:[~2023-03-01 15:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02  5:01 [PATCH V3 0/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem Shravan S
2021-06-02  5:01 ` [PATCH V3 1/1] " Shravan S
2021-08-02  8:59   ` Hans de Goede
     [not found]     ` <>
2023-03-01 15:09       ` Hans de Goede [this message]
2021-08-02 10:09   ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).