From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Philipp Jungkamp <p.jungkamp@gmx.net>
Cc: Jiri Kosina <jikos@kernel.org>,
Jonathan Cameron <jic23@kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
<linux-iio@vger.kernel.org>
Subject: Re: [PATCH 3/3] IIO: hid-sensor-prox: Use generic usage
Date: Thu, 17 Nov 2022 15:14:31 +0000 [thread overview]
Message-ID: <20221117151431.00001bab@Huawei.com> (raw)
In-Reply-To: <20221116231947.18031-3-p.jungkamp@gmx.net>
On Thu, 17 Nov 2022 00:19:47 +0100
Philipp Jungkamp <p.jungkamp@gmx.net> wrote:
> Use a generic 'hsdev->usage' instead of the HID_USAGE_SENSOR_PROX to
> allow this driver to drive the Lenvo custom proximity sensor, which is
> registered under a 'custom' usage and not HID_USAGE_SENSOR_PROX.
>
> Check for raw_len to accomodate the ReportSize(8) field used on the
> Lenovo Yoga 9 14IAP7.
>
> Add the Lenovo Intelligent Sensing Solution (LISS) human presence sensor
> to the platform device ids.
>
> Signed-off-by: Philipp Jungkamp <p.jungkamp@gmx.net>
As with previous - prefer this split into a noop patch then one that
adds the new use case.
It's small enough I'm not that bothered though if you'd rather not.
A few comments inline.
Thanks,
Jonathan
> ---
> drivers/hid/hid-sensor-custom.c | 10 ++++++++
> drivers/iio/light/hid-sensor-prox.c | 39 +++++++++++++++++++++--------
> 2 files changed, 38 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> index 124493b8abaf..ec49dc80f074 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -795,6 +795,16 @@ static const struct hid_sensor_custom_match hid_sensor_custom_known_table[] = {
> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> }
> },
> + { /* human presence */
> + .tag = "LISS",
> + .luid = "0226000171AC0081",
> + .model = "VL53L1_HOD Sensor",
> + .manufacturer = "ST_MICRO",
> + .check_dmi = true,
> + .dmi.matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + }
> + },
> {}
> };
>
> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
> index f10fa2abfe72..cca6b75c44d5 100644
> --- a/drivers/iio/light/hid-sensor-prox.c
> +++ b/drivers/iio/light/hid-sensor-prox.c
> @@ -61,6 +61,7 @@ static int prox_read_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct prox_state *prox_state = iio_priv(indio_dev);
> + struct hid_sensor_hub_device *hsdev;
> int report_id = -1;
> u32 address;
> int ret_type;
> @@ -75,6 +76,7 @@ static int prox_read_raw(struct iio_dev *indio_dev,
> report_id = prox_state->prox_attr.report_id;
> min = prox_state->prox_attr.logical_minimum;
> address = HID_USAGE_SENSOR_HUMAN_PRESENCE;
> + hsdev = prox_state->common_attributes.hsdev;
> break;
> default:
> report_id = -1;
> @@ -84,8 +86,9 @@ static int prox_read_raw(struct iio_dev *indio_dev,
> hid_sensor_power_state(&prox_state->common_attributes,
> true);
> *val = sensor_hub_input_attr_get_raw_value(
> - prox_state->common_attributes.hsdev,
> - HID_USAGE_SENSOR_PROX, address,
> + hsdev,
> + hsdev->usage,
> + address,
Wrapping is already odd here but this patch can avoid making it worse
by trying to get multiple params on one line < 80 chars.
> report_id,
> SENSOR_HUB_SYNC,
> min < 0);
> @@ -191,10 +194,16 @@ static int prox_capture_sample(struct hid_sensor_hub_device *hsdev,
>
> switch (usage_id) {
> case HID_USAGE_SENSOR_HUMAN_PRESENCE:
> - prox_state->human_presence = *(u32 *)raw_data;
> - ret = 0;
> - break;
> - default:
> + switch (raw_len) {
> + case 1:
> + prox_state->human_presence = *(u8 *)raw_data;
> + ret = 0;
No obvious reason not to use direct returns here as they will be slightly
more readable as well as shortening the code a little.
return 0;
> + break;
> + case 4:
> + prox_state->human_presence = *(u32 *)raw_data;
> + ret = 0;
> + break;
Likely to generate warnings if a compiler can't see far enough to tell this
only ever gets 1 or 4 in raw_len.
Avoid that by adding a default.
> + }
> break;
> }
>
> @@ -244,7 +253,8 @@ static int hid_prox_probe(struct platform_device *pdev)
> prox_state->common_attributes.hsdev = hsdev;
> prox_state->common_attributes.pdev = pdev;
>
> - ret = hid_sensor_parse_common_attributes(hsdev, HID_USAGE_SENSOR_PROX,
> + ret = hid_sensor_parse_common_attributes(hsdev,
> + hsdev->usage,
> &prox_state->common_attributes,
> prox_sensitivity_addresses,
> ARRAY_SIZE(prox_sensitivity_addresses));
> @@ -262,7 +272,8 @@ static int hid_prox_probe(struct platform_device *pdev)
>
> ret = prox_parse_report(pdev, hsdev,
> (struct iio_chan_spec *)indio_dev->channels,
> - HID_USAGE_SENSOR_PROX, prox_state);
> + hsdev->usage,
> + prox_state);
As below.
> if (ret) {
> dev_err(&pdev->dev, "failed to setup attributes\n");
> return ret;
> @@ -291,8 +302,9 @@ static int hid_prox_probe(struct platform_device *pdev)
> prox_state->callbacks.send_event = prox_proc_event;
> prox_state->callbacks.capture_sample = prox_capture_sample;
> prox_state->callbacks.pdev = pdev;
> - ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_PROX,
> - &prox_state->callbacks);
> + ret = sensor_hub_register_callback(hsdev,
> + hsdev->usage,
> + &prox_state->callbacks);
As below.
> if (ret < 0) {
> dev_err(&pdev->dev, "callback reg failed\n");
> goto error_iio_unreg;
> @@ -314,7 +326,8 @@ static int hid_prox_remove(struct platform_device *pdev)
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> struct prox_state *prox_state = iio_priv(indio_dev);
>
> - sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_PROX);
> + sensor_hub_remove_callback(hsdev,
> + hsdev->usage);
Similar to previous patch. Line wrap is too short.
> iio_device_unregister(indio_dev);
> hid_sensor_remove_trigger(indio_dev, &prox_state->common_attributes);
>
> @@ -326,6 +339,10 @@ static const struct platform_device_id hid_prox_ids[] = {
> /* Format: HID-SENSOR-usage_id_in_hex_lowercase */
> .name = "HID-SENSOR-200011",
> },
> + {
> + /* Format: HID-SENSOR-tag-usage_id_in_hex_lowercase */
> + .name = "HID-SENSOR-LISS-0226",
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(platform, hid_prox_ids);
> --
> 2.38.1
>
next prev parent reply other threads:[~2022-11-17 15:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 12:11 PROBLEM: Lenovo ALS sensor disguised under custom usage Philipp Jungkamp
2022-11-16 23:19 ` [PATCH 1/3] HID: hid-sensor-custom: More custom iio sensors Philipp Jungkamp
2022-11-16 23:19 ` [PATCH 2/3] IIO: hid-sensor-als: Use generic usage Philipp Jungkamp
2022-11-17 15:09 ` Jonathan Cameron
2022-11-16 23:19 ` [PATCH 3/3] IIO: hid-sensor-prox: " Philipp Jungkamp
2022-11-17 15:14 ` Jonathan Cameron [this message]
2022-11-17 15:05 ` [PATCH 1/3] HID: hid-sensor-custom: More custom iio sensors Jonathan Cameron
2022-11-17 23:42 ` [PATCH v2 1/4] HID: hid-sensor-custom: Allow more " Philipp Jungkamp
2022-11-17 23:43 ` [PATCH v2 2/4] HID: hid-sensor-custom: Add LISS custom sensors Philipp Jungkamp
2022-11-18 20:16 ` srinivas pandruvada
2022-11-17 23:43 ` [PATCH v2 3/4] IIO: hid-sensor-als: Use generic usage Philipp Jungkamp
2022-11-17 23:43 ` [PATCH v2 4/4] IIO: hid-sensor-prox: " Philipp Jungkamp
2022-11-18 20:11 ` [PATCH v2 1/4] HID: hid-sensor-custom: Allow more custom iio sensors srinivas pandruvada
2022-11-17 23:48 ` [PATCH v3 " Philipp Jungkamp
2022-11-17 23:48 ` [PATCH v3 2/4] HID: hid-sensor-custom: Add LISS custom sensors Philipp Jungkamp
2022-11-17 23:48 ` [PATCH v3 3/4] IIO: hid-sensor-als: Use generic usage Philipp Jungkamp
2022-11-18 20:23 ` srinivas pandruvada
2022-11-21 17:59 ` Jiri Kosina
2022-11-21 19:55 ` srinivas pandruvada
2022-11-23 17:16 ` Jonathan Cameron
2022-11-17 23:48 ` [PATCH v3 4/4] IIO: hid-sensor-prox: " Philipp Jungkamp
2022-11-18 20:26 ` srinivas pandruvada
2022-11-23 17:17 ` Jonathan Cameron
2022-11-23 17:08 ` [PATCH v3 1/4] HID: hid-sensor-custom: Allow more custom iio sensors Jonathan Cameron
2022-11-23 17:10 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221117151431.00001bab@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=jic23@kernel.org \
--cc=jikos@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=p.jungkamp@gmx.net \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.