[PATCH V4 0/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem

[PATCH V4 0/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem

[Shravan S]

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 to the User-space using the sysfs_notify 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.

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 sysfs_notify interface.
•	WWAN Device Service listens for sysfs_notify messages and reads the sysfs data and routes them 
	to Modem using MBIM.


Shravan S (1):
  platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem

 .../ABI/testing/sysfs-driver-intc_sar         |  56 ++++
 MAINTAINERS                                   |   7 +
 drivers/platform/x86/Kconfig                  |  15 +
 drivers/platform/x86/Makefile                 |   1 +
 drivers/platform/x86/intel-sar.c              | 317 ++++++++++++++++++
 include/linux/platform_data/x86/intel-sar.h   |  88 +++++
 6 files changed, 484 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intc_sar
 create mode 100644 drivers/platform/x86/intel-sar.c
 create mode 100644 include/linux/platform_data/x86/intel-sar.h


base-commit: 902e7f373fff2476b53824264c12e4e76c7ec02a
-- 
2.17.1

[PATCH V4 1/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem

[Shravan S]

BIOS SAR driver for RF power regulation on Intel M.2 Modem.
Uses ACPI to communicate to BIOS to retrieve SAR information data.
Uses Sysfs to communicate this data to userspace via read and notify.
Userspace will use MBIM interface to enable data communication to modem.

Signed-off-by: Shravan S <s.shravan@intel.com>
---
V4 :
* Code changes based on review comments.
* Logging related changes
* Added Documentation and Maintainer file updates

---
 .../ABI/testing/sysfs-driver-intc_sar         |  56 ++++
 MAINTAINERS                                   |   7 +
 drivers/platform/x86/Kconfig                  |  15 +
 drivers/platform/x86/Makefile                 |   1 +
 drivers/platform/x86/intel-sar.c              | 317 ++++++++++++++++++
 include/linux/platform_data/x86/intel-sar.h   |  88 +++++
 6 files changed, 484 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intc_sar
 create mode 100644 drivers/platform/x86/intel-sar.c
 create mode 100644 include/linux/platform_data/x86/intel-sar.h

diff --git a/Documentation/ABI/testing/sysfs-driver-intc_sar b/Documentation/ABI/testing/sysfs-driver-intc_sar
new file mode 100644
index 000000000000..3acc84a1b3c8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intc_sar
@@ -0,0 +1,56 @@
+What:		/sys/bus/platform/devices/INTC1092:00/intc_reg
+Date:		August 2021
+KernelVersion:	5.13.8
+Contact:	Shravan S <s.shravan@intel.com>,
+		An Sudhakar <sudhakar.an@intel.com>
+Description:
+		Specific Absorption Rate (SAR) regulatory mode is typically
+		derived based on information like mcc/mnc that is available for
+		the currently attached LTE network. A userspace application is
+		required to set the current SAR regulatory mode on the Dynamic SAR
+		driver using this sysfs node. Such an application can also read
+		back using this sysfs node, the currently configured regulatory mode
+		value from the Dynamic SAR driver.
+
+		Acceptable regulatory modes are:
+			==	====
+			0	FCC
+			1	CE
+			2	ISED
+			==	====
+
+		- The regulatory mode value has one of the above values. 
+		- The default regulatory mode used in the driver is 0.
+
+What:		/sys/bus/platform/devices/INTC1092:00/intc_data
+Date:		August 2021
+KernelVersion:	5.13.8
+Contact:	Shravan S <s.shravan@intel.com>,
+		An Sudhakar <sudhakar.an@intel.com>
+Description:
+		This sysfs entry is used to retrieve Dynamic SAR information 
+		emitted/maintained by a BIOS that supports Dynamic SAR.
+
+		The retrieved information is in the order given below:
+		- device_mode
+		- bandtable_index
+		- antennatable_index
+		- sartable_index
+		
+		The above information is sent as integer values separated
+		by a single space. This information can then be pushed to a
+		WWAN modem that uses this to control the transmit signal
+		level using the Band/Antenna/SAR table index information.
+		These parameters are derived/decided by aggregating
+		device-mode like laptop/tablet/clamshell etc. and the
+		proximity-sensor data available to the embedded controller on
+		given host. The regulatory mode configured on Dynamic SAR
+		driver also influences these values.
+		
+		The above information is communicated to a userspace
+		application using EPOLLPRI event on file-descriptor (fd)
+		obtained by opening this sysfs entry. This event is received
+		using the epoll() system call with EPOLLET flag to get only
+		edge triggered events. On getting such an event, application
+		can then read this information from the sysfs node and
+		consume the given information.
diff --git a/MAINTAINERS b/MAINTAINERS
index c9467d2839f5..c38c4b4ae49c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9221,6 +9221,13 @@ L:	platform-driver-x86@vger.kernel.org
 S:	Maintained
 F:	drivers/platform/x86/intel_atomisp2_led.c
 
+INTEL BIOS SAR DRIVER
+M:	Shravan S <s.shravan@intel.com>
+M:	Intel Corporation <linuxwwan@intel.com>
+L:	platform-driver-x86@vger.kernel.org
+S:	Maintained
+F:	drivers/platform/x86/intel-sar.c
+
 INTEL BROXTON PMC DRIVER
 M:	Mika Westerberg <mika.westerberg@linux.intel.com>
 M:	Zha Qipeng <qipeng.zha@intel.com>
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 7d385c3b2239..eb39bc1b4711 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1247,6 +1247,21 @@ config INTEL_PUNIT_IPC
 	  This driver provides support for Intel P-Unit Mailbox IPC mechanism,
 	  which is used to bridge the communications between kernel and P-Unit.
 
+config INTEL_SAR
+	tristate "Intel Specific Absorption Rate Driver"
+	depends on ACPI
+	help
+	  This driver helps to limit the exposure of human body to RF frequency by
+	  providing information to userspace application that will inform 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 will interact with SAR
+	  driver to obtain information like the device mode, Antenna index, baseband index,
+	  SAR table index and use available communication like MBIM interface to enable
+	  data communication to modem for RF power regulation. Enable this config when
+	  given platform needs to support "Dynamic SAR" configuration for a modem available
+	  on the platform.
+
 config INTEL_SCU_IPC
 	bool
 
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 7ee369aab10d..3610ab7a12df 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -123,6 +123,7 @@ obj-$(CONFIG_INTEL_SMARTCONNECT)		+= intel-smartconnect.o
 obj-$(CONFIG_INTEL_SPEED_SELECT_INTERFACE)	+= intel_speed_select_if/
 obj-$(CONFIG_INTEL_TURBO_MAX_3)			+= intel_turbo_max_3.o
 obj-$(CONFIG_INTEL_UNCORE_FREQ_CONTROL)		+= intel-uncore-frequency.o
+obj-$(CONFIG_INTEL_SAR)				+= intel-sar.o
 
 # Intel PMIC / PMC / P-Unit devices
 obj-$(CONFIG_INTEL_BXTWC_PMIC_TMU)	+= intel_bxtwc_tmu.o
diff --git a/drivers/platform/x86/intel-sar.c b/drivers/platform/x86/intel-sar.c
new file mode 100644
index 000000000000..da52a3a5a5a8
--- /dev/null
+++ b/drivers/platform/x86/intel-sar.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Corporation - ACPI for Specific Absorption Rate
+ * Copyright (c) 2021, Intel Corporation.
+ */
+
+#include <asm/errno.h>
+#include <linux/acpi.h>
+#include <linux/kobject.h>
+#include <linux/platform_data/x86/intel-sar.h>
+#include <linux/platform_device.h>
+#include <linux/sysfs.h>
+
+/**
+ * get_int_value - Retrieve Integer values from ACPI Object
+ * Value of the integer from the object of ACPI is obtained.
+ * @obj: acpi_object pointer which has the integer value
+ * @out: output pointer will get integer value
+ * returns 0 on success
+ */
+static int get_int_value(union acpi_object *obj, int *out)
+{
+	if (obj && obj->type == ACPI_TYPE_INTEGER) {
+		*out = (int)obj->integer.value;
+		return 0;
+	} else {
+		return -EIO;
+	}
+}
+
+/**
+ * update_sar_data - sar data is updated based on reg_value
+ * sar_data is updated based on regulatory value
+ * context->reg_value will never exceed MAX_REGULATORY
+ * @context: context pointer used for data
+ */
+static void update_sar_data(struct wwan_sar_context *context)
+{
+	struct wwan_device_mode_configuration *config =
+		&context->config_data[context->reg_value];
+
+	if (config->device_mode_info &&
+	    context->sar_data.device_mode < config->total_dev_mode) {
+		struct wwan_device_mode_info *dev_mode =
+			&config->device_mode_info[context->sar_data.device_mode];
+
+		context->sar_data.antennatable_index = dev_mode->antennatable_index;
+		context->sar_data.bandtable_index = dev_mode->bandtable_index;
+		context->sar_data.sartable_index = dev_mode->sartable_index;
+	}
+}
+
+/**
+ * parse_package - parse package for SAR
+ * @context: context pointer used for data
+ * @item : acpi_object ptr
+ * returns if success or error
+ */
+static acpi_status parse_package(struct wwan_sar_context *context, union acpi_object *item)
+{
+	struct wwan_device_mode_configuration *data;
+	int value = 0, itr = 0, reg = 0, count = 0;
+	union acpi_object *num;
+
+	num = &item->package.elements[0];
+	if ((get_int_value(num, &value) != 0) || (value < 0 || value >= MAX_REGULATORY))
+		return AE_ERROR;
+
+	reg = value;
+
+	data = &context->config_data[reg];
+	if (data->total_dev_mode > MAX_DEV_MODES || data->total_dev_mode == 0)
+		return AE_ERROR;
+	count = (data->total_dev_mode < item->package.count) ?
+			 data->total_dev_mode : item->package.count;
+	data->device_mode_info = kmalloc_array(data->total_dev_mode,
+					       sizeof(struct wwan_device_mode_info), GFP_KERNEL);
+	if (!data->device_mode_info)
+		return AE_ERROR;
+	for (itr = 0; itr < count; itr++) {
+		struct wwan_device_mode_info temp = { 0 };
+
+		num = &item->package.elements[itr + 1];
+		if (num->type != ACPI_TYPE_PACKAGE || num->package.count < TOTAL_DATA)
+			continue;
+		if (get_int_value(&num->package.elements[0], &temp.device_mode) != 0)
+			continue;
+		if (get_int_value(&num->package.elements[1], &temp.bandtable_index) != 0)
+			continue;
+		if (get_int_value(&num->package.elements[2], &temp.antennatable_index) != 0)
+			continue;
+		if (get_int_value(&num->package.elements[3], &temp.sartable_index) != 0)
+			continue;
+		data->device_mode_info[itr] = temp;
+	}
+	return AE_OK;
+}
+
+/**
+ * sar_get_device_mode - Extraction of information from BIOS via DSM calls
+ * Retrieve the current device mode from the BIOS
+ * @device: ACPI device for which to retrieve the data
+ * Returns AE_OK on success
+ */
+static acpi_status sar_get_device_mode(struct platform_device *device)
+{
+	struct wwan_sar_context *context = dev_get_drvdata(&device->dev);
+	acpi_status status = AE_OK;
+	union acpi_object *out;
+	int value = 0;
+	u32 rev = 0;
+
+	out = acpi_evaluate_dsm(context->handle, &context->guid, rev,
+				COMMAND_ID_DEV_MODE, NULL);
+	if (get_int_value(out, &value) != 0) {
+		pr_err("%s: Cmd:%d Failed\n", __func__, COMMAND_ID_DEV_MODE);
+		status = AE_ERROR;
+		goto dev_mode_error;
+	}
+	context->sar_data.device_mode = value;
+	sysfs_notify(&device->dev.kobj, NULL, SYSFS_DATANAME);
+
+dev_mode_error:
+	ACPI_FREE(out);
+	return status;
+}
+
+static const struct acpi_device_id sar_device_ids[] = {
+	{ "INTC1092", 0},
+	{ "", 0},
+};
+
+MODULE_DEVICE_TABLE(acpi, sar_device_ids);
+
+static const struct platform_device_id sar_device_table[] = {
+	{"intc1092", 0},
+	{},
+};
+
+static ssize_t intc_data_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct wwan_sar_context *context = dev_get_drvdata(dev);
+
+	return sysfs_emit(buf, "%d %d %d %d\n", context->sar_data.device_mode,
+		      context->sar_data.bandtable_index,
+		      context->sar_data.antennatable_index,
+		      context->sar_data.sartable_index);
+}
+
+static ssize_t intc_reg_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct wwan_sar_context *context = dev_get_drvdata(dev);
+
+	return sysfs_emit(buf, "%d\n", context->reg_value);
+}
+
+static ssize_t intc_reg_store(struct device *dev, struct device_attribute *attr,
+			      const char *buf, size_t count)
+{
+	struct wwan_sar_context *context = dev_get_drvdata(dev);
+	unsigned long value = 0;
+	int read = 0;
+
+	if (!count) {
+		pr_err("%s count = %d", __func__, (int)count);
+		return -EFAULT;
+	}
+	read = kstrtoul(buf, 0, &value);
+	if (read <= 0) {
+		pr_err("%s Not a integer", __func__);
+		return -EINVAL;
+	}
+	if (value >= MAX_REGULATORY)
+		return -EINVAL;
+	context->reg_value = (int)value;
+	update_sar_data(context);
+	dev_set_drvdata(dev, context);
+	sysfs_notify(&dev->kobj, NULL, SYSFS_DATANAME);
+	return count;
+}
+
+static DEVICE_ATTR_RO(intc_data);
+static DEVICE_ATTR_RW(intc_reg);
+
+static struct attribute *intcsar_attrs[] = {
+	&dev_attr_intc_data.attr,
+	&dev_attr_intc_reg.attr,
+	NULL
+};
+
+static struct attribute_group intcsar_group = {
+	.attrs = intcsar_attrs,
+};
+
+static void sar_notify(acpi_handle handle, u32 event, void *data)
+{
+	struct platform_device *device = data;
+
+	if (event == SAR_EVENT) {
+		if (sar_get_device_mode(device) != AE_OK)
+			pr_err("sar_get_device_mode error");
+	}
+}
+
+static int sar_probe(struct platform_device *device)
+{
+	union acpi_object *out, *item, req;
+	struct wwan_sar_context *context;
+	acpi_status status = AE_OK;
+	u32 rev = 0, reg = 0;
+	int result = 0;
+
+	context = kmalloc(sizeof(*context), GFP_KERNEL);
+	if (!context)
+		return -ENOMEM;
+	memset(context, 0, sizeof(struct wwan_sar_context));
+	context->sar_device = device;
+	dev_set_drvdata(&device->dev, context);
+	if (guid_parse(SAR_DSM_UUID, &context->guid)) {
+		pr_err("%s: UUID error\n", __func__);
+		goto r_free;
+	}
+	context->handle = ACPI_HANDLE(&device->dev);
+	for (reg = 0; reg < MAX_REGULATORY; reg++) {
+		req.type = ACPI_TYPE_INTEGER;
+		req.integer.value = reg;
+		out = acpi_evaluate_dsm(context->handle, &context->guid, rev,
+					COMMAND_ID_CONFIG_TABLE, &req);
+		if (!out) {
+			pr_err("%s: Cmd:%d Failed\n", __func__, COMMAND_ID_CONFIG_TABLE);
+			continue;
+		}
+		if (out->type == ACPI_TYPE_PACKAGE && out->package.count >= 3 &&
+		    out->package.elements[0].type == ACPI_TYPE_INTEGER &&
+		    out->package.elements[1].type == ACPI_TYPE_INTEGER &&
+		    out->package.elements[2].type == ACPI_TYPE_PACKAGE) {
+			context->config_data[reg].version = out->package.elements[0].integer.value;
+			context->config_data[reg].total_dev_mode =
+				out->package.elements[1].integer.value;
+			if (context->config_data[reg].total_dev_mode <= 0 ||
+			    context->config_data[reg].total_dev_mode > MAX_DEV_MODES) {
+				pr_err("total_dev_mode is not within range : %d\n",
+				       context->config_data[reg].total_dev_mode);
+				ACPI_FREE(out);
+				continue;
+			}
+			item = &out->package.elements[2];
+			if (item->package.count > 0)
+				status = parse_package(context, item);
+			else
+				status = AE_ERROR;
+			if (status != AE_OK) {
+				ACPI_FREE(out);
+				continue;
+			}
+		}
+		ACPI_FREE(out);
+	}
+	update_sar_data(context);
+	result = sysfs_create_group(&device->dev.kobj, &intcsar_group);
+	if (result) {
+		pr_err("sysfs creation failed\n");
+		goto r_free;
+	}
+	if (sar_get_device_mode(device) != AE_OK) {
+		pr_err("Failed sar_get_device_mode\n");
+		goto r_sys;
+	}
+	if (acpi_install_notify_handler(ACPI_HANDLE(&device->dev), ACPI_DEVICE_NOTIFY,
+					sar_notify, (void *)device) != AE_OK) {
+		pr_err("Failed acpi_install_notify_handler\n");
+		goto r_sys;
+	}
+	return 0;
+
+r_sys:
+	sysfs_remove_group(&device->dev.kobj, &intcsar_group);
+r_free:
+	kfree(context);
+	return -1;
+}
+
+static int sar_remove(struct platform_device *device)
+{
+	struct wwan_sar_context *context = dev_get_drvdata(&device->dev);
+	int reg = 0;
+
+	acpi_remove_notify_handler(ACPI_HANDLE(&device->dev),
+				   ACPI_DEVICE_NOTIFY, sar_notify);
+	sysfs_remove_group(&device->dev.kobj, &intcsar_group);
+	for (reg = 0; reg < MAX_REGULATORY; reg++) {
+		kfree(context->config_data[reg].device_mode_info);
+		context->config_data[reg].device_mode_info = NULL;
+	}
+	kfree(context);
+	return 0;
+}
+
+MODULE_DEVICE_TABLE(platform, sar_device_table);
+
+static struct platform_driver sar_driver = {
+	.probe = sar_probe,
+	.remove = sar_remove,
+	.driver = {
+			.name = DRVNAME,
+			.owner = THIS_MODULE,
+			/* FOR ACPI HANDLING */
+			.acpi_match_table = ACPI_PTR(sar_device_ids),
+			},
+	.id_table = sar_device_table,
+};
+
+module_platform_driver(sar_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Platform device driver for INTEL MODEM BIOS SAR");
+MODULE_AUTHOR("Shravan S <s.shravan@intel.com>");
diff --git a/include/linux/platform_data/x86/intel-sar.h b/include/linux/platform_data/x86/intel-sar.h
new file mode 100644
index 000000000000..42e93f729d4a
--- /dev/null
+++ b/include/linux/platform_data/x86/intel-sar.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Intel Corporation Header File for Specific Absorption Rate
+ * Copyright (c) 2021, Intel Corporation.
+ */
+#ifndef INTEL_SAR_H
+#define INTEL_SAR_H
+
+#define DRVNAME "intc_sar"
+#define SYSFS_DATANAME "intc_data"
+#define SAR_DSM_UUID "82737E72-3A33-4C45-A9C7-57C0411A5F13"
+#define COMMAND_ID_DEV_MODE 1
+#define COMMAND_ID_CONFIG_TABLE 2
+#define COMMAND_TEST_SET 31
+#define MAX_REGULATORY 3
+#define SAR_EVENT 0x80
+#define MAX_DEV_MODES 50
+#define TOTAL_DATA 4
+
+/**
+ * Structure wwan_device_mode_info - device mode information
+ * Holds the data that needs to be passed to userspace.
+ * The data is updated from the BIOS sensor information.
+ * @device_mode: Specific mode of the device
+ * @bandtable_index: Index of RF band
+ * @antennatable_index: Index of antenna
+ * @sartable_index: Index of SAR
+ */
+struct wwan_device_mode_info {
+		int device_mode;
+		int bandtable_index;
+		int antennatable_index;
+		int sartable_index;
+};
+
+/**
+ * Structure wwan_device_mode_configuration - device configuration
+ * Holds the data that is configured and obtained on probe event.
+ * The data is updated from the BIOS sensor information.
+ * @version: Mode configuration version
+ * @total_dev_mode: Total number of device modes
+ * @device_mode_info: pointer to structure wwan_device_mode_info
+ */
+struct wwan_device_mode_configuration {
+		int version;
+		int total_dev_mode;
+		struct wwan_device_mode_info *device_mode_info;
+};
+
+/**
+ * Structure wwan_supported_info - userspace datastore
+ * Holds the data that is obtained from userspace
+ * The data is updated from the userspace and send value back in the
+ * structure format that is mentioned here.
+ * @reg_mode_needed: regulatory mode set by user for tests
+ * @bios_table_revision: Version of SAR table
+ * @num_supported_modes: Total supported modes based on reg_mode
+ */
+struct wwan_supported_info {
+		int reg_mode_needed;
+		int bios_table_revision;
+		int num_supported_modes;
+};
+
+/**
+ * Structure wwan_sar_context - context of SAR
+ * Holds the complete context as long as the driver is in existence
+ * The context holds instance of the data used for different cases.
+ * @guid: Group id
+ * @handle: store acpi handle
+ * @reg_value: regulatory value
+ * Regulatory 0: FCC, 1: CE, 2: ISED
+ * @sar_device: platform_device type
+ * @sar_kobject: kobject for sysfs
+ * @supported_data: wwan_supported_info struct
+ * @sar_data: wwan_device_mode_info struct
+ * @config_data: wwan_device_mode_configuration array struct
+ */
+struct wwan_sar_context {
+		guid_t guid;
+		acpi_handle handle;
+		int reg_value;
+		struct platform_device *sar_device;
+		struct wwan_supported_info supported_data;
+		struct wwan_device_mode_info sar_data;
+		struct wwan_device_mode_configuration config_data[MAX_REGULATORY];
+};
+#endif /* INTEL_SAR_H */
-- 
2.17.1

Re: [PATCH V4 1/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem

[Andy Shevchenko]

(Side note, most of the comments you may have avoided if you had read
an internal Wiki page about popular style mistakes)
Another note, comments given even against one occurrence of similar
code should be considered for the others.

On Sat, Aug 7, 2021 at 12:24 AM Shravan S <s.shravan@intel.com> wrote:
>
> BIOS SAR driver for RF power regulation on Intel M.2 Modem.
> Uses ACPI to communicate to BIOS to retrieve SAR information data.
> Uses Sysfs to communicate this data to userspace via read and notify.
> Userspace will use MBIM interface to enable data communication to modem.

This is going to be a commit message. The one above is poorly written
to the reader. E.g. what should I get from it "Uses ACPI"? Perhaps
something more elaborative like "It uses ACPI specific methods FOO and
BAR to retrieve this and that information". "The driver provides a
custom sysfs interface, documented in Documentation/...."

...

>  drivers/platform/x86/Kconfig                  |  15 +
>  drivers/platform/x86/Makefile                 |   1 +
>  drivers/platform/x86/intel-sar.c              | 317 ++++++++++++++++++

Use intel/ subfolder, please.

...

> +               derived based on information like mcc/mnc that is available for

What are the mcc/mnc TLAs?

...

> +INTEL BIOS SAR DRIVER
> +M:     Shravan S <s.shravan@intel.com>
> +M:     Intel Corporation <linuxwwan@intel.com>
> +L:     platform-driver-x86@vger.kernel.org
> +S:     Maintained
> +F:     drivers/platform/x86/intel-sar.c

And nicely misses the file brought in this patch...

...

> +#include <asm/errno.h>

Why asm?
Why at the beginning of the inclusion list?

> +#include <linux/acpi.h>

> +#include <linux/kobject.h>
> +#include <linux/platform_data/x86/intel-sar.h>
> +#include <linux/platform_device.h>
> +#include <linux/sysfs.h>

...

> +/**
> + * get_int_value - Retrieve Integer values from ACPI Object

> + * Value of the integer from the object of ACPI is obtained.

Put this after field descriptions. Same for all kernel doc descriptions.

> + * @obj: acpi_object pointer which has the integer value
> + * @out: output pointer will get integer value

> + * returns 0 on success

and that's it?

Besides that, your style doesn't follow the grammar and punctuation rules.

> + */
> +static int get_int_value(union acpi_object *obj, int *out)
> +{
> +       if (obj && obj->type == ACPI_TYPE_INTEGER) {
> +               *out = (int)obj->integer.value;
> +               return 0;

> +       } else {

Redundant.

> +               return -EIO;
> +       }

Besides above, use standard pattern

  if (foo != expected)
    return error;

> +}

...

> +static acpi_status parse_package(struct wwan_sar_context *context, union acpi_object *item)
> +{
> +       struct wwan_device_mode_configuration *data;

> +       int value = 0, itr = 0, reg = 0, count = 0;

Why redundant assignments? They actually may hide the real errors.

> +       union acpi_object *num;
> +
> +       num = &item->package.elements[0];

> +       if ((get_int_value(num, &value) != 0) || (value < 0 || value >= MAX_REGULATORY))

Too many parentheses. " != 0" is redundant (this applies to many
places in the proposed patch).

> +               return AE_ERROR;
> +
> +       reg = value;
> +
> +       data = &context->config_data[reg];
> +       if (data->total_dev_mode > MAX_DEV_MODES || data->total_dev_mode == 0)
> +               return AE_ERROR;
> +       count = (data->total_dev_mode < item->package.count) ?
> +                        data->total_dev_mode : item->package.count;
> +       data->device_mode_info = kmalloc_array(data->total_dev_mode,
> +                                              sizeof(struct wwan_device_mode_info), GFP_KERNEL);
> +       if (!data->device_mode_info)
> +               return AE_ERROR;
> +       for (itr = 0; itr < count; itr++) {
> +               struct wwan_device_mode_info temp = { 0 };
> +
> +               num = &item->package.elements[itr + 1];
> +               if (num->type != ACPI_TYPE_PACKAGE || num->package.count < TOTAL_DATA)
> +                       continue;
> +               if (get_int_value(&num->package.elements[0], &temp.device_mode) != 0)
> +                       continue;
> +               if (get_int_value(&num->package.elements[1], &temp.bandtable_index) != 0)
> +                       continue;
> +               if (get_int_value(&num->package.elements[2], &temp.antennatable_index) != 0)
> +                       continue;
> +               if (get_int_value(&num->package.elements[3], &temp.sartable_index) != 0)
> +                       continue;
> +               data->device_mode_info[itr] = temp;
> +       }
> +       return AE_OK;
> +}

...

> +static acpi_status sar_get_device_mode(struct platform_device *device)
> +{
> +       struct wwan_sar_context *context = dev_get_drvdata(&device->dev);
> +       acpi_status status = AE_OK;
> +       union acpi_object *out;
> +       int value = 0;
> +       u32 rev = 0;
> +
> +       out = acpi_evaluate_dsm(context->handle, &context->guid, rev,
> +                               COMMAND_ID_DEV_MODE, NULL);
> +       if (get_int_value(out, &value) != 0) {

> +               pr_err("%s: Cmd:%d Failed\n", __func__, COMMAND_ID_DEV_MODE);

Use dev_err() and similar when you have a struct device.
The message itself looks like debugging, to be an error you have to
provide a human readable one and without __func__.

> +               status = AE_ERROR;
> +               goto dev_mode_error;
> +       }
> +       context->sar_data.device_mode = value;
> +       sysfs_notify(&device->dev.kobj, NULL, SYSFS_DATANAME);
> +
> +dev_mode_error:
> +       ACPI_FREE(out);
> +       return status;
> +}
> +
> +static const struct acpi_device_id sar_device_ids[] = {
> +       { "INTC1092", 0},

> +       { "", 0},

No comma for terminator, moreover the { } is enough.

> +};

> +

Redundant blank line.

> +MODULE_DEVICE_TABLE(acpi, sar_device_ids);

...

> +static const struct platform_device_id sar_device_table[] = {
> +       {"intc1092", 0},
> +       {},

No comma.

> +};

...

> +static ssize_t intc_reg_store(struct device *dev, struct device_attribute *attr,
> +                             const char *buf, size_t count)
> +{
> +       struct wwan_sar_context *context = dev_get_drvdata(dev);
> +       unsigned long value = 0;
> +       int read = 0;

> +       if (!count) {
> +               pr_err("%s count = %d", __func__, (int)count);
> +               return -EFAULT;
> +       }

Is it ever possible?

> +       read = kstrtoul(buf, 0, &value);
> +       if (read <= 0) {
> +               pr_err("%s Not a integer", __func__);
> +               return -EINVAL;

Don't shadow an error code.

> +       }


> +       if (value >= MAX_REGULATORY)
> +               return -EINVAL;

ERANGE?
EOVERFLOW?

> +       context->reg_value = (int)value;

Why to use unsigned long in then cast to int? Maybe use int in the first place?

> +       update_sar_data(context);

> +       dev_set_drvdata(dev, context);

This seems a misuse of the field.

> +       sysfs_notify(&dev->kobj, NULL, SYSFS_DATANAME);
> +       return count;
> +}

> +

Redundant.

> +static DEVICE_ATTR_RO(intc_data);
> +static DEVICE_ATTR_RW(intc_reg);

Attach each of them to the respective functions.

...

> +static int sar_probe(struct platform_device *device)
> +{
> +       union acpi_object *out, *item, req;
> +       struct wwan_sar_context *context;
> +       acpi_status status = AE_OK;
> +       u32 rev = 0, reg = 0;
> +       int result = 0;

Why assignments?

> +       context = kmalloc(sizeof(*context), GFP_KERNEL);
> +       if (!context)
> +               return -ENOMEM;
> +       memset(context, 0, sizeof(struct wwan_sar_context));

NIH kzalloc().

> +       context->sar_device = device;
> +       dev_set_drvdata(&device->dev, context);

> +       if (guid_parse(SAR_DSM_UUID, &context->guid)) {

Shadowed error code

> +               pr_err("%s: UUID error\n", __func__);
> +               goto r_free;
> +       }
> +       context->handle = ACPI_HANDLE(&device->dev);

> +       for (reg = 0; reg < MAX_REGULATORY; reg++) {
> +               req.type = ACPI_TYPE_INTEGER;
> +               req.integer.value = reg;
> +               out = acpi_evaluate_dsm(context->handle, &context->guid, rev,
> +                                       COMMAND_ID_CONFIG_TABLE, &req);
> +               if (!out) {
> +                       pr_err("%s: Cmd:%d Failed\n", __func__, COMMAND_ID_CONFIG_TABLE);
> +                       continue;
> +               }
> +               if (out->type == ACPI_TYPE_PACKAGE && out->package.count >= 3 &&
> +                   out->package.elements[0].type == ACPI_TYPE_INTEGER &&
> +                   out->package.elements[1].type == ACPI_TYPE_INTEGER &&
> +                   out->package.elements[2].type == ACPI_TYPE_PACKAGE) {
> +                       context->config_data[reg].version = out->package.elements[0].integer.value;
> +                       context->config_data[reg].total_dev_mode =
> +                               out->package.elements[1].integer.value;
> +                       if (context->config_data[reg].total_dev_mode <= 0 ||
> +                           context->config_data[reg].total_dev_mode > MAX_DEV_MODES) {
> +                               pr_err("total_dev_mode is not within range : %d\n",
> +                                      context->config_data[reg].total_dev_mode);
> +                               ACPI_FREE(out);
> +                               continue;
> +                       }
> +                       item = &out->package.elements[2];
> +                       if (item->package.count > 0)
> +                               status = parse_package(context, item);
> +                       else
> +                               status = AE_ERROR;
> +                       if (status != AE_OK) {
> +                               ACPI_FREE(out);
> +                               continue;
> +                       }
> +               }
> +               ACPI_FREE(out);
> +       }

Try to refactor this for-loop. Perhaps even move it out to a function or so.

> +       update_sar_data(context);
> +       result = sysfs_create_group(&device->dev.kobj, &intcsar_group);
> +       if (result) {
> +               pr_err("sysfs creation failed\n");
> +               goto r_free;
> +       }
> +       if (sar_get_device_mode(device) != AE_OK) {
> +               pr_err("Failed sar_get_device_mode\n");
> +               goto r_sys;
> +       }
> +       if (acpi_install_notify_handler(ACPI_HANDLE(&device->dev), ACPI_DEVICE_NOTIFY,
> +                                       sar_notify, (void *)device) != AE_OK) {
> +               pr_err("Failed acpi_install_notify_handler\n");
> +               goto r_sys;
> +       }
> +       return 0;
> +
> +r_sys:
> +       sysfs_remove_group(&device->dev.kobj, &intcsar_group);
> +r_free:
> +       kfree(context);

> +       return -1;

What is this?

> +}
> +
> +static int sar_remove(struct platform_device *device)
> +{
> +       struct wwan_sar_context *context = dev_get_drvdata(&device->dev);
> +       int reg = 0;
> +
> +       acpi_remove_notify_handler(ACPI_HANDLE(&device->dev),
> +                                  ACPI_DEVICE_NOTIFY, sar_notify);
> +       sysfs_remove_group(&device->dev.kobj, &intcsar_group);
> +       for (reg = 0; reg < MAX_REGULATORY; reg++) {
> +               kfree(context->config_data[reg].device_mode_info);
> +               context->config_data[reg].device_mode_info = NULL;
> +       }
> +       kfree(context);
> +       return 0;
> +}

...

> +MODULE_DEVICE_TABLE(platform, sar_device_table);

Besides the misplaced line in the code, why do you need this?

...

> +                       /* FOR ACPI HANDLING */

Useless.

...

> +       .id_table = sar_device_table,

Why?

> +};

> +

Redundant blank line.

...

> +/*
> + * Intel Corporation Header File for Specific Absorption Rate

What is this supposed to mean?

> + * Copyright (c) 2021, Intel Corporation.
> + */

It seems like your header lacks the inclusion of the needed headers
and/or type forward declarations.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V4 0/1] platform/x86: Add BIOS Dynamic SAR driver for Intel M.2 Modem

[Hans de Goede]

Hi,

On 8/6/21 4:56 PM, 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 to the User-space using the sysfs_notify 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.
> 
> 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 sysfs_notify interface.
> •	WWAN Device Service listens for sysfs_notify messages and reads the sysfs data and routes them 
> 	to Modem using MBIM.

Thank you for the new version.

I expect that you will send a new version addressing Andy's remarks,
so I'm going to drop this version from my queue.

Regards,

Hans