platform-driver-x86.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Hans de Goede <hdegoede@redhat.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Shravan S <s.shravan@intel.com>
Cc: Mark Gross <mgross@linux.intel.com>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	"An, Sudhakar" <sudhakar.an@intel.com>
Subject: Re: [PATCH V2 1/1] [x86]: BIOS Dynamic SAR driver for Intel M.2 Modem
Date: Mon, 28 Jun 2021 19:47:12 +0200	[thread overview]
Message-ID: <f9e0a2b8-6e30-0b85-34d0-16a101da4686@metux.net> (raw)
In-Reply-To: <79bd7236-dec1-ffde-8c23-3a500e04eedd@redhat.com>

On 28.06.21 17:12, Hans de Goede wrote:

Hi,

> I'm not in favor of internal reviews, esp. not when new userspace
> API is involved. I would greatly prefer for the discussions surrounding
> this to be kept public.

ACK. Please do that in open public. There're still lots of things to
discuss that should be discussed in wide public, instead of comittee
behind closed doors.

> I agree that ideally we should have some generic userspace API for this,
> but I'm afraid that ATM that simply is not possible. 

Why not ? Lets collect the actual requirements and talk about some
viable solutions (I've already got a few ideas ...)

> This whole notion of maximum tx power being controlled based on various 
> sensors because of SAR reasons is pretty new (at least in the PC/laptop space) 
> and I know of a couple of vendors who are slapping some adhoc firmware
> interface on the sensor readings for some modem related userspace
> process to consume.

We should bring them here onboard, public discussion. And at the same
time we should make it crystally clear to them that weird adhoc hacks
won't be accepted and just give them very bad reputation and
shitstorming. Seriously, I believe we should go that route, in order
to prevent even more damage by insane firmware interfaces.

Such stuff really doesn't belong into firmware, at least not the way its
done now. Instead there just should be a clear description of the actual
hardware.

> I don't think that it is realistic to try and layer a common userspace
> interface over this at this point time. Actually I believe that even
> trying to do so is a bad idea at this point in time, since this is
> all so new that we are bound to get it badly wrong if we try to
> design a common userspace API for this now.

actually, I don't think it should go through userland (except perhaps
a knob for switching it on/off).

> I also don't want to wait for this to all crystallize out since that
> will likely take years; and we should add support for this under Linux
> in a reasonable time-frame. For laptops which ship with Linux
> pre-installed it is important that there is feature parity between
> Windows and Linux; and support for these new type of modems which need
> this "SAR" integration is one of the biggest pain points with this ATM.

I don't think that this should serve as an excuse for slappy and vendor 
specific solutions, especially when userland is involved.

And if we really do that, then just as some intermediate solution,
and lets put it under staging.


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

  reply	other threads:[~2021-06-28 17:47 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 [this message]
2021-06-28 18:20         ` Hans de Goede
2021-06-29 10:08           ` Enrico Weigelt, metux IT consult
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=f9e0a2b8-6e30-0b85-34d0-16a101da4686@metux.net \
    --to=lkml@metux.net \
    --cc=andy.shevchenko@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=s.shravan@intel.com \
    --cc=sudhakar.an@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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