platform-driver-x86.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
	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 20:20:02 +0200	[thread overview]
Message-ID: <5bcc0591-8b9c-b7c4-cbcd-7b209c4c1b69@redhat.com> (raw)
In-Reply-To: <f9e0a2b8-6e30-0b85-34d0-16a101da4686@metux.net>

Hi Enrico,

On 6/28/21 7:47 PM, Enrico Weigelt, metux IT consult wrote:
> 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 ...)

Because we don't know the actual requirements yet. This is a very
young technology and still evolving fast. 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.

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

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

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.

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.

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

Yes you've made your opinion on this abundantly clear and I must say
that the whole tone of your emails in this thread and the
"I know better then everyone else" attitude in this thread seriously
rubs me the wrong way.

Don't be surprised if I do not answer any further emails from you in
this thread. That won't be because I don't read them, but that will be
because I deliberately choose to not answer them because IMHO your
strong opinion on how everyone must bow to your vision of how exactly
this all must be implemented adds very little of value to this thread.

Regards,

Hans


  reply	other threads:[~2021-06-28 18:20 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 [this message]
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=5bcc0591-8b9c-b7c4-cbcd-7b209c4c1b69@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=lkml@metux.net \
    --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).