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