archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <>
To: Hans de Goede <>,
	Andy Shevchenko <>,
	Shravan S <>
Cc: Mark Gross <>,
	Platform Driver <>,
	"An, Sudhakar" <>
Subject: Re: [PATCH V2 1/1] [x86]: BIOS Dynamic SAR driver for Intel M.2 Modem
Date: Tue, 29 Jun 2021 12:08:56 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 28.06.21 20:20, Hans de Goede wrote:

>> Why not ? Lets collect the actual requirements and talk about some
>> viable solutions (I've already got a few ideas ...)
> Because we don't know the actual requirements yet. This is a very
> young technology and still evolving fast. 

Well, with some background in HF engineering, it's not so hard guessing
in which direction it goes. Of course, there're lots of tiny details,
but I don't think they have huge impact on how such subsys could look

Let's recap, what this is actually for: we wanna limit the RF power for
other reasons than just the regulatory ones - in this case biological
compatibility. There can be other reasons like EM interference or
explosion detection. Indeed we already have these in embedded world,
we just didn't invent a generic control mechanism for that.

In the case of bioprotection of these tablets, the decision is *usually*
made by whether a human being is currently holding it. In this
particular case this seems to be done by certain sensors. But there can
be other scenarios, where it always needs to be active, eg. in an ER.

Question A: where exactly do we have to cap the power ? (which RF)
This depends on the actual board (antenna configuration, wires, etc) and
possibly environmental parameters. (think of external antennas, possibly
with extra amps). In general we need a clean association to the actual
devices to be tuned. For out-of-the-box devices there should be a sane
preset from the vendor, but at some point some operator might tune it.

Question B: what are the exact RF power limits to apply ?
This depends on a lot of factors and needs actual lab measurements.
Certainly, it's the duty of the vendor to do these measurements and
provide scientific data. He should also provide sane defaults, but
operator needs to be able to tune this. External antenna with higher
gain is the most obvious case.

Question C: when to apply which "operation mode" (IOW: which set of
limits to apply right now ? This depends on various factors, depending
on the actual use case. One parameter could be whether some user's
holding the device, but there could be others like are we in a specific
building or room.

While distilling this out, we see that:

a) it hasn't much to do with some specific RF module or even some
    specific vendor. therefore designing something that's just for
    the currently discussed Intel Modems, it's conceptionally wrong
    (even though I appreciate that Intel is sponsoring that kind of

b) the human-user detection is an entirely different field, just like
    ambient or g-sensors. we should split off that topic and look for
    a proper place to do that (does that even need kernel support ?)


1. the solution needs to provide means for capping RF power on certain
    RF devices depending on configurable tables, that can be tuned by
    by operator / system integrator
2. the solution needs to support several "operation modes" that can be
    selected by configurable factors, e.g. whether human is nearby,
    device location, time of day, etc.
3. the vendor shall supply sane defaults (based on actual lab
    measurements) for specific hardware for common scenarios

As things are right now, I don't see that the need to touch the kernel
at all. The most interesting question here is how to get the vendor's
presets. But even if he puts them into acpi tables, we can read them
out from userland by now.

IMHO, the best approach for that would be just collecting the data in
some central place, one package that other tools can just use. We have
similar approach for things like firmware or microcode. Actually, we
already have something similar with tzdata, and we don't let the kernel
try to fetch tz data from all the various authorities.

In summary, I don't see that we have to do anything on kernel side
right now. It's entirely up to userland.

> Also whether we like it
> or not, we don't get to dictate what the involved firmware and
> hardware interfaces get to look like. So any API which we come
> up with must be capable of working with the existing fw and
> hw interfaces as shipped in actual devices.

No, we don't. But we don't need to support all the most weird stuff.
We don't do special hacks for Nvidia's or NI's proprietary crap,
do we ?

What we certainly can do is ignore and blame.

As said, the only new thing that comes in here is extracting the vendors
presets from acpi (if we don't have any better data source). We don't
need any extra kernel support for that.

What Intel can do in this case:
* drop the whole idea of special kernel drivers
* drop the idea of proprietary acpi stuff
* work closely with the board vendors on a public database for the
   sane presets in certain use cases (that I called "operation modes")

> <sigh> we are in no place to make demands here "standard" (non
> chrome-os / android) Linux laptop-os usage is a tiny fraction of the
> market. 

Where did you get this data from ? It might be correct that only few
vendors offer their notebooks specifically for Linux, but that tells
nothing about the actual user numbers. In recent years, the percentage
of Windows users (especialyl on laptops) of my non-tech frieds is
rapidly decreasing - not representative, but shows a strong direction.

But at the beginning of the discussion, especially Chromebooks have been
mentioned as some primary platform (at least for now) - these indeed are
specifically made for Linux. The most likely next category in line are
android smartphones - again Linux. (BTW is there any that runs acpi ?).
And it seems the most push right now coming from Intel, Shravan et al.
He's one of us, Linux kernel folks. So I'm very confident in claming
that we actually do have a great deal of influence on that front now.

> So new features like this are primarily developed on other OS-es
> and typically we either take the firmware interfaces as is, or we don't
> support the feature.

I wouldn't underline that. This particular topic (more precisely some
superset of it) indeed has been implemented on Linux-based embedded
devices long ago. Yet device specific, not standardized. And entirely
in userspace. Nothing that the Kernel community ever needed to care

> You seem to believe in an utopia where we fully control all the layers
> and can design and implement everything to be just perfect, but the
> reality is quite different from this.

In embedded world, we actually are to a very large extent. (at least on
software and custom hardware).

> You also seem to forget that perfect is the enemy of good. This case is
> an excellent example of a case where we cannot design anything close to
> the "perfect" API in one go because we don't have the necessary
> problem-domain information / experience yet.

As mentioned above, we don't need to do that at all. At least for the
kernel. The only thing we *should* do (but that's not a kernel topic) is
finding a common mechanism to retrieve and collect the preset data from
the board vendors. Everything's userland only.


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 -- +49-151-27565287

  reply	other threads:[~2021-06-29 10:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10  7:40 [PATCH V2 0/1] [x86] BIOS SAR Driver for M.2 Intel Modems Shravan S
2021-05-10  7:40 ` [PATCH V2 1/1] [x86]: BIOS Dynamic SAR driver for Intel M.2 Modem Shravan S
2021-06-24 10:24   ` Andy Shevchenko
2021-06-28 15:12     ` Hans de Goede
2021-06-28 17:47       ` Enrico Weigelt, metux IT consult
2021-06-28 18:20         ` Hans de Goede
2021-06-29 10:08           ` Enrico Weigelt, metux IT consult [this message]
2021-06-28 14:45   ` Enrico Weigelt, metux IT consult
2021-07-15 16:20   ` Hans de Goede
2021-07-27 14:38     ` Shravan, S

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