Hi Shravan, On 4/28/21 5:22 AM, Shravan S wrote: > SAR (Specific Absorption Rate) driver is a host driver implemented for Linux > or chrome platform to limit the exposure of human body to RF frequency by informing > the Intel M.2 modem to regulate the RF power based on SAR data obtained from the sensors > captured in the BIOS. ACPI interface exposes this data from the BIOS to SAR driver. The > front end application in userspace ( eg: Modem Manager) will interact with SAR driver > to obtain information like the device mode (Example: tablets, laptops, etx), Antenna index, > baseband index, SAR table index and use available communication like MBIM interface to enable > data communication to modem for RF power regulation. > > The BIOS gets notified about device mode changes through Sensor Driver. This information is > given to a (newly created) WWAN ACPI function driver when there is a device mode change. > The driver then uses a _DSM method to retrieve the required information from BIOS. > This information is then forwarded/multicast to the User-space using the NETLINK interface. > A lookup table is maintained inside the BIOS which suggests the SAR Table index and Antenna > Tuner Table Index values for individual device modes. > > The SAR parameters to be used on the Modem differs for each Regulatory Mode like FCC, CE and ISED. > Hence, the SAR parameters are stored separately in the SMBIOS table in the OEM BIOS, > for each of the Regulatory mode. Regulatory modes will be different based on the region and network > available in that region. If I'm reading the above correct then this code is really doing 2 things in 1 driver: 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/commit/Documentation/ABI/testing/sysfs-bus-iio?id=6505dfab33c519368e54ae7f3ea1bf4d9916fdc5 Would it be possible to use this standardized userspace interface for your use case ? 2. Exporting a table with various information from the BIOS tables to userspace. We do probably need a new userspace API for this, but I'm not sure netlink is the right answer here. Maybe just use a binary sysfs attribute under /sys/bus/platform/devices/INTC1092:00 ? That will make the interface non-generic, but I assume that the table contents are going to be Intel specific anyways so that should be fine. This will also allow simply exporting the table without the kernel needing to parse it. Using netlink is highly unusual for a driver living under platform/drivers/x86; and if you really want to use netlink for this then you should first define a generic protocol which is also going to work for other vendors' modems, which is impossible ATM because we don't know yet what other vendor's modems will need... Regards, Hans > > Hence the entire SAR functionality handling is divided into 2 parts: > > • A ACPI function driver implemented that uses a dedicated ACPI node for WWAN device. > sends notifications whenever there is change in Device Mode. (each OEM has different mechanism > of updating this DEVICE Mode info). This is notified to User-space applications using > the RT-NETLINK interface. > • WWAN Device Service listens for RT-NETLINK messages and routes them to Modem using MBIM. > > Shravan S (1): > [x86]: BIOS Dynamic SAR driver for Intel M.2 Modem > > drivers/platform/x86/Kconfig | 12 + > drivers/platform/x86/Makefile | 1 + > drivers/platform/x86/intel-sar.c | 589 ++++++++++++++++++++ > include/linux/platform_data/x86/intel-sar.h | 118 ++++ > 4 files changed, 720 insertions(+) > create mode 100644 drivers/platform/x86/intel-sar.c > create mode 100644 include/linux/platform_data/x86/intel-sar.h > > > base-commit: cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9 >
