* [PATCH v2 0/4] add custom hinge sensor support
@ 2020-11-19 10:03 Ye Xiang
2020-11-19 10:03 ` [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support Ye Xiang
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Ye Xiang @ 2020-11-19 10:03 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada
Cc: linux-input, linux-iio, linux-kernel, Ye Xiang
Here three separate iio devices are presented which presents angle for
hinge, keyboard and screen.
This driver works on devices with Intel integrated sensor hub, where
hinge sensor is presented using a custom sensor usage id.
Here the angle is presented in degrees, which is converted to radians.
Changes since v1:
- fixed errors reported by lkp
Ye Xiang (4):
HID: hid-sensor-custom: Add custom sensor iio support
iio: hid-sensor-trigger: Decrement runtime pm enable count on driver
removal
iio: hid-sensor-trigger: Use iio->trig instead trig field internal
structure
iio: hid-sensors: Add hinge sensor driver
drivers/hid/hid-sensor-custom.c | 170 ++++++++
.../hid-sensors/hid-sensor-attributes.c | 2 +
.../common/hid-sensors/hid-sensor-trigger.c | 8 +-
drivers/iio/position/Kconfig | 16 +
drivers/iio/position/Makefile | 3 +
.../iio/position/hid-sensor-custom-hinge.c | 412 ++++++++++++++++++
include/linux/hid-sensor-ids.h | 39 ++
7 files changed, 647 insertions(+), 3 deletions(-)
create mode 100644 drivers/iio/position/hid-sensor-custom-hinge.c
--
2.17.1
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support
2020-11-19 10:03 [PATCH v2 0/4] add custom hinge sensor support Ye Xiang
@ 2020-11-19 10:03 ` Ye Xiang
2020-11-21 17:21 ` Jonathan Cameron
2020-11-19 10:03 ` [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal Ye Xiang
` (2 subsequent siblings)
3 siblings, 1 reply; 25+ messages in thread
From: Ye Xiang @ 2020-11-19 10:03 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada
Cc: linux-input, linux-iio, linux-kernel, Ye Xiang
Currently custom sensors properties are not decoded and it is up to
user space to interpret.
Some manufacturers already standardized the meaning of some custom sensors.
They can be presented as a proper IIO sensor. We can identify these sensors
based on manufacturer and serial number property in the report.
This change is identifying hinge sensor when the manufacturer is "INTEL".
This creates a platform device so that a sensor driver can be loaded to
process these sensors.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
---
drivers/hid/hid-sensor-custom.c | 170 ++++++++++++++++++++++++++++++++
include/linux/hid-sensor-ids.h | 39 ++++++++
2 files changed, 209 insertions(+)
diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
index 4d25577a8573..bb96d9c09daf 100644
--- a/drivers/hid/hid-sensor-custom.c
+++ b/drivers/hid/hid-sensor-custom.c
@@ -4,6 +4,7 @@
* Copyright (c) 2015, Intel Corporation.
*/
+#include <linux/ctype.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -21,6 +22,7 @@
#define HID_CUSTOM_TOTAL_ATTRS (HID_CUSTOM_MAX_CORE_ATTRS + 1)
#define HID_CUSTOM_FIFO_SIZE 4096
#define HID_CUSTOM_MAX_FEATURE_BYTES 64
+#define HID_SENSOR_USAGE_LENGTH (4 + 1)
struct hid_sensor_custom_field {
int report_id;
@@ -50,6 +52,8 @@ struct hid_sensor_custom {
struct kfifo data_fifo;
unsigned long misc_opened;
wait_queue_head_t wait;
+ struct platform_device *custom_pdev;
+ bool custom_pdev_exposed;
};
/* Header for each sample to user space via dev interface */
@@ -746,11 +750,159 @@ static void hid_sensor_custom_dev_if_remove(struct hid_sensor_custom
}
+/*
+ * use sensors luid which is defined in FW, such as ISH,
+ * to identify sensor.
+ */
+static char *known_sensor_luid[] = { "020B000000000000" };
+
+static int get_luid_table_index(unsigned char *usage_str)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(known_sensor_luid); i++) {
+ if (!strncmp(usage_str, known_sensor_luid[i],
+ strlen(known_sensor_luid[i])))
+ return i;
+ }
+
+ return -1;
+}
+
+static int get_known_custom_sensor_index(struct hid_sensor_hub_device *hsdev)
+{
+ struct hid_sensor_hub_attribute_info sensor_manufacturer = { 0 };
+ struct hid_sensor_hub_attribute_info sensor_luid_info = { 0 };
+ int report_size;
+ int ret;
+ u16 *w_buf;
+ int w_buf_len;
+ char *buf;
+ int buf_len;
+ int i;
+ int index;
+
+ w_buf_len = sizeof(u16) * HID_CUSTOM_MAX_FEATURE_BYTES;
+ buf_len = sizeof(char) * HID_CUSTOM_MAX_FEATURE_BYTES;
+ w_buf = kzalloc(w_buf_len, GFP_KERNEL);
+ if (!w_buf)
+ return -1;
+
+ buf = kzalloc(buf_len, GFP_KERNEL);
+ if (!buf) {
+ kfree(w_buf);
+ return -1;
+ }
+
+ /* get manufacturer info */
+ ret = sensor_hub_input_get_attribute_info(
+ hsdev, HID_FEATURE_REPORT, hsdev->usage,
+ HID_USAGE_SENSOR_PROP_MANUFACTURER, &sensor_manufacturer);
+ if (ret < 0)
+ goto err_out;
+
+ report_size =
+ sensor_hub_get_feature(hsdev, sensor_manufacturer.report_id,
+ sensor_manufacturer.index, w_buf_len,
+ w_buf);
+ if (report_size <= 0) {
+ hid_err(hsdev->hdev,
+ "Failed to get sensor manufacturer info %d\n",
+ report_size);
+ goto err_out;
+ }
+
+ /* convert from wide char to char */
+ for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
+ buf[i] = (char)w_buf[i];
+
+ /* ensure it's ISH sensor */
+ if (strncmp(buf, "INTEL", strlen("INTEL")))
+ goto err_out;
+
+ memset(w_buf, 0, w_buf_len);
+ memset(buf, 0, buf_len);
+
+ /* get real usage id */
+ ret = sensor_hub_input_get_attribute_info(
+ hsdev, HID_FEATURE_REPORT, hsdev->usage,
+ HID_USAGE_SENSOR_PROP_SERIAL_NUM, &sensor_luid_info);
+ if (ret < 0)
+ goto err_out;
+
+ report_size = sensor_hub_get_feature(hsdev, sensor_luid_info.report_id,
+ sensor_luid_info.index, w_buf_len,
+ w_buf);
+ if (report_size <= 0) {
+ hid_err(hsdev->hdev, "Failed to get real usage info %d\n",
+ report_size);
+ goto err_out;
+ }
+
+ /* convert from wide char to char */
+ for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
+ buf[i] = (char)w_buf[i];
+
+ if (strlen(buf) != strlen(known_sensor_luid[0]) + 5) {
+ hid_err(hsdev->hdev,
+ "%s luid length not match %zu != (%zu + 5)\n", __func__,
+ strlen(buf), strlen(known_sensor_luid[0]));
+ goto err_out;
+ }
+
+ /* get table index with luid (not matching 'LUID: ' in luid) */
+ index = get_luid_table_index(&buf[5]);
+ kfree(w_buf);
+ kfree(buf);
+ return index;
+
+err_out:
+ kfree(w_buf);
+ kfree(buf);
+ return -1;
+}
+
+static struct platform_device *
+register_platform_device(struct platform_device *pdev,
+ struct hid_sensor_hub_device *hsdev, int index)
+{
+ char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
+ struct platform_device *custom_pdev;
+ const char *dev_name;
+ char *c;
+ int ret;
+
+ /* copy real usage id */
+ memcpy(real_usage, known_sensor_luid[index], 4);
+
+ /* usage id are all lowcase */
+ for (c = real_usage; *c != '\0'; c++)
+ *c = tolower(*c);
+
+ /* HID-SENSOR-INT-REAL_USAGE_ID */
+ dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s", real_usage);
+ if (!dev_name)
+ return NULL;
+
+ custom_pdev = platform_device_register_data(pdev->dev.parent, dev_name,
+ PLATFORM_DEVID_NONE, hsdev,
+ sizeof(*hsdev));
+ kfree(dev_name);
+ ret = PTR_ERR_OR_ZERO(custom_pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "platform_device_register_data failed ret:%d\n", ret);
+ return NULL;
+ }
+
+ return custom_pdev;
+}
+
static int hid_sensor_custom_probe(struct platform_device *pdev)
{
struct hid_sensor_custom *sensor_inst;
struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
int ret;
+ int index;
sensor_inst = devm_kzalloc(&pdev->dev, sizeof(*sensor_inst),
GFP_KERNEL);
@@ -764,6 +916,19 @@ static int hid_sensor_custom_probe(struct platform_device *pdev)
sensor_inst->pdev = pdev;
mutex_init(&sensor_inst->mutex);
platform_set_drvdata(pdev, sensor_inst);
+
+ index = get_known_custom_sensor_index(hsdev);
+ if (index >= 0) {
+ sensor_inst->custom_pdev =
+ register_platform_device(pdev, hsdev, index);
+ if (sensor_inst->custom_pdev) {
+ sensor_inst->custom_pdev_exposed = true;
+ return 0;
+ }
+
+ dev_err(&pdev->dev, "register_platform_device failed\n");
+ }
+
ret = sensor_hub_register_callback(hsdev, hsdev->usage,
&sensor_inst->callbacks);
if (ret < 0) {
@@ -802,6 +967,11 @@ static int hid_sensor_custom_remove(struct platform_device *pdev)
struct hid_sensor_custom *sensor_inst = platform_get_drvdata(pdev);
struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
+ if (sensor_inst->custom_pdev_exposed) {
+ platform_device_unregister(sensor_inst->custom_pdev);
+ return 0;
+ }
+
hid_sensor_custom_dev_if_remove(sensor_inst);
hid_sensor_custom_remove_attributes(sensor_inst);
sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
index 530c09f3e64a..46db3056f04b 100644
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@ -128,6 +128,10 @@
#define HID_USAGE_SENSOR_UNITS_DEGREES_PER_SECOND 0x15
/* Common selectors */
+#define HID_USAGE_SENSOR_PROP_DESC 0x200300
+#define HID_USAGE_SENSOR_PROP_FRIENDLY_NAME 0x200301
+#define HID_USAGE_SENSOR_PROP_SERIAL_NUM 0x200307
+#define HID_USAGE_SENSOR_PROP_MANUFACTURER 0x200305
#define HID_USAGE_SENSOR_PROP_REPORT_INTERVAL 0x20030E
#define HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS 0x20030F
#define HID_USAGE_SENSOR_PROP_SENSITIVITY_RANGE_PCT 0x200310
@@ -159,4 +163,39 @@
#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x200840
#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x200841
+/* Custom Sensor (2000e1) */
+#define HID_USAGE_SENSOR_HINGE 0x20020B
+#define HID_USAGE_SENSOR_DATA_FIELD_LOCATION 0x200400
+#define HID_USAGE_SENSOR_DATA_FIELE_TIME_SINCE_SYS_BOOT 0x20052B
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_USAGE 0x200541
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE 0x200543
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 0x200544
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2 0x200545
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3 0x200546
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_4 0x200547
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_5 0x200548
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_6 0x200549
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_7 0x20054A
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_8 0x20054B
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_9 0x20054C
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_10 0x20054D
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_11 0x20054E
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_12 0x20054F
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_13 0x200550
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_14 0x200551
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_15 0x200552
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_16 0x200553
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_17 0x200554
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_18 0x200555
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_19 0x200556
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_20 0x200557
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_21 0x200558
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_22 0x200559
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_23 0x20055A
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_24 0x20055B
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_25 0x20055C
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_26 0x20055D
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_27 0x20055E
+#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_28 0x20055F
+
#endif
--
2.17.1
^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal
2020-11-19 10:03 [PATCH v2 0/4] add custom hinge sensor support Ye Xiang
2020-11-19 10:03 ` [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support Ye Xiang
@ 2020-11-19 10:03 ` Ye Xiang
2020-11-21 17:22 ` Jonathan Cameron
2020-11-19 10:03 ` [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure Ye Xiang
2020-11-19 10:03 ` [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver Ye Xiang
3 siblings, 1 reply; 25+ messages in thread
From: Ye Xiang @ 2020-11-19 10:03 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada
Cc: linux-input, linux-iio, linux-kernel, Ye Xiang
To avoid pm_runtime_disable called repeatedly by hid sensor drivers,
decrease runtime pm enable count after call it.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
---
drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
index ff375790b7e8..30340abcbc8d 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -227,8 +227,10 @@ static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
struct hid_sensor_common *attrb)
{
- if (atomic_read(&attrb->runtime_pm_enable))
+ if (atomic_read(&attrb->runtime_pm_enable)) {
pm_runtime_disable(&attrb->pdev->dev);
+ atomic_dec(&attrb->runtime_pm_enable);
+ }
pm_runtime_set_suspended(&attrb->pdev->dev);
pm_runtime_put_noidle(&attrb->pdev->dev);
--
2.17.1
^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure
2020-11-19 10:03 [PATCH v2 0/4] add custom hinge sensor support Ye Xiang
2020-11-19 10:03 ` [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support Ye Xiang
2020-11-19 10:03 ` [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal Ye Xiang
@ 2020-11-19 10:03 ` Ye Xiang
2020-11-21 17:33 ` Jonathan Cameron
2020-11-19 10:03 ` [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver Ye Xiang
3 siblings, 1 reply; 25+ messages in thread
From: Ye Xiang @ 2020-11-19 10:03 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada
Cc: linux-input, linux-iio, linux-kernel, Ye Xiang
Use iio->trig instead of attrb->trig as parameter of iio_trigger_unregister
and iio_trigger_free. This allows one HID sensor driver to create
multiple iio devices. In this case common attributes are shared and
there can be one instance for the structure containing common attributes
for all iio devices.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
---
drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
index 30340abcbc8d..bb5e7c8ff15b 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -236,8 +236,8 @@ void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
pm_runtime_put_noidle(&attrb->pdev->dev);
cancel_work_sync(&attrb->work);
- iio_trigger_unregister(attrb->trigger);
- iio_trigger_free(attrb->trigger);
+ iio_trigger_unregister(indio_dev->trig);
+ iio_trigger_free(indio_dev->trig);
iio_triggered_buffer_cleanup(indio_dev);
}
EXPORT_SYMBOL(hid_sensor_remove_trigger);
--
2.17.1
^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-19 10:03 [PATCH v2 0/4] add custom hinge sensor support Ye Xiang
` (2 preceding siblings ...)
2020-11-19 10:03 ` [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure Ye Xiang
@ 2020-11-19 10:03 ` Ye Xiang
2020-11-21 17:56 ` Jonathan Cameron
3 siblings, 1 reply; 25+ messages in thread
From: Ye Xiang @ 2020-11-19 10:03 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada
Cc: linux-input, linux-iio, linux-kernel, Ye Xiang
The Hinge sensor is a common custom sensor on laptops. It calculates
the angle between the lid (screen) and the base (keyboard). In addition,
it also exposes screen and the keyboard angels with respect to the
ground. Applications can easily get laptop's status in space through
this sensor, in order to display appropriate user interface.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
---
.../hid-sensors/hid-sensor-attributes.c | 2 +
drivers/iio/position/Kconfig | 16 +
drivers/iio/position/Makefile | 3 +
.../iio/position/hid-sensor-custom-hinge.c | 412 ++++++++++++++++++
4 files changed, 433 insertions(+)
create mode 100644 drivers/iio/position/hid-sensor-custom-hinge.c
diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
index 442ff787f7af..5b822a4298a0 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
@@ -71,6 +71,8 @@ static struct {
{HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES, 1000, 0},
{HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
+ {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
+ {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0, 17453293},
};
static void simple_div(int dividend, int divisor, int *whole,
diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
index eda67f008c5b..0346f6f2b422 100644
--- a/drivers/iio/position/Kconfig
+++ b/drivers/iio/position/Kconfig
@@ -16,4 +16,20 @@ config IQS624_POS
To compile this driver as a module, choose M here: the module
will be called iqs624-pos.
+config HID_SENSOR_CUSTOM_HINGE
+ depends on HID_SENSOR_HUB
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ select HID_SENSOR_IIO_COMMON
+ select HID_SENSOR_IIO_TRIGGER
+ tristate "HID Hinge"
+ help
+ This sensor present three angles, hinge angel, screen angles
+ and keyboard angle respect to horizon (ground).
+ Say yes here to build support for the HID SENSOR CUSTOM
+ HINGE.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hid-sensor-custom-hinge.
+
endmenu
diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
index 3cbe7a734352..7a6225977a01 100644
--- a/drivers/iio/position/Makefile
+++ b/drivers/iio/position/Makefile
@@ -5,3 +5,6 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
+
+obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
+ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c b/drivers/iio/position/hid-sensor-custom-hinge.c
new file mode 100644
index 000000000000..a91b333f36fa
--- /dev/null
+++ b/drivers/iio/position/hid-sensor-custom-hinge.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HID Sensors Driver
+ * Copyright (c) 2020, Intel Corporation.
+ */
+#include <linux/hid-sensor-hub.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/iio.h>
+#include <linux/platform_device.h>
+
+#include "hid-sensor-trigger.h"
+
+/* Channel definitions */
+static const struct iio_chan_spec hinge_channels[] = {
+ { .type = IIO_ANGL,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type =
+ BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) | BIT(IIO_CHAN_INFO_HYSTERESIS),
+ .scan_type.realbits = 16,
+ .scan_type.storagebits = 32,
+ .scan_type.sign = 's',
+ .scan_index = 0 },
+
+ IIO_CHAN_SOFT_TIMESTAMP(1)
+};
+
+struct hinge_state {
+ struct iio_dev *indio_dev;
+ struct hid_sensor_hub_attribute_info hinge;
+ /* Reserve for 1 channel + pading + timestamp */
+ u32 hinge_val[1 + 3];
+ int scale_pre_decml;
+ int scale_post_decml;
+ int scale_precision;
+ int value_offset;
+ int64_t timestamp;
+ u32 hinge_address;
+};
+
+#define IIO_DEV_NUM 3
+
+struct hinge_group {
+ struct hinge_state *hg_states[IIO_DEV_NUM];
+ struct hid_sensor_hub_callbacks callbacks;
+ struct hid_sensor_common common_attributes;
+};
+
+static struct hinge_group *hg_group;
+
+/* Channel read_raw handler */
+static int hinge_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val, int *val2,
+ long mask)
+{
+ struct hinge_state *hg_state = iio_priv(indio_dev);
+ struct hid_sensor_hub_device *hsdev;
+ int report_id = -1;
+ int ret_type;
+ s32 min;
+
+ hsdev = hg_group->common_attributes.hsdev;
+
+ *val = 0;
+ *val2 = 0;
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ hid_sensor_power_state(&hg_group->common_attributes, true);
+ report_id = hg_state->hinge.report_id;
+ min = hg_state->hinge.logical_minimum;
+ if (report_id < 0) {
+ *val = 0;
+ hid_sensor_power_state(&hg_group->common_attributes,
+ false);
+ return -EINVAL;
+ }
+
+ *val = sensor_hub_input_attr_get_raw_value(
+ hg_group->common_attributes.hsdev, hsdev->usage,
+ hg_state->hinge_address, report_id, SENSOR_HUB_SYNC,
+ min < 0);
+
+ hid_sensor_power_state(&hg_group->common_attributes, false);
+ ret_type = IIO_VAL_INT;
+ break;
+ case IIO_CHAN_INFO_SCALE:
+ *val = hg_state->scale_pre_decml;
+ *val2 = hg_state->scale_post_decml;
+ ret_type = hg_state->scale_precision;
+ break;
+ case IIO_CHAN_INFO_OFFSET:
+ *val = hg_state->value_offset;
+ ret_type = IIO_VAL_INT;
+ break;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ ret_type = hid_sensor_read_samp_freq_value(
+ &hg_group->common_attributes, val, val2);
+ break;
+ case IIO_CHAN_INFO_HYSTERESIS:
+ ret_type = hid_sensor_read_raw_hyst_value(
+ &hg_group->common_attributes, val, val2);
+ break;
+ default:
+ ret_type = -EINVAL;
+ break;
+ }
+
+ return ret_type;
+}
+
+/* Channel write_raw handler */
+static int hinge_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val, int val2,
+ long mask)
+{
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ ret = hid_sensor_write_samp_freq_value(
+ &hg_group->common_attributes, val, val2);
+ break;
+ case IIO_CHAN_INFO_HYSTERESIS:
+ ret = hid_sensor_write_raw_hyst_value(
+ &hg_group->common_attributes, val, val2);
+
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static const struct iio_info hinge_info = {
+ .read_raw = &hinge_read_raw,
+ .write_raw = &hinge_write_raw,
+};
+
+/*
+ * Function to push data to buffer;
+ * wrapper added for symmetry with other hid-sensor drivers
+ */
+static void hid_sensor_push_data(struct iio_dev *indio_dev, void *data, int len,
+ int64_t timestamp)
+{
+ iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
+}
+
+/*
+ * Callback handler to send event after all samples are received
+ * and captured.
+ */
+static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
+ unsigned int usage_id, void *priv)
+{
+ int i;
+
+ for (i = 0; i < IIO_DEV_NUM; ++i) {
+ struct hinge_state *hg_state;
+ struct iio_dev *indio_dev;
+
+ hg_state = hg_group->hg_states[i];
+ indio_dev = hg_state->indio_dev;
+
+ dev_dbg(&indio_dev->dev, "%s timestamp:%llu scan_bytes:%d\n",
+ __func__, hg_state->timestamp, indio_dev->scan_bytes);
+
+ if (!hg_state->timestamp)
+ hg_state->timestamp = iio_get_time_ns(indio_dev);
+
+ hid_sensor_push_data(indio_dev, hg_state->hinge_val,
+ sizeof(hg_state->hinge_val),
+ hg_state->timestamp);
+
+ hg_state->timestamp = 0;
+ }
+
+ return 0;
+}
+
+/* Capture samples in local storage */
+static int hinge_capture_sample(struct hid_sensor_hub_device *hsdev,
+ unsigned int usage_id, size_t raw_len,
+ char *raw_data, void *priv)
+{
+ struct hinge_state *hg_state;
+ int offset;
+ int ret = -EINVAL;
+ int i;
+
+ if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
+ for (i = 0; i < IIO_DEV_NUM; i++)
+ hg_group->hg_states[i]->timestamp =
+ hid_sensor_convert_timestamp(
+ &hg_group->common_attributes,
+ *(int64_t *)raw_data);
+ return 0;
+ }
+
+ switch (usage_id) {
+ case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
+ case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
+ case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
+ offset = usage_id - HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
+ hg_state = hg_group->hg_states[offset];
+ hg_state->hinge_val[0] = *(u32 *)raw_data;
+ ret = 0;
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
+/* Parse report which is specific to an usage id */
+static int hinge_parse_report(struct platform_device *pdev,
+ struct hid_sensor_hub_device *hsdev,
+ unsigned int usage_id, unsigned int attr_usage_id,
+ struct hinge_state *st)
+{
+ int ret;
+
+ ret = sensor_hub_input_get_attribute_info(
+ hsdev, HID_INPUT_REPORT, usage_id, attr_usage_id, &st->hinge);
+ if (ret < 0)
+ return ret;
+
+ st->hinge_address = attr_usage_id;
+ st->scale_precision =
+ hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE, &st->hinge,
+ &st->scale_pre_decml,
+ &st->scale_post_decml);
+
+ /* Set Sensitivity field ids, when there is no individual modifier */
+ if (hg_group->common_attributes.sensitivity.index < 0) {
+ sensor_hub_input_get_attribute_info(
+ hsdev, HID_FEATURE_REPORT, usage_id,
+ HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
+ HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1,
+ &hg_group->common_attributes.sensitivity);
+ dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
+ hg_group->common_attributes.sensitivity.index,
+ hg_group->common_attributes.sensitivity.report_id);
+ }
+
+ return ret;
+}
+
+/* Function to initialize the processing for usage id */
+static int hinge_add_iio_device(struct platform_device *pdev, int index,
+ const char *name, struct hinge_state **st)
+{
+ struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
+ struct hinge_state *hg_state;
+ struct iio_dev *indio_dev;
+ int ret;
+
+ indio_dev =
+ devm_iio_device_alloc(&pdev->dev, sizeof(struct hinge_state));
+ if (indio_dev == NULL)
+ return -ENOMEM;
+
+ hg_state = iio_priv(indio_dev);
+ hg_state->indio_dev = indio_dev;
+
+ indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
+ indio_dev->channels =
+ kmemdup(hinge_channels, sizeof(hinge_channels), GFP_KERNEL);
+ if (!indio_dev->channels)
+ return -ENOMEM;
+
+ ret = hinge_parse_report(
+ pdev, hsdev, hsdev->usage,
+ HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 + index, hg_state);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to setup attributes\n");
+ goto error_free_dev_mem;
+ }
+
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->info = &hinge_info;
+ indio_dev->name = name;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = hid_sensor_setup_trigger(indio_dev, name,
+ &hg_group->common_attributes);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "trigger setup failed\n");
+ goto error_free_dev_mem;
+ }
+
+ ret = iio_device_register(indio_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "device register failed\n");
+ goto error_remove_trigger;
+ }
+
+ *st = hg_state;
+
+ return ret;
+
+error_remove_trigger:
+ hid_sensor_remove_trigger(indio_dev, &hg_group->common_attributes);
+error_free_dev_mem:
+ kfree(indio_dev->channels);
+ return ret;
+}
+
+/* Function to deinitialize the processing for usage id */
+static int hinge_remove_iio_device(struct platform_device *pdev, int index)
+{
+ struct hinge_state *hg_state = hg_group->hg_states[index];
+ struct iio_dev *indio_dev = hg_state->indio_dev;
+
+ iio_device_unregister(indio_dev);
+ hid_sensor_remove_trigger(indio_dev, &hg_group->common_attributes);
+ kfree(indio_dev->channels);
+
+ return 0;
+}
+
+static int hid_hinge_probe(struct platform_device *pdev)
+{
+ struct hinge_state *hg_state;
+ struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
+ static const char *const names[] = { "hinge", "screen", "keyboard" };
+ int ret;
+ int i;
+
+ hg_group = devm_kzalloc(&pdev->dev, sizeof(struct hinge_group),
+ GFP_KERNEL);
+ if (!hg_group)
+ return -ENOMEM;
+
+ hg_group->common_attributes.hsdev = hsdev;
+ hg_group->common_attributes.pdev = pdev;
+
+ ret = hid_sensor_parse_common_attributes(hsdev, hsdev->usage,
+ &hg_group->common_attributes);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to setup common attributes\n");
+ return ret;
+ }
+
+ atomic_set(&hg_group->common_attributes.data_ready, 0);
+ for (i = 0; i < IIO_DEV_NUM; i++) {
+ ret = hinge_add_iio_device(pdev, i, names[i], &hg_state);
+ if (ret)
+ goto err_probe;
+
+ hg_group->hg_states[i] = hg_state;
+ }
+
+ /* use the first iio device to do the PM */
+ platform_set_drvdata(pdev, hg_group->hg_states[0]->indio_dev);
+
+ hg_group->callbacks.send_event = hinge_proc_event;
+ hg_group->callbacks.capture_sample = hinge_capture_sample;
+ hg_group->callbacks.pdev = pdev;
+ ret = sensor_hub_register_callback(hsdev, hsdev->usage,
+ &hg_group->callbacks);
+ if (ret < 0)
+ dev_err(&pdev->dev, "callback reg failed\n");
+
+ return ret;
+
+err_probe:
+ for (i--; i >= 0; i--)
+ hinge_remove_iio_device(pdev, i);
+
+ return ret;
+}
+
+/* Function to deinitialize the processing for usage id */
+static int hid_hinge_remove(struct platform_device *pdev)
+{
+ struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
+ int i;
+
+ sensor_hub_remove_callback(hsdev, hsdev->usage);
+
+ for (i = 0; i < IIO_DEV_NUM; i++)
+ hinge_remove_iio_device(pdev, i);
+
+ return 0;
+}
+
+static const struct platform_device_id hid_hinge_ids[] = {
+ {
+ /* Format: HID-SENSOR-INT-usage_id_in_hex_lowercase */
+ .name = "HID-SENSOR-INT-020b",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
+
+static struct platform_driver hid_hinge_platform_driver = {
+ .id_table = hid_hinge_ids,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .pm = &hid_sensor_pm_ops,
+ },
+ .probe = hid_hinge_probe,
+ .remove = hid_hinge_remove,
+};
+module_platform_driver(hid_hinge_platform_driver);
+
+MODULE_DESCRIPTION("HID Sensor Custom Hinge");
+MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
+MODULE_LICENSE("GPL");
--
2.17.1
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support
2020-11-19 10:03 ` [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support Ye Xiang
@ 2020-11-21 17:21 ` Jonathan Cameron
2020-11-24 10:29 ` Ye, Xiang
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-21 17:21 UTC (permalink / raw)
To: Ye Xiang; +Cc: jikos, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Thu, 19 Nov 2020 18:03:28 +0800
Ye Xiang <xiang.ye@intel.com> wrote:
> Currently custom sensors properties are not decoded and it is up to
> user space to interpret.
>
> Some manufacturers already standardized the meaning of some custom sensors.
> They can be presented as a proper IIO sensor. We can identify these sensors
> based on manufacturer and serial number property in the report.
>
> This change is identifying hinge sensor when the manufacturer is "INTEL".
> This creates a platform device so that a sensor driver can be loaded to
> process these sensors.
>
> Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Hi Ye Xiang,
Various comments inline.
Thanks,
Jonathan
> ---
> drivers/hid/hid-sensor-custom.c | 170 ++++++++++++++++++++++++++++++++
> include/linux/hid-sensor-ids.h | 39 ++++++++
> 2 files changed, 209 insertions(+)
>
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> index 4d25577a8573..bb96d9c09daf 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -4,6 +4,7 @@
> * Copyright (c) 2015, Intel Corporation.
> */
>
> +#include <linux/ctype.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> @@ -21,6 +22,7 @@
> #define HID_CUSTOM_TOTAL_ATTRS (HID_CUSTOM_MAX_CORE_ATTRS + 1)
> #define HID_CUSTOM_FIFO_SIZE 4096
> #define HID_CUSTOM_MAX_FEATURE_BYTES 64
> +#define HID_SENSOR_USAGE_LENGTH (4 + 1)
>
> struct hid_sensor_custom_field {
> int report_id;
> @@ -50,6 +52,8 @@ struct hid_sensor_custom {
> struct kfifo data_fifo;
> unsigned long misc_opened;
> wait_queue_head_t wait;
> + struct platform_device *custom_pdev;
> + bool custom_pdev_exposed;
> };
>
> /* Header for each sample to user space via dev interface */
> @@ -746,11 +750,159 @@ static void hid_sensor_custom_dev_if_remove(struct hid_sensor_custom
>
> }
>
> +/*
> + * use sensors luid which is defined in FW, such as ISH,
> + * to identify sensor.
> + */
const?
> +static char *known_sensor_luid[] = { "020B000000000000" };
> +
> +static int get_luid_table_index(unsigned char *usage_str)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(known_sensor_luid); i++) {
> + if (!strncmp(usage_str, known_sensor_luid[i],
> + strlen(known_sensor_luid[i])))
> + return i;
> + }
> +
> + return -1;
> +}
> +
> +static int get_known_custom_sensor_index(struct hid_sensor_hub_device *hsdev)
> +{
> + struct hid_sensor_hub_attribute_info sensor_manufacturer = { 0 };
> + struct hid_sensor_hub_attribute_info sensor_luid_info = { 0 };
> + int report_size;
> + int ret;
> + u16 *w_buf;
> + int w_buf_len;
> + char *buf;
> + int buf_len;
> + int i;
> + int index;
> +
> + w_buf_len = sizeof(u16) * HID_CUSTOM_MAX_FEATURE_BYTES;
> + buf_len = sizeof(char) * HID_CUSTOM_MAX_FEATURE_BYTES;
Given these are compile time values, these two could just go
directly above with no loss of readability.
int w_buf_len = siezof(u16)...
> + w_buf = kzalloc(w_buf_len, GFP_KERNEL);
> + if (!w_buf)
> + return -1;
Better to return meaningful error values and if the error
isn't just 'didn't find it' - probably -ENODEV and we should check that
was the cause of the problem at the call site for this function.
If it was a memory allocation error we should quit out instead of trying
something else.
> +
> + buf = kzalloc(buf_len, GFP_KERNEL);
> + if (!buf) {
> + kfree(w_buf);
Given we have error handling for this below, better to be consistent
and use a goto + an additional error label for htis case.
> + return -1;
> + }
> +
> + /* get manufacturer info */
> + ret = sensor_hub_input_get_attribute_info(
> + hsdev, HID_FEATURE_REPORT, hsdev->usage,
> + HID_USAGE_SENSOR_PROP_MANUFACTURER, &sensor_manufacturer);
> + if (ret < 0)
From HID point of view, is that allowed to fail? Probably best to add
a comment to say if it is or isn't.
I'd like to be able to read this code and know which of these error paths
just means we don't have a matching sensor.
> + goto err_out;
> +
> + report_size =
> + sensor_hub_get_feature(hsdev, sensor_manufacturer.report_id,
> + sensor_manufacturer.index, w_buf_len,
> + w_buf);
> + if (report_size <= 0) {
> + hid_err(hsdev->hdev,
> + "Failed to get sensor manufacturer info %d\n",
> + report_size);
> + goto err_out;
> + }
> +
> + /* convert from wide char to char */
> + for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
> + buf[i] = (char)w_buf[i];
> +
> + /* ensure it's ISH sensor */
> + if (strncmp(buf, "INTEL", strlen("INTEL")))
> + goto err_out;
> +
> + memset(w_buf, 0, w_buf_len);
> + memset(buf, 0, buf_len);
> +
> + /* get real usage id */
> + ret = sensor_hub_input_get_attribute_info(
> + hsdev, HID_FEATURE_REPORT, hsdev->usage,
> + HID_USAGE_SENSOR_PROP_SERIAL_NUM, &sensor_luid_info);
> + if (ret < 0)
> + goto err_out;
> +
> + report_size = sensor_hub_get_feature(hsdev, sensor_luid_info.report_id,
> + sensor_luid_info.index, w_buf_len,
> + w_buf);
> + if (report_size <= 0) {
> + hid_err(hsdev->hdev, "Failed to get real usage info %d\n",
> + report_size);
> + goto err_out;
> + }
> +
> + /* convert from wide char to char */
> + for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
> + buf[i] = (char)w_buf[i];
> +
> + if (strlen(buf) != strlen(known_sensor_luid[0]) + 5) {
> + hid_err(hsdev->hdev,
> + "%s luid length not match %zu != (%zu + 5)\n", __func__,
> + strlen(buf), strlen(known_sensor_luid[0]));
> + goto err_out;
> + }
> +
> + /* get table index with luid (not matching 'LUID: ' in luid) */
> + index = get_luid_table_index(&buf[5]);
Nicer to share the code block here with the error / unwind path below.
Particular as index might be -1 and hence an error.
> + kfree(w_buf);
> + kfree(buf);
> + return index;
> +
> +err_out:
> + kfree(w_buf);
> + kfree(buf);
> + return -1;
> +}
> +
> +static struct platform_device *
> +register_platform_device(struct platform_device *pdev,
Function needs a prefix as that sounds very generic.
When I saw it below, I assumed it was a generic call not
one in this file.
> + struct hid_sensor_hub_device *hsdev, int index)
> +{
> + char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
> + struct platform_device *custom_pdev;
> + const char *dev_name;
> + char *c;
> + int ret;
> +
> + /* copy real usage id */
> + memcpy(real_usage, known_sensor_luid[index], 4);
> +
> + /* usage id are all lowcase */
> + for (c = real_usage; *c != '\0'; c++)
> + *c = tolower(*c);
> +
> + /* HID-SENSOR-INT-REAL_USAGE_ID */
> + dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s", real_usage);
> + if (!dev_name)
> + return NULL;
> +
> + custom_pdev = platform_device_register_data(pdev->dev.parent, dev_name,
> + PLATFORM_DEVID_NONE, hsdev,
> + sizeof(*hsdev));
> + kfree(dev_name);
> + ret = PTR_ERR_OR_ZERO(custom_pdev);
> + if (ret) {
> + dev_err(&pdev->dev, "platform_device_register_data failed ret:%d\n", ret);
> + return NULL;
> + }
> +
> + return custom_pdev;
> +}
> +
> static int hid_sensor_custom_probe(struct platform_device *pdev)
> {
> struct hid_sensor_custom *sensor_inst;
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> int ret;
> + int index;
>
> sensor_inst = devm_kzalloc(&pdev->dev, sizeof(*sensor_inst),
> GFP_KERNEL);
> @@ -764,6 +916,19 @@ static int hid_sensor_custom_probe(struct platform_device *pdev)
> sensor_inst->pdev = pdev;
> mutex_init(&sensor_inst->mutex);
> platform_set_drvdata(pdev, sensor_inst);
> +
> + index = get_known_custom_sensor_index(hsdev);
> + if (index >= 0) {
> + sensor_inst->custom_pdev =
> + register_platform_device(pdev, hsdev, index);
> + if (sensor_inst->custom_pdev) {
> + sensor_inst->custom_pdev_exposed = true;
> + return 0;
> + }
> +
> + dev_err(&pdev->dev, "register_platform_device failed\n");
This feels like somewhat odd logic. We aren't looking at a fallback for
something that is expected to fail so it doesn't make sense to carry
on.
> + }
> +
> ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> &sensor_inst->callbacks);
> if (ret < 0) {
> @@ -802,6 +967,11 @@ static int hid_sensor_custom_remove(struct platform_device *pdev)
> struct hid_sensor_custom *sensor_inst = platform_get_drvdata(pdev);
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
>
> + if (sensor_inst->custom_pdev_exposed) {
> + platform_device_unregister(sensor_inst->custom_pdev);
> + return 0;
> + }
> +
> hid_sensor_custom_dev_if_remove(sensor_inst);
> hid_sensor_custom_remove_attributes(sensor_inst);
> sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> index 530c09f3e64a..46db3056f04b 100644
> --- a/include/linux/hid-sensor-ids.h
> +++ b/include/linux/hid-sensor-ids.h
> @@ -128,6 +128,10 @@
> #define HID_USAGE_SENSOR_UNITS_DEGREES_PER_SECOND 0x15
>
> /* Common selectors */
> +#define HID_USAGE_SENSOR_PROP_DESC 0x200300
> +#define HID_USAGE_SENSOR_PROP_FRIENDLY_NAME 0x200301
> +#define HID_USAGE_SENSOR_PROP_SERIAL_NUM 0x200307
> +#define HID_USAGE_SENSOR_PROP_MANUFACTURER 0x200305
> #define HID_USAGE_SENSOR_PROP_REPORT_INTERVAL 0x20030E
> #define HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS 0x20030F
> #define HID_USAGE_SENSOR_PROP_SENSITIVITY_RANGE_PCT 0x200310
> @@ -159,4 +163,39 @@
> #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x200840
> #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x200841
>
> +/* Custom Sensor (2000e1) */
> +#define HID_USAGE_SENSOR_HINGE 0x20020B
> +#define HID_USAGE_SENSOR_DATA_FIELD_LOCATION 0x200400
> +#define HID_USAGE_SENSOR_DATA_FIELE_TIME_SINCE_SYS_BOOT 0x20052B
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_USAGE 0x200541
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE 0x200543
Given these are all defined in a block could we use a macro?
HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) 0x200543 + (x)
perhaps?
I'm not sure what the preferred convention is in this file.
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 0x200544
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2 0x200545
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3 0x200546
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_4 0x200547
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_5 0x200548
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_6 0x200549
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_7 0x20054A
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_8 0x20054B
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_9 0x20054C
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_10 0x20054D
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_11 0x20054E
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_12 0x20054F
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_13 0x200550
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_14 0x200551
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_15 0x200552
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_16 0x200553
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_17 0x200554
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_18 0x200555
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_19 0x200556
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_20 0x200557
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_21 0x200558
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_22 0x200559
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_23 0x20055A
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_24 0x20055B
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_25 0x20055C
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_26 0x20055D
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_27 0x20055E
> +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_28 0x20055F
> +
> #endif
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal
2020-11-19 10:03 ` [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal Ye Xiang
@ 2020-11-21 17:22 ` Jonathan Cameron
2020-11-22 1:54 ` Pandruvada, Srinivas
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-21 17:22 UTC (permalink / raw)
To: Ye Xiang; +Cc: jikos, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Thu, 19 Nov 2020 18:03:29 +0800
Ye Xiang <xiang.ye@intel.com> wrote:
> To avoid pm_runtime_disable called repeatedly by hid sensor drivers,
> decrease runtime pm enable count after call it.
>
> Signed-off-by: Ye Xiang <xiang.ye@intel.com>
This sounds like a fix. If so please make that clear and add a fixes tag.
If it couldn't have been triggered before, then please explain why in this
patch description.
Thanks,
Jonathan
> ---
> drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index ff375790b7e8..30340abcbc8d 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -227,8 +227,10 @@ static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
> void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
> struct hid_sensor_common *attrb)
> {
> - if (atomic_read(&attrb->runtime_pm_enable))
> + if (atomic_read(&attrb->runtime_pm_enable)) {
> pm_runtime_disable(&attrb->pdev->dev);
> + atomic_dec(&attrb->runtime_pm_enable);
> + }
>
> pm_runtime_set_suspended(&attrb->pdev->dev);
> pm_runtime_put_noidle(&attrb->pdev->dev);
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure
2020-11-19 10:03 ` [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure Ye Xiang
@ 2020-11-21 17:33 ` Jonathan Cameron
0 siblings, 0 replies; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-21 17:33 UTC (permalink / raw)
To: Ye Xiang; +Cc: jikos, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Thu, 19 Nov 2020 18:03:30 +0800
Ye Xiang <xiang.ye@intel.com> wrote:
> Use iio->trig instead of attrb->trig as parameter of iio_trigger_unregister
> and iio_trigger_free. This allows one HID sensor driver to create
> multiple iio devices. In this case common attributes are shared and
> there can be one instance for the structure containing common attributes
> for all iio devices.
>
> Signed-off-by: Ye Xiang <xiang.ye@intel.com>
Whilst indio_dev->trig is set to the local trigger at startup,
I'm not seeing the validate callbacks that will be needed to ensure it
is still set to that trigger when you remove the driver.
Specifically validate_trigger callback for all the hid sensor devices.
It is entirely possible that should be set and these devices can only
use the hid sensor trigger, but I don't think it currently is.
Thus this patch is going to cause some interesting crashes.
Note this is the reason all IIO drivers have to carry an extra copy
of the trig pointer.
So you'll have to do something a bit more interesting to pass that
trigger to the relevant devices that share it.
Arguably if they are actually sharing the trigger, then we shouldn't really
have separate IIO devices in the first place as we loose the
connection between the timing of the data across the different channels.
Jonathan
> ---
> drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 30340abcbc8d..bb5e7c8ff15b 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -236,8 +236,8 @@ void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
> pm_runtime_put_noidle(&attrb->pdev->dev);
>
> cancel_work_sync(&attrb->work);
> - iio_trigger_unregister(attrb->trigger);
> - iio_trigger_free(attrb->trigger);
> + iio_trigger_unregister(indio_dev->trig);
> + iio_trigger_free(indio_dev->trig);
> iio_triggered_buffer_cleanup(indio_dev);
> }
> EXPORT_SYMBOL(hid_sensor_remove_trigger);
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-19 10:03 ` [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver Ye Xiang
@ 2020-11-21 17:56 ` Jonathan Cameron
2020-11-22 1:46 ` Pandruvada, Srinivas
2020-11-24 6:43 ` Ye, Xiang
0 siblings, 2 replies; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-21 17:56 UTC (permalink / raw)
To: Ye Xiang; +Cc: jikos, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Thu, 19 Nov 2020 18:03:31 +0800
Ye Xiang <xiang.ye@intel.com> wrote:
> The Hinge sensor is a common custom sensor on laptops. It calculates
> the angle between the lid (screen) and the base (keyboard). In addition,
> it also exposes screen and the keyboard angels with respect to the
> ground. Applications can easily get laptop's status in space through
> this sensor, in order to display appropriate user interface.
I'm a little unclear on why the 3 axes aren't treated as a single sensor.
You seem to always grab the 3 together or am I missing something?
That will greatly simplify things and get rid of the need to have
a shared trigger with the problems that causes in the previous
patch.
Thanks,
Jonathan
>
> Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> ---
> .../hid-sensors/hid-sensor-attributes.c | 2 +
> drivers/iio/position/Kconfig | 16 +
> drivers/iio/position/Makefile | 3 +
> .../iio/position/hid-sensor-custom-hinge.c | 412 ++++++++++++++++++
Given it's custom probably needs a more specific name. I guess
hid-sensor-custom-intel-hinge.c might be safe?
Same for other places we need names in here.
> 4 files changed, 433 insertions(+)
> create mode 100644 drivers/iio/position/hid-sensor-custom-hinge.c
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> index 442ff787f7af..5b822a4298a0 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> @@ -71,6 +71,8 @@ static struct {
> {HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES, 1000, 0},
>
> {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> + {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0, 17453293},
> };
>
> static void simple_div(int dividend, int divisor, int *whole,
> diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
> index eda67f008c5b..0346f6f2b422 100644
> --- a/drivers/iio/position/Kconfig
> +++ b/drivers/iio/position/Kconfig
> @@ -16,4 +16,20 @@ config IQS624_POS
> To compile this driver as a module, choose M here: the module
> will be called iqs624-pos.
>
> +config HID_SENSOR_CUSTOM_HINGE
> + depends on HID_SENSOR_HUB
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + select HID_SENSOR_IIO_COMMON
> + select HID_SENSOR_IIO_TRIGGER
> + tristate "HID Hinge"
> + help
> + This sensor present three angles, hinge angel, screen angles
> + and keyboard angle respect to horizon (ground).
> + Say yes here to build support for the HID SENSOR CUSTOM
> + HINGE.
Capitalization is a bit odd looking. I'd drop it.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called hid-sensor-custom-hinge.
> +
> endmenu
> diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
> index 3cbe7a734352..7a6225977a01 100644
> --- a/drivers/iio/position/Makefile
> +++ b/drivers/iio/position/Makefile
> @@ -5,3 +5,6 @@
> # When adding new entries keep the list in alphabetical order
>
> obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> +
> +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
Alphabetical order preferred.
> +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
Why?
> diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c b/drivers/iio/position/hid-sensor-custom-hinge.c
> new file mode 100644
> index 000000000000..a91b333f36fa
> --- /dev/null
> +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> @@ -0,0 +1,412 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * HID Sensors Driver
> + * Copyright (c) 2020, Intel Corporation.
> + */
> +#include <linux/hid-sensor-hub.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/platform_device.h>
> +
> +#include "hid-sensor-trigger.h"
> +
> +/* Channel definitions */
> +static const struct iio_chan_spec hinge_channels[] = {
> + { .type = IIO_ANGL,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type =
> + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_SAMP_FREQ) | BIT(IIO_CHAN_INFO_HYSTERESIS),
> + .scan_type.realbits = 16,
> + .scan_type.storagebits = 32,
It a bit odd to see a single channel that is 16 bits inside a 32 bit with
no shift or similar. Why not just pack it into 16 bits?
> + .scan_type.sign = 's',
> + .scan_index = 0 },
> +
> + IIO_CHAN_SOFT_TIMESTAMP(1)
> +};
> +
> +struct hinge_state {
> + struct iio_dev *indio_dev;
> + struct hid_sensor_hub_attribute_info hinge;
> + /* Reserve for 1 channel + pading + timestamp */
> + u32 hinge_val[1 + 3];
__aligned(8)
see below for requirements on this.
Perhaps better to use
struct hinge_scan {
u32 val;
s64 timestamp __aligned(8); // Note this is needed for x86_32
} scan;
> + int scale_pre_decml;
> + int scale_post_decml;
> + int scale_precision;
> + int value_offset;
> + int64_t timestamp;
> + u32 hinge_address;
> +};
> +
> +#define IIO_DEV_NUM 3
That needs a prefix to make it clear it's not a generic constant
but is specific to this driver.
> +
> +struct hinge_group {
> + struct hinge_state *hg_states[IIO_DEV_NUM];
> + struct hid_sensor_hub_callbacks callbacks;
> + struct hid_sensor_common common_attributes;
> +};
> +
> +static struct hinge_group *hg_group;
We shouldn't see globals like this. Please figure out how to avoid it.
> +
> +/* Channel read_raw handler */
> +static int hinge_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val, int *val2,
> + long mask)
> +{
> + struct hinge_state *hg_state = iio_priv(indio_dev);
> + struct hid_sensor_hub_device *hsdev;
> + int report_id = -1;
> + int ret_type;
> + s32 min;
> +
> + hsdev = hg_group->common_attributes.hsdev;
> +
> + *val = 0;
> + *val2 = 0;
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + hid_sensor_power_state(&hg_group->common_attributes, true);
> + report_id = hg_state->hinge.report_id;
> + min = hg_state->hinge.logical_minimum;
> + if (report_id < 0) {
> + *val = 0;
> + hid_sensor_power_state(&hg_group->common_attributes,
> + false);
> + return -EINVAL;
> + }
> +
> + *val = sensor_hub_input_attr_get_raw_value(
> + hg_group->common_attributes.hsdev, hsdev->usage,
> + hg_state->hinge_address, report_id, SENSOR_HUB_SYNC,
> + min < 0);
> +
> + hid_sensor_power_state(&hg_group->common_attributes, false);
> + ret_type = IIO_VAL_INT;
> + break;
> + case IIO_CHAN_INFO_SCALE:
> + *val = hg_state->scale_pre_decml;
> + *val2 = hg_state->scale_post_decml;
> + ret_type = hg_state->scale_precision;
> + break;
> + case IIO_CHAN_INFO_OFFSET:
> + *val = hg_state->value_offset;
> + ret_type = IIO_VAL_INT;
> + break;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + ret_type = hid_sensor_read_samp_freq_value(
> + &hg_group->common_attributes, val, val2);
> + break;
> + case IIO_CHAN_INFO_HYSTERESIS:
> + ret_type = hid_sensor_read_raw_hyst_value(
> + &hg_group->common_attributes, val, val2);
> + break;
> + default:
> + ret_type = -EINVAL;
> + break;
> + }
> +
> + return ret_type;
> +}
> +
> +/* Channel write_raw handler */
> +static int hinge_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val, int val2,
> + long mask)
> +{
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + ret = hid_sensor_write_samp_freq_value(
> + &hg_group->common_attributes, val, val2);
> + break;
> + case IIO_CHAN_INFO_HYSTERESIS:
> + ret = hid_sensor_write_raw_hyst_value(
> + &hg_group->common_attributes, val, val2);
> +
> + break;
> + default:
> + ret = -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> +static const struct iio_info hinge_info = {
> + .read_raw = &hinge_read_raw,
> + .write_raw = &hinge_write_raw,
> +};
> +
> +/*
> + * Function to push data to buffer;
> + * wrapper added for symmetry with other hid-sensor drivers
> + */
> +static void hid_sensor_push_data(struct iio_dev *indio_dev, void *data, int len,
This doesn't seem to be generic, so don't name it as such.
> + int64_t timestamp)
> +{
> + iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
I hope that data buffer obeys the various rules needed by (and admittedly
not that well documented) iio_push_to_buffers_with_timestamp()
1. Needs to be 8 byte aligned.
2. Needs to have space for an aligned 8 byte timestamp at the end.
> +}
> +
> +/*
> + * Callback handler to send event after all samples are received
> + * and captured.
> + */
> +static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
> + unsigned int usage_id, void *priv)
> +{
> + int i;
> +
> + for (i = 0; i < IIO_DEV_NUM; ++i) {
If we push for all sensors together, better to have
this as a single iio_device with 3 channels.
Use the channel labels (just added to IIO) to identify which is which.
> + struct hinge_state *hg_state;
> + struct iio_dev *indio_dev;
> +
> + hg_state = hg_group->hg_states[i];
> + indio_dev = hg_state->indio_dev;
> +
> + dev_dbg(&indio_dev->dev, "%s timestamp:%llu scan_bytes:%d\n",
> + __func__, hg_state->timestamp, indio_dev->scan_bytes);
> +
> + if (!hg_state->timestamp)
> + hg_state->timestamp = iio_get_time_ns(indio_dev);
> +
> + hid_sensor_push_data(indio_dev, hg_state->hinge_val,
> + sizeof(hg_state->hinge_val),
> + hg_state->timestamp);
> +
> + hg_state->timestamp = 0;
> + }
> +
> + return 0;
> +}
> +
> +/* Capture samples in local storage */
> +static int hinge_capture_sample(struct hid_sensor_hub_device *hsdev,
> + unsigned int usage_id, size_t raw_len,
> + char *raw_data, void *priv)
> +{
> + struct hinge_state *hg_state;
> + int offset;
> + int ret = -EINVAL;
> + int i;
> +
> + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> + for (i = 0; i < IIO_DEV_NUM; i++)
> + hg_group->hg_states[i]->timestamp =
This rather implies all the data is captured together... If so single
iio_device may make more sense.
> + hid_sensor_convert_timestamp(
> + &hg_group->common_attributes,
> + *(int64_t *)raw_data);
> + return 0;
> + }
> +
> + switch (usage_id) {
> + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> + offset = usage_id - HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> + hg_state = hg_group->hg_states[offset];
> + hg_state->hinge_val[0] = *(u32 *)raw_data;
> + ret = 0;
return 0;
> + break;
> + default:
return -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +/* Parse report which is specific to an usage id */
> +static int hinge_parse_report(struct platform_device *pdev,
> + struct hid_sensor_hub_device *hsdev,
> + unsigned int usage_id, unsigned int attr_usage_id,
> + struct hinge_state *st)
> +{
> + int ret;
> +
> + ret = sensor_hub_input_get_attribute_info(
> + hsdev, HID_INPUT_REPORT, usage_id, attr_usage_id, &st->hinge);
> + if (ret < 0)
> + return ret;
> +
> + st->hinge_address = attr_usage_id;
> + st->scale_precision =
> + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE, &st->hinge,
> + &st->scale_pre_decml,
> + &st->scale_post_decml);
> +
> + /* Set Sensitivity field ids, when there is no individual modifier */
> + if (hg_group->common_attributes.sensitivity.index < 0) {
> + sensor_hub_input_get_attribute_info(
> + hsdev, HID_FEATURE_REPORT, usage_id,
> + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
> + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1,
> + &hg_group->common_attributes.sensitivity);
> + dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
> + hg_group->common_attributes.sensitivity.index,
> + hg_group->common_attributes.sensitivity.report_id);
> + }
> +
> + return ret;
> +}
> +
> +/* Function to initialize the processing for usage id */
> +static int hinge_add_iio_device(struct platform_device *pdev, int index,
> + const char *name, struct hinge_state **st)
> +{
> + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> + struct hinge_state *hg_state;
> + struct iio_dev *indio_dev;
> + int ret;
> +
> + indio_dev =
> + devm_iio_device_alloc(&pdev->dev, sizeof(struct hinge_state));
sizeof (*hg_state) preferred.
> + if (indio_dev == NULL)
> + return -ENOMEM;
> +
> + hg_state = iio_priv(indio_dev);
> + hg_state->indio_dev = indio_dev;
> +
> + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> + indio_dev->channels =
> + kmemdup(hinge_channels, sizeof(hinge_channels), GFP_KERNEL);
I don't immediately see anything that is modifying channels. As such you
should be able have it shared by all the instances.
> + if (!indio_dev->channels)
> + return -ENOMEM;
> +
> + ret = hinge_parse_report(
> + pdev, hsdev, hsdev->usage,
> + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 + index, hg_state);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to setup attributes\n");
> + goto error_free_dev_mem;
> + }
> +
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->info = &hinge_info;
> + indio_dev->name = name;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = hid_sensor_setup_trigger(indio_dev, name,
> + &hg_group->common_attributes);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "trigger setup failed\n");
> + goto error_free_dev_mem;
> + }
> +
> + ret = iio_device_register(indio_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "device register failed\n");
> + goto error_remove_trigger;
> + }
> +
> + *st = hg_state;
> +
> + return ret;
> +
> +error_remove_trigger:
> + hid_sensor_remove_trigger(indio_dev, &hg_group->common_attributes);
> +error_free_dev_mem:
> + kfree(indio_dev->channels);
> + return ret;
> +}
> +
> +/* Function to deinitialize the processing for usage id */
> +static int hinge_remove_iio_device(struct platform_device *pdev, int index)
> +{
> + struct hinge_state *hg_state = hg_group->hg_states[index];
> + struct iio_dev *indio_dev = hg_state->indio_dev;
> +
> + iio_device_unregister(indio_dev);
> + hid_sensor_remove_trigger(indio_dev, &hg_group->common_attributes);
> + kfree(indio_dev->channels);
> +
> + return 0;
> +}
> +
> +static int hid_hinge_probe(struct platform_device *pdev)
> +{
> + struct hinge_state *hg_state;
> + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> + static const char *const names[] = { "hinge", "screen", "keyboard" };
> + int ret;
> + int i;
> +
> + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct hinge_group),
> + GFP_KERNEL);
As mentioned above, I'd really not expect to see a global like this.
Technically nothing stops there being more than one instance of this
device on a platform (even if that would be a bit odd) + it's almost
always cleaner to not use a global in the first place.
> + if (!hg_group)
> + return -ENOMEM;
> +
> + hg_group->common_attributes.hsdev = hsdev;
> + hg_group->common_attributes.pdev = pdev;
> +
> + ret = hid_sensor_parse_common_attributes(hsdev, hsdev->usage,
> + &hg_group->common_attributes);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to setup common attributes\n");
> + return ret;
> + }
> +
> + atomic_set(&hg_group->common_attributes.data_ready, 0);
> + for (i = 0; i < IIO_DEV_NUM; i++) {
> + ret = hinge_add_iio_device(pdev, i, names[i], &hg_state);
> + if (ret)
> + goto err_probe;
> +
> + hg_group->hg_states[i] = hg_state;
> + }
> +
> + /* use the first iio device to do the PM */
> + platform_set_drvdata(pdev, hg_group->hg_states[0]->indio_dev);
> +
> + hg_group->callbacks.send_event = hinge_proc_event;
> + hg_group->callbacks.capture_sample = hinge_capture_sample;
> + hg_group->callbacks.pdev = pdev;
> + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> + &hg_group->callbacks);
> + if (ret < 0)
> + dev_err(&pdev->dev, "callback reg failed\n");
> +
> + return ret;
> +
> +err_probe:
> + for (i--; i >= 0; i--)
> + hinge_remove_iio_device(pdev, i);
> +
> + return ret;
> +}
> +
> +/* Function to deinitialize the processing for usage id */
> +static int hid_hinge_remove(struct platform_device *pdev)
> +{
> + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> + int i;
> +
> + sensor_hub_remove_callback(hsdev, hsdev->usage);
> +
> + for (i = 0; i < IIO_DEV_NUM; i++)
> + hinge_remove_iio_device(pdev, i);
> +
> + return 0;
> +}
> +
> +static const struct platform_device_id hid_hinge_ids[] = {
> + {
> + /* Format: HID-SENSOR-INT-usage_id_in_hex_lowercase */
> + .name = "HID-SENSOR-INT-020b",
> + },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> +
> +static struct platform_driver hid_hinge_platform_driver = {
> + .id_table = hid_hinge_ids,
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .pm = &hid_sensor_pm_ops,
> + },
> + .probe = hid_hinge_probe,
> + .remove = hid_hinge_remove,
> +};
> +module_platform_driver(hid_hinge_platform_driver);
> +
> +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> +MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-21 17:56 ` Jonathan Cameron
@ 2020-11-22 1:46 ` Pandruvada, Srinivas
2020-11-22 2:14 ` Pandruvada, Srinivas
2020-11-24 6:43 ` Ye, Xiang
1 sibling, 1 reply; 25+ messages in thread
From: Pandruvada, Srinivas @ 2020-11-22 1:46 UTC (permalink / raw)
To: jic23, Ye, Xiang; +Cc: jikos, linux-input, linux-kernel, linux-iio
On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> On Thu, 19 Nov 2020 18:03:31 +0800
> Ye Xiang <xiang.ye@intel.com> wrote:
>
> > The Hinge sensor is a common custom sensor on laptops. It
> > calculates
> > the angle between the lid (screen) and the base (keyboard). In
> > addition,
> > it also exposes screen and the keyboard angels with respect to the
> > ground. Applications can easily get laptop's status in space
> > through
> > this sensor, in order to display appropriate user interface.
>
> I'm a little unclear on why the 3 axes aren't treated as a single
> sensor.
> You seem to always grab the 3 together or am I missing something?
>
> That will greatly simplify things and get rid of the need to have
> a shared trigger with the problems that causes in the previous
> patch.
They are not three axes, they are independent. Xiang did try adding x,
y and z component to represent x as hinge, y as keyboard and z as lid.
But I was not convinced.
The problem is that then what will be sysfs interface? They are really
a three sensors. Or we create new interface to call
in_angl_raw_keyboard
in_angl_raw_screen
in_angl_raw_lid.
Thanks,
Srinivas
>
> Thanks,
>
> Jonathan
>
> > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > ---
> > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > drivers/iio/position/Kconfig | 16 +
> > drivers/iio/position/Makefile | 3 +
> > .../iio/position/hid-sensor-custom-hinge.c | 412
> > ++++++++++++++++++
>
> Given it's custom probably needs a more specific name. I guess
> hid-sensor-custom-intel-hinge.c might be safe?
>
> Same for other places we need names in here.
>
> > 4 files changed, 433 insertions(+)
> > create mode 100644 drivers/iio/position/hid-sensor-custom-hinge.c
> >
> > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > index 442ff787f7af..5b822a4298a0 100644
> > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > @@ -71,6 +71,8 @@ static struct {
> > {HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES,
> > 1000, 0},
> >
> > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > + {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > 17453293},
> > };
> >
> > static void simple_div(int dividend, int divisor, int *whole,
> > diff --git a/drivers/iio/position/Kconfig
> > b/drivers/iio/position/Kconfig
> > index eda67f008c5b..0346f6f2b422 100644
> > --- a/drivers/iio/position/Kconfig
> > +++ b/drivers/iio/position/Kconfig
> > @@ -16,4 +16,20 @@ config IQS624_POS
> > To compile this driver as a module, choose M here: the module
> > will be called iqs624-pos.
> >
> > +config HID_SENSOR_CUSTOM_HINGE
> > + depends on HID_SENSOR_HUB
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > + select HID_SENSOR_IIO_COMMON
> > + select HID_SENSOR_IIO_TRIGGER
> > + tristate "HID Hinge"
> > + help
> > + This sensor present three angles, hinge angel, screen angles
> > + and keyboard angle respect to horizon (ground).
> > + Say yes here to build support for the HID SENSOR CUSTOM
> > + HINGE.
>
> Capitalization is a bit odd looking. I'd drop it.
>
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called hid-sensor-custom-hinge.
> > +
> > endmenu
> > diff --git a/drivers/iio/position/Makefile
> > b/drivers/iio/position/Makefile
> > index 3cbe7a734352..7a6225977a01 100644
> > --- a/drivers/iio/position/Makefile
> > +++ b/drivers/iio/position/Makefile
> > @@ -5,3 +5,6 @@
> > # When adding new entries keep the list in alphabetical order
> >
> > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > +
> > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
>
> Alphabetical order preferred.
>
> > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
>
> Why?
>
> > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > new file mode 100644
> > index 000000000000..a91b333f36fa
> > --- /dev/null
> > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > @@ -0,0 +1,412 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * HID Sensors Driver
> > + * Copyright (c) 2020, Intel Corporation.
> > + */
> > +#include <linux/hid-sensor-hub.h>
> > +#include <linux/iio/buffer.h>
> > +#include <linux/iio/iio.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include "hid-sensor-trigger.h"
> > +
> > +/* Channel definitions */
> > +static const struct iio_chan_spec hinge_channels[] = {
> > + { .type = IIO_ANGL,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > + .info_mask_shared_by_type =
> > + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE)
> > |
> > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > + .scan_type.realbits = 16,
> > + .scan_type.storagebits = 32,
>
> It a bit odd to see a single channel that is 16 bits inside a 32 bit
> with
> no shift or similar. Why not just pack it into 16 bits?
>
> > + .scan_type.sign = 's',
> > + .scan_index = 0 },
> > +
> > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > +};
> > +
> > +struct hinge_state {
> > + struct iio_dev *indio_dev;
> > + struct hid_sensor_hub_attribute_info hinge;
> > + /* Reserve for 1 channel + pading + timestamp */
> > + u32 hinge_val[1 + 3];
>
> __aligned(8)
>
> see below for requirements on this.
> Perhaps better to use
>
> struct hinge_scan {
> u32 val;
> s64 timestamp __aligned(8); // Note this is needed for
> x86_32
> } scan;
>
> > + int scale_pre_decml;
> > + int scale_post_decml;
> > + int scale_precision;
> > + int value_offset;
> > + int64_t timestamp;
> > + u32 hinge_address;
> > +};
> > +
> > +#define IIO_DEV_NUM 3
>
> That needs a prefix to make it clear it's not a generic constant
> but is specific to this driver.
>
> > +
> > +struct hinge_group {
> > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > + struct hid_sensor_hub_callbacks callbacks;
> > + struct hid_sensor_common common_attributes;
> > +};
> > +
> > +static struct hinge_group *hg_group;
>
> We shouldn't see globals like this. Please figure out how to avoid
> it.
>
> > +
> > +/* Channel read_raw handler */
> > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int *val,
> > int *val2,
> > + long mask)
> > +{
> > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > + struct hid_sensor_hub_device *hsdev;
> > + int report_id = -1;
> > + int ret_type;
> > + s32 min;
> > +
> > + hsdev = hg_group->common_attributes.hsdev;
> > +
> > + *val = 0;
> > + *val2 = 0;
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + hid_sensor_power_state(&hg_group->common_attributes,
> > true);
> > + report_id = hg_state->hinge.report_id;
> > + min = hg_state->hinge.logical_minimum;
> > + if (report_id < 0) {
> > + *val = 0;
> > + hid_sensor_power_state(&hg_group-
> > >common_attributes,
> > + false);
> > + return -EINVAL;
> > + }
> > +
> > + *val = sensor_hub_input_attr_get_raw_value(
> > + hg_group->common_attributes.hsdev, hsdev-
> > >usage,
> > + hg_state->hinge_address, report_id,
> > SENSOR_HUB_SYNC,
> > + min < 0);
> > +
> > + hid_sensor_power_state(&hg_group->common_attributes,
> > false);
> > + ret_type = IIO_VAL_INT;
> > + break;
> > + case IIO_CHAN_INFO_SCALE:
> > + *val = hg_state->scale_pre_decml;
> > + *val2 = hg_state->scale_post_decml;
> > + ret_type = hg_state->scale_precision;
> > + break;
> > + case IIO_CHAN_INFO_OFFSET:
> > + *val = hg_state->value_offset;
> > + ret_type = IIO_VAL_INT;
> > + break;
> > + case IIO_CHAN_INFO_SAMP_FREQ:
> > + ret_type = hid_sensor_read_samp_freq_value(
> > + &hg_group->common_attributes, val, val2);
> > + break;
> > + case IIO_CHAN_INFO_HYSTERESIS:
> > + ret_type = hid_sensor_read_raw_hyst_value(
> > + &hg_group->common_attributes, val, val2);
> > + break;
> > + default:
> > + ret_type = -EINVAL;
> > + break;
> > + }
> > +
> > + return ret_type;
> > +}
> > +
> > +/* Channel write_raw handler */
> > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int val,
> > int val2,
> > + long mask)
> > +{
> > + int ret;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_SAMP_FREQ:
> > + ret = hid_sensor_write_samp_freq_value(
> > + &hg_group->common_attributes, val, val2);
> > + break;
> > + case IIO_CHAN_INFO_HYSTERESIS:
> > + ret = hid_sensor_write_raw_hyst_value(
> > + &hg_group->common_attributes, val, val2);
> > +
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static const struct iio_info hinge_info = {
> > + .read_raw = &hinge_read_raw,
> > + .write_raw = &hinge_write_raw,
> > +};
> > +
> > +/*
> > + * Function to push data to buffer;
> > + * wrapper added for symmetry with other hid-sensor drivers
> > + */
> > +static void hid_sensor_push_data(struct iio_dev *indio_dev, void
> > *data, int len,
>
> This doesn't seem to be generic, so don't name it as such.
>
> > + int64_t timestamp)
> > +{
> > + iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
> I hope that data buffer obeys the various rules needed by (and
> admittedly
> not that well documented) iio_push_to_buffers_with_timestamp()
>
> 1. Needs to be 8 byte aligned.
> 2. Needs to have space for an aligned 8 byte timestamp at the end.
>
> > +}
> > +
> > +/*
> > + * Callback handler to send event after all samples are received
> > + * and captured.
> > + */
> > +static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
> > + unsigned int usage_id, void *priv)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> If we push for all sensors together, better to have
> this as a single iio_device with 3 channels.
>
> Use the channel labels (just added to IIO) to identify which is
> which.
>
> > + struct hinge_state *hg_state;
> > + struct iio_dev *indio_dev;
> > +
> > + hg_state = hg_group->hg_states[i];
> > + indio_dev = hg_state->indio_dev;
> > +
> > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > scan_bytes:%d\n",
> > + __func__, hg_state->timestamp, indio_dev-
> > >scan_bytes);
> > +
> > + if (!hg_state->timestamp)
> > + hg_state->timestamp =
> > iio_get_time_ns(indio_dev);
> > +
> > + hid_sensor_push_data(indio_dev, hg_state->hinge_val,
> > + sizeof(hg_state->hinge_val),
> > + hg_state->timestamp);
> > +
> > + hg_state->timestamp = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/* Capture samples in local storage */
> > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > *hsdev,
> > + unsigned int usage_id, size_t raw_len,
> > + char *raw_data, void *priv)
> > +{
> > + struct hinge_state *hg_state;
> > + int offset;
> > + int ret = -EINVAL;
> > + int i;
> > +
> > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > + for (i = 0; i < IIO_DEV_NUM; i++)
> > + hg_group->hg_states[i]->timestamp =
>
> This rather implies all the data is captured together... If so single
> iio_device may make more sense.
>
> > + hid_sensor_convert_timestamp(
> > + &hg_group->common_attributes,
> > + *(int64_t *)raw_data);
> > + return 0;
> > + }
> > +
> > + switch (usage_id) {
> > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > + offset = usage_id -
> > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > + hg_state = hg_group->hg_states[offset];
> > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > + ret = 0;
>
> return 0;
>
> > + break;
> > + default:
> return -EINVAL;
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/* Parse report which is specific to an usage id */
> > +static int hinge_parse_report(struct platform_device *pdev,
> > + struct hid_sensor_hub_device *hsdev,
> > + unsigned int usage_id, unsigned int
> > attr_usage_id,
> > + struct hinge_state *st)
> > +{
> > + int ret;
> > +
> > + ret = sensor_hub_input_get_attribute_info(
> > + hsdev, HID_INPUT_REPORT, usage_id, attr_usage_id, &st-
> > >hinge);
> > + if (ret < 0)
> > + return ret;
> > +
> > + st->hinge_address = attr_usage_id;
> > + st->scale_precision =
> > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE, &st-
> > >hinge,
> > + &st->scale_pre_decml,
> > + &st->scale_post_decml);
> > +
> > + /* Set Sensitivity field ids, when there is no individual
> > modifier */
> > + if (hg_group->common_attributes.sensitivity.index < 0) {
> > + sensor_hub_input_get_attribute_info(
> > + hsdev, HID_FEATURE_REPORT, usage_id,
> > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_AB
> > S |
> > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALU
> > E_1,
> > + &hg_group->common_attributes.sensitivity);
> > + dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
> > + hg_group->common_attributes.sensitivity.index,
> > + hg_group-
> > >common_attributes.sensitivity.report_id);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/* Function to initialize the processing for usage id */
> > +static int hinge_add_iio_device(struct platform_device *pdev, int
> > index,
> > + const char *name, struct hinge_state
> > **st)
> > +{
> > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > + struct hinge_state *hg_state;
> > + struct iio_dev *indio_dev;
> > + int ret;
> > +
> > + indio_dev =
> > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > hinge_state));
>
> sizeof (*hg_state) preferred.
>
> > + if (indio_dev == NULL)
> > + return -ENOMEM;
> > +
> > + hg_state = iio_priv(indio_dev);
> > + hg_state->indio_dev = indio_dev;
> > +
> > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > + indio_dev->channels =
> > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > GFP_KERNEL);
>
> I don't immediately see anything that is modifying channels. As such
> you
> should be able have it shared by all the instances.
>
> > + if (!indio_dev->channels)
> > + return -ENOMEM;
> > +
> > + ret = hinge_parse_report(
> > + pdev, hsdev, hsdev->usage,
> > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 + index,
> > hg_state);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to setup attributes\n");
> > + goto error_free_dev_mem;
> > + }
> > +
> > + indio_dev->dev.parent = &pdev->dev;
> > + indio_dev->info = &hinge_info;
> > + indio_dev->name = name;
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > +
> > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > + &hg_group->common_attributes);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "trigger setup failed\n");
> > + goto error_free_dev_mem;
> > + }
> > +
> > + ret = iio_device_register(indio_dev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "device register failed\n");
> > + goto error_remove_trigger;
> > + }
> > +
> > + *st = hg_state;
> > +
> > + return ret;
> > +
> > +error_remove_trigger:
> > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > >common_attributes);
> > +error_free_dev_mem:
> > + kfree(indio_dev->channels);
> > + return ret;
> > +}
> > +
> > +/* Function to deinitialize the processing for usage id */
> > +static int hinge_remove_iio_device(struct platform_device *pdev,
> > int index)
> > +{
> > + struct hinge_state *hg_state = hg_group->hg_states[index];
> > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > +
> > + iio_device_unregister(indio_dev);
> > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > >common_attributes);
> > + kfree(indio_dev->channels);
> > +
> > + return 0;
> > +}
> > +
> > +static int hid_hinge_probe(struct platform_device *pdev)
> > +{
> > + struct hinge_state *hg_state;
> > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > + static const char *const names[] = { "hinge", "screen",
> > "keyboard" };
> > + int ret;
> > + int i;
> > +
> > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct hinge_group),
> > + GFP_KERNEL);
>
> As mentioned above, I'd really not expect to see a global like this.
> Technically nothing stops there being more than one instance of this
> device on a platform (even if that would be a bit odd) + it's almost
> always cleaner to not use a global in the first place.
>
> > + if (!hg_group)
> > + return -ENOMEM;
> > +
> > + hg_group->common_attributes.hsdev = hsdev;
> > + hg_group->common_attributes.pdev = pdev;
> > +
> > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev->usage,
> > + &hg_group-
> > >common_attributes);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to setup common
> > attributes\n");
> > + return ret;
> > + }
> > +
> > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > + ret = hinge_add_iio_device(pdev, i, names[i],
> > &hg_state);
> > + if (ret)
> > + goto err_probe;
> > +
> > + hg_group->hg_states[i] = hg_state;
> > + }
> > +
> > + /* use the first iio device to do the PM */
> > + platform_set_drvdata(pdev, hg_group->hg_states[0]->indio_dev);
> > +
> > + hg_group->callbacks.send_event = hinge_proc_event;
> > + hg_group->callbacks.capture_sample = hinge_capture_sample;
> > + hg_group->callbacks.pdev = pdev;
> > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > + &hg_group->callbacks);
> > + if (ret < 0)
> > + dev_err(&pdev->dev, "callback reg failed\n");
> > +
> > + return ret;
> > +
> > +err_probe:
> > + for (i--; i >= 0; i--)
> > + hinge_remove_iio_device(pdev, i);
> > +
> > + return ret;
> > +}
> > +
> > +/* Function to deinitialize the processing for usage id */
> > +static int hid_hinge_remove(struct platform_device *pdev)
> > +{
> > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > + int i;
> > +
> > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > +
> > + for (i = 0; i < IIO_DEV_NUM; i++)
> > + hinge_remove_iio_device(pdev, i);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct platform_device_id hid_hinge_ids[] = {
> > + {
> > + /* Format: HID-SENSOR-INT-usage_id_in_hex_lowercase */
> > + .name = "HID-SENSOR-INT-020b",
> > + },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > +
> > +static struct platform_driver hid_hinge_platform_driver = {
> > + .id_table = hid_hinge_ids,
> > + .driver = {
> > + .name = KBUILD_MODNAME,
> > + .pm = &hid_sensor_pm_ops,
> > + },
> > + .probe = hid_hinge_probe,
> > + .remove = hid_hinge_remove,
> > +};
> > +module_platform_driver(hid_hinge_platform_driver);
> > +
> > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > +MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal
2020-11-21 17:22 ` Jonathan Cameron
@ 2020-11-22 1:54 ` Pandruvada, Srinivas
0 siblings, 0 replies; 25+ messages in thread
From: Pandruvada, Srinivas @ 2020-11-22 1:54 UTC (permalink / raw)
To: jic23, Ye, Xiang; +Cc: jikos, linux-input, linux-kernel, linux-iio
On Sat, 2020-11-21 at 17:22 +0000, Jonathan Cameron wrote:
> On Thu, 19 Nov 2020 18:03:29 +0800
> Ye Xiang <xiang.ye@intel.com> wrote:
>
> > To avoid pm_runtime_disable called repeatedly by hid sensor
> > drivers,
> > decrease runtime pm enable count after call it.
> >
> > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> This sounds like a fix. If so please make that clear and add a fixes
> tag.
>
> If it couldn't have been triggered before, then please explain why in
> this
> patch description.
Normally it is not a problem as this is called during driver remove and
next time insmod this data structure is recreated and count will init
again. This is the artifect of the shared iio devices and one of them
is still open, so the instance will not be freed.
But patch is fine as to do opposite of what is done during alloc.
Thanks,
Srinivas
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > index ff375790b7e8..30340abcbc8d 100644
> > --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > @@ -227,8 +227,10 @@ static int
> > hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
> > void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
> > struct hid_sensor_common *attrb)
> > {
> > - if (atomic_read(&attrb->runtime_pm_enable))
> > + if (atomic_read(&attrb->runtime_pm_enable)) {
> > pm_runtime_disable(&attrb->pdev->dev);
> > + atomic_dec(&attrb->runtime_pm_enable);
> > + }
> >
> > pm_runtime_set_suspended(&attrb->pdev->dev);
> > pm_runtime_put_noidle(&attrb->pdev->dev);
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-22 1:46 ` Pandruvada, Srinivas
@ 2020-11-22 2:14 ` Pandruvada, Srinivas
2020-11-22 14:14 ` Jonathan Cameron
0 siblings, 1 reply; 25+ messages in thread
From: Pandruvada, Srinivas @ 2020-11-22 2:14 UTC (permalink / raw)
To: jic23, Ye, Xiang; +Cc: jikos, linux-input, linux-kernel, linux-iio
On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > On Thu, 19 Nov 2020 18:03:31 +0800
> > Ye Xiang <xiang.ye@intel.com> wrote:
> >
> > > The Hinge sensor is a common custom sensor on laptops. It
> > > calculates
> > > the angle between the lid (screen) and the base (keyboard). In
> > > addition,
> > > it also exposes screen and the keyboard angels with respect to
> > > the
> > > ground. Applications can easily get laptop's status in space
> > > through
> > > this sensor, in order to display appropriate user interface.
> >
> > I'm a little unclear on why the 3 axes aren't treated as a single
> > sensor.
> > You seem to always grab the 3 together or am I missing something?
> >
> > That will greatly simplify things and get rid of the need to have
> > a shared trigger with the problems that causes in the previous
> > patch.
>
> They are not three axes, they are independent. Xiang did try adding
> x,
> y and z component to represent x as hinge, y as keyboard and z as
> lid.
> But I was not convinced.
> The problem is that then what will be sysfs interface? They are
> really
> a three sensors. Or we create new interface to call
> in_angl_raw_keyboard
> in_angl_raw_screen
> in_angl_raw_lid.
>
You seem to indicate this is possible now some new "label" patch.
Is this the patch?
commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
Author: Phil Reid <preid@electromag.com.au>
Date: Thu Sep 19 22:36:08 2019 +0800
Ideally, one iio device here is much easy to manage as other HID
sensors. If we can add something other that "x", "y" and "z" component.
Thanks,
Srinivas
> Thanks,
> Srinivas
>
>
> > Thanks,
> >
> > Jonathan
> >
> > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > ---
> > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > drivers/iio/position/Kconfig | 16 +
> > > drivers/iio/position/Makefile | 3 +
> > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > ++++++++++++++++++
> >
> > Given it's custom probably needs a more specific name. I guess
> > hid-sensor-custom-intel-hinge.c might be safe?
> >
> > Same for other places we need names in here.
> >
> > > 4 files changed, 433 insertions(+)
> > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > hinge.c
> > >
> > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > attributes.c
> > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > index 442ff787f7af..5b822a4298a0 100644
> > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > @@ -71,6 +71,8 @@ static struct {
> > > {HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES,
> > > 1000, 0},
> > >
> > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > + {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > 17453293},
> > > };
> > >
> > > static void simple_div(int dividend, int divisor, int *whole,
> > > diff --git a/drivers/iio/position/Kconfig
> > > b/drivers/iio/position/Kconfig
> > > index eda67f008c5b..0346f6f2b422 100644
> > > --- a/drivers/iio/position/Kconfig
> > > +++ b/drivers/iio/position/Kconfig
> > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > To compile this driver as a module, choose M here: the module
> > > will be called iqs624-pos.
> > >
> > > +config HID_SENSOR_CUSTOM_HINGE
> > > + depends on HID_SENSOR_HUB
> > > + select IIO_BUFFER
> > > + select IIO_TRIGGERED_BUFFER
> > > + select HID_SENSOR_IIO_COMMON
> > > + select HID_SENSOR_IIO_TRIGGER
> > > + tristate "HID Hinge"
> > > + help
> > > + This sensor present three angles, hinge angel, screen angles
> > > + and keyboard angle respect to horizon (ground).
> > > + Say yes here to build support for the HID SENSOR CUSTOM
> > > + HINGE.
> >
> > Capitalization is a bit odd looking. I'd drop it.
> >
> > > +
> > > + To compile this driver as a module, choose M here: the
> > > + module will be called hid-sensor-custom-hinge.
> > > +
> > > endmenu
> > > diff --git a/drivers/iio/position/Makefile
> > > b/drivers/iio/position/Makefile
> > > index 3cbe7a734352..7a6225977a01 100644
> > > --- a/drivers/iio/position/Makefile
> > > +++ b/drivers/iio/position/Makefile
> > > @@ -5,3 +5,6 @@
> > > # When adding new entries keep the list in alphabetical order
> > >
> > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > +
> > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > hinge.o
> >
> > Alphabetical order preferred.
> >
> > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
> >
> > Why?
> >
> > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > new file mode 100644
> > > index 000000000000..a91b333f36fa
> > > --- /dev/null
> > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > @@ -0,0 +1,412 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * HID Sensors Driver
> > > + * Copyright (c) 2020, Intel Corporation.
> > > + */
> > > +#include <linux/hid-sensor-hub.h>
> > > +#include <linux/iio/buffer.h>
> > > +#include <linux/iio/iio.h>
> > > +#include <linux/platform_device.h>
> > > +
> > > +#include "hid-sensor-trigger.h"
> > > +
> > > +/* Channel definitions */
> > > +static const struct iio_chan_spec hinge_channels[] = {
> > > + { .type = IIO_ANGL,
> > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > + .info_mask_shared_by_type =
> > > + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE)
> > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > + .scan_type.realbits = 16,
> > > + .scan_type.storagebits = 32,
> >
> > It a bit odd to see a single channel that is 16 bits inside a 32
> > bit
> > with
> > no shift or similar. Why not just pack it into 16 bits?
> >
> > > + .scan_type.sign = 's',
> > > + .scan_index = 0 },
> > > +
> > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > +};
> > > +
> > > +struct hinge_state {
> > > + struct iio_dev *indio_dev;
> > > + struct hid_sensor_hub_attribute_info hinge;
> > > + /* Reserve for 1 channel + pading + timestamp */
> > > + u32 hinge_val[1 + 3];
> >
> > __aligned(8)
> >
> > see below for requirements on this.
> > Perhaps better to use
> >
> > struct hinge_scan {
> > u32 val;
> > s64 timestamp __aligned(8); // Note this is needed for
> > x86_32
> > } scan;
> >
> > > + int scale_pre_decml;
> > > + int scale_post_decml;
> > > + int scale_precision;
> > > + int value_offset;
> > > + int64_t timestamp;
> > > + u32 hinge_address;
> > > +};
> > > +
> > > +#define IIO_DEV_NUM 3
> >
> > That needs a prefix to make it clear it's not a generic constant
> > but is specific to this driver.
> >
> > > +
> > > +struct hinge_group {
> > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > + struct hid_sensor_hub_callbacks callbacks;
> > > + struct hid_sensor_common common_attributes;
> > > +};
> > > +
> > > +static struct hinge_group *hg_group;
> >
> > We shouldn't see globals like this. Please figure out how to avoid
> > it.
> >
> > > +
> > > +/* Channel read_raw handler */
> > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan, int *val,
> > > int *val2,
> > > + long mask)
> > > +{
> > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > + struct hid_sensor_hub_device *hsdev;
> > > + int report_id = -1;
> > > + int ret_type;
> > > + s32 min;
> > > +
> > > + hsdev = hg_group->common_attributes.hsdev;
> > > +
> > > + *val = 0;
> > > + *val2 = 0;
> > > + switch (mask) {
> > > + case IIO_CHAN_INFO_RAW:
> > > + hid_sensor_power_state(&hg_group->common_attributes,
> > > true);
> > > + report_id = hg_state->hinge.report_id;
> > > + min = hg_state->hinge.logical_minimum;
> > > + if (report_id < 0) {
> > > + *val = 0;
> > > + hid_sensor_power_state(&hg_group-
> > > > common_attributes,
> > > + false);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + *val = sensor_hub_input_attr_get_raw_value(
> > > + hg_group->common_attributes.hsdev, hsdev-
> > > > usage,
> > > + hg_state->hinge_address, report_id,
> > > SENSOR_HUB_SYNC,
> > > + min < 0);
> > > +
> > > + hid_sensor_power_state(&hg_group->common_attributes,
> > > false);
> > > + ret_type = IIO_VAL_INT;
> > > + break;
> > > + case IIO_CHAN_INFO_SCALE:
> > > + *val = hg_state->scale_pre_decml;
> > > + *val2 = hg_state->scale_post_decml;
> > > + ret_type = hg_state->scale_precision;
> > > + break;
> > > + case IIO_CHAN_INFO_OFFSET:
> > > + *val = hg_state->value_offset;
> > > + ret_type = IIO_VAL_INT;
> > > + break;
> > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > + ret_type = hid_sensor_read_samp_freq_value(
> > > + &hg_group->common_attributes, val, val2);
> > > + break;
> > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > + &hg_group->common_attributes, val, val2);
> > > + break;
> > > + default:
> > > + ret_type = -EINVAL;
> > > + break;
> > > + }
> > > +
> > > + return ret_type;
> > > +}
> > > +
> > > +/* Channel write_raw handler */
> > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan, int val,
> > > int val2,
> > > + long mask)
> > > +{
> > > + int ret;
> > > +
> > > + switch (mask) {
> > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > + ret = hid_sensor_write_samp_freq_value(
> > > + &hg_group->common_attributes, val, val2);
> > > + break;
> > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > + ret = hid_sensor_write_raw_hyst_value(
> > > + &hg_group->common_attributes, val, val2);
> > > +
> > > + break;
> > > + default:
> > > + ret = -EINVAL;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static const struct iio_info hinge_info = {
> > > + .read_raw = &hinge_read_raw,
> > > + .write_raw = &hinge_write_raw,
> > > +};
> > > +
> > > +/*
> > > + * Function to push data to buffer;
> > > + * wrapper added for symmetry with other hid-sensor drivers
> > > + */
> > > +static void hid_sensor_push_data(struct iio_dev *indio_dev, void
> > > *data, int len,
> >
> > This doesn't seem to be generic, so don't name it as such.
> >
> > > + int64_t timestamp)
> > > +{
> > > + iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
> > I hope that data buffer obeys the various rules needed by (and
> > admittedly
> > not that well documented) iio_push_to_buffers_with_timestamp()
> >
> > 1. Needs to be 8 byte aligned.
> > 2. Needs to have space for an aligned 8 byte timestamp at the end.
> >
> > > +}
> > > +
> > > +/*
> > > + * Callback handler to send event after all samples are received
> > > + * and captured.
> > > + */
> > > +static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
> > > + unsigned int usage_id, void *priv)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > If we push for all sensors together, better to have
> > this as a single iio_device with 3 channels.
> >
> > Use the channel labels (just added to IIO) to identify which is
> > which.
> >
> > > + struct hinge_state *hg_state;
> > > + struct iio_dev *indio_dev;
> > > +
> > > + hg_state = hg_group->hg_states[i];
> > > + indio_dev = hg_state->indio_dev;
> > > +
> > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > scan_bytes:%d\n",
> > > + __func__, hg_state->timestamp, indio_dev-
> > > > scan_bytes);
> > > +
> > > + if (!hg_state->timestamp)
> > > + hg_state->timestamp =
> > > iio_get_time_ns(indio_dev);
> > > +
> > > + hid_sensor_push_data(indio_dev, hg_state->hinge_val,
> > > + sizeof(hg_state->hinge_val),
> > > + hg_state->timestamp);
> > > +
> > > + hg_state->timestamp = 0;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/* Capture samples in local storage */
> > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > *hsdev,
> > > + unsigned int usage_id, size_t raw_len,
> > > + char *raw_data, void *priv)
> > > +{
> > > + struct hinge_state *hg_state;
> > > + int offset;
> > > + int ret = -EINVAL;
> > > + int i;
> > > +
> > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > + hg_group->hg_states[i]->timestamp =
> >
> > This rather implies all the data is captured together... If so
> > single
> > iio_device may make more sense.
> >
> > > + hid_sensor_convert_timestamp(
> > > + &hg_group->common_attributes,
> > > + *(int64_t *)raw_data);
> > > + return 0;
> > > + }
> > > +
> > > + switch (usage_id) {
> > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > + offset = usage_id -
> > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > + hg_state = hg_group->hg_states[offset];
> > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > + ret = 0;
> >
> > return 0;
> >
> > > + break;
> > > + default:
> > return -EINVAL;
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +/* Parse report which is specific to an usage id */
> > > +static int hinge_parse_report(struct platform_device *pdev,
> > > + struct hid_sensor_hub_device *hsdev,
> > > + unsigned int usage_id, unsigned int
> > > attr_usage_id,
> > > + struct hinge_state *st)
> > > +{
> > > + int ret;
> > > +
> > > + ret = sensor_hub_input_get_attribute_info(
> > > + hsdev, HID_INPUT_REPORT, usage_id, attr_usage_id, &st-
> > > > hinge);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + st->hinge_address = attr_usage_id;
> > > + st->scale_precision =
> > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE, &st-
> > > > hinge,
> > > + &st->scale_pre_decml,
> > > + &st->scale_post_decml);
> > > +
> > > + /* Set Sensitivity field ids, when there is no individual
> > > modifier */
> > > + if (hg_group->common_attributes.sensitivity.index < 0) {
> > > + sensor_hub_input_get_attribute_info(
> > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_AB
> > > S |
> > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALU
> > > E_1,
> > > + &hg_group->common_attributes.sensitivity);
> > > + dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
> > > + hg_group->common_attributes.sensitivity.index,
> > > + hg_group-
> > > > common_attributes.sensitivity.report_id);
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +/* Function to initialize the processing for usage id */
> > > +static int hinge_add_iio_device(struct platform_device *pdev,
> > > int
> > > index,
> > > + const char *name, struct hinge_state
> > > **st)
> > > +{
> > > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > > + struct hinge_state *hg_state;
> > > + struct iio_dev *indio_dev;
> > > + int ret;
> > > +
> > > + indio_dev =
> > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > hinge_state));
> >
> > sizeof (*hg_state) preferred.
> >
> > > + if (indio_dev == NULL)
> > > + return -ENOMEM;
> > > +
> > > + hg_state = iio_priv(indio_dev);
> > > + hg_state->indio_dev = indio_dev;
> > > +
> > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > + indio_dev->channels =
> > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > GFP_KERNEL);
> >
> > I don't immediately see anything that is modifying channels. As
> > such
> > you
> > should be able have it shared by all the instances.
> >
> > > + if (!indio_dev->channels)
> > > + return -ENOMEM;
> > > +
> > > + ret = hinge_parse_report(
> > > + pdev, hsdev, hsdev->usage,
> > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 + index,
> > > hg_state);
> > > + if (ret) {
> > > + dev_err(&pdev->dev, "failed to setup attributes\n");
> > > + goto error_free_dev_mem;
> > > + }
> > > +
> > > + indio_dev->dev.parent = &pdev->dev;
> > > + indio_dev->info = &hinge_info;
> > > + indio_dev->name = name;
> > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > +
> > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > + &hg_group->common_attributes);
> > > + if (ret < 0) {
> > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > + goto error_free_dev_mem;
> > > + }
> > > +
> > > + ret = iio_device_register(indio_dev);
> > > + if (ret) {
> > > + dev_err(&pdev->dev, "device register failed\n");
> > > + goto error_remove_trigger;
> > > + }
> > > +
> > > + *st = hg_state;
> > > +
> > > + return ret;
> > > +
> > > +error_remove_trigger:
> > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > common_attributes);
> > > +error_free_dev_mem:
> > > + kfree(indio_dev->channels);
> > > + return ret;
> > > +}
> > > +
> > > +/* Function to deinitialize the processing for usage id */
> > > +static int hinge_remove_iio_device(struct platform_device *pdev,
> > > int index)
> > > +{
> > > + struct hinge_state *hg_state = hg_group->hg_states[index];
> > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > +
> > > + iio_device_unregister(indio_dev);
> > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > common_attributes);
> > > + kfree(indio_dev->channels);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > +{
> > > + struct hinge_state *hg_state;
> > > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > > + static const char *const names[] = { "hinge", "screen",
> > > "keyboard" };
> > > + int ret;
> > > + int i;
> > > +
> > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct hinge_group),
> > > + GFP_KERNEL);
> >
> > As mentioned above, I'd really not expect to see a global like
> > this.
> > Technically nothing stops there being more than one instance of
> > this
> > device on a platform (even if that would be a bit odd) + it's
> > almost
> > always cleaner to not use a global in the first place.
> >
> > > + if (!hg_group)
> > > + return -ENOMEM;
> > > +
> > > + hg_group->common_attributes.hsdev = hsdev;
> > > + hg_group->common_attributes.pdev = pdev;
> > > +
> > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev->usage,
> > > + &hg_group-
> > > > common_attributes);
> > > + if (ret) {
> > > + dev_err(&pdev->dev, "failed to setup common
> > > attributes\n");
> > > + return ret;
> > > + }
> > > +
> > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > &hg_state);
> > > + if (ret)
> > > + goto err_probe;
> > > +
> > > + hg_group->hg_states[i] = hg_state;
> > > + }
> > > +
> > > + /* use the first iio device to do the PM */
> > > + platform_set_drvdata(pdev, hg_group->hg_states[0]->indio_dev);
> > > +
> > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > + hg_group->callbacks.capture_sample = hinge_capture_sample;
> > > + hg_group->callbacks.pdev = pdev;
> > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > + &hg_group->callbacks);
> > > + if (ret < 0)
> > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > +
> > > + return ret;
> > > +
> > > +err_probe:
> > > + for (i--; i >= 0; i--)
> > > + hinge_remove_iio_device(pdev, i);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +/* Function to deinitialize the processing for usage id */
> > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > +{
> > > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > > + int i;
> > > +
> > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > +
> > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > + hinge_remove_iio_device(pdev, i);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > + {
> > > + /* Format: HID-SENSOR-INT-usage_id_in_hex_lowercase */
> > > + .name = "HID-SENSOR-INT-020b",
> > > + },
> > > + { /* sentinel */ }
> > > +};
> > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > +
> > > +static struct platform_driver hid_hinge_platform_driver = {
> > > + .id_table = hid_hinge_ids,
> > > + .driver = {
> > > + .name = KBUILD_MODNAME,
> > > + .pm = &hid_sensor_pm_ops,
> > > + },
> > > + .probe = hid_hinge_probe,
> > > + .remove = hid_hinge_remove,
> > > +};
> > > +module_platform_driver(hid_hinge_platform_driver);
> > > +
> > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > +MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-22 2:14 ` Pandruvada, Srinivas
@ 2020-11-22 14:14 ` Jonathan Cameron
2020-11-22 15:51 ` Pandruvada, Srinivas
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-22 14:14 UTC (permalink / raw)
To: Pandruvada, Srinivas
Cc: Ye, Xiang, jikos, linux-input, linux-kernel, linux-iio
On Sun, 22 Nov 2020 02:14:16 +0000
"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> > On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > > On Thu, 19 Nov 2020 18:03:31 +0800
> > > Ye Xiang <xiang.ye@intel.com> wrote:
> > >
> > > > The Hinge sensor is a common custom sensor on laptops. It
> > > > calculates
> > > > the angle between the lid (screen) and the base (keyboard). In
> > > > addition,
> > > > it also exposes screen and the keyboard angels with respect to
> > > > the
> > > > ground. Applications can easily get laptop's status in space
> > > > through
> > > > this sensor, in order to display appropriate user interface.
> > >
> > > I'm a little unclear on why the 3 axes aren't treated as a single
> > > sensor.
> > > You seem to always grab the 3 together or am I missing something?
> > >
> > > That will greatly simplify things and get rid of the need to have
> > > a shared trigger with the problems that causes in the previous
> > > patch.
> >
> > They are not three axes, they are independent. Xiang did try adding
> > x,
> > y and z component to represent x as hinge, y as keyboard and z as
> > lid.
> > But I was not convinced.
> > The problem is that then what will be sysfs interface? They are
> > really
> > a three sensors. Or we create new interface to call
> > in_angl_raw_keyboard
> > in_angl_raw_screen
> > in_angl_raw_lid.
> >
> You seem to indicate this is possible now some new "label" patch.
> Is this the patch?
> commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
> Author: Phil Reid <preid@electromag.com.au>
> Date: Thu Sep 19 22:36:08 2019 +0800
Nope, this one
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1d4ef9b39ebecca827642b8897d2d79ea2026682
The one above adds a per device label which wouldn't be much use for your
case, but this one adds a per channel label.
Done via a read_label callback.
Here you'd want to use indexed channels so something like.
in_angl0_raw
in_angl1_raw
in_angl2_raw
and
in_angl0_label = keyboard
in_angl1_label = screen
in_angl2_label = lid
>
> Ideally, one iio device here is much easy to manage as other HID
> sensors. If we can add something other that "x", "y" and "z" component.
Agreed, using axes makes no real sense here and extended_name is
just a mess from ABI point of view. Trying to solve this was the
reason we added the _label interface.
Jonathan
>
> Thanks,
> Srinivas
>
> > Thanks,
> > Srinivas
> >
> >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > > ---
> > > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > > drivers/iio/position/Kconfig | 16 +
> > > > drivers/iio/position/Makefile | 3 +
> > > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > > ++++++++++++++++++
> > >
> > > Given it's custom probably needs a more specific name. I guess
> > > hid-sensor-custom-intel-hinge.c might be safe?
> > >
> > > Same for other places we need names in here.
> > >
> > > > 4 files changed, 433 insertions(+)
> > > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > > hinge.c
> > > >
> > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > > attributes.c
> > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > index 442ff787f7af..5b822a4298a0 100644
> > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > @@ -71,6 +71,8 @@ static struct {
> > > > {HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES,
> > > > 1000, 0},
> > > >
> > > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > > + {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > > 17453293},
> > > > };
> > > >
> > > > static void simple_div(int dividend, int divisor, int *whole,
> > > > diff --git a/drivers/iio/position/Kconfig
> > > > b/drivers/iio/position/Kconfig
> > > > index eda67f008c5b..0346f6f2b422 100644
> > > > --- a/drivers/iio/position/Kconfig
> > > > +++ b/drivers/iio/position/Kconfig
> > > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > > To compile this driver as a module, choose M here: the module
> > > > will be called iqs624-pos.
> > > >
> > > > +config HID_SENSOR_CUSTOM_HINGE
> > > > + depends on HID_SENSOR_HUB
> > > > + select IIO_BUFFER
> > > > + select IIO_TRIGGERED_BUFFER
> > > > + select HID_SENSOR_IIO_COMMON
> > > > + select HID_SENSOR_IIO_TRIGGER
> > > > + tristate "HID Hinge"
> > > > + help
> > > > + This sensor present three angles, hinge angel, screen angles
> > > > + and keyboard angle respect to horizon (ground).
> > > > + Say yes here to build support for the HID SENSOR CUSTOM
> > > > + HINGE.
> > >
> > > Capitalization is a bit odd looking. I'd drop it.
> > >
> > > > +
> > > > + To compile this driver as a module, choose M here: the
> > > > + module will be called hid-sensor-custom-hinge.
> > > > +
> > > > endmenu
> > > > diff --git a/drivers/iio/position/Makefile
> > > > b/drivers/iio/position/Makefile
> > > > index 3cbe7a734352..7a6225977a01 100644
> > > > --- a/drivers/iio/position/Makefile
> > > > +++ b/drivers/iio/position/Makefile
> > > > @@ -5,3 +5,6 @@
> > > > # When adding new entries keep the list in alphabetical order
> > > >
> > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > +
> > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > > hinge.o
> > >
> > > Alphabetical order preferred.
> > >
> > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
> > >
> > > Why?
> > >
> > > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > new file mode 100644
> > > > index 000000000000..a91b333f36fa
> > > > --- /dev/null
> > > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > @@ -0,0 +1,412 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +/*
> > > > + * HID Sensors Driver
> > > > + * Copyright (c) 2020, Intel Corporation.
> > > > + */
> > > > +#include <linux/hid-sensor-hub.h>
> > > > +#include <linux/iio/buffer.h>
> > > > +#include <linux/iio/iio.h>
> > > > +#include <linux/platform_device.h>
> > > > +
> > > > +#include "hid-sensor-trigger.h"
> > > > +
> > > > +/* Channel definitions */
> > > > +static const struct iio_chan_spec hinge_channels[] = {
> > > > + { .type = IIO_ANGL,
> > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > > + .info_mask_shared_by_type =
> > > > + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE)
> > > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > > + .scan_type.realbits = 16,
> > > > + .scan_type.storagebits = 32,
> > >
> > > It a bit odd to see a single channel that is 16 bits inside a 32
> > > bit
> > > with
> > > no shift or similar. Why not just pack it into 16 bits?
> > >
> > > > + .scan_type.sign = 's',
> > > > + .scan_index = 0 },
> > > > +
> > > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > > +};
> > > > +
> > > > +struct hinge_state {
> > > > + struct iio_dev *indio_dev;
> > > > + struct hid_sensor_hub_attribute_info hinge;
> > > > + /* Reserve for 1 channel + pading + timestamp */
> > > > + u32 hinge_val[1 + 3];
> > >
> > > __aligned(8)
> > >
> > > see below for requirements on this.
> > > Perhaps better to use
> > >
> > > struct hinge_scan {
> > > u32 val;
> > > s64 timestamp __aligned(8); // Note this is needed for
> > > x86_32
> > > } scan;
> > >
> > > > + int scale_pre_decml;
> > > > + int scale_post_decml;
> > > > + int scale_precision;
> > > > + int value_offset;
> > > > + int64_t timestamp;
> > > > + u32 hinge_address;
> > > > +};
> > > > +
> > > > +#define IIO_DEV_NUM 3
> > >
> > > That needs a prefix to make it clear it's not a generic constant
> > > but is specific to this driver.
> > >
> > > > +
> > > > +struct hinge_group {
> > > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > > + struct hid_sensor_hub_callbacks callbacks;
> > > > + struct hid_sensor_common common_attributes;
> > > > +};
> > > > +
> > > > +static struct hinge_group *hg_group;
> > >
> > > We shouldn't see globals like this. Please figure out how to avoid
> > > it.
> > >
> > > > +
> > > > +/* Channel read_raw handler */
> > > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > > + struct iio_chan_spec const *chan, int *val,
> > > > int *val2,
> > > > + long mask)
> > > > +{
> > > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > > + struct hid_sensor_hub_device *hsdev;
> > > > + int report_id = -1;
> > > > + int ret_type;
> > > > + s32 min;
> > > > +
> > > > + hsdev = hg_group->common_attributes.hsdev;
> > > > +
> > > > + *val = 0;
> > > > + *val2 = 0;
> > > > + switch (mask) {
> > > > + case IIO_CHAN_INFO_RAW:
> > > > + hid_sensor_power_state(&hg_group->common_attributes,
> > > > true);
> > > > + report_id = hg_state->hinge.report_id;
> > > > + min = hg_state->hinge.logical_minimum;
> > > > + if (report_id < 0) {
> > > > + *val = 0;
> > > > + hid_sensor_power_state(&hg_group-
> > > > > common_attributes,
> > > > + false);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + *val = sensor_hub_input_attr_get_raw_value(
> > > > + hg_group->common_attributes.hsdev, hsdev-
> > > > > usage,
> > > > + hg_state->hinge_address, report_id,
> > > > SENSOR_HUB_SYNC,
> > > > + min < 0);
> > > > +
> > > > + hid_sensor_power_state(&hg_group->common_attributes,
> > > > false);
> > > > + ret_type = IIO_VAL_INT;
> > > > + break;
> > > > + case IIO_CHAN_INFO_SCALE:
> > > > + *val = hg_state->scale_pre_decml;
> > > > + *val2 = hg_state->scale_post_decml;
> > > > + ret_type = hg_state->scale_precision;
> > > > + break;
> > > > + case IIO_CHAN_INFO_OFFSET:
> > > > + *val = hg_state->value_offset;
> > > > + ret_type = IIO_VAL_INT;
> > > > + break;
> > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > + ret_type = hid_sensor_read_samp_freq_value(
> > > > + &hg_group->common_attributes, val, val2);
> > > > + break;
> > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > > + &hg_group->common_attributes, val, val2);
> > > > + break;
> > > > + default:
> > > > + ret_type = -EINVAL;
> > > > + break;
> > > > + }
> > > > +
> > > > + return ret_type;
> > > > +}
> > > > +
> > > > +/* Channel write_raw handler */
> > > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > > + struct iio_chan_spec const *chan, int val,
> > > > int val2,
> > > > + long mask)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + switch (mask) {
> > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > + ret = hid_sensor_write_samp_freq_value(
> > > > + &hg_group->common_attributes, val, val2);
> > > > + break;
> > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > + ret = hid_sensor_write_raw_hyst_value(
> > > > + &hg_group->common_attributes, val, val2);
> > > > +
> > > > + break;
> > > > + default:
> > > > + ret = -EINVAL;
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static const struct iio_info hinge_info = {
> > > > + .read_raw = &hinge_read_raw,
> > > > + .write_raw = &hinge_write_raw,
> > > > +};
> > > > +
> > > > +/*
> > > > + * Function to push data to buffer;
> > > > + * wrapper added for symmetry with other hid-sensor drivers
> > > > + */
> > > > +static void hid_sensor_push_data(struct iio_dev *indio_dev, void
> > > > *data, int len,
> > >
> > > This doesn't seem to be generic, so don't name it as such.
> > >
> > > > + int64_t timestamp)
> > > > +{
> > > > + iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
> > > I hope that data buffer obeys the various rules needed by (and
> > > admittedly
> > > not that well documented) iio_push_to_buffers_with_timestamp()
> > >
> > > 1. Needs to be 8 byte aligned.
> > > 2. Needs to have space for an aligned 8 byte timestamp at the end.
> > >
> > > > +}
> > > > +
> > > > +/*
> > > > + * Callback handler to send event after all samples are received
> > > > + * and captured.
> > > > + */
> > > > +static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
> > > > + unsigned int usage_id, void *priv)
> > > > +{
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > > If we push for all sensors together, better to have
> > > this as a single iio_device with 3 channels.
> > >
> > > Use the channel labels (just added to IIO) to identify which is
> > > which.
> > >
> > > > + struct hinge_state *hg_state;
> > > > + struct iio_dev *indio_dev;
> > > > +
> > > > + hg_state = hg_group->hg_states[i];
> > > > + indio_dev = hg_state->indio_dev;
> > > > +
> > > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > > scan_bytes:%d\n",
> > > > + __func__, hg_state->timestamp, indio_dev-
> > > > > scan_bytes);
> > > > +
> > > > + if (!hg_state->timestamp)
> > > > + hg_state->timestamp =
> > > > iio_get_time_ns(indio_dev);
> > > > +
> > > > + hid_sensor_push_data(indio_dev, hg_state->hinge_val,
> > > > + sizeof(hg_state->hinge_val),
> > > > + hg_state->timestamp);
> > > > +
> > > > + hg_state->timestamp = 0;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/* Capture samples in local storage */
> > > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > > *hsdev,
> > > > + unsigned int usage_id, size_t raw_len,
> > > > + char *raw_data, void *priv)
> > > > +{
> > > > + struct hinge_state *hg_state;
> > > > + int offset;
> > > > + int ret = -EINVAL;
> > > > + int i;
> > > > +
> > > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > + hg_group->hg_states[i]->timestamp =
> > >
> > > This rather implies all the data is captured together... If so
> > > single
> > > iio_device may make more sense.
> > >
> > > > + hid_sensor_convert_timestamp(
> > > > + &hg_group->common_attributes,
> > > > + *(int64_t *)raw_data);
> > > > + return 0;
> > > > + }
> > > > +
> > > > + switch (usage_id) {
> > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > > + offset = usage_id -
> > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > > + hg_state = hg_group->hg_states[offset];
> > > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > > + ret = 0;
> > >
> > > return 0;
> > >
> > > > + break;
> > > > + default:
> > > return -EINVAL;
> > > > + break;
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/* Parse report which is specific to an usage id */
> > > > +static int hinge_parse_report(struct platform_device *pdev,
> > > > + struct hid_sensor_hub_device *hsdev,
> > > > + unsigned int usage_id, unsigned int
> > > > attr_usage_id,
> > > > + struct hinge_state *st)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + ret = sensor_hub_input_get_attribute_info(
> > > > + hsdev, HID_INPUT_REPORT, usage_id, attr_usage_id, &st-
> > > > > hinge);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + st->hinge_address = attr_usage_id;
> > > > + st->scale_precision =
> > > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE, &st-
> > > > > hinge,
> > > > + &st->scale_pre_decml,
> > > > + &st->scale_post_decml);
> > > > +
> > > > + /* Set Sensitivity field ids, when there is no individual
> > > > modifier */
> > > > + if (hg_group->common_attributes.sensitivity.index < 0) {
> > > > + sensor_hub_input_get_attribute_info(
> > > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_AB
> > > > S |
> > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALU
> > > > E_1,
> > > > + &hg_group->common_attributes.sensitivity);
> > > > + dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
> > > > + hg_group->common_attributes.sensitivity.index,
> > > > + hg_group-
> > > > > common_attributes.sensitivity.report_id);
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/* Function to initialize the processing for usage id */
> > > > +static int hinge_add_iio_device(struct platform_device *pdev,
> > > > int
> > > > index,
> > > > + const char *name, struct hinge_state
> > > > **st)
> > > > +{
> > > > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > > > + struct hinge_state *hg_state;
> > > > + struct iio_dev *indio_dev;
> > > > + int ret;
> > > > +
> > > > + indio_dev =
> > > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > > hinge_state));
> > >
> > > sizeof (*hg_state) preferred.
> > >
> > > > + if (indio_dev == NULL)
> > > > + return -ENOMEM;
> > > > +
> > > > + hg_state = iio_priv(indio_dev);
> > > > + hg_state->indio_dev = indio_dev;
> > > > +
> > > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > > + indio_dev->channels =
> > > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > > GFP_KERNEL);
> > >
> > > I don't immediately see anything that is modifying channels. As
> > > such
> > > you
> > > should be able have it shared by all the instances.
> > >
> > > > + if (!indio_dev->channels)
> > > > + return -ENOMEM;
> > > > +
> > > > + ret = hinge_parse_report(
> > > > + pdev, hsdev, hsdev->usage,
> > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 + index,
> > > > hg_state);
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "failed to setup attributes\n");
> > > > + goto error_free_dev_mem;
> > > > + }
> > > > +
> > > > + indio_dev->dev.parent = &pdev->dev;
> > > > + indio_dev->info = &hinge_info;
> > > > + indio_dev->name = name;
> > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > +
> > > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > > + &hg_group->common_attributes);
> > > > + if (ret < 0) {
> > > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > > + goto error_free_dev_mem;
> > > > + }
> > > > +
> > > > + ret = iio_device_register(indio_dev);
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "device register failed\n");
> > > > + goto error_remove_trigger;
> > > > + }
> > > > +
> > > > + *st = hg_state;
> > > > +
> > > > + return ret;
> > > > +
> > > > +error_remove_trigger:
> > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > common_attributes);
> > > > +error_free_dev_mem:
> > > > + kfree(indio_dev->channels);
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/* Function to deinitialize the processing for usage id */
> > > > +static int hinge_remove_iio_device(struct platform_device *pdev,
> > > > int index)
> > > > +{
> > > > + struct hinge_state *hg_state = hg_group->hg_states[index];
> > > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > > +
> > > > + iio_device_unregister(indio_dev);
> > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > common_attributes);
> > > > + kfree(indio_dev->channels);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > > +{
> > > > + struct hinge_state *hg_state;
> > > > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > > > + static const char *const names[] = { "hinge", "screen",
> > > > "keyboard" };
> > > > + int ret;
> > > > + int i;
> > > > +
> > > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct hinge_group),
> > > > + GFP_KERNEL);
> > >
> > > As mentioned above, I'd really not expect to see a global like
> > > this.
> > > Technically nothing stops there being more than one instance of
> > > this
> > > device on a platform (even if that would be a bit odd) + it's
> > > almost
> > > always cleaner to not use a global in the first place.
> > >
> > > > + if (!hg_group)
> > > > + return -ENOMEM;
> > > > +
> > > > + hg_group->common_attributes.hsdev = hsdev;
> > > > + hg_group->common_attributes.pdev = pdev;
> > > > +
> > > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev->usage,
> > > > + &hg_group-
> > > > > common_attributes);
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "failed to setup common
> > > > attributes\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > > &hg_state);
> > > > + if (ret)
> > > > + goto err_probe;
> > > > +
> > > > + hg_group->hg_states[i] = hg_state;
> > > > + }
> > > > +
> > > > + /* use the first iio device to do the PM */
> > > > + platform_set_drvdata(pdev, hg_group->hg_states[0]->indio_dev);
> > > > +
> > > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > > + hg_group->callbacks.capture_sample = hinge_capture_sample;
> > > > + hg_group->callbacks.pdev = pdev;
> > > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > > + &hg_group->callbacks);
> > > > + if (ret < 0)
> > > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > > +
> > > > + return ret;
> > > > +
> > > > +err_probe:
> > > > + for (i--; i >= 0; i--)
> > > > + hinge_remove_iio_device(pdev, i);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/* Function to deinitialize the processing for usage id */
> > > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > > +{
> > > > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > > > + int i;
> > > > +
> > > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > > +
> > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > + hinge_remove_iio_device(pdev, i);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > > + {
> > > > + /* Format: HID-SENSOR-INT-usage_id_in_hex_lowercase */
> > > > + .name = "HID-SENSOR-INT-020b",
> > > > + },
> > > > + { /* sentinel */ }
> > > > +};
> > > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > > +
> > > > +static struct platform_driver hid_hinge_platform_driver = {
> > > > + .id_table = hid_hinge_ids,
> > > > + .driver = {
> > > > + .name = KBUILD_MODNAME,
> > > > + .pm = &hid_sensor_pm_ops,
> > > > + },
> > > > + .probe = hid_hinge_probe,
> > > > + .remove = hid_hinge_remove,
> > > > +};
> > > > +module_platform_driver(hid_hinge_platform_driver);
> > > > +
> > > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > > +MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-22 14:14 ` Jonathan Cameron
@ 2020-11-22 15:51 ` Pandruvada, Srinivas
2020-11-22 16:50 ` Jonathan Cameron
0 siblings, 1 reply; 25+ messages in thread
From: Pandruvada, Srinivas @ 2020-11-22 15:51 UTC (permalink / raw)
To: jic23; +Cc: jikos, linux-input, Ye, Xiang, linux-kernel, linux-iio
On Sun, 2020-11-22 at 14:14 +0000, Jonathan Cameron wrote:
> On Sun, 22 Nov 2020 02:14:16 +0000
> "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
>
> > On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> > > On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > > > On Thu, 19 Nov 2020 18:03:31 +0800
> > > > Ye Xiang <xiang.ye@intel.com> wrote:
> > > >
> > > > > The Hinge sensor is a common custom sensor on laptops. It
> > > > > calculates
> > > > > the angle between the lid (screen) and the base (keyboard).
> > > > > In
> > > > > addition,
> > > > > it also exposes screen and the keyboard angels with respect
> > > > > to
> > > > > the
> > > > > ground. Applications can easily get laptop's status in space
> > > > > through
> > > > > this sensor, in order to display appropriate user
> > > > > interface.
> > > >
> > > > I'm a little unclear on why the 3 axes aren't treated as a
> > > > single
> > > > sensor.
> > > > You seem to always grab the 3 together or am I missing
> > > > something?
> > > >
> > > > That will greatly simplify things and get rid of the need to
> > > > have
> > > > a shared trigger with the problems that causes in the previous
> > > > patch.
> > >
> > > They are not three axes, they are independent. Xiang did try
> > > adding
> > > x,
> > > y and z component to represent x as hinge, y as keyboard and z as
> > > lid.
> > > But I was not convinced.
> > > The problem is that then what will be sysfs interface? They are
> > > really
> > > a three sensors. Or we create new interface to call
> > > in_angl_raw_keyboard
> > > in_angl_raw_screen
> > > in_angl_raw_lid.
> > >
> > You seem to indicate this is possible now some new "label" patch.
> > Is this the patch?
> > commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
> > Author: Phil Reid <preid@electromag.com.au>
> > Date: Thu Sep 19 22:36:08 2019 +0800
>
> Nope, this one
> https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1d4ef9b39ebecca827642b8897d2d79ea2026682
>
> The one above adds a per device label which wouldn't be much use for
> your
> case, but this one adds a per channel label.
>
> Done via a read_label callback.
>
> Here you'd want to use indexed channels so something like.
>
> in_angl0_raw
> in_angl1_raw
> in_angl2_raw
>
> and
>
> in_angl0_label = keyboard
> in_angl1_label = screen
> in_angl2_label = lid
Thanks Jonathan. This will make the job easier.
Xiang,
You can use this method. Then you will not need other changes except
patch 1/4.
Also add a documentation patch to explain the mapping.
Thanks,
Srinivas
>
>
>
> > Ideally, one iio device here is much easy to manage as other HID
> > sensors. If we can add something other that "x", "y" and "z"
> > component.
>
> Agreed, using axes makes no real sense here and extended_name is
> just a mess from ABI point of view. Trying to solve this was the
> reason we added the _label interface.
>
> Jonathan
>
>
> > Thanks,
> > Srinivas
> >
> > > Thanks,
> > > Srinivas
> > >
> > >
> > > > Thanks,
> > > >
> > > > Jonathan
> > > >
> > > > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > > > ---
> > > > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > > > drivers/iio/position/Kconfig | 16 +
> > > > > drivers/iio/position/Makefile | 3 +
> > > > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > > > ++++++++++++++++++
> > > >
> > > > Given it's custom probably needs a more specific name. I guess
> > > > hid-sensor-custom-intel-hinge.c might be safe?
> > > >
> > > > Same for other places we need names in here.
> > > >
> > > > > 4 files changed, 433 insertions(+)
> > > > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > > > hinge.c
> > > > >
> > > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > > > attributes.c
> > > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > index 442ff787f7af..5b822a4298a0 100644
> > > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > @@ -71,6 +71,8 @@ static struct {
> > > > > {HID_USAGE_SENSOR_TEMPERATURE,
> > > > > HID_USAGE_SENSOR_UNITS_DEGREES,
> > > > > 1000, 0},
> > > > >
> > > > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > > > + {HID_USAGE_SENSOR_HINGE,
> > > > > HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > > > 17453293},
> > > > > };
> > > > >
> > > > > static void simple_div(int dividend, int divisor, int
> > > > > *whole,
> > > > > diff --git a/drivers/iio/position/Kconfig
> > > > > b/drivers/iio/position/Kconfig
> > > > > index eda67f008c5b..0346f6f2b422 100644
> > > > > --- a/drivers/iio/position/Kconfig
> > > > > +++ b/drivers/iio/position/Kconfig
> > > > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > > > To compile this driver as a module, choose M here:
> > > > > the module
> > > > > will be called iqs624-pos.
> > > > >
> > > > > +config HID_SENSOR_CUSTOM_HINGE
> > > > > + depends on HID_SENSOR_HUB
> > > > > + select IIO_BUFFER
> > > > > + select IIO_TRIGGERED_BUFFER
> > > > > + select HID_SENSOR_IIO_COMMON
> > > > > + select HID_SENSOR_IIO_TRIGGER
> > > > > + tristate "HID Hinge"
> > > > > + help
> > > > > + This sensor present three angles, hinge angel, screen
> > > > > angles
> > > > > + and keyboard angle respect to horizon (ground).
> > > > > + Say yes here to build support for the HID SENSOR
> > > > > CUSTOM
> > > > > + HINGE.
> > > >
> > > > Capitalization is a bit odd looking. I'd drop it.
> > > >
> > > > > +
> > > > > + To compile this driver as a module, choose M here:
> > > > > the
> > > > > + module will be called hid-sensor-custom-hinge.
> > > > > +
> > > > > endmenu
> > > > > diff --git a/drivers/iio/position/Makefile
> > > > > b/drivers/iio/position/Makefile
> > > > > index 3cbe7a734352..7a6225977a01 100644
> > > > > --- a/drivers/iio/position/Makefile
> > > > > +++ b/drivers/iio/position/Makefile
> > > > > @@ -5,3 +5,6 @@
> > > > > # When adding new entries keep the list in alphabetical
> > > > > order
> > > > >
> > > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > > +
> > > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > > > hinge.o
> > > >
> > > > Alphabetical order preferred.
> > > >
> > > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-
> > > > > sensors
> > > >
> > > > Why?
> > > >
> > > > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > new file mode 100644
> > > > > index 000000000000..a91b333f36fa
> > > > > --- /dev/null
> > > > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > @@ -0,0 +1,412 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > +/*
> > > > > + * HID Sensors Driver
> > > > > + * Copyright (c) 2020, Intel Corporation.
> > > > > + */
> > > > > +#include <linux/hid-sensor-hub.h>
> > > > > +#include <linux/iio/buffer.h>
> > > > > +#include <linux/iio/iio.h>
> > > > > +#include <linux/platform_device.h>
> > > > > +
> > > > > +#include "hid-sensor-trigger.h"
> > > > > +
> > > > > +/* Channel definitions */
> > > > > +static const struct iio_chan_spec hinge_channels[] = {
> > > > > + { .type = IIO_ANGL,
> > > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > > > + .info_mask_shared_by_type =
> > > > > + BIT(IIO_CHAN_INFO_OFFSET) |
> > > > > BIT(IIO_CHAN_INFO_SCALE)
> > > > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > > > + .scan_type.realbits = 16,
> > > > > + .scan_type.storagebits = 32,
> > > >
> > > > It a bit odd to see a single channel that is 16 bits inside a
> > > > 32
> > > > bit
> > > > with
> > > > no shift or similar. Why not just pack it into 16 bits?
> > > >
> > > > > + .scan_type.sign = 's',
> > > > > + .scan_index = 0 },
> > > > > +
> > > > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > > > +};
> > > > > +
> > > > > +struct hinge_state {
> > > > > + struct iio_dev *indio_dev;
> > > > > + struct hid_sensor_hub_attribute_info hinge;
> > > > > + /* Reserve for 1 channel + pading + timestamp */
> > > > > + u32 hinge_val[1 + 3];
> > > >
> > > > __aligned(8)
> > > >
> > > > see below for requirements on this.
> > > > Perhaps better to use
> > > >
> > > > struct hinge_scan {
> > > > u32 val;
> > > > s64 timestamp __aligned(8); // Note this is
> > > > needed for
> > > > x86_32
> > > > } scan;
> > > >
> > > > > + int scale_pre_decml;
> > > > > + int scale_post_decml;
> > > > > + int scale_precision;
> > > > > + int value_offset;
> > > > > + int64_t timestamp;
> > > > > + u32 hinge_address;
> > > > > +};
> > > > > +
> > > > > +#define IIO_DEV_NUM 3
> > > >
> > > > That needs a prefix to make it clear it's not a generic
> > > > constant
> > > > but is specific to this driver.
> > > >
> > > > > +
> > > > > +struct hinge_group {
> > > > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > > > + struct hid_sensor_hub_callbacks callbacks;
> > > > > + struct hid_sensor_common common_attributes;
> > > > > +};
> > > > > +
> > > > > +static struct hinge_group *hg_group;
> > > >
> > > > We shouldn't see globals like this. Please figure out how to
> > > > avoid
> > > > it.
> > > >
> > > > > +
> > > > > +/* Channel read_raw handler */
> > > > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > > > + struct iio_chan_spec const *chan, int
> > > > > *val,
> > > > > int *val2,
> > > > > + long mask)
> > > > > +{
> > > > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > > > + struct hid_sensor_hub_device *hsdev;
> > > > > + int report_id = -1;
> > > > > + int ret_type;
> > > > > + s32 min;
> > > > > +
> > > > > + hsdev = hg_group->common_attributes.hsdev;
> > > > > +
> > > > > + *val = 0;
> > > > > + *val2 = 0;
> > > > > + switch (mask) {
> > > > > + case IIO_CHAN_INFO_RAW:
> > > > > + hid_sensor_power_state(&hg_group-
> > > > > >common_attributes,
> > > > > true);
> > > > > + report_id = hg_state->hinge.report_id;
> > > > > + min = hg_state->hinge.logical_minimum;
> > > > > + if (report_id < 0) {
> > > > > + *val = 0;
> > > > > + hid_sensor_power_state(&hg_group-
> > > > > > common_attributes,
> > > > > + false);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + *val = sensor_hub_input_attr_get_raw_value(
> > > > > + hg_group->common_attributes.hsdev,
> > > > > hsdev-
> > > > > > usage,
> > > > > + hg_state->hinge_address, report_id,
> > > > > SENSOR_HUB_SYNC,
> > > > > + min < 0);
> > > > > +
> > > > > + hid_sensor_power_state(&hg_group-
> > > > > >common_attributes,
> > > > > false);
> > > > > + ret_type = IIO_VAL_INT;
> > > > > + break;
> > > > > + case IIO_CHAN_INFO_SCALE:
> > > > > + *val = hg_state->scale_pre_decml;
> > > > > + *val2 = hg_state->scale_post_decml;
> > > > > + ret_type = hg_state->scale_precision;
> > > > > + break;
> > > > > + case IIO_CHAN_INFO_OFFSET:
> > > > > + *val = hg_state->value_offset;
> > > > > + ret_type = IIO_VAL_INT;
> > > > > + break;
> > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > + ret_type = hid_sensor_read_samp_freq_value(
> > > > > + &hg_group->common_attributes, val,
> > > > > val2);
> > > > > + break;
> > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > > > + &hg_group->common_attributes, val,
> > > > > val2);
> > > > > + break;
> > > > > + default:
> > > > > + ret_type = -EINVAL;
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + return ret_type;
> > > > > +}
> > > > > +
> > > > > +/* Channel write_raw handler */
> > > > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > > > + struct iio_chan_spec const *chan,
> > > > > int val,
> > > > > int val2,
> > > > > + long mask)
> > > > > +{
> > > > > + int ret;
> > > > > +
> > > > > + switch (mask) {
> > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > + ret = hid_sensor_write_samp_freq_value(
> > > > > + &hg_group->common_attributes, val,
> > > > > val2);
> > > > > + break;
> > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > + ret = hid_sensor_write_raw_hyst_value(
> > > > > + &hg_group->common_attributes, val,
> > > > > val2);
> > > > > +
> > > > > + break;
> > > > > + default:
> > > > > + ret = -EINVAL;
> > > > > + }
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +static const struct iio_info hinge_info = {
> > > > > + .read_raw = &hinge_read_raw,
> > > > > + .write_raw = &hinge_write_raw,
> > > > > +};
> > > > > +
> > > > > +/*
> > > > > + * Function to push data to buffer;
> > > > > + * wrapper added for symmetry with other hid-sensor drivers
> > > > > + */
> > > > > +static void hid_sensor_push_data(struct iio_dev *indio_dev,
> > > > > void
> > > > > *data, int len,
> > > >
> > > > This doesn't seem to be generic, so don't name it as such.
> > > >
> > > > > + int64_t timestamp)
> > > > > +{
> > > > > + iio_push_to_buffers_with_timestamp(indio_dev, data,
> > > > > timestamp);
> > > > I hope that data buffer obeys the various rules needed by (and
> > > > admittedly
> > > > not that well documented) iio_push_to_buffers_with_timestamp()
> > > >
> > > > 1. Needs to be 8 byte aligned.
> > > > 2. Needs to have space for an aligned 8 byte timestamp at the
> > > > end.
> > > >
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Callback handler to send event after all samples are
> > > > > received
> > > > > + * and captured.
> > > > > + */
> > > > > +static int hinge_proc_event(struct hid_sensor_hub_device
> > > > > *hsdev,
> > > > > + unsigned int usage_id, void *priv)
> > > > > +{
> > > > > + int i;
> > > > > +
> > > > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > > > If we push for all sensors together, better to have
> > > > this as a single iio_device with 3 channels.
> > > >
> > > > Use the channel labels (just added to IIO) to identify which is
> > > > which.
> > > >
> > > > > + struct hinge_state *hg_state;
> > > > > + struct iio_dev *indio_dev;
> > > > > +
> > > > > + hg_state = hg_group->hg_states[i];
> > > > > + indio_dev = hg_state->indio_dev;
> > > > > +
> > > > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > > > scan_bytes:%d\n",
> > > > > + __func__, hg_state->timestamp,
> > > > > indio_dev-
> > > > > > scan_bytes);
> > > > > +
> > > > > + if (!hg_state->timestamp)
> > > > > + hg_state->timestamp =
> > > > > iio_get_time_ns(indio_dev);
> > > > > +
> > > > > + hid_sensor_push_data(indio_dev, hg_state-
> > > > > >hinge_val,
> > > > > + sizeof(hg_state-
> > > > > >hinge_val),
> > > > > + hg_state->timestamp);
> > > > > +
> > > > > + hg_state->timestamp = 0;
> > > > > + }
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +/* Capture samples in local storage */
> > > > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > > > *hsdev,
> > > > > + unsigned int usage_id, size_t
> > > > > raw_len,
> > > > > + char *raw_data, void *priv)
> > > > > +{
> > > > > + struct hinge_state *hg_state;
> > > > > + int offset;
> > > > > + int ret = -EINVAL;
> > > > > + int i;
> > > > > +
> > > > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > + hg_group->hg_states[i]->timestamp =
> > > >
> > > > This rather implies all the data is captured together... If so
> > > > single
> > > > iio_device may make more sense.
> > > >
> > > > > + hid_sensor_convert_timestamp(
> > > > > + &hg_group-
> > > > > >common_attributes,
> > > > > + *(int64_t *)raw_data);
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + switch (usage_id) {
> > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > > > + offset = usage_id -
> > > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > > > + hg_state = hg_group->hg_states[offset];
> > > > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > > > + ret = 0;
> > > >
> > > > return 0;
> > > >
> > > > > + break;
> > > > > + default:
> > > > return -EINVAL;
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +/* Parse report which is specific to an usage id */
> > > > > +static int hinge_parse_report(struct platform_device *pdev,
> > > > > + struct hid_sensor_hub_device
> > > > > *hsdev,
> > > > > + unsigned int usage_id, unsigned
> > > > > int
> > > > > attr_usage_id,
> > > > > + struct hinge_state *st)
> > > > > +{
> > > > > + int ret;
> > > > > +
> > > > > + ret = sensor_hub_input_get_attribute_info(
> > > > > + hsdev, HID_INPUT_REPORT, usage_id,
> > > > > attr_usage_id, &st-
> > > > > > hinge);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + st->hinge_address = attr_usage_id;
> > > > > + st->scale_precision =
> > > > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE,
> > > > > &st-
> > > > > > hinge,
> > > > > + &st->scale_pre_decml,
> > > > > + &st->scale_post_decml);
> > > > > +
> > > > > + /* Set Sensitivity field ids, when there is no
> > > > > individual
> > > > > modifier */
> > > > > + if (hg_group->common_attributes.sensitivity.index < 0)
> > > > > {
> > > > > + sensor_hub_input_get_attribute_info(
> > > > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > > IVITY_AB
> > > > > S |
> > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUS
> > > > > TOM_VALU
> > > > > E_1,
> > > > > + &hg_group-
> > > > > >common_attributes.sensitivity);
> > > > > + dev_dbg(&pdev->dev, "Sensitivity index:report
> > > > > %d:%d\n",
> > > > > + hg_group-
> > > > > >common_attributes.sensitivity.index,
> > > > > + hg_group-
> > > > > > common_attributes.sensitivity.report_id);
> > > > > + }
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +/* Function to initialize the processing for usage id */
> > > > > +static int hinge_add_iio_device(struct platform_device
> > > > > *pdev,
> > > > > int
> > > > > index,
> > > > > + const char *name, struct
> > > > > hinge_state
> > > > > **st)
> > > > > +{
> > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > >dev.platform_data;
> > > > > + struct hinge_state *hg_state;
> > > > > + struct iio_dev *indio_dev;
> > > > > + int ret;
> > > > > +
> > > > > + indio_dev =
> > > > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > > > hinge_state));
> > > >
> > > > sizeof (*hg_state) preferred.
> > > >
> > > > > + if (indio_dev == NULL)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + hg_state = iio_priv(indio_dev);
> > > > > + hg_state->indio_dev = indio_dev;
> > > > > +
> > > > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > > > + indio_dev->channels =
> > > > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > > > GFP_KERNEL);
> > > >
> > > > I don't immediately see anything that is modifying channels. As
> > > > such
> > > > you
> > > > should be able have it shared by all the instances.
> > > >
> > > > > + if (!indio_dev->channels)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + ret = hinge_parse_report(
> > > > > + pdev, hsdev, hsdev->usage,
> > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 +
> > > > > index,
> > > > > hg_state);
> > > > > + if (ret) {
> > > > > + dev_err(&pdev->dev, "failed to setup
> > > > > attributes\n");
> > > > > + goto error_free_dev_mem;
> > > > > + }
> > > > > +
> > > > > + indio_dev->dev.parent = &pdev->dev;
> > > > > + indio_dev->info = &hinge_info;
> > > > > + indio_dev->name = name;
> > > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > > +
> > > > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > > > + &hg_group-
> > > > > >common_attributes);
> > > > > + if (ret < 0) {
> > > > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > > > + goto error_free_dev_mem;
> > > > > + }
> > > > > +
> > > > > + ret = iio_device_register(indio_dev);
> > > > > + if (ret) {
> > > > > + dev_err(&pdev->dev, "device register
> > > > > failed\n");
> > > > > + goto error_remove_trigger;
> > > > > + }
> > > > > +
> > > > > + *st = hg_state;
> > > > > +
> > > > > + return ret;
> > > > > +
> > > > > +error_remove_trigger:
> > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > common_attributes);
> > > > > +error_free_dev_mem:
> > > > > + kfree(indio_dev->channels);
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +/* Function to deinitialize the processing for usage id */
> > > > > +static int hinge_remove_iio_device(struct platform_device
> > > > > *pdev,
> > > > > int index)
> > > > > +{
> > > > > + struct hinge_state *hg_state = hg_group-
> > > > > >hg_states[index];
> > > > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > > > +
> > > > > + iio_device_unregister(indio_dev);
> > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > common_attributes);
> > > > > + kfree(indio_dev->channels);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > > > +{
> > > > > + struct hinge_state *hg_state;
> > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > >dev.platform_data;
> > > > > + static const char *const names[] = { "hinge", "screen",
> > > > > "keyboard" };
> > > > > + int ret;
> > > > > + int i;
> > > > > +
> > > > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct
> > > > > hinge_group),
> > > > > + GFP_KERNEL);
> > > >
> > > > As mentioned above, I'd really not expect to see a global like
> > > > this.
> > > > Technically nothing stops there being more than one instance of
> > > > this
> > > > device on a platform (even if that would be a bit odd) + it's
> > > > almost
> > > > always cleaner to not use a global in the first place.
> > > >
> > > > > + if (!hg_group)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + hg_group->common_attributes.hsdev = hsdev;
> > > > > + hg_group->common_attributes.pdev = pdev;
> > > > > +
> > > > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev-
> > > > > >usage,
> > > > > + &hg_group-
> > > > > > common_attributes);
> > > > > + if (ret) {
> > > > > + dev_err(&pdev->dev, "failed to setup common
> > > > > attributes\n");
> > > > > + return ret;
> > > > > + }
> > > > > +
> > > > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > > > &hg_state);
> > > > > + if (ret)
> > > > > + goto err_probe;
> > > > > +
> > > > > + hg_group->hg_states[i] = hg_state;
> > > > > + }
> > > > > +
> > > > > + /* use the first iio device to do the PM */
> > > > > + platform_set_drvdata(pdev, hg_group->hg_states[0]-
> > > > > >indio_dev);
> > > > > +
> > > > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > > > + hg_group->callbacks.capture_sample =
> > > > > hinge_capture_sample;
> > > > > + hg_group->callbacks.pdev = pdev;
> > > > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > > > + &hg_group-
> > > > > >callbacks);
> > > > > + if (ret < 0)
> > > > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > > > +
> > > > > + return ret;
> > > > > +
> > > > > +err_probe:
> > > > > + for (i--; i >= 0; i--)
> > > > > + hinge_remove_iio_device(pdev, i);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +/* Function to deinitialize the processing for usage id */
> > > > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > > > +{
> > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > >dev.platform_data;
> > > > > + int i;
> > > > > +
> > > > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > > > +
> > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > + hinge_remove_iio_device(pdev, i);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > > > + {
> > > > > + /* Format: HID-SENSOR-INT-
> > > > > usage_id_in_hex_lowercase */
> > > > > + .name = "HID-SENSOR-INT-020b",
> > > > > + },
> > > > > + { /* sentinel */ }
> > > > > +};
> > > > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > > > +
> > > > > +static struct platform_driver hid_hinge_platform_driver = {
> > > > > + .id_table = hid_hinge_ids,
> > > > > + .driver = {
> > > > > + .name = KBUILD_MODNAME,
> > > > > + .pm = &hid_sensor_pm_ops,
> > > > > + },
> > > > > + .probe = hid_hinge_probe,
> > > > > + .remove = hid_hinge_remove,
> > > > > +};
> > > > > +module_platform_driver(hid_hinge_platform_driver);
> > > > > +
> > > > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > > > +MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-22 15:51 ` Pandruvada, Srinivas
@ 2020-11-22 16:50 ` Jonathan Cameron
2020-11-24 3:30 ` Ye, Xiang
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-22 16:50 UTC (permalink / raw)
To: Pandruvada, Srinivas
Cc: jikos, linux-input, Ye, Xiang, linux-kernel, linux-iio
On Sun, 22 Nov 2020 15:51:18 +0000
"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> On Sun, 2020-11-22 at 14:14 +0000, Jonathan Cameron wrote:
> > On Sun, 22 Nov 2020 02:14:16 +0000
> > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> >
> > > On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> > > > On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > > > > On Thu, 19 Nov 2020 18:03:31 +0800
> > > > > Ye Xiang <xiang.ye@intel.com> wrote:
> > > > >
> > > > > > The Hinge sensor is a common custom sensor on laptops. It
> > > > > > calculates
> > > > > > the angle between the lid (screen) and the base (keyboard).
> > > > > > In
> > > > > > addition,
> > > > > > it also exposes screen and the keyboard angels with respect
> > > > > > to
> > > > > > the
> > > > > > ground. Applications can easily get laptop's status in space
> > > > > > through
> > > > > > this sensor, in order to display appropriate user
> > > > > > interface.
> > > > >
> > > > > I'm a little unclear on why the 3 axes aren't treated as a
> > > > > single
> > > > > sensor.
> > > > > You seem to always grab the 3 together or am I missing
> > > > > something?
> > > > >
> > > > > That will greatly simplify things and get rid of the need to
> > > > > have
> > > > > a shared trigger with the problems that causes in the previous
> > > > > patch.
> > > >
> > > > They are not three axes, they are independent. Xiang did try
> > > > adding
> > > > x,
> > > > y and z component to represent x as hinge, y as keyboard and z as
> > > > lid.
> > > > But I was not convinced.
> > > > The problem is that then what will be sysfs interface? They are
> > > > really
> > > > a three sensors. Or we create new interface to call
> > > > in_angl_raw_keyboard
> > > > in_angl_raw_screen
> > > > in_angl_raw_lid.
> > > >
> > > You seem to indicate this is possible now some new "label" patch.
> > > Is this the patch?
> > > commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
> > > Author: Phil Reid <preid@electromag.com.au>
> > > Date: Thu Sep 19 22:36:08 2019 +0800
> >
> > Nope, this one
> > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1d4ef9b39ebecca827642b8897d2d79ea2026682
> >
> > The one above adds a per device label which wouldn't be much use for
> > your
> > case, but this one adds a per channel label.
> >
> > Done via a read_label callback.
> >
> > Here you'd want to use indexed channels so something like.
> >
> > in_angl0_raw
> > in_angl1_raw
> > in_angl2_raw
> >
> > and
> >
> > in_angl0_label = keyboard
> > in_angl1_label = screen
> > in_angl2_label = lid
>
> Thanks Jonathan. This will make the job easier.
> Xiang,
> You can use this method. Then you will not need other changes except
> patch 1/4.
> Also add a documentation patch to explain the mapping.
Ah. So we have a slightly problem with sysfs ABI docs at the moment.
The scripts that auto generate the html and similar docs from them
don't cope with the same name of attribute in multiple documentation
files.
https://lore.kernel.org/linux-iio/20201110082658.2edc1ab5@coco.lan/
The upshot being we can't have more specific docs for a particular
part that match up with the generic docs. That will apply in this
case.
So for now, our solution is to put it in the main docs, but provide
a subsection in there talking about more specific constraints for
a particular device.
Note I haven't actually proposed any fixes for this problem yet so
you get to do the first one ;)
Thanks,
Jonathan
>
> Thanks,
> Srinivas
>
> >
> >
> >
> > > Ideally, one iio device here is much easy to manage as other HID
> > > sensors. If we can add something other that "x", "y" and "z"
> > > component.
> >
> > Agreed, using axes makes no real sense here and extended_name is
> > just a mess from ABI point of view. Trying to solve this was the
> > reason we added the _label interface.
> >
> > Jonathan
> >
> >
> > > Thanks,
> > > Srinivas
> > >
> > > > Thanks,
> > > > Srinivas
> > > >
> > > >
> > > > > Thanks,
> > > > >
> > > > > Jonathan
> > > > >
> > > > > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > > > > ---
> > > > > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > > > > drivers/iio/position/Kconfig | 16 +
> > > > > > drivers/iio/position/Makefile | 3 +
> > > > > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > > > > ++++++++++++++++++
> > > > >
> > > > > Given it's custom probably needs a more specific name. I guess
> > > > > hid-sensor-custom-intel-hinge.c might be safe?
> > > > >
> > > > > Same for other places we need names in here.
> > > > >
> > > > > > 4 files changed, 433 insertions(+)
> > > > > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > > > > hinge.c
> > > > > >
> > > > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > > > > attributes.c
> > > > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > index 442ff787f7af..5b822a4298a0 100644
> > > > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > @@ -71,6 +71,8 @@ static struct {
> > > > > > {HID_USAGE_SENSOR_TEMPERATURE,
> > > > > > HID_USAGE_SENSOR_UNITS_DEGREES,
> > > > > > 1000, 0},
> > > > > >
> > > > > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > > > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > > > > + {HID_USAGE_SENSOR_HINGE,
> > > > > > HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > > > > 17453293},
> > > > > > };
> > > > > >
> > > > > > static void simple_div(int dividend, int divisor, int
> > > > > > *whole,
> > > > > > diff --git a/drivers/iio/position/Kconfig
> > > > > > b/drivers/iio/position/Kconfig
> > > > > > index eda67f008c5b..0346f6f2b422 100644
> > > > > > --- a/drivers/iio/position/Kconfig
> > > > > > +++ b/drivers/iio/position/Kconfig
> > > > > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > > > > To compile this driver as a module, choose M here:
> > > > > > the module
> > > > > > will be called iqs624-pos.
> > > > > >
> > > > > > +config HID_SENSOR_CUSTOM_HINGE
> > > > > > + depends on HID_SENSOR_HUB
> > > > > > + select IIO_BUFFER
> > > > > > + select IIO_TRIGGERED_BUFFER
> > > > > > + select HID_SENSOR_IIO_COMMON
> > > > > > + select HID_SENSOR_IIO_TRIGGER
> > > > > > + tristate "HID Hinge"
> > > > > > + help
> > > > > > + This sensor present three angles, hinge angel, screen
> > > > > > angles
> > > > > > + and keyboard angle respect to horizon (ground).
> > > > > > + Say yes here to build support for the HID SENSOR
> > > > > > CUSTOM
> > > > > > + HINGE.
> > > > >
> > > > > Capitalization is a bit odd looking. I'd drop it.
> > > > >
> > > > > > +
> > > > > > + To compile this driver as a module, choose M here:
> > > > > > the
> > > > > > + module will be called hid-sensor-custom-hinge.
> > > > > > +
> > > > > > endmenu
> > > > > > diff --git a/drivers/iio/position/Makefile
> > > > > > b/drivers/iio/position/Makefile
> > > > > > index 3cbe7a734352..7a6225977a01 100644
> > > > > > --- a/drivers/iio/position/Makefile
> > > > > > +++ b/drivers/iio/position/Makefile
> > > > > > @@ -5,3 +5,6 @@
> > > > > > # When adding new entries keep the list in alphabetical
> > > > > > order
> > > > > >
> > > > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > > > +
> > > > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > > > > hinge.o
> > > > >
> > > > > Alphabetical order preferred.
> > > > >
> > > > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-
> > > > > > sensors
> > > > >
> > > > > Why?
> > > > >
> > > > > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > new file mode 100644
> > > > > > index 000000000000..a91b333f36fa
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > @@ -0,0 +1,412 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > +/*
> > > > > > + * HID Sensors Driver
> > > > > > + * Copyright (c) 2020, Intel Corporation.
> > > > > > + */
> > > > > > +#include <linux/hid-sensor-hub.h>
> > > > > > +#include <linux/iio/buffer.h>
> > > > > > +#include <linux/iio/iio.h>
> > > > > > +#include <linux/platform_device.h>
> > > > > > +
> > > > > > +#include "hid-sensor-trigger.h"
> > > > > > +
> > > > > > +/* Channel definitions */
> > > > > > +static const struct iio_chan_spec hinge_channels[] = {
> > > > > > + { .type = IIO_ANGL,
> > > > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > > > > + .info_mask_shared_by_type =
> > > > > > + BIT(IIO_CHAN_INFO_OFFSET) |
> > > > > > BIT(IIO_CHAN_INFO_SCALE)
> > > > > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > > > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > > > > + .scan_type.realbits = 16,
> > > > > > + .scan_type.storagebits = 32,
> > > > >
> > > > > It a bit odd to see a single channel that is 16 bits inside a
> > > > > 32
> > > > > bit
> > > > > with
> > > > > no shift or similar. Why not just pack it into 16 bits?
> > > > >
> > > > > > + .scan_type.sign = 's',
> > > > > > + .scan_index = 0 },
> > > > > > +
> > > > > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > > > > +};
> > > > > > +
> > > > > > +struct hinge_state {
> > > > > > + struct iio_dev *indio_dev;
> > > > > > + struct hid_sensor_hub_attribute_info hinge;
> > > > > > + /* Reserve for 1 channel + pading + timestamp */
> > > > > > + u32 hinge_val[1 + 3];
> > > > >
> > > > > __aligned(8)
> > > > >
> > > > > see below for requirements on this.
> > > > > Perhaps better to use
> > > > >
> > > > > struct hinge_scan {
> > > > > u32 val;
> > > > > s64 timestamp __aligned(8); // Note this is
> > > > > needed for
> > > > > x86_32
> > > > > } scan;
> > > > >
> > > > > > + int scale_pre_decml;
> > > > > > + int scale_post_decml;
> > > > > > + int scale_precision;
> > > > > > + int value_offset;
> > > > > > + int64_t timestamp;
> > > > > > + u32 hinge_address;
> > > > > > +};
> > > > > > +
> > > > > > +#define IIO_DEV_NUM 3
> > > > >
> > > > > That needs a prefix to make it clear it's not a generic
> > > > > constant
> > > > > but is specific to this driver.
> > > > >
> > > > > > +
> > > > > > +struct hinge_group {
> > > > > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > > > > + struct hid_sensor_hub_callbacks callbacks;
> > > > > > + struct hid_sensor_common common_attributes;
> > > > > > +};
> > > > > > +
> > > > > > +static struct hinge_group *hg_group;
> > > > >
> > > > > We shouldn't see globals like this. Please figure out how to
> > > > > avoid
> > > > > it.
> > > > >
> > > > > > +
> > > > > > +/* Channel read_raw handler */
> > > > > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > > > > + struct iio_chan_spec const *chan, int
> > > > > > *val,
> > > > > > int *val2,
> > > > > > + long mask)
> > > > > > +{
> > > > > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > > > > + struct hid_sensor_hub_device *hsdev;
> > > > > > + int report_id = -1;
> > > > > > + int ret_type;
> > > > > > + s32 min;
> > > > > > +
> > > > > > + hsdev = hg_group->common_attributes.hsdev;
> > > > > > +
> > > > > > + *val = 0;
> > > > > > + *val2 = 0;
> > > > > > + switch (mask) {
> > > > > > + case IIO_CHAN_INFO_RAW:
> > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > >common_attributes,
> > > > > > true);
> > > > > > + report_id = hg_state->hinge.report_id;
> > > > > > + min = hg_state->hinge.logical_minimum;
> > > > > > + if (report_id < 0) {
> > > > > > + *val = 0;
> > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > common_attributes,
> > > > > > + false);
> > > > > > + return -EINVAL;
> > > > > > + }
> > > > > > +
> > > > > > + *val = sensor_hub_input_attr_get_raw_value(
> > > > > > + hg_group->common_attributes.hsdev,
> > > > > > hsdev-
> > > > > > > usage,
> > > > > > + hg_state->hinge_address, report_id,
> > > > > > SENSOR_HUB_SYNC,
> > > > > > + min < 0);
> > > > > > +
> > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > >common_attributes,
> > > > > > false);
> > > > > > + ret_type = IIO_VAL_INT;
> > > > > > + break;
> > > > > > + case IIO_CHAN_INFO_SCALE:
> > > > > > + *val = hg_state->scale_pre_decml;
> > > > > > + *val2 = hg_state->scale_post_decml;
> > > > > > + ret_type = hg_state->scale_precision;
> > > > > > + break;
> > > > > > + case IIO_CHAN_INFO_OFFSET:
> > > > > > + *val = hg_state->value_offset;
> > > > > > + ret_type = IIO_VAL_INT;
> > > > > > + break;
> > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > + ret_type = hid_sensor_read_samp_freq_value(
> > > > > > + &hg_group->common_attributes, val,
> > > > > > val2);
> > > > > > + break;
> > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > > > > + &hg_group->common_attributes, val,
> > > > > > val2);
> > > > > > + break;
> > > > > > + default:
> > > > > > + ret_type = -EINVAL;
> > > > > > + break;
> > > > > > + }
> > > > > > +
> > > > > > + return ret_type;
> > > > > > +}
> > > > > > +
> > > > > > +/* Channel write_raw handler */
> > > > > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > > > > + struct iio_chan_spec const *chan,
> > > > > > int val,
> > > > > > int val2,
> > > > > > + long mask)
> > > > > > +{
> > > > > > + int ret;
> > > > > > +
> > > > > > + switch (mask) {
> > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > + ret = hid_sensor_write_samp_freq_value(
> > > > > > + &hg_group->common_attributes, val,
> > > > > > val2);
> > > > > > + break;
> > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > + ret = hid_sensor_write_raw_hyst_value(
> > > > > > + &hg_group->common_attributes, val,
> > > > > > val2);
> > > > > > +
> > > > > > + break;
> > > > > > + default:
> > > > > > + ret = -EINVAL;
> > > > > > + }
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +static const struct iio_info hinge_info = {
> > > > > > + .read_raw = &hinge_read_raw,
> > > > > > + .write_raw = &hinge_write_raw,
> > > > > > +};
> > > > > > +
> > > > > > +/*
> > > > > > + * Function to push data to buffer;
> > > > > > + * wrapper added for symmetry with other hid-sensor drivers
> > > > > > + */
> > > > > > +static void hid_sensor_push_data(struct iio_dev *indio_dev,
> > > > > > void
> > > > > > *data, int len,
> > > > >
> > > > > This doesn't seem to be generic, so don't name it as such.
> > > > >
> > > > > > + int64_t timestamp)
> > > > > > +{
> > > > > > + iio_push_to_buffers_with_timestamp(indio_dev, data,
> > > > > > timestamp);
> > > > > I hope that data buffer obeys the various rules needed by (and
> > > > > admittedly
> > > > > not that well documented) iio_push_to_buffers_with_timestamp()
> > > > >
> > > > > 1. Needs to be 8 byte aligned.
> > > > > 2. Needs to have space for an aligned 8 byte timestamp at the
> > > > > end.
> > > > >
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Callback handler to send event after all samples are
> > > > > > received
> > > > > > + * and captured.
> > > > > > + */
> > > > > > +static int hinge_proc_event(struct hid_sensor_hub_device
> > > > > > *hsdev,
> > > > > > + unsigned int usage_id, void *priv)
> > > > > > +{
> > > > > > + int i;
> > > > > > +
> > > > > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > > > > If we push for all sensors together, better to have
> > > > > this as a single iio_device with 3 channels.
> > > > >
> > > > > Use the channel labels (just added to IIO) to identify which is
> > > > > which.
> > > > >
> > > > > > + struct hinge_state *hg_state;
> > > > > > + struct iio_dev *indio_dev;
> > > > > > +
> > > > > > + hg_state = hg_group->hg_states[i];
> > > > > > + indio_dev = hg_state->indio_dev;
> > > > > > +
> > > > > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > > > > scan_bytes:%d\n",
> > > > > > + __func__, hg_state->timestamp,
> > > > > > indio_dev-
> > > > > > > scan_bytes);
> > > > > > +
> > > > > > + if (!hg_state->timestamp)
> > > > > > + hg_state->timestamp =
> > > > > > iio_get_time_ns(indio_dev);
> > > > > > +
> > > > > > + hid_sensor_push_data(indio_dev, hg_state-
> > > > > > >hinge_val,
> > > > > > + sizeof(hg_state-
> > > > > > >hinge_val),
> > > > > > + hg_state->timestamp);
> > > > > > +
> > > > > > + hg_state->timestamp = 0;
> > > > > > + }
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +/* Capture samples in local storage */
> > > > > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > > > > *hsdev,
> > > > > > + unsigned int usage_id, size_t
> > > > > > raw_len,
> > > > > > + char *raw_data, void *priv)
> > > > > > +{
> > > > > > + struct hinge_state *hg_state;
> > > > > > + int offset;
> > > > > > + int ret = -EINVAL;
> > > > > > + int i;
> > > > > > +
> > > > > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > + hg_group->hg_states[i]->timestamp =
> > > > >
> > > > > This rather implies all the data is captured together... If so
> > > > > single
> > > > > iio_device may make more sense.
> > > > >
> > > > > > + hid_sensor_convert_timestamp(
> > > > > > + &hg_group-
> > > > > > >common_attributes,
> > > > > > + *(int64_t *)raw_data);
> > > > > > + return 0;
> > > > > > + }
> > > > > > +
> > > > > > + switch (usage_id) {
> > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > > > > + offset = usage_id -
> > > > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > > > > + hg_state = hg_group->hg_states[offset];
> > > > > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > > > > + ret = 0;
> > > > >
> > > > > return 0;
> > > > >
> > > > > > + break;
> > > > > > + default:
> > > > > return -EINVAL;
> > > > > > + break;
> > > > > > + }
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +/* Parse report which is specific to an usage id */
> > > > > > +static int hinge_parse_report(struct platform_device *pdev,
> > > > > > + struct hid_sensor_hub_device
> > > > > > *hsdev,
> > > > > > + unsigned int usage_id, unsigned
> > > > > > int
> > > > > > attr_usage_id,
> > > > > > + struct hinge_state *st)
> > > > > > +{
> > > > > > + int ret;
> > > > > > +
> > > > > > + ret = sensor_hub_input_get_attribute_info(
> > > > > > + hsdev, HID_INPUT_REPORT, usage_id,
> > > > > > attr_usage_id, &st-
> > > > > > > hinge);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + st->hinge_address = attr_usage_id;
> > > > > > + st->scale_precision =
> > > > > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE,
> > > > > > &st-
> > > > > > > hinge,
> > > > > > + &st->scale_pre_decml,
> > > > > > + &st->scale_post_decml);
> > > > > > +
> > > > > > + /* Set Sensitivity field ids, when there is no
> > > > > > individual
> > > > > > modifier */
> > > > > > + if (hg_group->common_attributes.sensitivity.index < 0)
> > > > > > {
> > > > > > + sensor_hub_input_get_attribute_info(
> > > > > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > > > IVITY_AB
> > > > > > S |
> > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUS
> > > > > > TOM_VALU
> > > > > > E_1,
> > > > > > + &hg_group-
> > > > > > >common_attributes.sensitivity);
> > > > > > + dev_dbg(&pdev->dev, "Sensitivity index:report
> > > > > > %d:%d\n",
> > > > > > + hg_group-
> > > > > > >common_attributes.sensitivity.index,
> > > > > > + hg_group-
> > > > > > > common_attributes.sensitivity.report_id);
> > > > > > + }
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +/* Function to initialize the processing for usage id */
> > > > > > +static int hinge_add_iio_device(struct platform_device
> > > > > > *pdev,
> > > > > > int
> > > > > > index,
> > > > > > + const char *name, struct
> > > > > > hinge_state
> > > > > > **st)
> > > > > > +{
> > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > >dev.platform_data;
> > > > > > + struct hinge_state *hg_state;
> > > > > > + struct iio_dev *indio_dev;
> > > > > > + int ret;
> > > > > > +
> > > > > > + indio_dev =
> > > > > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > > > > hinge_state));
> > > > >
> > > > > sizeof (*hg_state) preferred.
> > > > >
> > > > > > + if (indio_dev == NULL)
> > > > > > + return -ENOMEM;
> > > > > > +
> > > > > > + hg_state = iio_priv(indio_dev);
> > > > > > + hg_state->indio_dev = indio_dev;
> > > > > > +
> > > > > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > > > > + indio_dev->channels =
> > > > > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > > > > GFP_KERNEL);
> > > > >
> > > > > I don't immediately see anything that is modifying channels. As
> > > > > such
> > > > > you
> > > > > should be able have it shared by all the instances.
> > > > >
> > > > > > + if (!indio_dev->channels)
> > > > > > + return -ENOMEM;
> > > > > > +
> > > > > > + ret = hinge_parse_report(
> > > > > > + pdev, hsdev, hsdev->usage,
> > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 +
> > > > > > index,
> > > > > > hg_state);
> > > > > > + if (ret) {
> > > > > > + dev_err(&pdev->dev, "failed to setup
> > > > > > attributes\n");
> > > > > > + goto error_free_dev_mem;
> > > > > > + }
> > > > > > +
> > > > > > + indio_dev->dev.parent = &pdev->dev;
> > > > > > + indio_dev->info = &hinge_info;
> > > > > > + indio_dev->name = name;
> > > > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > > > +
> > > > > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > > > > + &hg_group-
> > > > > > >common_attributes);
> > > > > > + if (ret < 0) {
> > > > > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > > > > + goto error_free_dev_mem;
> > > > > > + }
> > > > > > +
> > > > > > + ret = iio_device_register(indio_dev);
> > > > > > + if (ret) {
> > > > > > + dev_err(&pdev->dev, "device register
> > > > > > failed\n");
> > > > > > + goto error_remove_trigger;
> > > > > > + }
> > > > > > +
> > > > > > + *st = hg_state;
> > > > > > +
> > > > > > + return ret;
> > > > > > +
> > > > > > +error_remove_trigger:
> > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > common_attributes);
> > > > > > +error_free_dev_mem:
> > > > > > + kfree(indio_dev->channels);
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > +static int hinge_remove_iio_device(struct platform_device
> > > > > > *pdev,
> > > > > > int index)
> > > > > > +{
> > > > > > + struct hinge_state *hg_state = hg_group-
> > > > > > >hg_states[index];
> > > > > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > > > > +
> > > > > > + iio_device_unregister(indio_dev);
> > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > common_attributes);
> > > > > > + kfree(indio_dev->channels);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > > > > +{
> > > > > > + struct hinge_state *hg_state;
> > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > >dev.platform_data;
> > > > > > + static const char *const names[] = { "hinge", "screen",
> > > > > > "keyboard" };
> > > > > > + int ret;
> > > > > > + int i;
> > > > > > +
> > > > > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct
> > > > > > hinge_group),
> > > > > > + GFP_KERNEL);
> > > > >
> > > > > As mentioned above, I'd really not expect to see a global like
> > > > > this.
> > > > > Technically nothing stops there being more than one instance of
> > > > > this
> > > > > device on a platform (even if that would be a bit odd) + it's
> > > > > almost
> > > > > always cleaner to not use a global in the first place.
> > > > >
> > > > > > + if (!hg_group)
> > > > > > + return -ENOMEM;
> > > > > > +
> > > > > > + hg_group->common_attributes.hsdev = hsdev;
> > > > > > + hg_group->common_attributes.pdev = pdev;
> > > > > > +
> > > > > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev-
> > > > > > >usage,
> > > > > > + &hg_group-
> > > > > > > common_attributes);
> > > > > > + if (ret) {
> > > > > > + dev_err(&pdev->dev, "failed to setup common
> > > > > > attributes\n");
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > > > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > > > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > > > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > > > > &hg_state);
> > > > > > + if (ret)
> > > > > > + goto err_probe;
> > > > > > +
> > > > > > + hg_group->hg_states[i] = hg_state;
> > > > > > + }
> > > > > > +
> > > > > > + /* use the first iio device to do the PM */
> > > > > > + platform_set_drvdata(pdev, hg_group->hg_states[0]-
> > > > > > >indio_dev);
> > > > > > +
> > > > > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > > > > + hg_group->callbacks.capture_sample =
> > > > > > hinge_capture_sample;
> > > > > > + hg_group->callbacks.pdev = pdev;
> > > > > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > > > > + &hg_group-
> > > > > > >callbacks);
> > > > > > + if (ret < 0)
> > > > > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > > > > +
> > > > > > + return ret;
> > > > > > +
> > > > > > +err_probe:
> > > > > > + for (i--; i >= 0; i--)
> > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > > > > +{
> > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > >dev.platform_data;
> > > > > > + int i;
> > > > > > +
> > > > > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > > > > +
> > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > > > > + {
> > > > > > + /* Format: HID-SENSOR-INT-
> > > > > > usage_id_in_hex_lowercase */
> > > > > > + .name = "HID-SENSOR-INT-020b",
> > > > > > + },
> > > > > > + { /* sentinel */ }
> > > > > > +};
> > > > > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > > > > +
> > > > > > +static struct platform_driver hid_hinge_platform_driver = {
> > > > > > + .id_table = hid_hinge_ids,
> > > > > > + .driver = {
> > > > > > + .name = KBUILD_MODNAME,
> > > > > > + .pm = &hid_sensor_pm_ops,
> > > > > > + },
> > > > > > + .probe = hid_hinge_probe,
> > > > > > + .remove = hid_hinge_remove,
> > > > > > +};
> > > > > > +module_platform_driver(hid_hinge_platform_driver);
> > > > > > +
> > > > > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > > > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > > > > +MODULE_LICENSE("GPL");
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-22 16:50 ` Jonathan Cameron
@ 2020-11-24 3:30 ` Ye, Xiang
2020-11-24 11:36 ` Jonathan Cameron
0 siblings, 1 reply; 25+ messages in thread
From: Ye, Xiang @ 2020-11-24 3:30 UTC (permalink / raw)
To: Jonathan Cameron, srinivas.pandruvada
Cc: jikos, jic23, linux-input, linux-iio, linux-kernel, even.xu
On Sun, Nov 22, 2020 at 04:50:47PM +0000, Jonathan Cameron wrote:
> On Sun, 22 Nov 2020 15:51:18 +0000
> "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
>
> > On Sun, 2020-11-22 at 14:14 +0000, Jonathan Cameron wrote:
> > > On Sun, 22 Nov 2020 02:14:16 +0000
> > > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> > >
> > > > On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> > > > > On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > > > > > On Thu, 19 Nov 2020 18:03:31 +0800
> > > > > > Ye Xiang <xiang.ye@intel.com> wrote:
> > > > > >
> > > > > > > The Hinge sensor is a common custom sensor on laptops. It
> > > > > > > calculates
> > > > > > > the angle between the lid (screen) and the base (keyboard).
> > > > > > > In
> > > > > > > addition,
> > > > > > > it also exposes screen and the keyboard angels with respect
> > > > > > > to
> > > > > > > the
> > > > > > > ground. Applications can easily get laptop's status in space
> > > > > > > through
> > > > > > > this sensor, in order to display appropriate user
> > > > > > > interface.
> > > > > >
> > > > > > I'm a little unclear on why the 3 axes aren't treated as a
> > > > > > single
> > > > > > sensor.
> > > > > > You seem to always grab the 3 together or am I missing
> > > > > > something?
> > > > > >
> > > > > > That will greatly simplify things and get rid of the need to
> > > > > > have
> > > > > > a shared trigger with the problems that causes in the previous
> > > > > > patch.
> > > > >
> > > > > They are not three axes, they are independent. Xiang did try
> > > > > adding
> > > > > x,
> > > > > y and z component to represent x as hinge, y as keyboard and z as
> > > > > lid.
> > > > > But I was not convinced.
> > > > > The problem is that then what will be sysfs interface? They are
> > > > > really
> > > > > a three sensors. Or we create new interface to call
> > > > > in_angl_raw_keyboard
> > > > > in_angl_raw_screen
> > > > > in_angl_raw_lid.
> > > > >
> > > > You seem to indicate this is possible now some new "label" patch.
> > > > Is this the patch?
> > > > commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
> > > > Author: Phil Reid <preid@electromag.com.au>
> > > > Date: Thu Sep 19 22:36:08 2019 +0800
> > >
> > > Nope, this one
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1d4ef9b39ebecca827642b8897d2d79ea2026682
> > >
> > > The one above adds a per device label which wouldn't be much use for
> > > your
> > > case, but this one adds a per channel label.
> > >
> > > Done via a read_label callback.
> > >
> > > Here you'd want to use indexed channels so something like.
> > >
> > > in_angl0_raw
> > > in_angl1_raw
> > > in_angl2_raw
> > >
> > > and
> > >
> > > in_angl0_label = keyboard
> > > in_angl1_label = screen
> > > in_angl2_label = lid
> >
> > Thanks Jonathan. This will make the job easier.
> > Xiang,
> > You can use this method. Then you will not need other changes except
> > patch 1/4.
> > Also add a documentation patch to explain the mapping.
>
> Ah. So we have a slightly problem with sysfs ABI docs at the moment.
> The scripts that auto generate the html and similar docs from them
> don't cope with the same name of attribute in multiple documentation
> files.
>
> https://lore.kernel.org/linux-iio/20201110082658.2edc1ab5@coco.lan/
>
> The upshot being we can't have more specific docs for a particular
> part that match up with the generic docs. That will apply in this
> case.
>
> So for now, our solution is to put it in the main docs, but provide
> a subsection in there talking about more specific constraints for
> a particular device.
>
> Note I haven't actually proposed any fixes for this problem yet so
> you get to do the first one ;)
>
> Thanks,
>
> Jonathan
@Srinivas
Yes, I will try this indexed channel and label based method.
@Jonathan
So, I need to add in_angl0_raw, in_angl1_raw, in_angl2_raw and in_angl0_label,
in_angl1_label,in_angl2_label description in sysfs-bus-iio. such as
What: /sys/bus/iio/devices/iio:deviceX/in_angl0_raw
What: /sys/bus/iio/devices/iio:deviceX/in_angl1_raw
What: /sys/bus/iio/devices/iio:deviceX/in_angl2_raw
KernelVersion: 5.12
Contact: linux-iio@vger.kernel.org
Description:
Angle of rotation. Units after application of scale and offset
are radians.
What: /sys/bus/iio/devices/iio:deviceX/in_angl0_label
What: /sys/bus/iio/devices/iio:deviceX/in_angl1_label
What: /sys/bus/iio/devices/iio:deviceX/in_angl2_label
KernelVersion: 5.12
Contact: linux-iio@vger.kernel.org
Description:
Optional symbolic label to a device channel.
Am i right?
>
>
>
> >
> > Thanks,
> > Srinivas
> >
> > >
> > >
> > >
> > > > Ideally, one iio device here is much easy to manage as other HID
> > > > sensors. If we can add something other that "x", "y" and "z"
> > > > component.
> > >
> > > Agreed, using axes makes no real sense here and extended_name is
> > > just a mess from ABI point of view. Trying to solve this was the
> > > reason we added the _label interface.
> > >
> > > Jonathan
> > >
> > >
> > > > Thanks,
> > > > Srinivas
> > > >
> > > > > Thanks,
> > > > > Srinivas
> > > > >
> > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jonathan
> > > > > >
> > > > > > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > > > > > ---
> > > > > > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > > > > > drivers/iio/position/Kconfig | 16 +
> > > > > > > drivers/iio/position/Makefile | 3 +
> > > > > > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > > > > > ++++++++++++++++++
> > > > > >
> > > > > > Given it's custom probably needs a more specific name. I guess
> > > > > > hid-sensor-custom-intel-hinge.c might be safe?
> > > > > >
> > > > > > Same for other places we need names in here.
> > > > > >
> > > > > > > 4 files changed, 433 insertions(+)
> > > > > > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > > > > > hinge.c
> > > > > > >
> > > > > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > > > > > attributes.c
> > > > > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > index 442ff787f7af..5b822a4298a0 100644
> > > > > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > @@ -71,6 +71,8 @@ static struct {
> > > > > > > {HID_USAGE_SENSOR_TEMPERATURE,
> > > > > > > HID_USAGE_SENSOR_UNITS_DEGREES,
> > > > > > > 1000, 0},
> > > > > > >
> > > > > > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > > > > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > > > > > + {HID_USAGE_SENSOR_HINGE,
> > > > > > > HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > > > > > 17453293},
> > > > > > > };
> > > > > > >
> > > > > > > static void simple_div(int dividend, int divisor, int
> > > > > > > *whole,
> > > > > > > diff --git a/drivers/iio/position/Kconfig
> > > > > > > b/drivers/iio/position/Kconfig
> > > > > > > index eda67f008c5b..0346f6f2b422 100644
> > > > > > > --- a/drivers/iio/position/Kconfig
> > > > > > > +++ b/drivers/iio/position/Kconfig
> > > > > > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > > > > > To compile this driver as a module, choose M here:
> > > > > > > the module
> > > > > > > will be called iqs624-pos.
> > > > > > >
> > > > > > > +config HID_SENSOR_CUSTOM_HINGE
> > > > > > > + depends on HID_SENSOR_HUB
> > > > > > > + select IIO_BUFFER
> > > > > > > + select IIO_TRIGGERED_BUFFER
> > > > > > > + select HID_SENSOR_IIO_COMMON
> > > > > > > + select HID_SENSOR_IIO_TRIGGER
> > > > > > > + tristate "HID Hinge"
> > > > > > > + help
> > > > > > > + This sensor present three angles, hinge angel, screen
> > > > > > > angles
> > > > > > > + and keyboard angle respect to horizon (ground).
> > > > > > > + Say yes here to build support for the HID SENSOR
> > > > > > > CUSTOM
> > > > > > > + HINGE.
> > > > > >
> > > > > > Capitalization is a bit odd looking. I'd drop it.
> > > > > >
> > > > > > > +
> > > > > > > + To compile this driver as a module, choose M here:
> > > > > > > the
> > > > > > > + module will be called hid-sensor-custom-hinge.
> > > > > > > +
> > > > > > > endmenu
> > > > > > > diff --git a/drivers/iio/position/Makefile
> > > > > > > b/drivers/iio/position/Makefile
> > > > > > > index 3cbe7a734352..7a6225977a01 100644
> > > > > > > --- a/drivers/iio/position/Makefile
> > > > > > > +++ b/drivers/iio/position/Makefile
> > > > > > > @@ -5,3 +5,6 @@
> > > > > > > # When adding new entries keep the list in alphabetical
> > > > > > > order
> > > > > > >
> > > > > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > > > > +
> > > > > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > > > > > hinge.o
> > > > > >
> > > > > > Alphabetical order preferred.
> > > > > >
> > > > > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-
> > > > > > > sensors
> > > > > >
> > > > > > Why?
> > > > > >
> > > > > > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..a91b333f36fa
> > > > > > > --- /dev/null
> > > > > > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > @@ -0,0 +1,412 @@
> > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > +/*
> > > > > > > + * HID Sensors Driver
> > > > > > > + * Copyright (c) 2020, Intel Corporation.
> > > > > > > + */
> > > > > > > +#include <linux/hid-sensor-hub.h>
> > > > > > > +#include <linux/iio/buffer.h>
> > > > > > > +#include <linux/iio/iio.h>
> > > > > > > +#include <linux/platform_device.h>
> > > > > > > +
> > > > > > > +#include "hid-sensor-trigger.h"
> > > > > > > +
> > > > > > > +/* Channel definitions */
> > > > > > > +static const struct iio_chan_spec hinge_channels[] = {
> > > > > > > + { .type = IIO_ANGL,
> > > > > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > > > > > + .info_mask_shared_by_type =
> > > > > > > + BIT(IIO_CHAN_INFO_OFFSET) |
> > > > > > > BIT(IIO_CHAN_INFO_SCALE)
> > > > > > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > > > > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > > > > > + .scan_type.realbits = 16,
> > > > > > > + .scan_type.storagebits = 32,
> > > > > >
> > > > > > It a bit odd to see a single channel that is 16 bits inside a
> > > > > > 32
> > > > > > bit
> > > > > > with
> > > > > > no shift or similar. Why not just pack it into 16 bits?
> > > > > >
> > > > > > > + .scan_type.sign = 's',
> > > > > > > + .scan_index = 0 },
> > > > > > > +
> > > > > > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > > > > > +};
> > > > > > > +
> > > > > > > +struct hinge_state {
> > > > > > > + struct iio_dev *indio_dev;
> > > > > > > + struct hid_sensor_hub_attribute_info hinge;
> > > > > > > + /* Reserve for 1 channel + pading + timestamp */
> > > > > > > + u32 hinge_val[1 + 3];
> > > > > >
> > > > > > __aligned(8)
> > > > > >
> > > > > > see below for requirements on this.
> > > > > > Perhaps better to use
> > > > > >
> > > > > > struct hinge_scan {
> > > > > > u32 val;
> > > > > > s64 timestamp __aligned(8); // Note this is
> > > > > > needed for
> > > > > > x86_32
> > > > > > } scan;
> > > > > >
> > > > > > > + int scale_pre_decml;
> > > > > > > + int scale_post_decml;
> > > > > > > + int scale_precision;
> > > > > > > + int value_offset;
> > > > > > > + int64_t timestamp;
> > > > > > > + u32 hinge_address;
> > > > > > > +};
> > > > > > > +
> > > > > > > +#define IIO_DEV_NUM 3
> > > > > >
> > > > > > That needs a prefix to make it clear it's not a generic
> > > > > > constant
> > > > > > but is specific to this driver.
> > > > > >
> > > > > > > +
> > > > > > > +struct hinge_group {
> > > > > > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > > > > > + struct hid_sensor_hub_callbacks callbacks;
> > > > > > > + struct hid_sensor_common common_attributes;
> > > > > > > +};
> > > > > > > +
> > > > > > > +static struct hinge_group *hg_group;
> > > > > >
> > > > > > We shouldn't see globals like this. Please figure out how to
> > > > > > avoid
> > > > > > it.
> > > > > >
> > > > > > > +
> > > > > > > +/* Channel read_raw handler */
> > > > > > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > > > > > + struct iio_chan_spec const *chan, int
> > > > > > > *val,
> > > > > > > int *val2,
> > > > > > > + long mask)
> > > > > > > +{
> > > > > > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > > > > > + struct hid_sensor_hub_device *hsdev;
> > > > > > > + int report_id = -1;
> > > > > > > + int ret_type;
> > > > > > > + s32 min;
> > > > > > > +
> > > > > > > + hsdev = hg_group->common_attributes.hsdev;
> > > > > > > +
> > > > > > > + *val = 0;
> > > > > > > + *val2 = 0;
> > > > > > > + switch (mask) {
> > > > > > > + case IIO_CHAN_INFO_RAW:
> > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > >common_attributes,
> > > > > > > true);
> > > > > > > + report_id = hg_state->hinge.report_id;
> > > > > > > + min = hg_state->hinge.logical_minimum;
> > > > > > > + if (report_id < 0) {
> > > > > > > + *val = 0;
> > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > common_attributes,
> > > > > > > + false);
> > > > > > > + return -EINVAL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + *val = sensor_hub_input_attr_get_raw_value(
> > > > > > > + hg_group->common_attributes.hsdev,
> > > > > > > hsdev-
> > > > > > > > usage,
> > > > > > > + hg_state->hinge_address, report_id,
> > > > > > > SENSOR_HUB_SYNC,
> > > > > > > + min < 0);
> > > > > > > +
> > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > >common_attributes,
> > > > > > > false);
> > > > > > > + ret_type = IIO_VAL_INT;
> > > > > > > + break;
> > > > > > > + case IIO_CHAN_INFO_SCALE:
> > > > > > > + *val = hg_state->scale_pre_decml;
> > > > > > > + *val2 = hg_state->scale_post_decml;
> > > > > > > + ret_type = hg_state->scale_precision;
> > > > > > > + break;
> > > > > > > + case IIO_CHAN_INFO_OFFSET:
> > > > > > > + *val = hg_state->value_offset;
> > > > > > > + ret_type = IIO_VAL_INT;
> > > > > > > + break;
> > > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > > + ret_type = hid_sensor_read_samp_freq_value(
> > > > > > > + &hg_group->common_attributes, val,
> > > > > > > val2);
> > > > > > > + break;
> > > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > > > > > + &hg_group->common_attributes, val,
> > > > > > > val2);
> > > > > > > + break;
> > > > > > > + default:
> > > > > > > + ret_type = -EINVAL;
> > > > > > > + break;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret_type;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* Channel write_raw handler */
> > > > > > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > > > > > + struct iio_chan_spec const *chan,
> > > > > > > int val,
> > > > > > > int val2,
> > > > > > > + long mask)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + switch (mask) {
> > > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > > + ret = hid_sensor_write_samp_freq_value(
> > > > > > > + &hg_group->common_attributes, val,
> > > > > > > val2);
> > > > > > > + break;
> > > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > > + ret = hid_sensor_write_raw_hyst_value(
> > > > > > > + &hg_group->common_attributes, val,
> > > > > > > val2);
> > > > > > > +
> > > > > > > + break;
> > > > > > > + default:
> > > > > > > + ret = -EINVAL;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static const struct iio_info hinge_info = {
> > > > > > > + .read_raw = &hinge_read_raw,
> > > > > > > + .write_raw = &hinge_write_raw,
> > > > > > > +};
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * Function to push data to buffer;
> > > > > > > + * wrapper added for symmetry with other hid-sensor drivers
> > > > > > > + */
> > > > > > > +static void hid_sensor_push_data(struct iio_dev *indio_dev,
> > > > > > > void
> > > > > > > *data, int len,
> > > > > >
> > > > > > This doesn't seem to be generic, so don't name it as such.
> > > > > >
> > > > > > > + int64_t timestamp)
> > > > > > > +{
> > > > > > > + iio_push_to_buffers_with_timestamp(indio_dev, data,
> > > > > > > timestamp);
> > > > > > I hope that data buffer obeys the various rules needed by (and
> > > > > > admittedly
> > > > > > not that well documented) iio_push_to_buffers_with_timestamp()
> > > > > >
> > > > > > 1. Needs to be 8 byte aligned.
> > > > > > 2. Needs to have space for an aligned 8 byte timestamp at the
> > > > > > end.
> > > > > >
> > > > > > > +}
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * Callback handler to send event after all samples are
> > > > > > > received
> > > > > > > + * and captured.
> > > > > > > + */
> > > > > > > +static int hinge_proc_event(struct hid_sensor_hub_device
> > > > > > > *hsdev,
> > > > > > > + unsigned int usage_id, void *priv)
> > > > > > > +{
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > > > > > If we push for all sensors together, better to have
> > > > > > this as a single iio_device with 3 channels.
> > > > > >
> > > > > > Use the channel labels (just added to IIO) to identify which is
> > > > > > which.
> > > > > >
> > > > > > > + struct hinge_state *hg_state;
> > > > > > > + struct iio_dev *indio_dev;
> > > > > > > +
> > > > > > > + hg_state = hg_group->hg_states[i];
> > > > > > > + indio_dev = hg_state->indio_dev;
> > > > > > > +
> > > > > > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > > > > > scan_bytes:%d\n",
> > > > > > > + __func__, hg_state->timestamp,
> > > > > > > indio_dev-
> > > > > > > > scan_bytes);
> > > > > > > +
> > > > > > > + if (!hg_state->timestamp)
> > > > > > > + hg_state->timestamp =
> > > > > > > iio_get_time_ns(indio_dev);
> > > > > > > +
> > > > > > > + hid_sensor_push_data(indio_dev, hg_state-
> > > > > > > >hinge_val,
> > > > > > > + sizeof(hg_state-
> > > > > > > >hinge_val),
> > > > > > > + hg_state->timestamp);
> > > > > > > +
> > > > > > > + hg_state->timestamp = 0;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* Capture samples in local storage */
> > > > > > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > > > > > *hsdev,
> > > > > > > + unsigned int usage_id, size_t
> > > > > > > raw_len,
> > > > > > > + char *raw_data, void *priv)
> > > > > > > +{
> > > > > > > + struct hinge_state *hg_state;
> > > > > > > + int offset;
> > > > > > > + int ret = -EINVAL;
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > > + hg_group->hg_states[i]->timestamp =
> > > > > >
> > > > > > This rather implies all the data is captured together... If so
> > > > > > single
> > > > > > iio_device may make more sense.
> > > > > >
> > > > > > > + hid_sensor_convert_timestamp(
> > > > > > > + &hg_group-
> > > > > > > >common_attributes,
> > > > > > > + *(int64_t *)raw_data);
> > > > > > > + return 0;
> > > > > > > + }
> > > > > > > +
> > > > > > > + switch (usage_id) {
> > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > > > > > + offset = usage_id -
> > > > > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > > > > > + hg_state = hg_group->hg_states[offset];
> > > > > > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > > > > > + ret = 0;
> > > > > >
> > > > > > return 0;
> > > > > >
> > > > > > > + break;
> > > > > > > + default:
> > > > > > return -EINVAL;
> > > > > > > + break;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* Parse report which is specific to an usage id */
> > > > > > > +static int hinge_parse_report(struct platform_device *pdev,
> > > > > > > + struct hid_sensor_hub_device
> > > > > > > *hsdev,
> > > > > > > + unsigned int usage_id, unsigned
> > > > > > > int
> > > > > > > attr_usage_id,
> > > > > > > + struct hinge_state *st)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = sensor_hub_input_get_attribute_info(
> > > > > > > + hsdev, HID_INPUT_REPORT, usage_id,
> > > > > > > attr_usage_id, &st-
> > > > > > > > hinge);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + st->hinge_address = attr_usage_id;
> > > > > > > + st->scale_precision =
> > > > > > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE,
> > > > > > > &st-
> > > > > > > > hinge,
> > > > > > > + &st->scale_pre_decml,
> > > > > > > + &st->scale_post_decml);
> > > > > > > +
> > > > > > > + /* Set Sensitivity field ids, when there is no
> > > > > > > individual
> > > > > > > modifier */
> > > > > > > + if (hg_group->common_attributes.sensitivity.index < 0)
> > > > > > > {
> > > > > > > + sensor_hub_input_get_attribute_info(
> > > > > > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > > > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > > > > IVITY_AB
> > > > > > > S |
> > > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUS
> > > > > > > TOM_VALU
> > > > > > > E_1,
> > > > > > > + &hg_group-
> > > > > > > >common_attributes.sensitivity);
> > > > > > > + dev_dbg(&pdev->dev, "Sensitivity index:report
> > > > > > > %d:%d\n",
> > > > > > > + hg_group-
> > > > > > > >common_attributes.sensitivity.index,
> > > > > > > + hg_group-
> > > > > > > > common_attributes.sensitivity.report_id);
> > > > > > > + }
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* Function to initialize the processing for usage id */
> > > > > > > +static int hinge_add_iio_device(struct platform_device
> > > > > > > *pdev,
> > > > > > > int
> > > > > > > index,
> > > > > > > + const char *name, struct
> > > > > > > hinge_state
> > > > > > > **st)
> > > > > > > +{
> > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > >dev.platform_data;
> > > > > > > + struct hinge_state *hg_state;
> > > > > > > + struct iio_dev *indio_dev;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + indio_dev =
> > > > > > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > > > > > hinge_state));
> > > > > >
> > > > > > sizeof (*hg_state) preferred.
> > > > > >
> > > > > > > + if (indio_dev == NULL)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + hg_state = iio_priv(indio_dev);
> > > > > > > + hg_state->indio_dev = indio_dev;
> > > > > > > +
> > > > > > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > > > > > + indio_dev->channels =
> > > > > > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > > > > > GFP_KERNEL);
> > > > > >
> > > > > > I don't immediately see anything that is modifying channels. As
> > > > > > such
> > > > > > you
> > > > > > should be able have it shared by all the instances.
> > > > > >
> > > > > > > + if (!indio_dev->channels)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + ret = hinge_parse_report(
> > > > > > > + pdev, hsdev, hsdev->usage,
> > > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 +
> > > > > > > index,
> > > > > > > hg_state);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(&pdev->dev, "failed to setup
> > > > > > > attributes\n");
> > > > > > > + goto error_free_dev_mem;
> > > > > > > + }
> > > > > > > +
> > > > > > > + indio_dev->dev.parent = &pdev->dev;
> > > > > > > + indio_dev->info = &hinge_info;
> > > > > > > + indio_dev->name = name;
> > > > > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > > > > +
> > > > > > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > > > > > + &hg_group-
> > > > > > > >common_attributes);
> > > > > > > + if (ret < 0) {
> > > > > > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > > > > > + goto error_free_dev_mem;
> > > > > > > + }
> > > > > > > +
> > > > > > > + ret = iio_device_register(indio_dev);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(&pdev->dev, "device register
> > > > > > > failed\n");
> > > > > > > + goto error_remove_trigger;
> > > > > > > + }
> > > > > > > +
> > > > > > > + *st = hg_state;
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > +error_remove_trigger:
> > > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > > common_attributes);
> > > > > > > +error_free_dev_mem:
> > > > > > > + kfree(indio_dev->channels);
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > > +static int hinge_remove_iio_device(struct platform_device
> > > > > > > *pdev,
> > > > > > > int index)
> > > > > > > +{
> > > > > > > + struct hinge_state *hg_state = hg_group-
> > > > > > > >hg_states[index];
> > > > > > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > > > > > +
> > > > > > > + iio_device_unregister(indio_dev);
> > > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > > common_attributes);
> > > > > > > + kfree(indio_dev->channels);
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > > > > > +{
> > > > > > > + struct hinge_state *hg_state;
> > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > >dev.platform_data;
> > > > > > > + static const char *const names[] = { "hinge", "screen",
> > > > > > > "keyboard" };
> > > > > > > + int ret;
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct
> > > > > > > hinge_group),
> > > > > > > + GFP_KERNEL);
> > > > > >
> > > > > > As mentioned above, I'd really not expect to see a global like
> > > > > > this.
> > > > > > Technically nothing stops there being more than one instance of
> > > > > > this
> > > > > > device on a platform (even if that would be a bit odd) + it's
> > > > > > almost
> > > > > > always cleaner to not use a global in the first place.
> > > > > >
> > > > > > > + if (!hg_group)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + hg_group->common_attributes.hsdev = hsdev;
> > > > > > > + hg_group->common_attributes.pdev = pdev;
> > > > > > > +
> > > > > > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev-
> > > > > > > >usage,
> > > > > > > + &hg_group-
> > > > > > > > common_attributes);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(&pdev->dev, "failed to setup common
> > > > > > > attributes\n");
> > > > > > > + return ret;
> > > > > > > + }
> > > > > > > +
> > > > > > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > > > > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > > > > > &hg_state);
> > > > > > > + if (ret)
> > > > > > > + goto err_probe;
> > > > > > > +
> > > > > > > + hg_group->hg_states[i] = hg_state;
> > > > > > > + }
> > > > > > > +
> > > > > > > + /* use the first iio device to do the PM */
> > > > > > > + platform_set_drvdata(pdev, hg_group->hg_states[0]-
> > > > > > > >indio_dev);
> > > > > > > +
> > > > > > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > > > > > + hg_group->callbacks.capture_sample =
> > > > > > > hinge_capture_sample;
> > > > > > > + hg_group->callbacks.pdev = pdev;
> > > > > > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > > > > > + &hg_group-
> > > > > > > >callbacks);
> > > > > > > + if (ret < 0)
> > > > > > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > +err_probe:
> > > > > > > + for (i--; i >= 0; i--)
> > > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > > > > > +{
> > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > >dev.platform_data;
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > > > > > +
> > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > > > > > + {
> > > > > > > + /* Format: HID-SENSOR-INT-
> > > > > > > usage_id_in_hex_lowercase */
> > > > > > > + .name = "HID-SENSOR-INT-020b",
> > > > > > > + },
> > > > > > > + { /* sentinel */ }
> > > > > > > +};
> > > > > > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > > > > > +
> > > > > > > +static struct platform_driver hid_hinge_platform_driver = {
> > > > > > > + .id_table = hid_hinge_ids,
> > > > > > > + .driver = {
> > > > > > > + .name = KBUILD_MODNAME,
> > > > > > > + .pm = &hid_sensor_pm_ops,
> > > > > > > + },
> > > > > > > + .probe = hid_hinge_probe,
> > > > > > > + .remove = hid_hinge_remove,
> > > > > > > +};
> > > > > > > +module_platform_driver(hid_hinge_platform_driver);
> > > > > > > +
> > > > > > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > > > > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > > > > > +MODULE_LICENSE("GPL");
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-21 17:56 ` Jonathan Cameron
2020-11-22 1:46 ` Pandruvada, Srinivas
@ 2020-11-24 6:43 ` Ye, Xiang
2020-11-24 11:39 ` Jonathan Cameron
1 sibling, 1 reply; 25+ messages in thread
From: Ye, Xiang @ 2020-11-24 6:43 UTC (permalink / raw)
To: Jonathan Cameron
Cc: jikos, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Sat, Nov 21, 2020 at 05:56:29PM +0000, Jonathan Cameron wrote:
> On Thu, 19 Nov 2020 18:03:31 +0800
> Ye Xiang <xiang.ye@intel.com> wrote:
>
> > The Hinge sensor is a common custom sensor on laptops. It calculates
> > the angle between the lid (screen) and the base (keyboard). In addition,
> > it also exposes screen and the keyboard angels with respect to the
> > ground. Applications can easily get laptop's status in space through
> > this sensor, in order to display appropriate user interface.
>
> I'm a little unclear on why the 3 axes aren't treated as a single sensor.
> You seem to always grab the 3 together or am I missing something?
>
> That will greatly simplify things and get rid of the need to have
> a shared trigger with the problems that causes in the previous
> patch.
>
> Thanks,
>
> Jonathan
>
> >
> > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > ---
> > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > drivers/iio/position/Kconfig | 16 +
> > drivers/iio/position/Makefile | 3 +
> > .../iio/position/hid-sensor-custom-hinge.c | 412 ++++++++++++++++++
>
> Given it's custom probably needs a more specific name. I guess
> hid-sensor-custom-intel-hinge.c might be safe?
>
> Same for other places we need names in here.
agree, will change the name to hid-sensor-custom-intel-hinge.c
>
> > 4 files changed, 433 insertions(+)
> > create mode 100644 drivers/iio/position/hid-sensor-custom-hinge.c
> >
> > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > index 442ff787f7af..5b822a4298a0 100644
> > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > @@ -71,6 +71,8 @@ static struct {
> > {HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES, 1000, 0},
> >
> > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > + {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0, 17453293},
> > };
> >
> > static void simple_div(int dividend, int divisor, int *whole,
> > diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
> > index eda67f008c5b..0346f6f2b422 100644
> > --- a/drivers/iio/position/Kconfig
> > +++ b/drivers/iio/position/Kconfig
> > @@ -16,4 +16,20 @@ config IQS624_POS
> > To compile this driver as a module, choose M here: the module
> > will be called iqs624-pos.
> >
> > +config HID_SENSOR_CUSTOM_HINGE
> > + depends on HID_SENSOR_HUB
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > + select HID_SENSOR_IIO_COMMON
> > + select HID_SENSOR_IIO_TRIGGER
> > + tristate "HID Hinge"
> > + help
> > + This sensor present three angles, hinge angel, screen angles
> > + and keyboard angle respect to horizon (ground).
> > + Say yes here to build support for the HID SENSOR CUSTOM
> > + HINGE.
>
> Capitalization is a bit odd looking. I'd drop it.
ok, will use lowercase.
>
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called hid-sensor-custom-hinge.
> > +
> > endmenu
> > diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
> > index 3cbe7a734352..7a6225977a01 100644
> > --- a/drivers/iio/position/Makefile
> > +++ b/drivers/iio/position/Makefile
> > @@ -5,3 +5,6 @@
> > # When adding new entries keep the list in alphabetical order
> >
> > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > +
> > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
>
> Alphabetical order preferred.
>
> > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
>
> Why?
hinge driver need to include #include "hid-sensor-trigger.h", if not using this cflag-y
it should be #include "../common/hid-sensors/hid-sensor-trigger.h"
>
> > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c b/drivers/iio/position/hid-sensor-custom-hinge.c
> > new file mode 100644
> > index 000000000000..a91b333f36fa
> > --- /dev/null
> > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > @@ -0,0 +1,412 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * HID Sensors Driver
> > + * Copyright (c) 2020, Intel Corporation.
> > + */
> > +#include <linux/hid-sensor-hub.h>
> > +#include <linux/iio/buffer.h>
> > +#include <linux/iio/iio.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include "hid-sensor-trigger.h"
> > +
> > +/* Channel definitions */
> > +static const struct iio_chan_spec hinge_channels[] = {
> > + { .type = IIO_ANGL,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > + .info_mask_shared_by_type =
> > + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE) |
> > + BIT(IIO_CHAN_INFO_SAMP_FREQ) | BIT(IIO_CHAN_INFO_HYSTERESIS),
> > + .scan_type.realbits = 16,
> > + .scan_type.storagebits = 32,
>
> It a bit odd to see a single channel that is 16 bits inside a 32 bit with
> no shift or similar. Why not just pack it into 16 bits?
As it's said in last email, will use one iio device with three labeled channel
then will not hard code the realbits and storagebits.
>
> > + .scan_type.sign = 's',
> > + .scan_index = 0 },
> > +
> > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > +};
> > +
> > +struct hinge_state {
> > + struct iio_dev *indio_dev;
> > + struct hid_sensor_hub_attribute_info hinge;
> > + /* Reserve for 1 channel + pading + timestamp */
> > + u32 hinge_val[1 + 3];
>
> __aligned(8)
>
> see below for requirements on this.
> Perhaps better to use
>
> struct hinge_scan {
> u32 val;
> s64 timestamp __aligned(8); // Note this is needed for x86_32
> } scan;
>
This patch use hard code pading for align(8)
I think your method this is a good choice, will use it thanks.
> > + int scale_pre_decml;
> > + int scale_post_decml;
> > + int scale_precision;
> > + int value_offset;
> > + int64_t timestamp;
> > + u32 hinge_address;
> > +};
> > +
> > +#define IIO_DEV_NUM 3
>
> That needs a prefix to make it clear it's not a generic constant
> but is specific to this driver.
Will use one iio device, so this macro will be abandon.
>
> > +
> > +struct hinge_group {
> > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > + struct hid_sensor_hub_callbacks callbacks;
> > + struct hid_sensor_common common_attributes;
> > +};
> > +
> > +static struct hinge_group *hg_group;
>
> We shouldn't see globals like this. Please figure out how to avoid it.
ditto
>
> > +
> > +/* Channel read_raw handler */
> > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int *val, int *val2,
> > + long mask)
> > +{
> > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > + struct hid_sensor_hub_device *hsdev;
> > + int report_id = -1;
> > + int ret_type;
> > + s32 min;
> > +
> > + hsdev = hg_group->common_attributes.hsdev;
> > +
> > + *val = 0;
> > + *val2 = 0;
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + hid_sensor_power_state(&hg_group->common_attributes, true);
> > + report_id = hg_state->hinge.report_id;
> > + min = hg_state->hinge.logical_minimum;
> > + if (report_id < 0) {
> > + *val = 0;
> > + hid_sensor_power_state(&hg_group->common_attributes,
> > + false);
> > + return -EINVAL;
> > + }
> > +
> > + *val = sensor_hub_input_attr_get_raw_value(
> > + hg_group->common_attributes.hsdev, hsdev->usage,
> > + hg_state->hinge_address, report_id, SENSOR_HUB_SYNC,
> > + min < 0);
> > +
> > + hid_sensor_power_state(&hg_group->common_attributes, false);
> > + ret_type = IIO_VAL_INT;
> > + break;
> > + case IIO_CHAN_INFO_SCALE:
> > + *val = hg_state->scale_pre_decml;
> > + *val2 = hg_state->scale_post_decml;
> > + ret_type = hg_state->scale_precision;
> > + break;
> > + case IIO_CHAN_INFO_OFFSET:
> > + *val = hg_state->value_offset;
> > + ret_type = IIO_VAL_INT;
> > + break;
> > + case IIO_CHAN_INFO_SAMP_FREQ:
> > + ret_type = hid_sensor_read_samp_freq_value(
> > + &hg_group->common_attributes, val, val2);
> > + break;
> > + case IIO_CHAN_INFO_HYSTERESIS:
> > + ret_type = hid_sensor_read_raw_hyst_value(
> > + &hg_group->common_attributes, val, val2);
> > + break;
> > + default:
> > + ret_type = -EINVAL;
> > + break;
> > + }
> > +
> > + return ret_type;
> > +}
> > +
> > +/* Channel write_raw handler */
> > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int val, int val2,
> > + long mask)
> > +{
> > + int ret;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_SAMP_FREQ:
> > + ret = hid_sensor_write_samp_freq_value(
> > + &hg_group->common_attributes, val, val2);
> > + break;
> > + case IIO_CHAN_INFO_HYSTERESIS:
> > + ret = hid_sensor_write_raw_hyst_value(
> > + &hg_group->common_attributes, val, val2);
> > +
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static const struct iio_info hinge_info = {
> > + .read_raw = &hinge_read_raw,
> > + .write_raw = &hinge_write_raw,
> > +};
> > +
> > +/*
> > + * Function to push data to buffer;
> > + * wrapper added for symmetry with other hid-sensor drivers
> > + */
> > +static void hid_sensor_push_data(struct iio_dev *indio_dev, void *data, int len,
>
> This doesn't seem to be generic, so don't name it as such.
got it.
>
> > + int64_t timestamp)
> > +{
> > + iio_push_to_buffers_with_timestamp(indio_dev, data, timestamp);
> I hope that data buffer obeys the various rules needed by (and admittedly
> not that well documented) iio_push_to_buffers_with_timestamp()
>
> 1. Needs to be 8 byte aligned.
> 2. Needs to have space for an aligned 8 byte timestamp at the end.
yes, it use a padding to make it align to 8byte. As is said before
, will use your recommend method instead.
>
> > +}
> > +
> > +/*
> > + * Callback handler to send event after all samples are received
> > + * and captured.
> > + */
> > +static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
> > + unsigned int usage_id, void *priv)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> If we push for all sensors together, better to have
> this as a single iio_device with 3 channels.
>
> Use the channel labels (just added to IIO) to identify which is which.
Will try to use channel labels
>
> > + struct hinge_state *hg_state;
> > + struct iio_dev *indio_dev;
> > +
> > + hg_state = hg_group->hg_states[i];
> > + indio_dev = hg_state->indio_dev;
> > +
> > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu scan_bytes:%d\n",
> > + __func__, hg_state->timestamp, indio_dev->scan_bytes);
> > +
> > + if (!hg_state->timestamp)
> > + hg_state->timestamp = iio_get_time_ns(indio_dev);
> > +
> > + hid_sensor_push_data(indio_dev, hg_state->hinge_val,
> > + sizeof(hg_state->hinge_val),
> > + hg_state->timestamp);
> > +
> > + hg_state->timestamp = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/* Capture samples in local storage */
> > +static int hinge_capture_sample(struct hid_sensor_hub_device *hsdev,
> > + unsigned int usage_id, size_t raw_len,
> > + char *raw_data, void *priv)
> > +{
> > + struct hinge_state *hg_state;
> > + int offset;
> > + int ret = -EINVAL;
> > + int i;
> > +
> > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > + for (i = 0; i < IIO_DEV_NUM; i++)
> > + hg_group->hg_states[i]->timestamp =
>
> This rather implies all the data is captured together... If so single
> iio_device may make more sense.
will use one iio device with three channel.
>
> > + hid_sensor_convert_timestamp(
> > + &hg_group->common_attributes,
> > + *(int64_t *)raw_data);
> > + return 0;
> > + }
> > +
> > + switch (usage_id) {
> > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > + offset = usage_id - HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > + hg_state = hg_group->hg_states[offset];
> > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > + ret = 0;
>
> return 0;
>
> > + break;
> > + default:
> return -EINVAL;
ok, but i think it's the same..
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/* Parse report which is specific to an usage id */
> > +static int hinge_parse_report(struct platform_device *pdev,
> > + struct hid_sensor_hub_device *hsdev,
> > + unsigned int usage_id, unsigned int attr_usage_id,
> > + struct hinge_state *st)
> > +{
> > + int ret;
> > +
> > + ret = sensor_hub_input_get_attribute_info(
> > + hsdev, HID_INPUT_REPORT, usage_id, attr_usage_id, &st->hinge);
> > + if (ret < 0)
> > + return ret;
> > +
> > + st->hinge_address = attr_usage_id;
> > + st->scale_precision =
> > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE, &st->hinge,
> > + &st->scale_pre_decml,
> > + &st->scale_post_decml);
> > +
> > + /* Set Sensitivity field ids, when there is no individual modifier */
> > + if (hg_group->common_attributes.sensitivity.index < 0) {
> > + sensor_hub_input_get_attribute_info(
> > + hsdev, HID_FEATURE_REPORT, usage_id,
> > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
> > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1,
> > + &hg_group->common_attributes.sensitivity);
> > + dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
> > + hg_group->common_attributes.sensitivity.index,
> > + hg_group->common_attributes.sensitivity.report_id);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/* Function to initialize the processing for usage id */
> > +static int hinge_add_iio_device(struct platform_device *pdev, int index,
> > + const char *name, struct hinge_state **st)
> > +{
> > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > + struct hinge_state *hg_state;
> > + struct iio_dev *indio_dev;
> > + int ret;
> > +
> > + indio_dev =
> > + devm_iio_device_alloc(&pdev->dev, sizeof(struct hinge_state));
>
> sizeof (*hg_state) preferred.
got it.
>
> > + if (indio_dev == NULL)
> > + return -ENOMEM;
> > +
> > + hg_state = iio_priv(indio_dev);
> > + hg_state->indio_dev = indio_dev;
> > +
> > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > + indio_dev->channels =
> > + kmemdup(hinge_channels, sizeof(hinge_channels), GFP_KERNEL);
>
> I don't immediately see anything that is modifying channels. As such you
> should be able have it shared by all the instances.
will try to use one iio device.
>
> > + if (!indio_dev->channels)
> > + return -ENOMEM;
> > +
> > + ret = hinge_parse_report(
> > + pdev, hsdev, hsdev->usage,
> > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 + index, hg_state);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to setup attributes\n");
> > + goto error_free_dev_mem;
> > + }
> > +
> > + indio_dev->dev.parent = &pdev->dev;
> > + indio_dev->info = &hinge_info;
> > + indio_dev->name = name;
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > +
> > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > + &hg_group->common_attributes);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "trigger setup failed\n");
> > + goto error_free_dev_mem;
> > + }
> > +
> > + ret = iio_device_register(indio_dev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "device register failed\n");
> > + goto error_remove_trigger;
> > + }
> > +
> > + *st = hg_state;
> > +
> > + return ret;
> > +
> > +error_remove_trigger:
> > + hid_sensor_remove_trigger(indio_dev, &hg_group->common_attributes);
> > +error_free_dev_mem:
> > + kfree(indio_dev->channels);
> > + return ret;
> > +}
> > +
> > +/* Function to deinitialize the processing for usage id */
> > +static int hinge_remove_iio_device(struct platform_device *pdev, int index)
> > +{
> > + struct hinge_state *hg_state = hg_group->hg_states[index];
> > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > +
> > + iio_device_unregister(indio_dev);
> > + hid_sensor_remove_trigger(indio_dev, &hg_group->common_attributes);
> > + kfree(indio_dev->channels);
> > +
> > + return 0;
> > +}
> > +
> > +static int hid_hinge_probe(struct platform_device *pdev)
> > +{
> > + struct hinge_state *hg_state;
> > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > + static const char *const names[] = { "hinge", "screen", "keyboard" };
> > + int ret;
> > + int i;
> > +
> > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct hinge_group),
> > + GFP_KERNEL);
>
> As mentioned above, I'd really not expect to see a global like this.
> Technically nothing stops there being more than one instance of this
> device on a platform (even if that would be a bit odd) + it's almost
> always cleaner to not use a global in the first place.
using one iio device can avoid using the global variable.
>
> > + if (!hg_group)
> > + return -ENOMEM;
> > +
> > + hg_group->common_attributes.hsdev = hsdev;
> > + hg_group->common_attributes.pdev = pdev;
> > +
> > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev->usage,
> > + &hg_group->common_attributes);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to setup common attributes\n");
> > + return ret;
> > + }
> > +
> > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > + ret = hinge_add_iio_device(pdev, i, names[i], &hg_state);
> > + if (ret)
> > + goto err_probe;
> > +
> > + hg_group->hg_states[i] = hg_state;
> > + }
> > +
> > + /* use the first iio device to do the PM */
> > + platform_set_drvdata(pdev, hg_group->hg_states[0]->indio_dev);
> > +
> > + hg_group->callbacks.send_event = hinge_proc_event;
> > + hg_group->callbacks.capture_sample = hinge_capture_sample;
> > + hg_group->callbacks.pdev = pdev;
> > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > + &hg_group->callbacks);
> > + if (ret < 0)
> > + dev_err(&pdev->dev, "callback reg failed\n");
> > +
> > + return ret;
> > +
> > +err_probe:
> > + for (i--; i >= 0; i--)
> > + hinge_remove_iio_device(pdev, i);
> > +
> > + return ret;
> > +}
> > +
> > +/* Function to deinitialize the processing for usage id */
> > +static int hid_hinge_remove(struct platform_device *pdev)
> > +{
> > + struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > + int i;
> > +
> > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > +
> > + for (i = 0; i < IIO_DEV_NUM; i++)
> > + hinge_remove_iio_device(pdev, i);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct platform_device_id hid_hinge_ids[] = {
> > + {
> > + /* Format: HID-SENSOR-INT-usage_id_in_hex_lowercase */
> > + .name = "HID-SENSOR-INT-020b",
> > + },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > +
> > +static struct platform_driver hid_hinge_platform_driver = {
> > + .id_table = hid_hinge_ids,
> > + .driver = {
> > + .name = KBUILD_MODNAME,
> > + .pm = &hid_sensor_pm_ops,
> > + },
> > + .probe = hid_hinge_probe,
> > + .remove = hid_hinge_remove,
> > +};
> > +module_platform_driver(hid_hinge_platform_driver);
> > +
> > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > +MODULE_LICENSE("GPL");
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support
2020-11-21 17:21 ` Jonathan Cameron
@ 2020-11-24 10:29 ` Ye, Xiang
2020-11-24 11:32 ` Jonathan Cameron
0 siblings, 1 reply; 25+ messages in thread
From: Ye, Xiang @ 2020-11-24 10:29 UTC (permalink / raw)
To: Jonathan Cameron
Cc: jikos, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Sat, Nov 21, 2020 at 05:21:27PM +0000, Jonathan Cameron wrote:
> On Thu, 19 Nov 2020 18:03:28 +0800
> Ye Xiang <xiang.ye@intel.com> wrote:
>
> > Currently custom sensors properties are not decoded and it is up to
> > user space to interpret.
> >
> > Some manufacturers already standardized the meaning of some custom sensors.
> > They can be presented as a proper IIO sensor. We can identify these sensors
> > based on manufacturer and serial number property in the report.
> >
> > This change is identifying hinge sensor when the manufacturer is "INTEL".
> > This creates a platform device so that a sensor driver can be loaded to
> > process these sensors.
> >
> > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
>
> Hi Ye Xiang,
>
> Various comments inline.
>
> Thanks,
>
> Jonathan
Thanks for review and comments
Xiang
>
> > ---
> > drivers/hid/hid-sensor-custom.c | 170 ++++++++++++++++++++++++++++++++
> > include/linux/hid-sensor-ids.h | 39 ++++++++
> > 2 files changed, 209 insertions(+)
> >
> > diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> > index 4d25577a8573..bb96d9c09daf 100644
> > --- a/drivers/hid/hid-sensor-custom.c
> > +++ b/drivers/hid/hid-sensor-custom.c
> > @@ -4,6 +4,7 @@
> > * Copyright (c) 2015, Intel Corporation.
> > */
> >
> > +#include <linux/ctype.h>
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/init.h>
> > @@ -21,6 +22,7 @@
> > #define HID_CUSTOM_TOTAL_ATTRS (HID_CUSTOM_MAX_CORE_ATTRS + 1)
> > #define HID_CUSTOM_FIFO_SIZE 4096
> > #define HID_CUSTOM_MAX_FEATURE_BYTES 64
> > +#define HID_SENSOR_USAGE_LENGTH (4 + 1)
> >
> > struct hid_sensor_custom_field {
> > int report_id;
> > @@ -50,6 +52,8 @@ struct hid_sensor_custom {
> > struct kfifo data_fifo;
> > unsigned long misc_opened;
> > wait_queue_head_t wait;
> > + struct platform_device *custom_pdev;
> > + bool custom_pdev_exposed;
> > };
> >
> > /* Header for each sample to user space via dev interface */
> > @@ -746,11 +750,159 @@ static void hid_sensor_custom_dev_if_remove(struct hid_sensor_custom
> >
> > }
> >
> > +/*
> > + * use sensors luid which is defined in FW, such as ISH,
> > + * to identify sensor.
> > + */
>
> const?
yes, it shoud be const.
>
> > +static char *known_sensor_luid[] = { "020B000000000000" };
> > +
> > +static int get_luid_table_index(unsigned char *usage_str)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(known_sensor_luid); i++) {
> > + if (!strncmp(usage_str, known_sensor_luid[i],
> > + strlen(known_sensor_luid[i])))
> > + return i;
> > + }
> > +
> > + return -1;
> > +}
> > +
> > +static int get_known_custom_sensor_index(struct hid_sensor_hub_device *hsdev)
> > +{
> > + struct hid_sensor_hub_attribute_info sensor_manufacturer = { 0 };
> > + struct hid_sensor_hub_attribute_info sensor_luid_info = { 0 };
> > + int report_size;
> > + int ret;
> > + u16 *w_buf;
> > + int w_buf_len;
> > + char *buf;
> > + int buf_len;
> > + int i;
> > + int index;
> > +
> > + w_buf_len = sizeof(u16) * HID_CUSTOM_MAX_FEATURE_BYTES;
> > + buf_len = sizeof(char) * HID_CUSTOM_MAX_FEATURE_BYTES;
> Given these are compile time values, these two could just go
> directly above with no loss of readability.
>
> int w_buf_len = siezof(u16)...
got it
>
> > + w_buf = kzalloc(w_buf_len, GFP_KERNEL);
> > + if (!w_buf)
> > + return -1;
>
> Better to return meaningful error values and if the error
> isn't just 'didn't find it' - probably -ENODEV and we should check that
> was the cause of the problem at the call site for this function.
> If it was a memory allocation error we should quit out instead of trying
> something else.
agree, will use -ENODEV, when "didn't find it"; use -ENOMEM when alloc failed.
>
> > +
> > + buf = kzalloc(buf_len, GFP_KERNEL);
> > + if (!buf) {
> > + kfree(w_buf);
> Given we have error handling for this below, better to be consistent
> and use a goto + an additional error label for htis case.
ok, will add additional error label to make it consistent.
>
> > + return -1;
> > + }
> > +
> > + /* get manufacturer info */
> > + ret = sensor_hub_input_get_attribute_info(
> > + hsdev, HID_FEATURE_REPORT, hsdev->usage,
> > + HID_USAGE_SENSOR_PROP_MANUFACTURER, &sensor_manufacturer);
> > + if (ret < 0)
>
> From HID point of view, is that allowed to fail? Probably best to add
> a comment to say if it is or isn't.
> I'd like to be able to read this code and know which of these error paths
> just means we don't have a matching sensor.
This is error checking of sensor_hub_input_get_attribute_info. If error, will
return the return value of sensor_hub_input_get_attribute_info in next version
patch.
>
> > + goto err_out;
> > +
> > + report_size =
> > + sensor_hub_get_feature(hsdev, sensor_manufacturer.report_id,
> > + sensor_manufacturer.index, w_buf_len,
> > + w_buf);
> > + if (report_size <= 0) {
> > + hid_err(hsdev->hdev,
> > + "Failed to get sensor manufacturer info %d\n",
> > + report_size);
> > + goto err_out;
> > + }
> > +
> > + /* convert from wide char to char */
> > + for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
> > + buf[i] = (char)w_buf[i];
> > +
> > + /* ensure it's ISH sensor */
> > + if (strncmp(buf, "INTEL", strlen("INTEL")))
> > + goto err_out;
> > +
> > + memset(w_buf, 0, w_buf_len);
> > + memset(buf, 0, buf_len);
> > +
> > + /* get real usage id */
> > + ret = sensor_hub_input_get_attribute_info(
> > + hsdev, HID_FEATURE_REPORT, hsdev->usage,
> > + HID_USAGE_SENSOR_PROP_SERIAL_NUM, &sensor_luid_info);
> > + if (ret < 0)
> > + goto err_out;
> > +
> > + report_size = sensor_hub_get_feature(hsdev, sensor_luid_info.report_id,
> > + sensor_luid_info.index, w_buf_len,
> > + w_buf);
> > + if (report_size <= 0) {
> > + hid_err(hsdev->hdev, "Failed to get real usage info %d\n",
> > + report_size);
> > + goto err_out;
> > + }
> > +
> > + /* convert from wide char to char */
> > + for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
> > + buf[i] = (char)w_buf[i];
> > +
> > + if (strlen(buf) != strlen(known_sensor_luid[0]) + 5) {
> > + hid_err(hsdev->hdev,
> > + "%s luid length not match %zu != (%zu + 5)\n", __func__,
> > + strlen(buf), strlen(known_sensor_luid[0]));
> > + goto err_out;
> > + }
> > +
> > + /* get table index with luid (not matching 'LUID: ' in luid) */
> > + index = get_luid_table_index(&buf[5]);
>
> Nicer to share the code block here with the error / unwind path below.
> Particular as index might be -1 and hence an error.
ok, will try to share it with error out.
>
> > + kfree(w_buf);
> > + kfree(buf);
> > + return index;
> > +
> > +err_out:
> > + kfree(w_buf);
> > + kfree(buf);
> > + return -1;
> > +}
> > +
> > +static struct platform_device *
> > +register_platform_device(struct platform_device *pdev,
>
> Function needs a prefix as that sounds very generic.
> When I saw it below, I assumed it was a generic call not
> one in this file.
got it.
>
> > + struct hid_sensor_hub_device *hsdev, int index)
> > +{
> > + char real_usage[HID_SENSOR_USAGE_LENGTH] = { 0 };
> > + struct platform_device *custom_pdev;
> > + const char *dev_name;
> > + char *c;
> > + int ret;
> > +
> > + /* copy real usage id */
> > + memcpy(real_usage, known_sensor_luid[index], 4);
> > +
> > + /* usage id are all lowcase */
> > + for (c = real_usage; *c != '\0'; c++)
> > + *c = tolower(*c);
> > +
> > + /* HID-SENSOR-INT-REAL_USAGE_ID */
> > + dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s", real_usage);
> > + if (!dev_name)
> > + return NULL;
> > +
> > + custom_pdev = platform_device_register_data(pdev->dev.parent, dev_name,
> > + PLATFORM_DEVID_NONE, hsdev,
> > + sizeof(*hsdev));
> > + kfree(dev_name);
> > + ret = PTR_ERR_OR_ZERO(custom_pdev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "platform_device_register_data failed ret:%d\n", ret);
> > + return NULL;
> > + }
> > +
> > + return custom_pdev;
> > +}
> > +
> > static int hid_sensor_custom_probe(struct platform_device *pdev)
> > {
> > struct hid_sensor_custom *sensor_inst;
> > struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> > int ret;
> > + int index;
> >
> > sensor_inst = devm_kzalloc(&pdev->dev, sizeof(*sensor_inst),
> > GFP_KERNEL);
> > @@ -764,6 +916,19 @@ static int hid_sensor_custom_probe(struct platform_device *pdev)
> > sensor_inst->pdev = pdev;
> > mutex_init(&sensor_inst->mutex);
> > platform_set_drvdata(pdev, sensor_inst);
> > +
> > + index = get_known_custom_sensor_index(hsdev);
> > + if (index >= 0) {
> > + sensor_inst->custom_pdev =
> > + register_platform_device(pdev, hsdev, index);
> > + if (sensor_inst->custom_pdev) {
> > + sensor_inst->custom_pdev_exposed = true;
> > + return 0;
> > + }
> > +
> > + dev_err(&pdev->dev, "register_platform_device failed\n");
>
> This feels like somewhat odd logic. We aren't looking at a fallback for
> something that is expected to fail so it doesn't make sense to carry
> on.
agree, will change to: if register platform failed, then return error code.
>
>
> > + }
> > +
> > ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > &sensor_inst->callbacks);
> > if (ret < 0) {
> > @@ -802,6 +967,11 @@ static int hid_sensor_custom_remove(struct platform_device *pdev)
> > struct hid_sensor_custom *sensor_inst = platform_get_drvdata(pdev);
> > struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> >
> > + if (sensor_inst->custom_pdev_exposed) {
> > + platform_device_unregister(sensor_inst->custom_pdev);
> > + return 0;
> > + }
> > +
> > hid_sensor_custom_dev_if_remove(sensor_inst);
> > hid_sensor_custom_remove_attributes(sensor_inst);
> > sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> > diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> > index 530c09f3e64a..46db3056f04b 100644
> > --- a/include/linux/hid-sensor-ids.h
> > +++ b/include/linux/hid-sensor-ids.h
> > @@ -128,6 +128,10 @@
> > #define HID_USAGE_SENSOR_UNITS_DEGREES_PER_SECOND 0x15
> >
> > /* Common selectors */
> > +#define HID_USAGE_SENSOR_PROP_DESC 0x200300
> > +#define HID_USAGE_SENSOR_PROP_FRIENDLY_NAME 0x200301
> > +#define HID_USAGE_SENSOR_PROP_SERIAL_NUM 0x200307
> > +#define HID_USAGE_SENSOR_PROP_MANUFACTURER 0x200305
> > #define HID_USAGE_SENSOR_PROP_REPORT_INTERVAL 0x20030E
> > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS 0x20030F
> > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_RANGE_PCT 0x200310
> > @@ -159,4 +163,39 @@
> > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x200840
> > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x200841
> >
> > +/* Custom Sensor (2000e1) */
> > +#define HID_USAGE_SENSOR_HINGE 0x20020B
> > +#define HID_USAGE_SENSOR_DATA_FIELD_LOCATION 0x200400
> > +#define HID_USAGE_SENSOR_DATA_FIELE_TIME_SINCE_SYS_BOOT 0x20052B
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_USAGE 0x200541
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE 0x200543
> Given these are all defined in a block could we use a macro?
> HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) 0x200543 + (x)
>
> perhaps?
>
> I'm not sure what the preferred convention is in this file.
If using HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x), we should give a range to x, like (1<x<28).
How to ensure the x is in the range? It can be an issue when someone using x out of the range.
Thanks
Xiang
>
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 0x200544
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2 0x200545
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3 0x200546
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_4 0x200547
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_5 0x200548
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_6 0x200549
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_7 0x20054A
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_8 0x20054B
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_9 0x20054C
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_10 0x20054D
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_11 0x20054E
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_12 0x20054F
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_13 0x200550
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_14 0x200551
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_15 0x200552
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_16 0x200553
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_17 0x200554
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_18 0x200555
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_19 0x200556
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_20 0x200557
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_21 0x200558
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_22 0x200559
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_23 0x20055A
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_24 0x20055B
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_25 0x20055C
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_26 0x20055D
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_27 0x20055E
> > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_28 0x20055F
> > +
> > #endif
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support
2020-11-24 10:29 ` Ye, Xiang
@ 2020-11-24 11:32 ` Jonathan Cameron
2020-11-25 2:27 ` Ye, Xiang
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-24 11:32 UTC (permalink / raw)
To: Ye, Xiang
Cc: Jonathan Cameron, jikos, srinivas.pandruvada, linux-input,
linux-iio, linux-kernel
Hi
...
> > > sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> > > diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> > > index 530c09f3e64a..46db3056f04b 100644
> > > --- a/include/linux/hid-sensor-ids.h
> > > +++ b/include/linux/hid-sensor-ids.h
> > > @@ -128,6 +128,10 @@
> > > #define HID_USAGE_SENSOR_UNITS_DEGREES_PER_SECOND 0x15
> > >
> > > /* Common selectors */
> > > +#define HID_USAGE_SENSOR_PROP_DESC 0x200300
> > > +#define HID_USAGE_SENSOR_PROP_FRIENDLY_NAME 0x200301
> > > +#define HID_USAGE_SENSOR_PROP_SERIAL_NUM 0x200307
> > > +#define HID_USAGE_SENSOR_PROP_MANUFACTURER 0x200305
> > > #define HID_USAGE_SENSOR_PROP_REPORT_INTERVAL 0x20030E
> > > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS 0x20030F
> > > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_RANGE_PCT 0x200310
> > > @@ -159,4 +163,39 @@
> > > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x200840
> > > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x200841
> > >
> > > +/* Custom Sensor (2000e1) */
> > > +#define HID_USAGE_SENSOR_HINGE 0x20020B
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_LOCATION 0x200400
> > > +#define HID_USAGE_SENSOR_DATA_FIELE_TIME_SINCE_SYS_BOOT 0x20052B
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_USAGE 0x200541
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE 0x200543
> > Given these are all defined in a block could we use a macro?
> > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) 0x200543 + (x)
> >
> > perhaps?
> >
> > I'm not sure what the preferred convention is in this file.
> If using HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x), we should give a range to x, like (1<x<28).
> How to ensure the x is in the range? It can be an issue when someone using x out of the range.
It can be done via build time checking.
https://elixir.bootlin.com/linux/latest/source/include/linux/build_bug.h#L49
Normally we wouldn't bother and would rely on review to pick up on this but
I'd have no problem with a paranoid check in the macro. Particularly as 28 isn't
exactly and obvious number to support!
>
> Thanks
> Xiang
> >
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 0x200544
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2 0x200545
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3 0x200546
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_4 0x200547
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_5 0x200548
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_6 0x200549
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_7 0x20054A
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_8 0x20054B
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_9 0x20054C
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_10 0x20054D
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_11 0x20054E
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_12 0x20054F
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_13 0x200550
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_14 0x200551
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_15 0x200552
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_16 0x200553
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_17 0x200554
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_18 0x200555
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_19 0x200556
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_20 0x200557
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_21 0x200558
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_22 0x200559
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_23 0x20055A
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_24 0x20055B
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_25 0x20055C
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_26 0x20055D
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_27 0x20055E
> > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_28 0x20055F
> > > +
> > > #endif
> >
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-24 3:30 ` Ye, Xiang
@ 2020-11-24 11:36 ` Jonathan Cameron
2020-11-25 3:24 ` Ye, Xiang
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-24 11:36 UTC (permalink / raw)
To: Ye, Xiang
Cc: Jonathan Cameron, srinivas.pandruvada, jikos, linux-input,
linux-iio, linux-kernel, even.xu
On Tue, 24 Nov 2020 11:30:50 +0800
"Ye, Xiang" <xiang.ye@intel.com> wrote:
> On Sun, Nov 22, 2020 at 04:50:47PM +0000, Jonathan Cameron wrote:
> > On Sun, 22 Nov 2020 15:51:18 +0000
> > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> >
> > > On Sun, 2020-11-22 at 14:14 +0000, Jonathan Cameron wrote:
> > > > On Sun, 22 Nov 2020 02:14:16 +0000
> > > > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> > > >
> > > > > On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> > > > > > On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > > > > > > On Thu, 19 Nov 2020 18:03:31 +0800
> > > > > > > Ye Xiang <xiang.ye@intel.com> wrote:
> > > > > > >
> > > > > > > > The Hinge sensor is a common custom sensor on laptops. It
> > > > > > > > calculates
> > > > > > > > the angle between the lid (screen) and the base (keyboard).
> > > > > > > > In
> > > > > > > > addition,
> > > > > > > > it also exposes screen and the keyboard angels with respect
> > > > > > > > to
> > > > > > > > the
> > > > > > > > ground. Applications can easily get laptop's status in space
> > > > > > > > through
> > > > > > > > this sensor, in order to display appropriate user
> > > > > > > > interface.
> > > > > > >
> > > > > > > I'm a little unclear on why the 3 axes aren't treated as a
> > > > > > > single
> > > > > > > sensor.
> > > > > > > You seem to always grab the 3 together or am I missing
> > > > > > > something?
> > > > > > >
> > > > > > > That will greatly simplify things and get rid of the need to
> > > > > > > have
> > > > > > > a shared trigger with the problems that causes in the previous
> > > > > > > patch.
> > > > > >
> > > > > > They are not three axes, they are independent. Xiang did try
> > > > > > adding
> > > > > > x,
> > > > > > y and z component to represent x as hinge, y as keyboard and z as
> > > > > > lid.
> > > > > > But I was not convinced.
> > > > > > The problem is that then what will be sysfs interface? They are
> > > > > > really
> > > > > > a three sensors. Or we create new interface to call
> > > > > > in_angl_raw_keyboard
> > > > > > in_angl_raw_screen
> > > > > > in_angl_raw_lid.
> > > > > >
> > > > > You seem to indicate this is possible now some new "label" patch.
> > > > > Is this the patch?
> > > > > commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
> > > > > Author: Phil Reid <preid@electromag.com.au>
> > > > > Date: Thu Sep 19 22:36:08 2019 +0800
> > > >
> > > > Nope, this one
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1d4ef9b39ebecca827642b8897d2d79ea2026682
> > > >
> > > > The one above adds a per device label which wouldn't be much use for
> > > > your
> > > > case, but this one adds a per channel label.
> > > >
> > > > Done via a read_label callback.
> > > >
> > > > Here you'd want to use indexed channels so something like.
> > > >
> > > > in_angl0_raw
> > > > in_angl1_raw
> > > > in_angl2_raw
> > > >
> > > > and
> > > >
> > > > in_angl0_label = keyboard
> > > > in_angl1_label = screen
> > > > in_angl2_label = lid
> > >
> > > Thanks Jonathan. This will make the job easier.
> > > Xiang,
> > > You can use this method. Then you will not need other changes except
> > > patch 1/4.
> > > Also add a documentation patch to explain the mapping.
> >
> > Ah. So we have a slightly problem with sysfs ABI docs at the moment.
> > The scripts that auto generate the html and similar docs from them
> > don't cope with the same name of attribute in multiple documentation
> > files.
> >
> > https://lore.kernel.org/linux-iio/20201110082658.2edc1ab5@coco.lan/
> >
> > The upshot being we can't have more specific docs for a particular
> > part that match up with the generic docs. That will apply in this
> > case.
> >
> > So for now, our solution is to put it in the main docs, but provide
> > a subsection in there talking about more specific constraints for
> > a particular device.
> >
> > Note I haven't actually proposed any fixes for this problem yet so
> > you get to do the first one ;)
> >
> > Thanks,
> >
> > Jonathan
> @Srinivas
> Yes, I will try this indexed channel and label based method.
>
> @Jonathan
> So, I need to add in_angl0_raw, in_angl1_raw, in_angl2_raw and in_angl0_label,
> in_angl1_label,in_angl2_label description in sysfs-bus-iio. such as
>
> What: /sys/bus/iio/devices/iio:deviceX/in_angl0_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_angl1_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_angl2_raw
You can use a wild card which in this case would give you one line that says
What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
> KernelVersion: 5.12
> Contact: linux-iio@vger.kernel.org
> Description:
> Angle of rotation. Units after application of scale and offset
> are radians.
>
> What: /sys/bus/iio/devices/iio:deviceX/in_angl0_label
> What: /sys/bus/iio/devices/iio:deviceX/in_angl1_label
> What: /sys/bus/iio/devices/iio:deviceX/in_angl2_label
As above, wild card is fine.
> KernelVersion: 5.12
> Contact: linux-iio@vger.kernel.org
> Description:
> Optional symbolic label to a device channel.
I'd add something device specific here even though it's in the main docs.
For intel,hid-hinge values are: hinge, keyboard, screen
>
>
> Am i right?
Almost with those tweaks above to give a bit more info and keep it a little
more compact.
Thanks,
Jonathan
>
> >
> >
> >
> > >
> > > Thanks,
> > > Srinivas
> > >
> > > >
> > > >
> > > >
> > > > > Ideally, one iio device here is much easy to manage as other HID
> > > > > sensors. If we can add something other that "x", "y" and "z"
> > > > > component.
> > > >
> > > > Agreed, using axes makes no real sense here and extended_name is
> > > > just a mess from ABI point of view. Trying to solve this was the
> > > > reason we added the _label interface.
> > > >
> > > > Jonathan
> > > >
> > > >
> > > > > Thanks,
> > > > > Srinivas
> > > > >
> > > > > > Thanks,
> > > > > > Srinivas
> > > > > >
> > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Jonathan
> > > > > > >
> > > > > > > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > > > > > > ---
> > > > > > > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > > > > > > drivers/iio/position/Kconfig | 16 +
> > > > > > > > drivers/iio/position/Makefile | 3 +
> > > > > > > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > > > > > > ++++++++++++++++++
> > > > > > >
> > > > > > > Given it's custom probably needs a more specific name. I guess
> > > > > > > hid-sensor-custom-intel-hinge.c might be safe?
> > > > > > >
> > > > > > > Same for other places we need names in here.
> > > > > > >
> > > > > > > > 4 files changed, 433 insertions(+)
> > > > > > > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > > > > > > hinge.c
> > > > > > > >
> > > > > > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > > > > > > attributes.c
> > > > > > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > > index 442ff787f7af..5b822a4298a0 100644
> > > > > > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > > @@ -71,6 +71,8 @@ static struct {
> > > > > > > > {HID_USAGE_SENSOR_TEMPERATURE,
> > > > > > > > HID_USAGE_SENSOR_UNITS_DEGREES,
> > > > > > > > 1000, 0},
> > > > > > > >
> > > > > > > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > > > > > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > > > > > > + {HID_USAGE_SENSOR_HINGE,
> > > > > > > > HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > > > > > > 17453293},
> > > > > > > > };
> > > > > > > >
> > > > > > > > static void simple_div(int dividend, int divisor, int
> > > > > > > > *whole,
> > > > > > > > diff --git a/drivers/iio/position/Kconfig
> > > > > > > > b/drivers/iio/position/Kconfig
> > > > > > > > index eda67f008c5b..0346f6f2b422 100644
> > > > > > > > --- a/drivers/iio/position/Kconfig
> > > > > > > > +++ b/drivers/iio/position/Kconfig
> > > > > > > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > > > > > > To compile this driver as a module, choose M here:
> > > > > > > > the module
> > > > > > > > will be called iqs624-pos.
> > > > > > > >
> > > > > > > > +config HID_SENSOR_CUSTOM_HINGE
> > > > > > > > + depends on HID_SENSOR_HUB
> > > > > > > > + select IIO_BUFFER
> > > > > > > > + select IIO_TRIGGERED_BUFFER
> > > > > > > > + select HID_SENSOR_IIO_COMMON
> > > > > > > > + select HID_SENSOR_IIO_TRIGGER
> > > > > > > > + tristate "HID Hinge"
> > > > > > > > + help
> > > > > > > > + This sensor present three angles, hinge angel, screen
> > > > > > > > angles
> > > > > > > > + and keyboard angle respect to horizon (ground).
> > > > > > > > + Say yes here to build support for the HID SENSOR
> > > > > > > > CUSTOM
> > > > > > > > + HINGE.
> > > > > > >
> > > > > > > Capitalization is a bit odd looking. I'd drop it.
> > > > > > >
> > > > > > > > +
> > > > > > > > + To compile this driver as a module, choose M here:
> > > > > > > > the
> > > > > > > > + module will be called hid-sensor-custom-hinge.
> > > > > > > > +
> > > > > > > > endmenu
> > > > > > > > diff --git a/drivers/iio/position/Makefile
> > > > > > > > b/drivers/iio/position/Makefile
> > > > > > > > index 3cbe7a734352..7a6225977a01 100644
> > > > > > > > --- a/drivers/iio/position/Makefile
> > > > > > > > +++ b/drivers/iio/position/Makefile
> > > > > > > > @@ -5,3 +5,6 @@
> > > > > > > > # When adding new entries keep the list in alphabetical
> > > > > > > > order
> > > > > > > >
> > > > > > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > > > > > +
> > > > > > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > > > > > > hinge.o
> > > > > > >
> > > > > > > Alphabetical order preferred.
> > > > > > >
> > > > > > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-
> > > > > > > > sensors
> > > > > > >
> > > > > > > Why?
> > > > > > >
> > > > > > > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..a91b333f36fa
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > > @@ -0,0 +1,412 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > +/*
> > > > > > > > + * HID Sensors Driver
> > > > > > > > + * Copyright (c) 2020, Intel Corporation.
> > > > > > > > + */
> > > > > > > > +#include <linux/hid-sensor-hub.h>
> > > > > > > > +#include <linux/iio/buffer.h>
> > > > > > > > +#include <linux/iio/iio.h>
> > > > > > > > +#include <linux/platform_device.h>
> > > > > > > > +
> > > > > > > > +#include "hid-sensor-trigger.h"
> > > > > > > > +
> > > > > > > > +/* Channel definitions */
> > > > > > > > +static const struct iio_chan_spec hinge_channels[] = {
> > > > > > > > + { .type = IIO_ANGL,
> > > > > > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > > > > > > + .info_mask_shared_by_type =
> > > > > > > > + BIT(IIO_CHAN_INFO_OFFSET) |
> > > > > > > > BIT(IIO_CHAN_INFO_SCALE)
> > > > > > > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > > > > > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > > > > > > + .scan_type.realbits = 16,
> > > > > > > > + .scan_type.storagebits = 32,
> > > > > > >
> > > > > > > It a bit odd to see a single channel that is 16 bits inside a
> > > > > > > 32
> > > > > > > bit
> > > > > > > with
> > > > > > > no shift or similar. Why not just pack it into 16 bits?
> > > > > > >
> > > > > > > > + .scan_type.sign = 's',
> > > > > > > > + .scan_index = 0 },
> > > > > > > > +
> > > > > > > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +struct hinge_state {
> > > > > > > > + struct iio_dev *indio_dev;
> > > > > > > > + struct hid_sensor_hub_attribute_info hinge;
> > > > > > > > + /* Reserve for 1 channel + pading + timestamp */
> > > > > > > > + u32 hinge_val[1 + 3];
> > > > > > >
> > > > > > > __aligned(8)
> > > > > > >
> > > > > > > see below for requirements on this.
> > > > > > > Perhaps better to use
> > > > > > >
> > > > > > > struct hinge_scan {
> > > > > > > u32 val;
> > > > > > > s64 timestamp __aligned(8); // Note this is
> > > > > > > needed for
> > > > > > > x86_32
> > > > > > > } scan;
> > > > > > >
> > > > > > > > + int scale_pre_decml;
> > > > > > > > + int scale_post_decml;
> > > > > > > > + int scale_precision;
> > > > > > > > + int value_offset;
> > > > > > > > + int64_t timestamp;
> > > > > > > > + u32 hinge_address;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +#define IIO_DEV_NUM 3
> > > > > > >
> > > > > > > That needs a prefix to make it clear it's not a generic
> > > > > > > constant
> > > > > > > but is specific to this driver.
> > > > > > >
> > > > > > > > +
> > > > > > > > +struct hinge_group {
> > > > > > > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > > > > > > + struct hid_sensor_hub_callbacks callbacks;
> > > > > > > > + struct hid_sensor_common common_attributes;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +static struct hinge_group *hg_group;
> > > > > > >
> > > > > > > We shouldn't see globals like this. Please figure out how to
> > > > > > > avoid
> > > > > > > it.
> > > > > > >
> > > > > > > > +
> > > > > > > > +/* Channel read_raw handler */
> > > > > > > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > > > > > > + struct iio_chan_spec const *chan, int
> > > > > > > > *val,
> > > > > > > > int *val2,
> > > > > > > > + long mask)
> > > > > > > > +{
> > > > > > > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > > > > > > + struct hid_sensor_hub_device *hsdev;
> > > > > > > > + int report_id = -1;
> > > > > > > > + int ret_type;
> > > > > > > > + s32 min;
> > > > > > > > +
> > > > > > > > + hsdev = hg_group->common_attributes.hsdev;
> > > > > > > > +
> > > > > > > > + *val = 0;
> > > > > > > > + *val2 = 0;
> > > > > > > > + switch (mask) {
> > > > > > > > + case IIO_CHAN_INFO_RAW:
> > > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > >common_attributes,
> > > > > > > > true);
> > > > > > > > + report_id = hg_state->hinge.report_id;
> > > > > > > > + min = hg_state->hinge.logical_minimum;
> > > > > > > > + if (report_id < 0) {
> > > > > > > > + *val = 0;
> > > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > > common_attributes,
> > > > > > > > + false);
> > > > > > > > + return -EINVAL;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + *val = sensor_hub_input_attr_get_raw_value(
> > > > > > > > + hg_group->common_attributes.hsdev,
> > > > > > > > hsdev-
> > > > > > > > > usage,
> > > > > > > > + hg_state->hinge_address, report_id,
> > > > > > > > SENSOR_HUB_SYNC,
> > > > > > > > + min < 0);
> > > > > > > > +
> > > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > >common_attributes,
> > > > > > > > false);
> > > > > > > > + ret_type = IIO_VAL_INT;
> > > > > > > > + break;
> > > > > > > > + case IIO_CHAN_INFO_SCALE:
> > > > > > > > + *val = hg_state->scale_pre_decml;
> > > > > > > > + *val2 = hg_state->scale_post_decml;
> > > > > > > > + ret_type = hg_state->scale_precision;
> > > > > > > > + break;
> > > > > > > > + case IIO_CHAN_INFO_OFFSET:
> > > > > > > > + *val = hg_state->value_offset;
> > > > > > > > + ret_type = IIO_VAL_INT;
> > > > > > > > + break;
> > > > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > > > + ret_type = hid_sensor_read_samp_freq_value(
> > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > val2);
> > > > > > > > + break;
> > > > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > val2);
> > > > > > > > + break;
> > > > > > > > + default:
> > > > > > > > + ret_type = -EINVAL;
> > > > > > > > + break;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return ret_type;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/* Channel write_raw handler */
> > > > > > > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > > > > > > + struct iio_chan_spec const *chan,
> > > > > > > > int val,
> > > > > > > > int val2,
> > > > > > > > + long mask)
> > > > > > > > +{
> > > > > > > > + int ret;
> > > > > > > > +
> > > > > > > > + switch (mask) {
> > > > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > > > + ret = hid_sensor_write_samp_freq_value(
> > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > val2);
> > > > > > > > + break;
> > > > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > > > + ret = hid_sensor_write_raw_hyst_value(
> > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > val2);
> > > > > > > > +
> > > > > > > > + break;
> > > > > > > > + default:
> > > > > > > > + ret = -EINVAL;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static const struct iio_info hinge_info = {
> > > > > > > > + .read_raw = &hinge_read_raw,
> > > > > > > > + .write_raw = &hinge_write_raw,
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * Function to push data to buffer;
> > > > > > > > + * wrapper added for symmetry with other hid-sensor drivers
> > > > > > > > + */
> > > > > > > > +static void hid_sensor_push_data(struct iio_dev *indio_dev,
> > > > > > > > void
> > > > > > > > *data, int len,
> > > > > > >
> > > > > > > This doesn't seem to be generic, so don't name it as such.
> > > > > > >
> > > > > > > > + int64_t timestamp)
> > > > > > > > +{
> > > > > > > > + iio_push_to_buffers_with_timestamp(indio_dev, data,
> > > > > > > > timestamp);
> > > > > > > I hope that data buffer obeys the various rules needed by (and
> > > > > > > admittedly
> > > > > > > not that well documented) iio_push_to_buffers_with_timestamp()
> > > > > > >
> > > > > > > 1. Needs to be 8 byte aligned.
> > > > > > > 2. Needs to have space for an aligned 8 byte timestamp at the
> > > > > > > end.
> > > > > > >
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * Callback handler to send event after all samples are
> > > > > > > > received
> > > > > > > > + * and captured.
> > > > > > > > + */
> > > > > > > > +static int hinge_proc_event(struct hid_sensor_hub_device
> > > > > > > > *hsdev,
> > > > > > > > + unsigned int usage_id, void *priv)
> > > > > > > > +{
> > > > > > > > + int i;
> > > > > > > > +
> > > > > > > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > > > > > > If we push for all sensors together, better to have
> > > > > > > this as a single iio_device with 3 channels.
> > > > > > >
> > > > > > > Use the channel labels (just added to IIO) to identify which is
> > > > > > > which.
> > > > > > >
> > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > + struct iio_dev *indio_dev;
> > > > > > > > +
> > > > > > > > + hg_state = hg_group->hg_states[i];
> > > > > > > > + indio_dev = hg_state->indio_dev;
> > > > > > > > +
> > > > > > > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > > > > > > scan_bytes:%d\n",
> > > > > > > > + __func__, hg_state->timestamp,
> > > > > > > > indio_dev-
> > > > > > > > > scan_bytes);
> > > > > > > > +
> > > > > > > > + if (!hg_state->timestamp)
> > > > > > > > + hg_state->timestamp =
> > > > > > > > iio_get_time_ns(indio_dev);
> > > > > > > > +
> > > > > > > > + hid_sensor_push_data(indio_dev, hg_state-
> > > > > > > > >hinge_val,
> > > > > > > > + sizeof(hg_state-
> > > > > > > > >hinge_val),
> > > > > > > > + hg_state->timestamp);
> > > > > > > > +
> > > > > > > > + hg_state->timestamp = 0;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/* Capture samples in local storage */
> > > > > > > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > > > > > > *hsdev,
> > > > > > > > + unsigned int usage_id, size_t
> > > > > > > > raw_len,
> > > > > > > > + char *raw_data, void *priv)
> > > > > > > > +{
> > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > + int offset;
> > > > > > > > + int ret = -EINVAL;
> > > > > > > > + int i;
> > > > > > > > +
> > > > > > > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > > > + hg_group->hg_states[i]->timestamp =
> > > > > > >
> > > > > > > This rather implies all the data is captured together... If so
> > > > > > > single
> > > > > > > iio_device may make more sense.
> > > > > > >
> > > > > > > > + hid_sensor_convert_timestamp(
> > > > > > > > + &hg_group-
> > > > > > > > >common_attributes,
> > > > > > > > + *(int64_t *)raw_data);
> > > > > > > > + return 0;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + switch (usage_id) {
> > > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > > > > > > + offset = usage_id -
> > > > > > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > > > > > > + hg_state = hg_group->hg_states[offset];
> > > > > > > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > > > > > > + ret = 0;
> > > > > > >
> > > > > > > return 0;
> > > > > > >
> > > > > > > > + break;
> > > > > > > > + default:
> > > > > > > return -EINVAL;
> > > > > > > > + break;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/* Parse report which is specific to an usage id */
> > > > > > > > +static int hinge_parse_report(struct platform_device *pdev,
> > > > > > > > + struct hid_sensor_hub_device
> > > > > > > > *hsdev,
> > > > > > > > + unsigned int usage_id, unsigned
> > > > > > > > int
> > > > > > > > attr_usage_id,
> > > > > > > > + struct hinge_state *st)
> > > > > > > > +{
> > > > > > > > + int ret;
> > > > > > > > +
> > > > > > > > + ret = sensor_hub_input_get_attribute_info(
> > > > > > > > + hsdev, HID_INPUT_REPORT, usage_id,
> > > > > > > > attr_usage_id, &st-
> > > > > > > > > hinge);
> > > > > > > > + if (ret < 0)
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > + st->hinge_address = attr_usage_id;
> > > > > > > > + st->scale_precision =
> > > > > > > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE,
> > > > > > > > &st-
> > > > > > > > > hinge,
> > > > > > > > + &st->scale_pre_decml,
> > > > > > > > + &st->scale_post_decml);
> > > > > > > > +
> > > > > > > > + /* Set Sensitivity field ids, when there is no
> > > > > > > > individual
> > > > > > > > modifier */
> > > > > > > > + if (hg_group->common_attributes.sensitivity.index < 0)
> > > > > > > > {
> > > > > > > > + sensor_hub_input_get_attribute_info(
> > > > > > > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > > > > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > > > > > IVITY_AB
> > > > > > > > S |
> > > > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUS
> > > > > > > > TOM_VALU
> > > > > > > > E_1,
> > > > > > > > + &hg_group-
> > > > > > > > >common_attributes.sensitivity);
> > > > > > > > + dev_dbg(&pdev->dev, "Sensitivity index:report
> > > > > > > > %d:%d\n",
> > > > > > > > + hg_group-
> > > > > > > > >common_attributes.sensitivity.index,
> > > > > > > > + hg_group-
> > > > > > > > > common_attributes.sensitivity.report_id);
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/* Function to initialize the processing for usage id */
> > > > > > > > +static int hinge_add_iio_device(struct platform_device
> > > > > > > > *pdev,
> > > > > > > > int
> > > > > > > > index,
> > > > > > > > + const char *name, struct
> > > > > > > > hinge_state
> > > > > > > > **st)
> > > > > > > > +{
> > > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > > >dev.platform_data;
> > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > + struct iio_dev *indio_dev;
> > > > > > > > + int ret;
> > > > > > > > +
> > > > > > > > + indio_dev =
> > > > > > > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > > > > > > hinge_state));
> > > > > > >
> > > > > > > sizeof (*hg_state) preferred.
> > > > > > >
> > > > > > > > + if (indio_dev == NULL)
> > > > > > > > + return -ENOMEM;
> > > > > > > > +
> > > > > > > > + hg_state = iio_priv(indio_dev);
> > > > > > > > + hg_state->indio_dev = indio_dev;
> > > > > > > > +
> > > > > > > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > > > > > > + indio_dev->channels =
> > > > > > > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > > > > > > GFP_KERNEL);
> > > > > > >
> > > > > > > I don't immediately see anything that is modifying channels. As
> > > > > > > such
> > > > > > > you
> > > > > > > should be able have it shared by all the instances.
> > > > > > >
> > > > > > > > + if (!indio_dev->channels)
> > > > > > > > + return -ENOMEM;
> > > > > > > > +
> > > > > > > > + ret = hinge_parse_report(
> > > > > > > > + pdev, hsdev, hsdev->usage,
> > > > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 +
> > > > > > > > index,
> > > > > > > > hg_state);
> > > > > > > > + if (ret) {
> > > > > > > > + dev_err(&pdev->dev, "failed to setup
> > > > > > > > attributes\n");
> > > > > > > > + goto error_free_dev_mem;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + indio_dev->dev.parent = &pdev->dev;
> > > > > > > > + indio_dev->info = &hinge_info;
> > > > > > > > + indio_dev->name = name;
> > > > > > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > > > > > +
> > > > > > > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > > > > > > + &hg_group-
> > > > > > > > >common_attributes);
> > > > > > > > + if (ret < 0) {
> > > > > > > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > > > > > > + goto error_free_dev_mem;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + ret = iio_device_register(indio_dev);
> > > > > > > > + if (ret) {
> > > > > > > > + dev_err(&pdev->dev, "device register
> > > > > > > > failed\n");
> > > > > > > > + goto error_remove_trigger;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + *st = hg_state;
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > +error_remove_trigger:
> > > > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > > > common_attributes);
> > > > > > > > +error_free_dev_mem:
> > > > > > > > + kfree(indio_dev->channels);
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > > > +static int hinge_remove_iio_device(struct platform_device
> > > > > > > > *pdev,
> > > > > > > > int index)
> > > > > > > > +{
> > > > > > > > + struct hinge_state *hg_state = hg_group-
> > > > > > > > >hg_states[index];
> > > > > > > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > > > > > > +
> > > > > > > > + iio_device_unregister(indio_dev);
> > > > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > > > common_attributes);
> > > > > > > > + kfree(indio_dev->channels);
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > > > > > > +{
> > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > > >dev.platform_data;
> > > > > > > > + static const char *const names[] = { "hinge", "screen",
> > > > > > > > "keyboard" };
> > > > > > > > + int ret;
> > > > > > > > + int i;
> > > > > > > > +
> > > > > > > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct
> > > > > > > > hinge_group),
> > > > > > > > + GFP_KERNEL);
> > > > > > >
> > > > > > > As mentioned above, I'd really not expect to see a global like
> > > > > > > this.
> > > > > > > Technically nothing stops there being more than one instance of
> > > > > > > this
> > > > > > > device on a platform (even if that would be a bit odd) + it's
> > > > > > > almost
> > > > > > > always cleaner to not use a global in the first place.
> > > > > > >
> > > > > > > > + if (!hg_group)
> > > > > > > > + return -ENOMEM;
> > > > > > > > +
> > > > > > > > + hg_group->common_attributes.hsdev = hsdev;
> > > > > > > > + hg_group->common_attributes.pdev = pdev;
> > > > > > > > +
> > > > > > > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev-
> > > > > > > > >usage,
> > > > > > > > + &hg_group-
> > > > > > > > > common_attributes);
> > > > > > > > + if (ret) {
> > > > > > > > + dev_err(&pdev->dev, "failed to setup common
> > > > > > > > attributes\n");
> > > > > > > > + return ret;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > > > > > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > > > > > > &hg_state);
> > > > > > > > + if (ret)
> > > > > > > > + goto err_probe;
> > > > > > > > +
> > > > > > > > + hg_group->hg_states[i] = hg_state;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + /* use the first iio device to do the PM */
> > > > > > > > + platform_set_drvdata(pdev, hg_group->hg_states[0]-
> > > > > > > > >indio_dev);
> > > > > > > > +
> > > > > > > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > > > > > > + hg_group->callbacks.capture_sample =
> > > > > > > > hinge_capture_sample;
> > > > > > > > + hg_group->callbacks.pdev = pdev;
> > > > > > > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > > > > > > + &hg_group-
> > > > > > > > >callbacks);
> > > > > > > > + if (ret < 0)
> > > > > > > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > +err_probe:
> > > > > > > > + for (i--; i >= 0; i--)
> > > > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > > > +
> > > > > > > > + return ret;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > > > > > > +{
> > > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > > >dev.platform_data;
> > > > > > > > + int i;
> > > > > > > > +
> > > > > > > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > > > > > > +
> > > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > > > > > > + {
> > > > > > > > + /* Format: HID-SENSOR-INT-
> > > > > > > > usage_id_in_hex_lowercase */
> > > > > > > > + .name = "HID-SENSOR-INT-020b",
> > > > > > > > + },
> > > > > > > > + { /* sentinel */ }
> > > > > > > > +};
> > > > > > > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > > > > > > +
> > > > > > > > +static struct platform_driver hid_hinge_platform_driver = {
> > > > > > > > + .id_table = hid_hinge_ids,
> > > > > > > > + .driver = {
> > > > > > > > + .name = KBUILD_MODNAME,
> > > > > > > > + .pm = &hid_sensor_pm_ops,
> > > > > > > > + },
> > > > > > > > + .probe = hid_hinge_probe,
> > > > > > > > + .remove = hid_hinge_remove,
> > > > > > > > +};
> > > > > > > > +module_platform_driver(hid_hinge_platform_driver);
> > > > > > > > +
> > > > > > > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > > > > > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > > > > > > +MODULE_LICENSE("GPL");
> >
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-24 6:43 ` Ye, Xiang
@ 2020-11-24 11:39 ` Jonathan Cameron
2020-11-25 2:39 ` Ye, Xiang
0 siblings, 1 reply; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-24 11:39 UTC (permalink / raw)
To: Ye, Xiang
Cc: Jonathan Cameron, jikos, srinivas.pandruvada, linux-input,
linux-iio, linux-kernel
> >
> > > +
> > > + To compile this driver as a module, choose M here: the
> > > + module will be called hid-sensor-custom-hinge.
> > > +
> > > endmenu
> > > diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
> > > index 3cbe7a734352..7a6225977a01 100644
> > > --- a/drivers/iio/position/Makefile
> > > +++ b/drivers/iio/position/Makefile
> > > @@ -5,3 +5,6 @@
> > > # When adding new entries keep the list in alphabetical order
> > >
> > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > +
> > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
> >
> > Alphabetical order preferred.
> >
> > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
> >
> > Why?
> hinge driver need to include #include "hid-sensor-trigger.h", if not using this cflag-y
> it should be #include "../common/hid-sensors/hid-sensor-trigger.h"
Even though that looks a bit ugly, I'd prefer that rather than having to realize we
were doing something not entirely obvious in the Makefile.
Thanks,
Jonathan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support
2020-11-24 11:32 ` Jonathan Cameron
@ 2020-11-25 2:27 ` Ye, Xiang
2020-11-28 13:29 ` Jonathan Cameron
0 siblings, 1 reply; 25+ messages in thread
From: Ye, Xiang @ 2020-11-25 2:27 UTC (permalink / raw)
To: Jonathan Cameron
Cc: jikos, jic23, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Tue, Nov 24, 2020 at 11:32:11AM +0000, Jonathan Cameron wrote:
> Hi
> ...
> > > > sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> > > > diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> > > > index 530c09f3e64a..46db3056f04b 100644
> > > > --- a/include/linux/hid-sensor-ids.h
> > > > +++ b/include/linux/hid-sensor-ids.h
> > > > @@ -128,6 +128,10 @@
> > > > #define HID_USAGE_SENSOR_UNITS_DEGREES_PER_SECOND 0x15
> > > >
> > > > /* Common selectors */
> > > > +#define HID_USAGE_SENSOR_PROP_DESC 0x200300
> > > > +#define HID_USAGE_SENSOR_PROP_FRIENDLY_NAME 0x200301
> > > > +#define HID_USAGE_SENSOR_PROP_SERIAL_NUM 0x200307
> > > > +#define HID_USAGE_SENSOR_PROP_MANUFACTURER 0x200305
> > > > #define HID_USAGE_SENSOR_PROP_REPORT_INTERVAL 0x20030E
> > > > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS 0x20030F
> > > > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_RANGE_PCT 0x200310
> > > > @@ -159,4 +163,39 @@
> > > > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x200840
> > > > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x200841
> > > >
> > > > +/* Custom Sensor (2000e1) */
> > > > +#define HID_USAGE_SENSOR_HINGE 0x20020B
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_LOCATION 0x200400
> > > > +#define HID_USAGE_SENSOR_DATA_FIELE_TIME_SINCE_SYS_BOOT 0x20052B
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_USAGE 0x200541
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE 0x200543
> > > Given these are all defined in a block could we use a macro?
> > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) 0x200543 + (x)
> > >
> > > perhaps?
> > >
> > > I'm not sure what the preferred convention is in this file.
> > If using HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x), we should give a range to x, like (1<x<28).
> > How to ensure the x is in the range? It can be an issue when someone using x out of the range.
>
> It can be done via build time checking.
> https://elixir.bootlin.com/linux/latest/source/include/linux/build_bug.h#L49
> Normally we wouldn't bother and would rely on review to pick up on this but
> I'd have no problem with a paranoid check in the macro. Particularly as 28 isn't
> exactly and obvious number to support!
Because HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE is used as case condition, we cannot use
Build_BUG_ON in the macro like below.
#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) \
({ \
BUILD_BUG_ON(x > 28); \
BUILD_BUG_ON(x < 0); \
(HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_BASE + (x)); \
})
I can use the define with a comments to declear the range of x.
#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_BASE 0x200543
/* Custom Sensor data 28=>x>=0 */
#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) \
(HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_BASE + (x))
Thanks
Ye, Xiang
>
> >
> > Thanks
> > Xiang
> > >
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 0x200544
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2 0x200545
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3 0x200546
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_4 0x200547
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_5 0x200548
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_6 0x200549
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_7 0x20054A
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_8 0x20054B
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_9 0x20054C
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_10 0x20054D
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_11 0x20054E
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_12 0x20054F
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_13 0x200550
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_14 0x200551
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_15 0x200552
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_16 0x200553
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_17 0x200554
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_18 0x200555
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_19 0x200556
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_20 0x200557
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_21 0x200558
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_22 0x200559
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_23 0x20055A
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_24 0x20055B
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_25 0x20055C
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_26 0x20055D
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_27 0x20055E
> > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_28 0x20055F
> > > > +
> > > > #endif
> > >
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-24 11:39 ` Jonathan Cameron
@ 2020-11-25 2:39 ` Ye, Xiang
0 siblings, 0 replies; 25+ messages in thread
From: Ye, Xiang @ 2020-11-25 2:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: jikos, jic23, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
Hi,
On Tue, Nov 24, 2020 at 11:39:51AM +0000, Jonathan Cameron wrote:
>
> > >
> > > > +
> > > > + To compile this driver as a module, choose M here: the
> > > > + module will be called hid-sensor-custom-hinge.
> > > > +
> > > > endmenu
> > > > diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
> > > > index 3cbe7a734352..7a6225977a01 100644
> > > > --- a/drivers/iio/position/Makefile
> > > > +++ b/drivers/iio/position/Makefile
> > > > @@ -5,3 +5,6 @@
> > > > # When adding new entries keep the list in alphabetical order
> > > >
> > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > +
> > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
> > >
> > > Alphabetical order preferred.
> > >
> > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-sensors
> > >
> > > Why?
> > hinge driver need to include #include "hid-sensor-trigger.h", if not using this cflag-y
> > it should be #include "../common/hid-sensors/hid-sensor-trigger.h"
>
> Even though that looks a bit ugly, I'd prefer that rather than having to realize we
> were doing something not entirely obvious in the Makefile.
Okay, will remove ccflags-y in the makefile
Thanks
Ye, Xiang
>
> Thanks,
>
> Jonathan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver
2020-11-24 11:36 ` Jonathan Cameron
@ 2020-11-25 3:24 ` Ye, Xiang
0 siblings, 0 replies; 25+ messages in thread
From: Ye, Xiang @ 2020-11-25 3:24 UTC (permalink / raw)
To: Jonathan Cameron
Cc: jikos, jic23, srinivas.pandruvada, linux-input, linux-iio, linux-kernel
On Tue, Nov 24, 2020 at 11:36:56AM +0000, Jonathan Cameron wrote:
> On Tue, 24 Nov 2020 11:30:50 +0800
> "Ye, Xiang" <xiang.ye@intel.com> wrote:
>
> > On Sun, Nov 22, 2020 at 04:50:47PM +0000, Jonathan Cameron wrote:
> > > On Sun, 22 Nov 2020 15:51:18 +0000
> > > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> > >
> > > > On Sun, 2020-11-22 at 14:14 +0000, Jonathan Cameron wrote:
> > > > > On Sun, 22 Nov 2020 02:14:16 +0000
> > > > > "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> wrote:
> > > > >
> > > > > > On Sat, 2020-11-21 at 17:46 -0800, Srinivas Pandruvada wrote:
> > > > > > > On Sat, 2020-11-21 at 17:56 +0000, Jonathan Cameron wrote:
> > > > > > > > On Thu, 19 Nov 2020 18:03:31 +0800
> > > > > > > > Ye Xiang <xiang.ye@intel.com> wrote:
> > > > > > > >
> > > > > > > > > The Hinge sensor is a common custom sensor on laptops. It
> > > > > > > > > calculates
> > > > > > > > > the angle between the lid (screen) and the base (keyboard).
> > > > > > > > > In
> > > > > > > > > addition,
> > > > > > > > > it also exposes screen and the keyboard angels with respect
> > > > > > > > > to
> > > > > > > > > the
> > > > > > > > > ground. Applications can easily get laptop's status in space
> > > > > > > > > through
> > > > > > > > > this sensor, in order to display appropriate user
> > > > > > > > > interface.
> > > > > > > >
> > > > > > > > I'm a little unclear on why the 3 axes aren't treated as a
> > > > > > > > single
> > > > > > > > sensor.
> > > > > > > > You seem to always grab the 3 together or am I missing
> > > > > > > > something?
> > > > > > > >
> > > > > > > > That will greatly simplify things and get rid of the need to
> > > > > > > > have
> > > > > > > > a shared trigger with the problems that causes in the previous
> > > > > > > > patch.
> > > > > > >
> > > > > > > They are not three axes, they are independent. Xiang did try
> > > > > > > adding
> > > > > > > x,
> > > > > > > y and z component to represent x as hinge, y as keyboard and z as
> > > > > > > lid.
> > > > > > > But I was not convinced.
> > > > > > > The problem is that then what will be sysfs interface? They are
> > > > > > > really
> > > > > > > a three sensors. Or we create new interface to call
> > > > > > > in_angl_raw_keyboard
> > > > > > > in_angl_raw_screen
> > > > > > > in_angl_raw_lid.
> > > > > > >
> > > > > > You seem to indicate this is possible now some new "label" patch.
> > > > > > Is this the patch?
> > > > > > commit 2c3d0c9ffd24d9b4c62c5dfb2104695a614be28c
> > > > > > Author: Phil Reid <preid@electromag.com.au>
> > > > > > Date: Thu Sep 19 22:36:08 2019 +0800
> > > > >
> > > > > Nope, this one
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1d4ef9b39ebecca827642b8897d2d79ea2026682
> > > > >
> > > > > The one above adds a per device label which wouldn't be much use for
> > > > > your
> > > > > case, but this one adds a per channel label.
> > > > >
> > > > > Done via a read_label callback.
> > > > >
> > > > > Here you'd want to use indexed channels so something like.
> > > > >
> > > > > in_angl0_raw
> > > > > in_angl1_raw
> > > > > in_angl2_raw
> > > > >
> > > > > and
> > > > >
> > > > > in_angl0_label = keyboard
> > > > > in_angl1_label = screen
> > > > > in_angl2_label = lid
> > > >
> > > > Thanks Jonathan. This will make the job easier.
> > > > Xiang,
> > > > You can use this method. Then you will not need other changes except
> > > > patch 1/4.
> > > > Also add a documentation patch to explain the mapping.
> > >
> > > Ah. So we have a slightly problem with sysfs ABI docs at the moment.
> > > The scripts that auto generate the html and similar docs from them
> > > don't cope with the same name of attribute in multiple documentation
> > > files.
> > >
> > > https://lore.kernel.org/linux-iio/20201110082658.2edc1ab5@coco.lan/
> > >
> > > The upshot being we can't have more specific docs for a particular
> > > part that match up with the generic docs. That will apply in this
> > > case.
> > >
> > > So for now, our solution is to put it in the main docs, but provide
> > > a subsection in there talking about more specific constraints for
> > > a particular device.
> > >
> > > Note I haven't actually proposed any fixes for this problem yet so
> > > you get to do the first one ;)
> > >
> > > Thanks,
> > >
> > > Jonathan
> > @Srinivas
> > Yes, I will try this indexed channel and label based method.
> >
> > @Jonathan
> > So, I need to add in_angl0_raw, in_angl1_raw, in_angl2_raw and in_angl0_label,
> > in_angl1_label,in_angl2_label description in sysfs-bus-iio. such as
> >
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl0_raw
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl1_raw
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl2_raw
> You can use a wild card which in this case would give you one line that says
>
> What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
Good idea, Wild card can reduce repetition, will adopt it.
>
> > KernelVersion: 5.12
> > Contact: linux-iio@vger.kernel.org
> > Description:
> > Angle of rotation. Units after application of scale and offset
> > are radians.
> >
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl0_label
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl1_label
> > What: /sys/bus/iio/devices/iio:deviceX/in_angl2_label
>
> As above, wild card is fine.
Ok.
>
> > KernelVersion: 5.12
> > Contact: linux-iio@vger.kernel.org
> > Description:
> > Optional symbolic label to a device channel.
> I'd add something device specific here even though it's in the main docs.
>
> For intel,hid-hinge values are: hinge, keyboard, screen
yes, add some detail fo intel hinge sensor
Optional symbolic label for channel Y.
For Intel hid hinge sensor, the label values are:
hinge, keyboard, screen. It means the three channels
each correspond respectively to hinge angle, keyboard angle,
and screen angle.
>
>
> >
> >
> > Am i right?
> Almost with those tweaks above to give a bit more info and keep it a little
> more compact.
>
> Thanks,
>
> Jonathan
yes, will revise the description according your advice. Thanks for review and comments
Thanks
Ye, Xiang
>
> >
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Srinivas
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > Ideally, one iio device here is much easy to manage as other HID
> > > > > > sensors. If we can add something other that "x", "y" and "z"
> > > > > > component.
> > > > >
> > > > > Agreed, using axes makes no real sense here and extended_name is
> > > > > just a mess from ABI point of view. Trying to solve this was the
> > > > > reason we added the _label interface.
> > > > >
> > > > > Jonathan
> > > > >
> > > > >
> > > > > > Thanks,
> > > > > > Srinivas
> > > > > >
> > > > > > > Thanks,
> > > > > > > Srinivas
> > > > > > >
> > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > > > > Signed-off-by: Ye Xiang <xiang.ye@intel.com>
> > > > > > > > > ---
> > > > > > > > > .../hid-sensors/hid-sensor-attributes.c | 2 +
> > > > > > > > > drivers/iio/position/Kconfig | 16 +
> > > > > > > > > drivers/iio/position/Makefile | 3 +
> > > > > > > > > .../iio/position/hid-sensor-custom-hinge.c | 412
> > > > > > > > > ++++++++++++++++++
> > > > > > > >
> > > > > > > > Given it's custom probably needs a more specific name. I guess
> > > > > > > > hid-sensor-custom-intel-hinge.c might be safe?
> > > > > > > >
> > > > > > > > Same for other places we need names in here.
> > > > > > > >
> > > > > > > > > 4 files changed, 433 insertions(+)
> > > > > > > > > create mode 100644 drivers/iio/position/hid-sensor-custom-
> > > > > > > > > hinge.c
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-
> > > > > > > > > attributes.c
> > > > > > > > > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > > > index 442ff787f7af..5b822a4298a0 100644
> > > > > > > > > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > > > > > > > > @@ -71,6 +71,8 @@ static struct {
> > > > > > > > > {HID_USAGE_SENSOR_TEMPERATURE,
> > > > > > > > > HID_USAGE_SENSOR_UNITS_DEGREES,
> > > > > > > > > 1000, 0},
> > > > > > > > >
> > > > > > > > > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > > > > > > > > + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > > > > > > > > + {HID_USAGE_SENSOR_HINGE,
> > > > > > > > > HID_USAGE_SENSOR_UNITS_DEGREES, 0,
> > > > > > > > > 17453293},
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > static void simple_div(int dividend, int divisor, int
> > > > > > > > > *whole,
> > > > > > > > > diff --git a/drivers/iio/position/Kconfig
> > > > > > > > > b/drivers/iio/position/Kconfig
> > > > > > > > > index eda67f008c5b..0346f6f2b422 100644
> > > > > > > > > --- a/drivers/iio/position/Kconfig
> > > > > > > > > +++ b/drivers/iio/position/Kconfig
> > > > > > > > > @@ -16,4 +16,20 @@ config IQS624_POS
> > > > > > > > > To compile this driver as a module, choose M here:
> > > > > > > > > the module
> > > > > > > > > will be called iqs624-pos.
> > > > > > > > >
> > > > > > > > > +config HID_SENSOR_CUSTOM_HINGE
> > > > > > > > > + depends on HID_SENSOR_HUB
> > > > > > > > > + select IIO_BUFFER
> > > > > > > > > + select IIO_TRIGGERED_BUFFER
> > > > > > > > > + select HID_SENSOR_IIO_COMMON
> > > > > > > > > + select HID_SENSOR_IIO_TRIGGER
> > > > > > > > > + tristate "HID Hinge"
> > > > > > > > > + help
> > > > > > > > > + This sensor present three angles, hinge angel, screen
> > > > > > > > > angles
> > > > > > > > > + and keyboard angle respect to horizon (ground).
> > > > > > > > > + Say yes here to build support for the HID SENSOR
> > > > > > > > > CUSTOM
> > > > > > > > > + HINGE.
> > > > > > > >
> > > > > > > > Capitalization is a bit odd looking. I'd drop it.
> > > > > > > >
> > > > > > > > > +
> > > > > > > > > + To compile this driver as a module, choose M here:
> > > > > > > > > the
> > > > > > > > > + module will be called hid-sensor-custom-hinge.
> > > > > > > > > +
> > > > > > > > > endmenu
> > > > > > > > > diff --git a/drivers/iio/position/Makefile
> > > > > > > > > b/drivers/iio/position/Makefile
> > > > > > > > > index 3cbe7a734352..7a6225977a01 100644
> > > > > > > > > --- a/drivers/iio/position/Makefile
> > > > > > > > > +++ b/drivers/iio/position/Makefile
> > > > > > > > > @@ -5,3 +5,6 @@
> > > > > > > > > # When adding new entries keep the list in alphabetical
> > > > > > > > > order
> > > > > > > > >
> > > > > > > > > obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
> > > > > > > > > +
> > > > > > > > > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-
> > > > > > > > > hinge.o
> > > > > > > >
> > > > > > > > Alphabetical order preferred.
> > > > > > > >
> > > > > > > > > +ccflags-y += -I$(srctree)/drivers/iio/common/hid-
> > > > > > > > > sensors
> > > > > > > >
> > > > > > > > Why?
> > > > > > > >
> > > > > > > > > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > > > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..a91b333f36fa
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > > > > > > > > @@ -0,0 +1,412 @@
> > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > +/*
> > > > > > > > > + * HID Sensors Driver
> > > > > > > > > + * Copyright (c) 2020, Intel Corporation.
> > > > > > > > > + */
> > > > > > > > > +#include <linux/hid-sensor-hub.h>
> > > > > > > > > +#include <linux/iio/buffer.h>
> > > > > > > > > +#include <linux/iio/iio.h>
> > > > > > > > > +#include <linux/platform_device.h>
> > > > > > > > > +
> > > > > > > > > +#include "hid-sensor-trigger.h"
> > > > > > > > > +
> > > > > > > > > +/* Channel definitions */
> > > > > > > > > +static const struct iio_chan_spec hinge_channels[] = {
> > > > > > > > > + { .type = IIO_ANGL,
> > > > > > > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > > > > > > > + .info_mask_shared_by_type =
> > > > > > > > > + BIT(IIO_CHAN_INFO_OFFSET) |
> > > > > > > > > BIT(IIO_CHAN_INFO_SCALE)
> > > > > > > > > + BIT(IIO_CHAN_INFO_SAMP_FREQ) |
> > > > > > > > > BIT(IIO_CHAN_INFO_HYSTERESIS),
> > > > > > > > > + .scan_type.realbits = 16,
> > > > > > > > > + .scan_type.storagebits = 32,
> > > > > > > >
> > > > > > > > It a bit odd to see a single channel that is 16 bits inside a
> > > > > > > > 32
> > > > > > > > bit
> > > > > > > > with
> > > > > > > > no shift or similar. Why not just pack it into 16 bits?
> > > > > > > >
> > > > > > > > > + .scan_type.sign = 's',
> > > > > > > > > + .scan_index = 0 },
> > > > > > > > > +
> > > > > > > > > + IIO_CHAN_SOFT_TIMESTAMP(1)
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +struct hinge_state {
> > > > > > > > > + struct iio_dev *indio_dev;
> > > > > > > > > + struct hid_sensor_hub_attribute_info hinge;
> > > > > > > > > + /* Reserve for 1 channel + pading + timestamp */
> > > > > > > > > + u32 hinge_val[1 + 3];
> > > > > > > >
> > > > > > > > __aligned(8)
> > > > > > > >
> > > > > > > > see below for requirements on this.
> > > > > > > > Perhaps better to use
> > > > > > > >
> > > > > > > > struct hinge_scan {
> > > > > > > > u32 val;
> > > > > > > > s64 timestamp __aligned(8); // Note this is
> > > > > > > > needed for
> > > > > > > > x86_32
> > > > > > > > } scan;
> > > > > > > >
> > > > > > > > > + int scale_pre_decml;
> > > > > > > > > + int scale_post_decml;
> > > > > > > > > + int scale_precision;
> > > > > > > > > + int value_offset;
> > > > > > > > > + int64_t timestamp;
> > > > > > > > > + u32 hinge_address;
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +#define IIO_DEV_NUM 3
> > > > > > > >
> > > > > > > > That needs a prefix to make it clear it's not a generic
> > > > > > > > constant
> > > > > > > > but is specific to this driver.
> > > > > > > >
> > > > > > > > > +
> > > > > > > > > +struct hinge_group {
> > > > > > > > > + struct hinge_state *hg_states[IIO_DEV_NUM];
> > > > > > > > > + struct hid_sensor_hub_callbacks callbacks;
> > > > > > > > > + struct hid_sensor_common common_attributes;
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +static struct hinge_group *hg_group;
> > > > > > > >
> > > > > > > > We shouldn't see globals like this. Please figure out how to
> > > > > > > > avoid
> > > > > > > > it.
> > > > > > > >
> > > > > > > > > +
> > > > > > > > > +/* Channel read_raw handler */
> > > > > > > > > +static int hinge_read_raw(struct iio_dev *indio_dev,
> > > > > > > > > + struct iio_chan_spec const *chan, int
> > > > > > > > > *val,
> > > > > > > > > int *val2,
> > > > > > > > > + long mask)
> > > > > > > > > +{
> > > > > > > > > + struct hinge_state *hg_state = iio_priv(indio_dev);
> > > > > > > > > + struct hid_sensor_hub_device *hsdev;
> > > > > > > > > + int report_id = -1;
> > > > > > > > > + int ret_type;
> > > > > > > > > + s32 min;
> > > > > > > > > +
> > > > > > > > > + hsdev = hg_group->common_attributes.hsdev;
> > > > > > > > > +
> > > > > > > > > + *val = 0;
> > > > > > > > > + *val2 = 0;
> > > > > > > > > + switch (mask) {
> > > > > > > > > + case IIO_CHAN_INFO_RAW:
> > > > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > > >common_attributes,
> > > > > > > > > true);
> > > > > > > > > + report_id = hg_state->hinge.report_id;
> > > > > > > > > + min = hg_state->hinge.logical_minimum;
> > > > > > > > > + if (report_id < 0) {
> > > > > > > > > + *val = 0;
> > > > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > > > common_attributes,
> > > > > > > > > + false);
> > > > > > > > > + return -EINVAL;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + *val = sensor_hub_input_attr_get_raw_value(
> > > > > > > > > + hg_group->common_attributes.hsdev,
> > > > > > > > > hsdev-
> > > > > > > > > > usage,
> > > > > > > > > + hg_state->hinge_address, report_id,
> > > > > > > > > SENSOR_HUB_SYNC,
> > > > > > > > > + min < 0);
> > > > > > > > > +
> > > > > > > > > + hid_sensor_power_state(&hg_group-
> > > > > > > > > >common_attributes,
> > > > > > > > > false);
> > > > > > > > > + ret_type = IIO_VAL_INT;
> > > > > > > > > + break;
> > > > > > > > > + case IIO_CHAN_INFO_SCALE:
> > > > > > > > > + *val = hg_state->scale_pre_decml;
> > > > > > > > > + *val2 = hg_state->scale_post_decml;
> > > > > > > > > + ret_type = hg_state->scale_precision;
> > > > > > > > > + break;
> > > > > > > > > + case IIO_CHAN_INFO_OFFSET:
> > > > > > > > > + *val = hg_state->value_offset;
> > > > > > > > > + ret_type = IIO_VAL_INT;
> > > > > > > > > + break;
> > > > > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > > > > + ret_type = hid_sensor_read_samp_freq_value(
> > > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > > val2);
> > > > > > > > > + break;
> > > > > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > > > > + ret_type = hid_sensor_read_raw_hyst_value(
> > > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > > val2);
> > > > > > > > > + break;
> > > > > > > > > + default:
> > > > > > > > > + ret_type = -EINVAL;
> > > > > > > > > + break;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + return ret_type;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/* Channel write_raw handler */
> > > > > > > > > +static int hinge_write_raw(struct iio_dev *indio_dev,
> > > > > > > > > + struct iio_chan_spec const *chan,
> > > > > > > > > int val,
> > > > > > > > > int val2,
> > > > > > > > > + long mask)
> > > > > > > > > +{
> > > > > > > > > + int ret;
> > > > > > > > > +
> > > > > > > > > + switch (mask) {
> > > > > > > > > + case IIO_CHAN_INFO_SAMP_FREQ:
> > > > > > > > > + ret = hid_sensor_write_samp_freq_value(
> > > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > > val2);
> > > > > > > > > + break;
> > > > > > > > > + case IIO_CHAN_INFO_HYSTERESIS:
> > > > > > > > > + ret = hid_sensor_write_raw_hyst_value(
> > > > > > > > > + &hg_group->common_attributes, val,
> > > > > > > > > val2);
> > > > > > > > > +
> > > > > > > > > + break;
> > > > > > > > > + default:
> > > > > > > > > + ret = -EINVAL;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +static const struct iio_info hinge_info = {
> > > > > > > > > + .read_raw = &hinge_read_raw,
> > > > > > > > > + .write_raw = &hinge_write_raw,
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +/*
> > > > > > > > > + * Function to push data to buffer;
> > > > > > > > > + * wrapper added for symmetry with other hid-sensor drivers
> > > > > > > > > + */
> > > > > > > > > +static void hid_sensor_push_data(struct iio_dev *indio_dev,
> > > > > > > > > void
> > > > > > > > > *data, int len,
> > > > > > > >
> > > > > > > > This doesn't seem to be generic, so don't name it as such.
> > > > > > > >
> > > > > > > > > + int64_t timestamp)
> > > > > > > > > +{
> > > > > > > > > + iio_push_to_buffers_with_timestamp(indio_dev, data,
> > > > > > > > > timestamp);
> > > > > > > > I hope that data buffer obeys the various rules needed by (and
> > > > > > > > admittedly
> > > > > > > > not that well documented) iio_push_to_buffers_with_timestamp()
> > > > > > > >
> > > > > > > > 1. Needs to be 8 byte aligned.
> > > > > > > > 2. Needs to have space for an aligned 8 byte timestamp at the
> > > > > > > > end.
> > > > > > > >
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/*
> > > > > > > > > + * Callback handler to send event after all samples are
> > > > > > > > > received
> > > > > > > > > + * and captured.
> > > > > > > > > + */
> > > > > > > > > +static int hinge_proc_event(struct hid_sensor_hub_device
> > > > > > > > > *hsdev,
> > > > > > > > > + unsigned int usage_id, void *priv)
> > > > > > > > > +{
> > > > > > > > > + int i;
> > > > > > > > > +
> > > > > > > > > + for (i = 0; i < IIO_DEV_NUM; ++i) {
> > > > > > > > If we push for all sensors together, better to have
> > > > > > > > this as a single iio_device with 3 channels.
> > > > > > > >
> > > > > > > > Use the channel labels (just added to IIO) to identify which is
> > > > > > > > which.
> > > > > > > >
> > > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > > + struct iio_dev *indio_dev;
> > > > > > > > > +
> > > > > > > > > + hg_state = hg_group->hg_states[i];
> > > > > > > > > + indio_dev = hg_state->indio_dev;
> > > > > > > > > +
> > > > > > > > > + dev_dbg(&indio_dev->dev, "%s timestamp:%llu
> > > > > > > > > scan_bytes:%d\n",
> > > > > > > > > + __func__, hg_state->timestamp,
> > > > > > > > > indio_dev-
> > > > > > > > > > scan_bytes);
> > > > > > > > > +
> > > > > > > > > + if (!hg_state->timestamp)
> > > > > > > > > + hg_state->timestamp =
> > > > > > > > > iio_get_time_ns(indio_dev);
> > > > > > > > > +
> > > > > > > > > + hid_sensor_push_data(indio_dev, hg_state-
> > > > > > > > > >hinge_val,
> > > > > > > > > + sizeof(hg_state-
> > > > > > > > > >hinge_val),
> > > > > > > > > + hg_state->timestamp);
> > > > > > > > > +
> > > > > > > > > + hg_state->timestamp = 0;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/* Capture samples in local storage */
> > > > > > > > > +static int hinge_capture_sample(struct hid_sensor_hub_device
> > > > > > > > > *hsdev,
> > > > > > > > > + unsigned int usage_id, size_t
> > > > > > > > > raw_len,
> > > > > > > > > + char *raw_data, void *priv)
> > > > > > > > > +{
> > > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > > + int offset;
> > > > > > > > > + int ret = -EINVAL;
> > > > > > > > > + int i;
> > > > > > > > > +
> > > > > > > > > + if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
> > > > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > > > > + hg_group->hg_states[i]->timestamp =
> > > > > > > >
> > > > > > > > This rather implies all the data is captured together... If so
> > > > > > > > single
> > > > > > > > iio_device may make more sense.
> > > > > > > >
> > > > > > > > > + hid_sensor_convert_timestamp(
> > > > > > > > > + &hg_group-
> > > > > > > > > >common_attributes,
> > > > > > > > > + *(int64_t *)raw_data);
> > > > > > > > > + return 0;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + switch (usage_id) {
> > > > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1:
> > > > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2:
> > > > > > > > > + case HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3:
> > > > > > > > > + offset = usage_id -
> > > > > > > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1;
> > > > > > > > > + hg_state = hg_group->hg_states[offset];
> > > > > > > > > + hg_state->hinge_val[0] = *(u32 *)raw_data;
> > > > > > > > > + ret = 0;
> > > > > > > >
> > > > > > > > return 0;
> > > > > > > >
> > > > > > > > > + break;
> > > > > > > > > + default:
> > > > > > > > return -EINVAL;
> > > > > > > > > + break;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/* Parse report which is specific to an usage id */
> > > > > > > > > +static int hinge_parse_report(struct platform_device *pdev,
> > > > > > > > > + struct hid_sensor_hub_device
> > > > > > > > > *hsdev,
> > > > > > > > > + unsigned int usage_id, unsigned
> > > > > > > > > int
> > > > > > > > > attr_usage_id,
> > > > > > > > > + struct hinge_state *st)
> > > > > > > > > +{
> > > > > > > > > + int ret;
> > > > > > > > > +
> > > > > > > > > + ret = sensor_hub_input_get_attribute_info(
> > > > > > > > > + hsdev, HID_INPUT_REPORT, usage_id,
> > > > > > > > > attr_usage_id, &st-
> > > > > > > > > > hinge);
> > > > > > > > > + if (ret < 0)
> > > > > > > > > + return ret;
> > > > > > > > > +
> > > > > > > > > + st->hinge_address = attr_usage_id;
> > > > > > > > > + st->scale_precision =
> > > > > > > > > + hid_sensor_format_scale(HID_USAGE_SENSOR_HINGE,
> > > > > > > > > &st-
> > > > > > > > > > hinge,
> > > > > > > > > + &st->scale_pre_decml,
> > > > > > > > > + &st->scale_post_decml);
> > > > > > > > > +
> > > > > > > > > + /* Set Sensitivity field ids, when there is no
> > > > > > > > > individual
> > > > > > > > > modifier */
> > > > > > > > > + if (hg_group->common_attributes.sensitivity.index < 0)
> > > > > > > > > {
> > > > > > > > > + sensor_hub_input_get_attribute_info(
> > > > > > > > > + hsdev, HID_FEATURE_REPORT, usage_id,
> > > > > > > > > + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSIT
> > > > > > > > > IVITY_AB
> > > > > > > > > S |
> > > > > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUS
> > > > > > > > > TOM_VALU
> > > > > > > > > E_1,
> > > > > > > > > + &hg_group-
> > > > > > > > > >common_attributes.sensitivity);
> > > > > > > > > + dev_dbg(&pdev->dev, "Sensitivity index:report
> > > > > > > > > %d:%d\n",
> > > > > > > > > + hg_group-
> > > > > > > > > >common_attributes.sensitivity.index,
> > > > > > > > > + hg_group-
> > > > > > > > > > common_attributes.sensitivity.report_id);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/* Function to initialize the processing for usage id */
> > > > > > > > > +static int hinge_add_iio_device(struct platform_device
> > > > > > > > > *pdev,
> > > > > > > > > int
> > > > > > > > > index,
> > > > > > > > > + const char *name, struct
> > > > > > > > > hinge_state
> > > > > > > > > **st)
> > > > > > > > > +{
> > > > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > > > >dev.platform_data;
> > > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > > + struct iio_dev *indio_dev;
> > > > > > > > > + int ret;
> > > > > > > > > +
> > > > > > > > > + indio_dev =
> > > > > > > > > + devm_iio_device_alloc(&pdev->dev, sizeof(struct
> > > > > > > > > hinge_state));
> > > > > > > >
> > > > > > > > sizeof (*hg_state) preferred.
> > > > > > > >
> > > > > > > > > + if (indio_dev == NULL)
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > +
> > > > > > > > > + hg_state = iio_priv(indio_dev);
> > > > > > > > > + hg_state->indio_dev = indio_dev;
> > > > > > > > > +
> > > > > > > > > + indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
> > > > > > > > > + indio_dev->channels =
> > > > > > > > > + kmemdup(hinge_channels, sizeof(hinge_channels),
> > > > > > > > > GFP_KERNEL);
> > > > > > > >
> > > > > > > > I don't immediately see anything that is modifying channels. As
> > > > > > > > such
> > > > > > > > you
> > > > > > > > should be able have it shared by all the instances.
> > > > > > > >
> > > > > > > > > + if (!indio_dev->channels)
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > +
> > > > > > > > > + ret = hinge_parse_report(
> > > > > > > > > + pdev, hsdev, hsdev->usage,
> > > > > > > > > + HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 +
> > > > > > > > > index,
> > > > > > > > > hg_state);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(&pdev->dev, "failed to setup
> > > > > > > > > attributes\n");
> > > > > > > > > + goto error_free_dev_mem;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + indio_dev->dev.parent = &pdev->dev;
> > > > > > > > > + indio_dev->info = &hinge_info;
> > > > > > > > > + indio_dev->name = name;
> > > > > > > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > > > > > > +
> > > > > > > > > + ret = hid_sensor_setup_trigger(indio_dev, name,
> > > > > > > > > + &hg_group-
> > > > > > > > > >common_attributes);
> > > > > > > > > + if (ret < 0) {
> > > > > > > > > + dev_err(&pdev->dev, "trigger setup failed\n");
> > > > > > > > > + goto error_free_dev_mem;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + ret = iio_device_register(indio_dev);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(&pdev->dev, "device register
> > > > > > > > > failed\n");
> > > > > > > > > + goto error_remove_trigger;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + *st = hg_state;
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > +
> > > > > > > > > +error_remove_trigger:
> > > > > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > > > > common_attributes);
> > > > > > > > > +error_free_dev_mem:
> > > > > > > > > + kfree(indio_dev->channels);
> > > > > > > > > + return ret;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > > > > +static int hinge_remove_iio_device(struct platform_device
> > > > > > > > > *pdev,
> > > > > > > > > int index)
> > > > > > > > > +{
> > > > > > > > > + struct hinge_state *hg_state = hg_group-
> > > > > > > > > >hg_states[index];
> > > > > > > > > + struct iio_dev *indio_dev = hg_state->indio_dev;
> > > > > > > > > +
> > > > > > > > > + iio_device_unregister(indio_dev);
> > > > > > > > > + hid_sensor_remove_trigger(indio_dev, &hg_group-
> > > > > > > > > > common_attributes);
> > > > > > > > > + kfree(indio_dev->channels);
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +static int hid_hinge_probe(struct platform_device *pdev)
> > > > > > > > > +{
> > > > > > > > > + struct hinge_state *hg_state;
> > > > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > > > >dev.platform_data;
> > > > > > > > > + static const char *const names[] = { "hinge", "screen",
> > > > > > > > > "keyboard" };
> > > > > > > > > + int ret;
> > > > > > > > > + int i;
> > > > > > > > > +
> > > > > > > > > + hg_group = devm_kzalloc(&pdev->dev, sizeof(struct
> > > > > > > > > hinge_group),
> > > > > > > > > + GFP_KERNEL);
> > > > > > > >
> > > > > > > > As mentioned above, I'd really not expect to see a global like
> > > > > > > > this.
> > > > > > > > Technically nothing stops there being more than one instance of
> > > > > > > > this
> > > > > > > > device on a platform (even if that would be a bit odd) + it's
> > > > > > > > almost
> > > > > > > > always cleaner to not use a global in the first place.
> > > > > > > >
> > > > > > > > > + if (!hg_group)
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > +
> > > > > > > > > + hg_group->common_attributes.hsdev = hsdev;
> > > > > > > > > + hg_group->common_attributes.pdev = pdev;
> > > > > > > > > +
> > > > > > > > > + ret = hid_sensor_parse_common_attributes(hsdev, hsdev-
> > > > > > > > > >usage,
> > > > > > > > > + &hg_group-
> > > > > > > > > > common_attributes);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(&pdev->dev, "failed to setup common
> > > > > > > > > attributes\n");
> > > > > > > > > + return ret;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + atomic_set(&hg_group->common_attributes.data_ready, 0);
> > > > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++) {
> > > > > > > > > + ret = hinge_add_iio_device(pdev, i, names[i],
> > > > > > > > > &hg_state);
> > > > > > > > > + if (ret)
> > > > > > > > > + goto err_probe;
> > > > > > > > > +
> > > > > > > > > + hg_group->hg_states[i] = hg_state;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + /* use the first iio device to do the PM */
> > > > > > > > > + platform_set_drvdata(pdev, hg_group->hg_states[0]-
> > > > > > > > > >indio_dev);
> > > > > > > > > +
> > > > > > > > > + hg_group->callbacks.send_event = hinge_proc_event;
> > > > > > > > > + hg_group->callbacks.capture_sample =
> > > > > > > > > hinge_capture_sample;
> > > > > > > > > + hg_group->callbacks.pdev = pdev;
> > > > > > > > > + ret = sensor_hub_register_callback(hsdev, hsdev->usage,
> > > > > > > > > + &hg_group-
> > > > > > > > > >callbacks);
> > > > > > > > > + if (ret < 0)
> > > > > > > > > + dev_err(&pdev->dev, "callback reg failed\n");
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > +
> > > > > > > > > +err_probe:
> > > > > > > > > + for (i--; i >= 0; i--)
> > > > > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +/* Function to deinitialize the processing for usage id */
> > > > > > > > > +static int hid_hinge_remove(struct platform_device *pdev)
> > > > > > > > > +{
> > > > > > > > > + struct hid_sensor_hub_device *hsdev = pdev-
> > > > > > > > > >dev.platform_data;
> > > > > > > > > + int i;
> > > > > > > > > +
> > > > > > > > > + sensor_hub_remove_callback(hsdev, hsdev->usage);
> > > > > > > > > +
> > > > > > > > > + for (i = 0; i < IIO_DEV_NUM; i++)
> > > > > > > > > + hinge_remove_iio_device(pdev, i);
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +static const struct platform_device_id hid_hinge_ids[] = {
> > > > > > > > > + {
> > > > > > > > > + /* Format: HID-SENSOR-INT-
> > > > > > > > > usage_id_in_hex_lowercase */
> > > > > > > > > + .name = "HID-SENSOR-INT-020b",
> > > > > > > > > + },
> > > > > > > > > + { /* sentinel */ }
> > > > > > > > > +};
> > > > > > > > > +MODULE_DEVICE_TABLE(platform, hid_hinge_ids);
> > > > > > > > > +
> > > > > > > > > +static struct platform_driver hid_hinge_platform_driver = {
> > > > > > > > > + .id_table = hid_hinge_ids,
> > > > > > > > > + .driver = {
> > > > > > > > > + .name = KBUILD_MODNAME,
> > > > > > > > > + .pm = &hid_sensor_pm_ops,
> > > > > > > > > + },
> > > > > > > > > + .probe = hid_hinge_probe,
> > > > > > > > > + .remove = hid_hinge_remove,
> > > > > > > > > +};
> > > > > > > > > +module_platform_driver(hid_hinge_platform_driver);
> > > > > > > > > +
> > > > > > > > > +MODULE_DESCRIPTION("HID Sensor Custom Hinge");
> > > > > > > > > +MODULE_AUTHOR("Ye Xiang <xiang.ye@intel.com>");
> > > > > > > > > +MODULE_LICENSE("GPL");
> > >
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support
2020-11-25 2:27 ` Ye, Xiang
@ 2020-11-28 13:29 ` Jonathan Cameron
0 siblings, 0 replies; 25+ messages in thread
From: Jonathan Cameron @ 2020-11-28 13:29 UTC (permalink / raw)
To: Ye, Xiang
Cc: Jonathan Cameron, jikos, srinivas.pandruvada, linux-input,
linux-iio, linux-kernel
On Wed, 25 Nov 2020 10:27:21 +0800
"Ye, Xiang" <xiang.ye@intel.com> wrote:
> On Tue, Nov 24, 2020 at 11:32:11AM +0000, Jonathan Cameron wrote:
> > Hi
> > ...
> > > > > sysfs_remove_group(&sensor_inst->pdev->dev.kobj,
> > > > > diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
> > > > > index 530c09f3e64a..46db3056f04b 100644
> > > > > --- a/include/linux/hid-sensor-ids.h
> > > > > +++ b/include/linux/hid-sensor-ids.h
> > > > > @@ -128,6 +128,10 @@
> > > > > #define HID_USAGE_SENSOR_UNITS_DEGREES_PER_SECOND 0x15
> > > > >
> > > > > /* Common selectors */
> > > > > +#define HID_USAGE_SENSOR_PROP_DESC 0x200300
> > > > > +#define HID_USAGE_SENSOR_PROP_FRIENDLY_NAME 0x200301
> > > > > +#define HID_USAGE_SENSOR_PROP_SERIAL_NUM 0x200307
> > > > > +#define HID_USAGE_SENSOR_PROP_MANUFACTURER 0x200305
> > > > > #define HID_USAGE_SENSOR_PROP_REPORT_INTERVAL 0x20030E
> > > > > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_ABS 0x20030F
> > > > > #define HID_USAGE_SENSOR_PROP_SENSITIVITY_RANGE_PCT 0x200310
> > > > > @@ -159,4 +163,39 @@
> > > > > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM 0x200840
> > > > > #define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x200841
> > > > >
> > > > > +/* Custom Sensor (2000e1) */
> > > > > +#define HID_USAGE_SENSOR_HINGE 0x20020B
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_LOCATION 0x200400
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELE_TIME_SINCE_SYS_BOOT 0x20052B
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_USAGE 0x200541
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE 0x200543
> > > > Given these are all defined in a block could we use a macro?
> > > > HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) 0x200543 + (x)
> > > >
> > > > perhaps?
> > > >
> > > > I'm not sure what the preferred convention is in this file.
> > > If using HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x), we should give a range to x, like (1<x<28).
> > > How to ensure the x is in the range? It can be an issue when someone using x out of the range.
> >
> > It can be done via build time checking.
> > https://elixir.bootlin.com/linux/latest/source/include/linux/build_bug.h#L49
> > Normally we wouldn't bother and would rely on review to pick up on this but
> > I'd have no problem with a paranoid check in the macro. Particularly as 28 isn't
> > exactly and obvious number to support!
> Because HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE is used as case condition, we cannot use
> Build_BUG_ON in the macro like below.
> #define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) \
> ({ \
> BUILD_BUG_ON(x > 28); \
> BUILD_BUG_ON(x < 0); \
> (HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_BASE + (x)); \
> })
Ah. I'd missed the case condition element. Good point!
>
> I can use the define with a comments to declear the range of x.
> #define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_BASE 0x200543
> /* Custom Sensor data 28=>x>=0 */
> #define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) \
> (HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_BASE + (x))
>
Sounds good to me.
Thanks,
Jonathan
> Thanks
> Ye, Xiang
> >
> > >
> > > Thanks
> > > Xiang
> > > >
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_1 0x200544
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_2 0x200545
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_3 0x200546
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_4 0x200547
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_5 0x200548
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_6 0x200549
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_7 0x20054A
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_8 0x20054B
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_9 0x20054C
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_10 0x20054D
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_11 0x20054E
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_12 0x20054F
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_13 0x200550
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_14 0x200551
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_15 0x200552
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_16 0x200553
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_17 0x200554
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_18 0x200555
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_19 0x200556
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_20 0x200557
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_21 0x200558
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_22 0x200559
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_23 0x20055A
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_24 0x20055B
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_25 0x20055C
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_26 0x20055D
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_27 0x20055E
> > > > > +#define HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE_28 0x20055F
> > > > > +
> > > > > #endif
> > > >
> >
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2020-11-28 22:05 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-19 10:03 [PATCH v2 0/4] add custom hinge sensor support Ye Xiang
2020-11-19 10:03 ` [PATCH v2 1/4] HID: hid-sensor-custom: Add custom sensor iio support Ye Xiang
2020-11-21 17:21 ` Jonathan Cameron
2020-11-24 10:29 ` Ye, Xiang
2020-11-24 11:32 ` Jonathan Cameron
2020-11-25 2:27 ` Ye, Xiang
2020-11-28 13:29 ` Jonathan Cameron
2020-11-19 10:03 ` [PATCH v2 2/4] iio: hid-sensor-trigger: Decrement runtime pm enable count on driver removal Ye Xiang
2020-11-21 17:22 ` Jonathan Cameron
2020-11-22 1:54 ` Pandruvada, Srinivas
2020-11-19 10:03 ` [PATCH v2 3/4] iio: hid-sensor-trigger: Use iio->trig instead trig field internal structure Ye Xiang
2020-11-21 17:33 ` Jonathan Cameron
2020-11-19 10:03 ` [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver Ye Xiang
2020-11-21 17:56 ` Jonathan Cameron
2020-11-22 1:46 ` Pandruvada, Srinivas
2020-11-22 2:14 ` Pandruvada, Srinivas
2020-11-22 14:14 ` Jonathan Cameron
2020-11-22 15:51 ` Pandruvada, Srinivas
2020-11-22 16:50 ` Jonathan Cameron
2020-11-24 3:30 ` Ye, Xiang
2020-11-24 11:36 ` Jonathan Cameron
2020-11-25 3:24 ` Ye, Xiang
2020-11-24 6:43 ` Ye, Xiang
2020-11-24 11:39 ` Jonathan Cameron
2020-11-25 2:39 ` Ye, Xiang
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).