* Re: [PATCH 05/11] iio: humidity: hid-sensor-humidity: use common device for devres
From: sashiko-bot @ 2026-06-16 11:27 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-5-0cd544286575@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Changing the devm allocation parent from the IIO device to the platform device creates a dangling pointer, as the IIO device can outlive the platform device.
Pre-existing issues:
- [High] The driver shares a single static global `struct hid_sensor_hub_callbacks humidity_callbacks` which is overwritten by each probed device, causing data corruption and Use-After-Free.
--
commit ba18caab7a04132bf9ca0d7432b6f7dcfedfbc00
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: humidity: hid-sensor-humidity: use common device for devres
This patch changes the devres allocation parent for the humidity channels
array. It moves the ownership from the IIO device to the HID platform
device to consolidate the devres ownership tree.
> diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
> index 6fed019f4099f..73120b87d641d 100644
> --- a/drivers/iio/humidity/hid-sensor-humidity.c
> +++ b/drivers/iio/humidity/hid-sensor-humidity.c
> @@ -215,7 +215,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - humid_chans = devm_kmemdup(&indio_dev->dev, humidity_channels,
> + humid_chans = devm_kmemdup(&pdev->dev, humidity_channels,
> sizeof(humidity_channels), GFP_KERNEL);
[Severity: High]
Does changing the devm allocation parent to the platform device create a
dangling pointer here?
In the IIO subsystem, the iio_dev object is reference-counted and can outlive
the platform device if userspace holds open file descriptors (for example,
/dev/iio:deviceX). Devres resources attached to pdev->dev are freed
unconditionally when the driver unbinds, but resources attached to
indio_dev->dev live until the iio_dev reference count drops to zero.
By moving the allocation of humidity_channels to pdev->dev, won't
indio_dev->channels point to freed memory immediately after unbind, leading
to a use-after-free if the IIO core or userspace continues to interact with
the still-alive iio_dev?
> if (!humid_chans)
> return -ENOMEM;
[ ... ]
While looking at hid_humidity_probe(), I noticed another detail:
drivers/iio/humidity/hid-sensor-humidity.c:hid_humidity_probe() {
...
humidity_callbacks.pdev = pdev;
ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_HUMIDITY,
&humidity_callbacks);
...
}
[Severity: High]
This is a pre-existing issue, but does assigning the local platform device to
the globally shared humidity_callbacks structure cause state corruption?
If a system has multiple humidity sensors probed, it appears the pdev of the
last probed sensor overwrites the pointer for all previous instances.
When sensor_hub_raw_event() dispatches an event for an earlier sensor, it
calls callback->capture_sample() with the overwritten pdev. Could this
corrupt the state of the newer sensor, or cause a use-after-free if the
newer sensor is unbound while the older one remains active?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 07/11] iio: temperature: hid-sensor-temperature: use common device for devres
From: sashiko-bot @ 2026-06-16 11:27 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-7-0cd544286575@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-After-Free of IIO channels array when in-kernel consumers hold references past driver unbind.
- [High] State corruption due to overwriting a static global callbacks structure during probe.
--
commit 92f73ed0d62d832f9bf6d6b90aa841b134a7d14d
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: temperature: hid-sensor-temperature: use common device for devres
This commit updates hid-sensor-temperature to allocate memory using the
platform device instead of the IIO device. This unifies devres ownership
under the platform device for deterministic resource release.
> diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
> index 9f628a8e5cfbe..31ebfd1a1fe2c 100644
> --- a/drivers/iio/temperature/hid-sensor-temperature.c
> +++ b/drivers/iio/temperature/hid-sensor-temperature.c
> @@ -213,8 +213,8 @@ static int hid_temperature_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - temp_chans = devm_kmemdup(&indio_dev->dev, temperature_channels,
> - sizeof(temperature_channels), GFP_KERNEL);
> + temp_chans = devm_kmemdup(&pdev->dev, temperature_channels,
> + sizeof(temperature_channels), GFP_KERNEL);
[Severity: High]
This isn't a bug introduced by this patch, but does using devm_kmemdup()
for the IIO channels array tie its lifecycle to driver unbind rather than
the IIO device's reference-counted lifecycle?
If an in-kernel consumer holds a reference to the IIO device after the
provider driver unbinds, the consumer might access the freed channels array
through its cached iio_channel pointer (e.g., via
iio_read_channel_ext_info(), which does not check if indio_dev->info was
cleared).
Could this lead to a use-after-free? Would it be safer to make the
channels array part of the iio_priv structure so it lives as long as the
indio_dev itself?
> if (!temp_chans)
> return -ENOMEM;
[Severity: High]
This is a pre-existing issue, but looking further down in
hid_temperature_probe(), is it safe to assign pdev to a global static
callbacks structure?
hid_temperature_probe() {
...
temperature_callbacks.pdev = pdev;
ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_TEMPERATURE,
&temperature_callbacks);
...
}
If a system contains multiple HID temperature sensors, would probing a
second sensor overwrite the pdev pointer with the new device instance?
When the sensor hub receives an event for the first sensor, it might fire
the callback using the pdev of the second sensor, pushing data into the
wrong device's buffer.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=7
^ permalink raw reply
* [PATCH 1/1] HID: core: Fix OOB read in hid_get_report for numbered reports
From: Lee Jones @ 2026-06-16 11:26 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Johan Hovold,
Greg Kroah-Hartman, linux-input, linux-kernel
When a caller passes a size of 0 to hid_report_raw_event() for a
numbered report, the function originally called hid_get_report() before
performing any size validation.
Inside hid_get_report(), if the report is numbered (report_enum->numbered
is true), it unconditionally dereferences data[0] to extract the report ID.
With a size of 0, this results in an out-of-bounds read or kernel panic.
Fix this by moving the numbered report size validation check before the
call to hid_get_report(), ensuring that size is at least 1 before
dereferencing the data pointer.
Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 41a79e43c82b..cf123347a2af 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2045,6 +2045,13 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
u8 *cdata = data;
int ret = 0;
+ if (report_enum->numbered && (size < 1 || bufsize < 1)) {
+ hid_warn_ratelimited(hid,
+ "Event data for numbered report is too short (%d vs %zu)\n",
+ size, bufsize);
+ return -EINVAL;
+ }
+
report = hid_get_report(report_enum, data);
if (!report)
return 0;
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* Re: [PATCH 02/11] iio: humidity: hid-sensor-humidity: align parenthesis for readability
From: sashiko-bot @ 2026-06-16 11:22 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-2-0cd544286575@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Global state corruption due to shared static `humidity_callbacks` struct
- [High] Out-of-bounds read and unaligned memory access in `humidity_capture_sample()`
- [High] Possible list corruption and use-after-free during device removal
--
commit 340e0cdb97cad589244be8376c8b1f7f79ff105f
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: humidity: hid-sensor-humidity: align parenthesis for readability
Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style
> diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
> index be2338d5f4070..6fed019f4099f 100644
> --- a/drivers/iio/humidity/hid-sensor-humidity.c
> +++ b/drivers/iio/humidity/hid-sensor-humidity.c
[ ... ]
> @@ -141,8 +141,8 @@ static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned int usage_id, size_t raw_len,
> - char *raw_data, void *pdev)
> + unsigned int usage_id, size_t raw_len,
> + char *raw_data, void *pdev)
[Severity: High]
This is a pre-existing issue, but is there a potential out-of-bounds read
and unaligned memory access here?
The HID sensor hub core invokes humidity_capture_sample() with raw_data
pointing to a field within a raw byte report buffer, and raw_len specifying
its exact byte size:
drivers/iio/humidity/hid-sensor-humidity.c:humidity_capture_sample() {
...
case HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY:
humid_st->scan.humidity_data = *(s32 *)raw_data;
return 0;
...
}
The driver unconditionally casts raw_data to a 32-bit integer pointer and
performs a 4-byte read. If raw_len is less than 4 (e.g., 1 or 2 bytes) and
the field resides at the end of the report buffer, does this result in an
out-of-bounds memory read?
Additionally, since HID reports are byte-packed, raw_data is not guaranteed
to be 32-bit aligned. Could an unaligned 32-bit read trigger a kernel panic
on architectures that strictly enforce alignment (e.g., ARMv5, SPARC)?
> {
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> struct hid_humidity_state *humid_st = iio_priv(indio_dev);
[ ... ]
> @@ -234,7 +234,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
> atomic_set(&humid_st->common_attributes.data_ready, 0);
>
> ret = hid_sensor_setup_trigger(indio_dev, name,
> - &humid_st->common_attributes);
> + &humid_st->common_attributes);
> if (ret)
> return ret;
>
> @@ -242,7 +242,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
>
> humidity_callbacks.pdev = pdev;
> ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_HUMIDITY,
> - &humidity_callbacks);
[Severity: High]
This isn't a bug introduced by this patch, but could this cause global state
corruption?
The humidity_callbacks struct is defined statically at the file scope. Here,
during hid_humidity_probe(), its pdev field is overwritten with the
instance-specific pdev.
The HID core (sensor_hub_register_callback()) stores the pointer to this
shared struct rather than copying its contents. If multiple humidity sensors
are probed, the global pdev will be overwritten by the last probed instance.
When sensor_hub_raw_event() processes an event, does it access callback->pdev
and erroneously route events from all connected sensors to the IIO device of
the last probed sensor, potentially causing data corruption or a
Use-After-Free if that device is later unbound?
> + &humidity_callbacks);
> if (ret)
> goto error_remove_trigger;
>
[Severity: High]
This is a pre-existing issue, but is there a possible list corruption and
use-after-free during device removal?
In hid_humidity_remove(), iio_device_unregister() is called before
sensor_hub_remove_callback(). This allows the HID sensor hub to continue
dispatching hardware events via the active callback while the IIO device is
being concurrently torn down.
When an event arrives, humidity_proc_event() checks the data_ready atomic
variable. Since this is an unlocked Time-Of-Check to Time-Of-Use race,
could data_ready be read as non-zero right before iio_device_unregister()
disables the trigger and clears it?
humidity_proc_event() then calls iio_push_to_buffers_with_timestamp(),
which iterates over the IIO buffer_list without taking locks.
Concurrently, iio_device_unregister() calls iio_disable_all_buffers()
which calls list_del_init() on the buffers. Does traversing a list
concurrently while elements are being removed and reinitialized cause
infinite loops or Use-After-Free crashes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: multitouch: set INPUT_PROP_PRESSUREPAD based on Digitizer/Button Type
From: Rong Zhang @ 2026-06-16 11:16 UTC (permalink / raw)
To: Peter Hutterer
Cc: devnull+peter.hutterer.who-t.net, bentiss, dmitry.torokhov, jikos,
linux-input, linux-kernel, linux-kselftest, shuah, vadim
In-Reply-To: <ajDO531wxzVZlL4g@quokka>
Hi Peter,
On Tue, 2026-06-16 at 14:24 +1000, Peter Hutterer wrote:
> Hi Rong,
>
> On Tue, Jun 02, 2026 at 01:25:57AM +0800, Rong Zhang wrote:
> >
> > Hi all,
> >
> > Hopefully I'm not too late to show up here.
> >
> > > From: Peter Hutterer <peter.hutterer@who-t.net>
> > >
> > > A Digitizer/Button Type value of 1 indicates the device is a
> > > pressurepad, see
> > > https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report
> > >
> > > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> > > ---
> > > drivers/hid/hid-multitouch.c | 12 +++++++++++-
> > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > > index 179dc316b4b518d78bdc900d9fd15756c5eba83e..382e6f50c4f7e663af7d028abb8be7cb2e6e7b8e 100644
> > > --- a/drivers/hid/hid-multitouch.c
> > > +++ b/drivers/hid/hid-multitouch.c
> > > @@ -81,6 +81,7 @@ MODULE_LICENSE("GPL");
> > > #define MT_INPUTMODE_TOUCHPAD 0x03
> > >
> > > #define MT_BUTTONTYPE_CLICKPAD 0
> > > +#define MT_BUTTONTYPE_PRESSUREPAD 1
> > >
> > > enum latency_mode {
> > > HID_LATENCY_NORMAL = 0,
> > > @@ -179,6 +180,7 @@ struct mt_device {
> > > __u8 inputmode_value; /* InputMode HID feature value */
> > > __u8 maxcontacts;
> > > bool is_buttonpad; /* is this device a button pad? */
> > > + bool is_pressurepad; /* is this device a pressurepad? */
> > > bool is_haptic_touchpad; /* is this device a haptic touchpad? */
> > > bool serial_maybe; /* need to check for serial protocol */
> > >
> > > @@ -530,8 +532,14 @@ static void mt_feature_mapping(struct hid_device *hdev,
> > > }
> > >
> > > mt_get_feature(hdev, field->report);
> > > - if (field->value[usage->usage_index] == MT_BUTTONTYPE_CLICKPAD)
> > > + switch (field->value[usage->usage_index]) {
> > > + case MT_BUTTONTYPE_CLICKPAD:
> > > td->is_buttonpad = true;
> > > + break;
> > > + case MT_BUTTONTYPE_PRESSUREPAD:
> > > + td->is_pressurepad = true;
> > > + break;
> > > + }
> > >
> > > break;
> > > case 0xff0000c5:
> > > @@ -1393,6 +1401,8 @@ static int mt_touch_input_configured(struct hid_device *hdev,
> > >
> > > if (td->is_buttonpad)
> > > __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
> > > + if (td->is_pressurepad)
> > > + __set_bit(INPUT_PROP_PRESSUREPAD, input->propbit);
> >
> > I noticed that this leads to dual reporting on my device.
> >
> > Consider previous checks:
> >
> > if (application == HID_DG_TOUCHPAD) {
> > mt_application->mt_flags |= INPUT_MT_POINTER;
> > td->inputmode_value = MT_INPUTMODE_TOUCHPAD;
> > }
> >
> > ...
> >
> > /* check for clickpads */
> > if ((app->mt_flags & INPUT_MT_POINTER) &&
> > (app->buttons_count == 1))
> > td->is_buttonpad = true;
> >
> > ... where `td->is_buttonpad' is set to true when a pressure pad has only
> > one button, i.e., the "touchpad button integrated with digitizer" [1].
> > Most (if not all) pressure pads fall into this category. As a result,
> > the presence of INPUT_PROP_PRESSUREPAD is always accompanied by the
> > presence of INPUT_PROP_BUTTONPAD.
>
> Yes, this is intended, see commit
> ae8966b7b5bd69b86209cc34bcca1ba9f18b68e6 which lists this in the commit
> message:
>
> ```
> This means:
> - clickpad: INPUT_PROP_BUTTONPAD
> - pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD
> - pressurepad with configurable haptics:
> INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD + FF_HAPTIC
> ```
>
> We have to keep setting BUTTONPAD on all pressurepads because otherwise
> we'd break existing userspace which relies on this.
Thanks a lot for your explanation. It makes sense to me.
Thanks,
Rong
>
> Cheers,
> Peter
>
^ permalink raw reply
* Re: [PATCH 01/11] iio: hid-sensors: add missing blank line after declarations
From: sashiko-bot @ 2026-06-16 11:22 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-1-0cd544286575@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but pending asynchronous suspend work is cancelled during device removal, leaving hardware powered on indefinitely.
--
commit fb90a2bc06515600f67795b51872db81c06e23a2
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: hid-sensors: add missing blank line after declarations
Add a blank line after variable declarations to improve
readability and align with kernel coding style.
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 417c4ab8c1b27..c8ccf96f3d035 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -314,7 +314,9 @@ static int __maybe_unused hid_sensor_resume(struct device *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
> +
> schedule_work(&attrb->work);
> +
> return 0;
> }
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem where
pending asynchronous suspend work might be cancelled during device removal,
leaving the hardware powered on indefinitely.
During driver removal, iio_device_unregister() disables active iio buffers,
triggering buffer_predisable(). This calls hid_sensor_power_state() with
state false, which queues an asynchronous suspend:
hid_sensor_power_state() {
...
} else {
atomic_dec(&st->user_requested_state);
pm_runtime_use_autosuspend(&st->pdev->dev);
ret = pm_runtime_put_autosuspend(&st->pdev->dev);
}
...
}
Immediately after, hid_sensor_remove_trigger() is called:
hid_sensor_remove_trigger() {
if (atomic_read(&attrb->runtime_pm_enable))
pm_runtime_disable(&attrb->pdev->dev);
pm_runtime_set_suspended(&attrb->pdev->dev);
...
}
Because pm_runtime_disable() cancels any pending asynchronous idle/suspend
work, is it possible the autosuspend work gets cancelled before execution?
If the work is cancelled, pm_runtime_set_suspended() would only update the
software pm state, leaving the actual physical hardware permanently powered
on. Does the driver need a synchronous suspend in the removal path before
disabling runtime pm?
>
> @@ -322,6 +324,7 @@ static int __maybe_unused hid_sensor_runtime_resume(struct device *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
> +
> return _hid_sensor_power_state(attrb, true);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 04/11] iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability
From: sashiko-bot @ 2026-06-16 11:19 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-4-0cd544286575@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Blindly reading 32 or 64 bits from `raw_data` without verifying `raw_len` can lead to slab-out-of-bounds reads.
--
commit 13804edb2c46947f67fe0d4d5d050f780422d2f7
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability
This commit adjusts the alignment of parentheses across multiple functions in
the hid-sensor-magn-3d driver. This improves readability and maintains
consistency with the kernel coding style.
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index 23884825eb00f..82507297c55bb 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
[ ... ]
> @@ -292,9 +291,9 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int magn_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> - u32 usage_id,
> - size_t raw_len, char *raw_data,
> - void *priv)
> + u32 usage_id,
> + size_t raw_len, char *raw_data,
> + void *priv)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(priv);
> struct magn_3d_state *magn_state = iio_priv(indio_dev);
[Severity: High]
This is a pre-existing issue, but since this patch touches the signature of
magn_3d_capture_sample(), could we be at risk of a slab out-of-bounds read
further down in the function?
If a device presents a crafted HID report descriptor that defines the
HID_USAGE_SENSOR_TIME_TIMESTAMP field with a smaller size, it could result in
raw_len being less than 8. Reading 8 bytes from raw_data in this case:
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
magn_state->timestamp =
hid_sensor_convert_timestamp(&magn_state->magn_flux_attributes,
*(s64 *)raw_data);
would read past the end of the buffer.
A similar dereference happens later in the function for the magnetic axes
where 4 bytes are read:
iio_val = magn_state->magn_val_addr[offset];
if (iio_val != NULL)
*iio_val = *((u32 *)raw_data);
Could this also trigger an out-of-bounds read if raw_len is smaller than 4?
Should we verify the size of raw_len before making these casts?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=4
^ permalink raw reply
* [PATCH 11/11] iio: hid-sensor-accel-3d: use ! instead of explicit NULL check
From: Sanjay Chitroda @ 2026-06-16 11:11 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada, David Lechner, Nuno Sá,
Andy Shevchenko
Cc: linux-input, linux-iio, linux-kernel
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/accel/hid-sensor-accel-3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 42c4259bf209..0999f7dbf434 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -329,7 +329,7 @@ static int hid_accel_3d_probe(struct platform_device *pdev)
indio_dev = devm_iio_device_alloc(&pdev->dev,
sizeof(struct accel_3d_state));
- if (indio_dev == NULL)
+ if (!indio_dev)
return -ENOMEM;
platform_set_drvdata(pdev, indio_dev);
--
2.34.1
^ permalink raw reply related
* [PATCH 11/11] iio: hid-sensor-accel-3d: use ! instead of explicit NULL check
From: Sanjay Chitroda @ 2026-06-16 11:01 UTC (permalink / raw)
To: jikos, jic23, srinivas.pandruvada, David Lechner, Nuno Sá,
Andy Shevchenko
Cc: linux-input, linux-iio, linux-kernel
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-950d25a05d9a@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/accel/hid-sensor-accel-3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 42c4259bf209..0999f7dbf434 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -329,7 +329,7 @@ static int hid_accel_3d_probe(struct platform_device *pdev)
indio_dev = devm_iio_device_alloc(&pdev->dev,
sizeof(struct accel_3d_state));
- if (indio_dev == NULL)
+ if (!indio_dev)
return -ENOMEM;
platform_set_drvdata(pdev, indio_dev);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 08/11] iio: hid-sensor-magn-3d: use ! instead of explicit NULL check
From: Joshua Crofts @ 2026-06-16 11:01 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada, linux-iio, linux-kernel,
linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-8-0cd544286575@gmail.com>
On Tue, 16 Jun 2026 15:56:13 +0530
Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
> the preferred kernel style.
>
> No functional change.
>
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---
Couldn't all of these null check patches be squashed into one,
considering these are all the same logical change and affect
HID drivers? Surely this is code churn a bit.
Same goes for the parentheses alignment patches.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH 02/11] iio: humidity: hid-sensor-humidity: align parenthesis for readability
From: Andy Shevchenko @ 2026-06-16 10:57 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada, linux-iio, linux-kernel,
linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-2-0cd544286575@gmail.com>
On Tue, Jun 16, 2026 at 03:56:07PM +0530, Sanjay Chitroda wrote:
> Adjust alignment of parentheses to improve readability and
> maintain consistency with kernel coding style
Same comment about punctuation.
...
> /* Callback handler to send event after all samples are received and captured */
> static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned int usage_id, void *pdev)
> + unsigned int usage_id, void *pdev)
Shouldn't usage_id be u32 to begin with? Can you check what's going on there?
(It used to be a change to implement that, maybe it was not comprehensive one and
needs a part 2?)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 03/11] iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability
From: Andy Shevchenko @ 2026-06-16 10:56 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada, linux-iio, linux-kernel,
linux-input
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-3-0cd544286575@gmail.com>
On Tue, Jun 16, 2026 at 03:56:08PM +0530, Sanjay Chitroda wrote:
> Adjust alignment of parentheses to improve readability and
> maintain consistency with kernel coding style
Respect English grammar and punctuation.
...
> /* Channel write_raw handler */
> static int gyro_3d_write_raw(struct iio_dev *indio_dev,
> - struct iio_chan_spec const *chan,
> - int val,
> - int val2,
> - long mask)
> + struct iio_chan_spec const *chan,
> + int val,
> + int val2,
> + long mask)
In cases like this have a chance to (re-)split logically.
static int gyro_3d_write_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int val, int val2, long mask)
...
These comments for the entire series.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: Add PMIH0108 haptics device node
From: Konrad Dybcio @ 2026-06-16 10:27 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-4-d24e422de6b4@oss.qualcomm.com>
On 6/16/26 12:08 PM, Fenglin Wu wrote:
> Add haptics device node in the PMIH0108 PMIC base dtsi files, and enable
> it on several boards according to the LRA (Linear Resonant Actuator)
> component mounted on each of them.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi | 9 +++++++++
> arch/arm64/boot/dts/qcom/pmih0108.dtsi | 9 +++++++++
> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +++++++
One commit per board, please
> 6 files changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> index 07247dc98b70..7e3f59fc008e 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> @@ -952,6 +952,13 @@ wifi@0 {
> };
> };
>
> +&pmih0108_e1_haptics {
> + status = "okay";
'status' should go last
> +
> + qcom,lra-period-us = <6667>;
> + qcom,vmax-mv = <3600>;
Do these properties depend on the physical characteristics on what's
connected to the other end of the haptics driver?
Konrad
^ permalink raw reply
* [PATCH 10/11] iio: hid-sensor-incl-3d: use ! instead of explicit NULL check
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/orientation/hid-sensor-incl-3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c b/drivers/iio/orientation/hid-sensor-incl-3d.c
index c7fbff498be7..4c4b0ef2e01c 100644
--- a/drivers/iio/orientation/hid-sensor-incl-3d.c
+++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
@@ -307,7 +307,7 @@ static int hid_incl_3d_probe(struct platform_device *pdev)
indio_dev = devm_iio_device_alloc(&pdev->dev,
sizeof(struct incl_3d_state));
- if (indio_dev == NULL)
+ if (!indio_dev)
return -ENOMEM;
platform_set_drvdata(pdev, indio_dev);
--
2.34.1
^ permalink raw reply related
* [PATCH 09/11] iio: hid-sensor-rotation: use ! instead of explicit NULL check
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/orientation/hid-sensor-rotation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
index 20563d8efaf6..fc925ec12d37 100644
--- a/drivers/iio/orientation/hid-sensor-rotation.c
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -278,7 +278,7 @@ static int hid_dev_rot_probe(struct platform_device *pdev)
indio_dev = devm_iio_device_alloc(&pdev->dev,
sizeof(struct dev_rot_state));
- if (indio_dev == NULL)
+ if (!indio_dev)
return -ENOMEM;
platform_set_drvdata(pdev, indio_dev);
--
2.34.1
^ permalink raw reply related
* [PATCH 08/11] iio: hid-sensor-magn-3d: use ! instead of explicit NULL check
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.
No functional change.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 82507297c55b..8f7a0b2bd795 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -467,7 +467,7 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
indio_dev = devm_iio_device_alloc(&pdev->dev,
sizeof(struct magn_3d_state));
- if (indio_dev == NULL)
+ if (!indio_dev)
return -ENOMEM;
platform_set_drvdata(pdev, indio_dev);
--
2.34.1
^ permalink raw reply related
* [PATCH 07/11] iio: temperature: hid-sensor-temperature: use common device for devres
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.
Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).
The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.
Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/temperature/hid-sensor-temperature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
index 9f628a8e5cfb..31ebfd1a1fe2 100644
--- a/drivers/iio/temperature/hid-sensor-temperature.c
+++ b/drivers/iio/temperature/hid-sensor-temperature.c
@@ -213,8 +213,8 @@ static int hid_temperature_probe(struct platform_device *pdev)
if (ret)
return ret;
- temp_chans = devm_kmemdup(&indio_dev->dev, temperature_channels,
- sizeof(temperature_channels), GFP_KERNEL);
+ temp_chans = devm_kmemdup(&pdev->dev, temperature_channels,
+ sizeof(temperature_channels), GFP_KERNEL);
if (!temp_chans)
return -ENOMEM;
--
2.34.1
^ permalink raw reply related
* [PATCH 06/11] iio: position: hid-sensor-custom-intel-hinge: use common device for devres
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.
Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).
The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.
Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/position/hid-sensor-custom-intel-hinge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/position/hid-sensor-custom-intel-hinge.c b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
index a26d391661fd..0ba9d2d43913 100644
--- a/drivers/iio/position/hid-sensor-custom-intel-hinge.c
+++ b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
@@ -292,7 +292,7 @@ static int hid_hinge_probe(struct platform_device *pdev)
}
indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
- indio_dev->channels = devm_kmemdup(&indio_dev->dev, hinge_channels,
+ indio_dev->channels = devm_kmemdup(&pdev->dev, hinge_channels,
sizeof(hinge_channels), GFP_KERNEL);
if (!indio_dev->channels)
return -ENOMEM;
--
2.34.1
^ permalink raw reply related
* [PATCH 05/11] iio: humidity: hid-sensor-humidity: use common device for devres
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda, Zhang Lixu
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.
Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).
The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.
Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Tested-by: Zhang Lixu <lixu.zhang@intel.com>
---
drivers/iio/humidity/hid-sensor-humidity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
index 6fed019f4099..73120b87d641 100644
--- a/drivers/iio/humidity/hid-sensor-humidity.c
+++ b/drivers/iio/humidity/hid-sensor-humidity.c
@@ -215,7 +215,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
if (ret)
return ret;
- humid_chans = devm_kmemdup(&indio_dev->dev, humidity_channels,
+ humid_chans = devm_kmemdup(&pdev->dev, humidity_channels,
sizeof(humidity_channels), GFP_KERNEL);
if (!humid_chans)
return -ENOMEM;
--
2.34.1
^ permalink raw reply related
* [PATCH 04/11] iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 78 +++++++++++++--------------
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 23884825eb00..82507297c55b 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -135,9 +135,9 @@ static const struct iio_chan_spec magn_3d_channels[] = {
/* Channel read_raw handler */
static int magn_3d_read_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int *val, int *val2,
- long mask)
+ struct iio_chan_spec const *chan,
+ int *val, int *val2,
+ long mask)
{
struct magn_3d_state *magn_state = iio_priv(indio_dev);
int report_id = -1;
@@ -167,8 +167,7 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
false);
return -EINVAL;
}
- hid_sensor_power_state(&magn_state->magn_flux_attributes,
- false);
+ hid_sensor_power_state(&magn_state->magn_flux_attributes, false);
ret_type = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_SCALE:
@@ -229,10 +228,10 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
/* Channel write_raw handler */
static int magn_3d_write_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int val,
- int val2,
- long mask)
+ struct iio_chan_spec const *chan,
+ int val,
+ int val2,
+ long mask)
{
struct magn_3d_state *magn_state = iio_priv(indio_dev);
int ret = 0;
@@ -270,8 +269,8 @@ static const struct iio_info magn_3d_info = {
/* Callback handler to send event after all samples are received and captured */
static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
- u32 usage_id,
- void *priv)
+ u32 usage_id,
+ void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
struct magn_3d_state *magn_state = iio_priv(indio_dev);
@@ -292,9 +291,9 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int magn_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
- u32 usage_id,
- size_t raw_len, char *raw_data,
- void *priv)
+ u32 usage_id,
+ size_t raw_len, char *raw_data,
+ void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
struct magn_3d_state *magn_state = iio_priv(indio_dev);
@@ -353,11 +352,12 @@ static int magn_3d_parse_report(struct platform_device *pdev,
u32 address = magn_3d_addresses[i];
/* Check if usage attribute exists in the sensor hub device */
- status = sensor_hub_input_get_attribute_info(hsdev,
- HID_INPUT_REPORT,
- usage_id,
- address,
- &(st->magn[i]));
+ status = sensor_hub_input_get_attribute_info(
+ hsdev,
+ HID_INPUT_REPORT,
+ usage_id,
+ address,
+ &(st->magn[i]));
if (!status)
attr_count++;
}
@@ -368,18 +368,17 @@ static int magn_3d_parse_report(struct platform_device *pdev,
return -EINVAL;
}
- dev_dbg(&pdev->dev, "magn_3d Found %d usage attributes\n",
- attr_count);
+ dev_dbg(&pdev->dev, "magn_3d Found %d usage attributes\n", attr_count);
dev_dbg(&pdev->dev, "magn_3d X: %x:%x Y: %x:%x Z: %x:%x\n",
- st->magn[0].index,
- st->magn[0].report_id,
- st->magn[1].index, st->magn[1].report_id,
- st->magn[2].index, st->magn[2].report_id);
+ st->magn[0].index,
+ st->magn[0].report_id,
+ st->magn[1].index, st->magn[1].report_id,
+ st->magn[2].index, st->magn[2].report_id);
/* Setup IIO channel array */
_channels = devm_kcalloc(&pdev->dev, attr_count,
- sizeof(struct iio_chan_spec),
- GFP_KERNEL);
+ sizeof(struct iio_chan_spec),
+ GFP_KERNEL);
if (!_channels) {
dev_err(&pdev->dev,
"failed to allocate space for iio channels\n");
@@ -426,8 +425,7 @@ static int magn_3d_parse_report(struct platform_device *pdev,
*channels = _channels;
- dev_dbg(&pdev->dev, "magn_3d Setup %d IIO channels\n",
- *chan_count);
+ dev_dbg(&pdev->dev, "magn_3d Setup %d IIO channels\n", *chan_count);
st->magn_flux_attr.scale_precision = hid_sensor_format_scale(
HID_USAGE_SENSOR_COMPASS_3D,
@@ -442,7 +440,8 @@ static int magn_3d_parse_report(struct platform_device *pdev,
&st->rot_attr.scale_post_decml);
if (st->rot_attributes.sensitivity.index < 0) {
- sensor_hub_input_get_attribute_info(hsdev,
+ sensor_hub_input_get_attribute_info(
+ hsdev,
HID_FEATURE_REPORT, usage_id,
HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH,
@@ -477,11 +476,12 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
magn_state->magn_flux_attributes.hsdev = hsdev;
magn_state->magn_flux_attributes.pdev = pdev;
- ret = hid_sensor_parse_common_attributes(hsdev,
- HID_USAGE_SENSOR_COMPASS_3D,
- &magn_state->magn_flux_attributes,
- magn_3d_sensitivity_addresses,
- ARRAY_SIZE(magn_3d_sensitivity_addresses));
+ ret = hid_sensor_parse_common_attributes(
+ hsdev,
+ HID_USAGE_SENSOR_COMPASS_3D,
+ &magn_state->magn_flux_attributes,
+ magn_3d_sensitivity_addresses,
+ ARRAY_SIZE(magn_3d_sensitivity_addresses));
if (ret) {
dev_err(&pdev->dev, "failed to setup common attributes\n");
return ret;
@@ -491,8 +491,8 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
magn_state->rot_attributes.sensitivity.index = -1;
ret = magn_3d_parse_report(pdev, hsdev,
- &channels, &chan_count,
- HID_USAGE_SENSOR_COMPASS_3D, magn_state);
+ &channels, &chan_count,
+ HID_USAGE_SENSOR_COMPASS_3D, magn_state);
if (ret) {
dev_err(&pdev->dev, "failed to parse report\n");
return ret;
@@ -507,7 +507,7 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
atomic_set(&magn_state->magn_flux_attributes.data_ready, 0);
ret = hid_sensor_setup_trigger(indio_dev, name,
- &magn_state->magn_flux_attributes);
+ &magn_state->magn_flux_attributes);
if (ret < 0) {
dev_err(&pdev->dev, "trigger setup failed\n");
return ret;
@@ -523,7 +523,7 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
magn_state->callbacks.capture_sample = magn_3d_capture_sample;
magn_state->callbacks.pdev = pdev;
ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_COMPASS_3D,
- &magn_state->callbacks);
+ &magn_state->callbacks);
if (ret < 0) {
dev_err(&pdev->dev, "callback reg failed\n");
goto error_iio_unreg;
--
2.34.1
^ permalink raw reply related
* [PATCH 03/11] iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 58 +++++++++++++++++------------------
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index bbca2111e79b..fa604cf26d06 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -85,9 +85,9 @@ static const struct iio_chan_spec gyro_3d_channels[] = {
/* Channel read_raw handler */
static int gyro_3d_read_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int *val, int *val2,
- long mask)
+ struct iio_chan_spec const *chan,
+ int *val, int *val2,
+ long mask)
{
struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
int report_id = -1;
@@ -112,8 +112,7 @@ static int gyro_3d_read_raw(struct iio_dev *indio_dev,
min < 0);
else {
*val = 0;
- hid_sensor_power_state(&gyro_state->common_attributes,
- false);
+ hid_sensor_power_state(&gyro_state->common_attributes, false);
return -EINVAL;
}
hid_sensor_power_state(&gyro_state->common_attributes, false);
@@ -146,10 +145,10 @@ static int gyro_3d_read_raw(struct iio_dev *indio_dev,
/* Channel write_raw handler */
static int gyro_3d_write_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int val,
- int val2,
- long mask)
+ struct iio_chan_spec const *chan,
+ int val,
+ int val2,
+ long mask)
{
struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
int ret = 0;
@@ -177,8 +176,8 @@ static const struct iio_info gyro_3d_info = {
/* Callback handler to send event after all samples are received and captured */
static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
- u32 usage_id,
- void *priv)
+ u32 usage_id,
+ void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
@@ -199,9 +198,9 @@ static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int gyro_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
- u32 usage_id,
- size_t raw_len, char *raw_data,
- void *priv)
+ u32 usage_id,
+ size_t raw_len, char *raw_data,
+ void *priv)
{
struct iio_dev *indio_dev = platform_get_drvdata(priv);
struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
@@ -240,11 +239,12 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
int ret;
for (unsigned int ch = CHANNEL_SCAN_INDEX_X; ch <= CHANNEL_SCAN_INDEX_Z; ch++) {
- ret = sensor_hub_input_get_attribute_info(hsdev,
- HID_INPUT_REPORT,
- usage_id,
- HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + ch,
- &st->gyro[ch]);
+ ret = sensor_hub_input_get_attribute_info(
+ hsdev,
+ HID_INPUT_REPORT,
+ usage_id,
+ HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + ch,
+ &st->gyro[ch]);
if (ret < 0)
break;
channels[ch].scan_type = (struct iio_scan_type) {
@@ -254,10 +254,10 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
};
}
dev_dbg(&pdev->dev, "gyro_3d %x:%x, %x:%x, %x:%x\n",
- st->gyro[0].index,
- st->gyro[0].report_id,
- st->gyro[1].index, st->gyro[1].report_id,
- st->gyro[2].index, st->gyro[2].report_id);
+ st->gyro[0].index,
+ st->gyro[0].report_id,
+ st->gyro[1].index, st->gyro[1].report_id,
+ st->gyro[2].index, st->gyro[2].report_id);
st->scale_precision = hid_sensor_format_scale(
HID_USAGE_SENSOR_GYRO_3D,
@@ -286,10 +286,10 @@ static int hid_gyro_3d_probe(struct platform_device *pdev)
gyro_state->common_attributes.pdev = pdev;
ret = hid_sensor_parse_common_attributes(hsdev,
- HID_USAGE_SENSOR_GYRO_3D,
- &gyro_state->common_attributes,
- gyro_3d_sensitivity_addresses,
- ARRAY_SIZE(gyro_3d_sensitivity_addresses));
+ HID_USAGE_SENSOR_GYRO_3D,
+ &gyro_state->common_attributes,
+ gyro_3d_sensitivity_addresses,
+ ARRAY_SIZE(gyro_3d_sensitivity_addresses));
if (ret) {
dev_err(&pdev->dev, "failed to setup common attributes\n");
return ret;
@@ -318,7 +318,7 @@ static int hid_gyro_3d_probe(struct platform_device *pdev)
atomic_set(&gyro_state->common_attributes.data_ready, 0);
ret = hid_sensor_setup_trigger(indio_dev, name,
- &gyro_state->common_attributes);
+ &gyro_state->common_attributes);
if (ret < 0) {
dev_err(&pdev->dev, "trigger setup failed\n");
return ret;
@@ -334,7 +334,7 @@ static int hid_gyro_3d_probe(struct platform_device *pdev)
gyro_state->callbacks.capture_sample = gyro_3d_capture_sample;
gyro_state->callbacks.pdev = pdev;
ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_GYRO_3D,
- &gyro_state->callbacks);
+ &gyro_state->callbacks);
if (ret < 0) {
dev_err(&pdev->dev, "callback reg failed\n");
goto error_iio_unreg;
--
2.34.1
^ permalink raw reply related
* [PATCH 02/11] iio: humidity: hid-sensor-humidity: align parenthesis for readability
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
drivers/iio/humidity/hid-sensor-humidity.c | 46 +++++++++++++++---------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
index be2338d5f407..6fed019f4099 100644
--- a/drivers/iio/humidity/hid-sensor-humidity.c
+++ b/drivers/iio/humidity/hid-sensor-humidity.c
@@ -45,7 +45,7 @@ static const struct iio_chan_spec humidity_channels[] = {
/* Adjust channel real bits based on report descriptor */
static void humidity_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
+ int channel, int size)
{
channels[channel].scan_type.sign = 's';
/* Real storage bits will change based on the report desc. */
@@ -55,8 +55,8 @@ static void humidity_adjust_channel_bit_mask(struct iio_chan_spec *channels,
}
static int humidity_read_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int *val, int *val2, long mask)
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
{
struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -101,8 +101,8 @@ static int humidity_read_raw(struct iio_dev *indio_dev,
}
static int humidity_write_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int val, int val2, long mask)
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
{
struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -127,7 +127,7 @@ static const struct iio_info humidity_info = {
/* Callback handler to send event after all samples are received and captured */
static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
- unsigned int usage_id, void *pdev)
+ unsigned int usage_id, void *pdev)
{
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -141,8 +141,8 @@ static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
/* Capture samples in local storage */
static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
- unsigned int usage_id, size_t raw_len,
- char *raw_data, void *pdev)
+ unsigned int usage_id, size_t raw_len,
+ char *raw_data, void *pdev)
{
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -159,17 +159,17 @@ static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
/* Parse report which is specific to an usage id */
static int humidity_parse_report(struct platform_device *pdev,
- struct hid_sensor_hub_device *hsdev,
- struct iio_chan_spec *channels,
- unsigned int usage_id,
- struct hid_humidity_state *st)
+ struct hid_sensor_hub_device *hsdev,
+ struct iio_chan_spec *channels,
+ unsigned int usage_id,
+ struct hid_humidity_state *st)
{
int ret;
ret = sensor_hub_input_get_attribute_info(hsdev, HID_INPUT_REPORT,
- usage_id,
- HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY,
- &st->humidity_attr);
+ usage_id,
+ HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY,
+ &st->humidity_attr);
if (ret < 0)
return ret;
@@ -208,20 +208,20 @@ static int hid_humidity_probe(struct platform_device *pdev)
humid_st->common_attributes.pdev = pdev;
ret = hid_sensor_parse_common_attributes(hsdev,
- HID_USAGE_SENSOR_HUMIDITY,
- &humid_st->common_attributes,
- humidity_sensitivity_addresses,
- ARRAY_SIZE(humidity_sensitivity_addresses));
+ HID_USAGE_SENSOR_HUMIDITY,
+ &humid_st->common_attributes,
+ humidity_sensitivity_addresses,
+ ARRAY_SIZE(humidity_sensitivity_addresses));
if (ret)
return ret;
humid_chans = devm_kmemdup(&indio_dev->dev, humidity_channels,
- sizeof(humidity_channels), GFP_KERNEL);
+ sizeof(humidity_channels), GFP_KERNEL);
if (!humid_chans)
return -ENOMEM;
ret = humidity_parse_report(pdev, hsdev, humid_chans,
- HID_USAGE_SENSOR_HUMIDITY, humid_st);
+ HID_USAGE_SENSOR_HUMIDITY, humid_st);
if (ret)
return ret;
@@ -234,7 +234,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
atomic_set(&humid_st->common_attributes.data_ready, 0);
ret = hid_sensor_setup_trigger(indio_dev, name,
- &humid_st->common_attributes);
+ &humid_st->common_attributes);
if (ret)
return ret;
@@ -242,7 +242,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
humidity_callbacks.pdev = pdev;
ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_HUMIDITY,
- &humidity_callbacks);
+ &humidity_callbacks);
if (ret)
goto error_remove_trigger;
--
2.34.1
^ permalink raw reply related
* [PATCH 01/11] iio: hid-sensors: add missing blank line after declarations
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda
In-Reply-To: <20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com>
From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Add a blank line after variable declarations to improve
readability and align with kernel coding style.
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
changes in v4:
- Rectify commit message with input from David
---
drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
index 417c4ab8c1b2..c8ccf96f3d03 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -314,7 +314,9 @@ static int __maybe_unused hid_sensor_resume(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
+
schedule_work(&attrb->work);
+
return 0;
}
@@ -322,6 +324,7 @@ static int __maybe_unused hid_sensor_runtime_resume(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
+
return _hid_sensor_power_state(attrb, true);
}
--
2.34.1
^ permalink raw reply related
* [PATCH 00/11] HID: iio: warning clean up and prefer kernel coding style
From: Sanjay Chitroda @ 2026-06-16 10:26 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jiri Kosina, Srinivas Pandruvada
Cc: linux-iio, linux-kernel, linux-input, Sanjay Chitroda, Zhang Lixu
Hi all,
This series updates HID IIO drivers to resolve checkpatch and
kernel coding style issue.
This improves readability and follow standard kernel coding style
No functional changes are introduced.
Testing:
- Compiled with W=1 for each patch in the series
---
Sanjay Chitroda (11):
iio: hid-sensors: add missing blank line after declarations
iio: humidity: hid-sensor-humidity: align parenthesis for readability
iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability
iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability
iio: humidity: hid-sensor-humidity: use common device for devres
iio: position: hid-sensor-custom-intel-hinge: use common device for devres
iio: temperature: hid-sensor-temperature: use common device for devres
iio: hid-sensor-magn-3d: use ! instead of explicit NULL check
iio: hid-sensor-rotation: use ! instead of explicit NULL check
iio: hid-sensor-incl-3d: use ! instead of explicit NULL check
iio: hid-sensor-accel-3d: use ! instead of explicit NULL check
drivers/iio/accel/hid-sensor-accel-3d.c | 2 +-
.../iio/common/hid-sensors/hid-sensor-trigger.c | 3 +
drivers/iio/gyro/hid-sensor-gyro-3d.c | 58 ++++++++--------
drivers/iio/humidity/hid-sensor-humidity.c | 48 ++++++-------
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 80 +++++++++++-----------
drivers/iio/orientation/hid-sensor-incl-3d.c | 2 +-
drivers/iio/orientation/hid-sensor-rotation.c | 2 +-
.../iio/position/hid-sensor-custom-intel-hinge.c | 2 +-
drivers/iio/temperature/hid-sensor-temperature.c | 4 +-
9 files changed, 102 insertions(+), 99 deletions(-)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260615-15-jun-hid-iio-alignment-46bba7279be3
Best regards,
--
Sanjay Chitroda <sanjayembeddedse@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Konrad Dybcio @ 2026-06-16 10:25 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-3-d24e422de6b4@oss.qualcomm.com>
On 6/16/26 12:08 PM, Fenglin Wu wrote:
> Add an initial driver for the Qualcomm PMIH010x PMIC haptics module,
> named as HAP530_HV. This module supports several play modes, including
> DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
> and hardware data handling logic. Currently, the driver provides support
> for two play modes using the input force-feedback framework: FF_CONSTANT
> effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
> waveform for FIFO mode.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
[...]
> +static int cfg_write(struct qcom_haptics *h, u32 off, u32 val)
static inline
although I have mixed feelings about having so many accessors
[...]
> +static int haptics_write_fifo_chunk(struct qcom_haptics *h,
> + const s8 *data, u32 len)
> +{
> + u32 i, bulk_len = ALIGN_DOWN(len, 4);
Please avoid mixing multiple declarations and assignments
> + int ret;
> +
> + for (i = 0; i < bulk_len; i += 4) {
You can do 'int i' in loops nowadays
> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
> + if (ret)
> + return ret;
> + }
> +
> + for (; i < len; i++) {
> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
> + if (ret)
> + return ret;
> + }
So if i'm reading this right, the first loop will always write
4*(len//4) bytes and the second one will be entered at most once,
to write len rem 4 bytes.. should this be an if instead?
> +
> + return 0;
> +}
> +
> +/*
> + * Configure the hardware FIFO memory boundary.
> + * FIFO occupies addresses [0, fifo_len).
> + */
> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
> +{
> + u32 fifo_len, fifo_units;
> +
> + /* Config all memory space for FIFO usage for now */
What's the not-"for now" endgame for this?
> + fifo_len = HAP530_MEM_TOTAL_BYTES;
> + fifo_len = ALIGN_DOWN(fifo_len, 64);
> + fifo_units = fifo_len / 64;
> + h->fifo_len = fifo_len;
> +
> + return ptn_write(h, HAP_PTN_MMAP_FIFO_REG,
> + MMAP_FIFO_EXIST_BIT |
> + FIELD_PREP(MMAP_FIFO_LEN_MASK, fifo_units - 1));
> +}
> +
> +static u32 haptics_gain_scaled_vmax(struct qcom_haptics *h, u32 vmax_mv)
> +{
> + u32 v = (u32)((u64)vmax_mv * h->gain / 0xFFFF);
mult_frac()
> +
> + return max_t(u32, v, VMAX_STEP_MV);
> +}
> +
> +static void haptics_fifo_irq_enable(struct qcom_haptics *h, bool enable)
> +{
> + if (h->irq_enabled == enable)
> + return;
> +
> + if (enable)
> + enable_irq(h->fifo_empty_irq);
> + else
> + disable_irq_nosync(h->fifo_empty_irq);
This is called in the .remove() path, I think you may need the
sync variant as the underlying device may be destroyed before the
ISR completes if there's a late interrupt
[...]
> +static int haptics_playback(struct input_dev *dev, int effect_id, int val)
> +{
> + struct qcom_haptics *h = input_get_drvdata(dev);
> +
> + h->cur_effect_id = effect_id;
> + h->play_request = (val > 0);
> + schedule_work(&h->play_work);
> + return 0;
nit: \n before return is 'nice'
[...]
> + ret = device_property_read_u32_array(&pdev->dev, "reg", regs,
> + ARRAY_SIZE(regs));
Here you use device_property_
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to read 'reg' property\n");
> +
> + h->cfg_base = regs[0];
> + h->ptn_base = regs[1];
> +
> + ret = of_property_read_u32(h->dev->of_node, "qcom,lra-period-us",
> + &h->t_lra_us);
And here you use of_property_ (please use device_)
[...]
> + input->name = "qcom-spmi-haptics";
Odd whitespace
Konrad
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox