Re: [PATCH 0/1] [x86] BIOS SAR Driver for M.2 Intel Modems

From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: "Shravan, S" <s.shravan@intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	"mgross@linux.intel.com" <mgross@linux.intel.com>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>
Cc: "An, Sudhakar" <sudhakar.an@intel.com>
Subject: Re: [PATCH 0/1] [x86] BIOS SAR Driver for M.2 Intel Modems
Date: Mon, 28 Jun 2021 17:23:35 +0200	[thread overview]
Message-ID: <d3ccbd96-7e6b-8fdf-3185-247a73964104@metux.net> (raw)
In-Reply-To: <MWHPR11MB14558B1E81705599C74239E5E3089@MWHPR11MB1455.namprd11.prod.outlook.com>

On 23.06.21 16:12, Shravan, S wrote:

Hi,

>>> 1. Listening to some sensors, which readings may impact the maximum
>>> amount of tx power which the modem may use. What kind of sensors are these ?
>>> Currently chrome-os based devices are using iio for proximity sensors,
>>> with specific labels added to each sensor to tell userspace that they
>>> indicate a human is close to one of the antennas:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
>>> mit/Documentation/ABI/testing/sysfs-bus-iio?id=6505dfab33c519368e54ae7
>>> f3ea1bf4d9916fdc5
>>>
>>> Would it be possible to use this standardized userspace interface for
>>> your use case ?
> 
> [Shravan] Proximity sensors can work in scenarios where there is no other sources of information which can alter the sar handling.
> OEMs have given feedback that the device mode (tablet mode/laptop mode/clamshell etc) also play a part in SAR handling. Hence this
> has to be aggregated with the proximity sensor information. Also such an aggregation is specific to given host platform. As a consequence,
> this is best realized within an entity like embedded controller available on the host platform. This new driver exposes such aggregated SAR
> parameters that needs to be configured on specific RF device.

Since this is totally hardware specific and doesn't even tell us which
radio interface this is about - why do we have to have this incomplete
stuff in acpi and the kernel in the first place ? As things are right
now, this can be completely done in userspace, including the tables.

It would be different if acpi tables could give us some precise and 
generic hardware description, so we could handle this in a generic
way and userland wouldn't even have to care about it.

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