* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Lee Jones @ 2026-05-06 9:16 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260504-wip-fix-core-v3-0-ce1f11f4968f@kernel.org>
On Mon, 04 May 2026, Benjamin Tissoires wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()") enforced the provided data to be at least the size of
> the declared buffer in the report descriptor to prevent a buffer
> overflow.
>
> We only had corner cases of malicious devices exposing the OOM because
> in most cases, the buffer provided by the transport layer needs to be
> allocated at probe time and is large enough to handle all the possible
> reports.
>
> However, the patch from above, which enforces the spec a little bit more
> introduced both regressions for devices not following the spec (not
> necesserally malicious), but also a stream of errors for those devices.
>
> Let's revert to the old behavior by giving more information to HID core
> to be able to decide whether it can or not memset the rest of the buffer
> to 0 and continue the processing.
>
> Note that the first commit makes an API change, but the callers are
> relatively limited, so it should be fine on its own. The second patch
> can't really make the same kind of API change because we have too many
> callers in various subsystems. We can switch them one by one to the safe
> approach when needed.
>
> The last 2 patches are small cleanups I initially put together with the
> 2 first patches, but they can be applied on their own and don't need to
> be pulled in stable like the first 2.
>
> Cheers,
> Benjamin
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> ---
> Changes in v3:
> - fixed ghib -> ghid in greybus
> - fixed i386 size_t debug size reported by kernel-bot
> - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
>
> Changes in v2:
> - added a small blurb explaining the difference between the safe and the
> non safe version of hid_safe_input_report
> - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
>
> ---
> Benjamin Tissoires (4):
> HID: pass the buffer size to hid_report_raw_event
> HID: core: introduce hid_safe_input_report()
> HID: multitouch: use __free(kfree) to clean up temporary buffers
> HID: wacom: use __free(kfree) to clean up temporary buffers
>
> drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> drivers/hid/hid-gfrm.c | 4 +--
> drivers/hid/hid-logitech-hidpp.c | 2 +-
> drivers/hid/hid-multitouch.c | 18 ++++------
> drivers/hid/hid-primax.c | 2 +-
> drivers/hid/hid-vivaldi-common.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> drivers/hid/usbhid/hid-core.c | 11 ++++---
> drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> drivers/staging/greybus/hid.c | 2 +-
> include/linux/hid.h | 6 ++--
> include/linux/hid_bpf.h | 14 +++++---
> 13 files changed, 109 insertions(+), 78 deletions(-)
What's the plan for this set Benjamin? -rcs or -next?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Linus Walleij @ 2026-05-06 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Svyatoslav Ryhel, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260506-nautilus-of-abstract-efficiency-eebe94@quoll>
On Wed, May 6, 2026 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, May 03, 2026 at 07:52:42PM +0300, Svyatoslav Ryhel wrote:
> > Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> > handheld devices and capable of supporting up to two motors.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Tested-by: Linus Walleij <linusw@kernel.org> # Samsung GT-I9070 Janice
>
> Drop the tag here, you cannot test a binding. It's not possible or
> otherwise explain how YAML file was tested by this device.
Right, I was probably sloppy and replied Tested-by on the cover
letter.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Krzysztof Kozlowski @ 2026-05-06 7:39 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, linux-input, devicetree, linux-kernel
In-Reply-To: <20260503165243.215979-2-clamor95@gmail.com>
On Sun, May 03, 2026 at 07:52:42PM +0300, Svyatoslav Ryhel wrote:
> Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> handheld devices and capable of supporting up to two motors.
>
> The exact datasheet for the ISA1200 is not available; all data was modeled
> based on available downstream kernel sources for various devices and
> fragments of information scattered across the internet.
>
> Tested-by: Linus Walleij <linusw@kernel.org> # Samsung GT-I9070 Janice
Drop the tag here, you cannot test a binding. It's not possible or
otherwise explain how YAML file was tested by this device.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and cleanup
From: Zhang, Lixu @ 2026-05-06 1:51 UTC (permalink / raw)
To: Jonathan Cameron, srinivas pandruvada
Cc: Sanjay Chitroda, jikos@kernel.org, Lechner, David,
nuno.sa@analog.com, andy@kernel.org, sakari.ailus@linux.intel.com,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260505173302.4284a077@jic23-huawei>
>-----Original Message-----
>From: Jonathan Cameron <jic23@kernel.org>
>Sent: Wednesday, May 6, 2026 12:33 AM
>To: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
>Cc: Sanjay Chitroda <sanjayembeddedse@gmail.com>; jikos@kernel.org;
>Lechner, David <dlechner@baylibre.com>; nuno.sa@analog.com;
>andy@kernel.org; sakari.ailus@linux.intel.com; linux-input@vger.kernel.org;
>linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; Zhang, Lixu
><lixu.zhang@intel.com>
>Subject: Re: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and
>cleanup
>
>On Fri, 01 May 2026 04:53:38 -0700
>srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
>
>> + Lixu
>>
>> On Wed, 2026-04-29 at 23:29 +0530, Sanjay Chitroda wrote:
>> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> >
>> > Key highlights:
>> > - Prepare change as pre-requisite for devm conversion for HID IIO
>> > drivers by removing redundant argument
>> > - Add devm API to setup trigger and clenaup resource using
>> > devm_add_action_or_reset()
>> > - few sample driver update using devm conversion to auto release
>> > resource
>> >
>>
>> devm_* calls are fine but needs tests particularly when forces ISH PCI
>> drivers unbind, while iio-sensor-proxy has open sessions.
>>
>> Lixu, Please check.
>Hold off perhaps until we have a v3 with fixes for the existing devm calls against
>wrong struct device.
Sure, I'll test the ISH unbind scenario once v3 is out.
Thanks,
Lixu
>
>Thanks,
>
>Jonathan
>
>>
>> Thanks,
>> Srinivas
>>
^ permalink raw reply
* Re: [PATCH v4 00/11] Input: support for STM FTS5
From: Dmitry Torokhov @ 2026-05-05 21:54 UTC (permalink / raw)
To: david
Cc: Maxime Coquelin, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg,
Bjorn Andersson, Konrad Dybcio, Petr Hodina, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel, Krzysztof Kozlowski,
devicetree, linux-arm-msm, phone-devel, Konrad Dybcio
In-Reply-To: <20260409-stmfts5-v4-0-64fe62027db5@ixit.cz>
On Thu, Apr 09, 2026 at 12:15:43AM +0200, David Heidelberg via B4 Relay wrote:
> Used on various phones. Minimal viable driver.
>
> Includes device-tree enabling touchscreen on Pixel 3.
>
> What is missing:
> - switching between AP and SLPI mode (to be able to wake up phone by touch)
> - firmware loading
> - anything above basic touch
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied #1 through #8 (#5 with minor edits).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Rob Herring (Arm) @ 2026-05-05 19:41 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Sen Chu, Matthias Brugger, Mark Brown, Gary Bisson,
AngeloGioacchino Del Regno, Lee Jones, linux-mediatek,
linux-kernel, linux-input, Louis-Alexis Eyraud, linux-arm-kernel,
linux-gpio, devicetree, Julien Massot, Fabien Parent, Macpaul Lin,
Val Packett, Liam Girdwood, Linus Walleij, linux-pm, Sean Wang,
Dmitry Torokhov, Conor Dooley, Akari Tsuyukusa, Chen Zhong,
Krzysztof Kozlowski
In-Reply-To: <20260420213529.1645560-5-l.scorcia@gmail.com>
On Mon, 20 Apr 2026 22:30:03 +0100, Luca Leonardo Scorcia wrote:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
> the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../pinctrl/mediatek,mt65xx-pinctrl.yaml | 1 +
> .../pinctrl/mediatek,mt6392-pinfunc.h | 39 +++++++++++++++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Dmitry Torokhov @ 2026-05-05 18:10 UTC (permalink / raw)
To: Kris Bahnsen
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <c49600c3-a78d-4d74-82bd-7f95328388a5@embeddedTS.com>
On Tue, May 05, 2026 at 09:21:50AM -0700, Kris Bahnsen wrote:
> Dmitry,
>
> On 5/4/26 8:01 PM, Dmitry Torokhov wrote:
> > Hi Kris,
> >
> > On Thu, Apr 30, 2026 at 05:37:38PM +0000, Kris Bahnsen wrote:
> >> The workaround for XPT2046 clears the command register, giving the
> >> touchscreen controller a NOP. The change incorrectly re-uses the
> >> req->scratch variable which is used as rx_buf for xfer[5], so by
> >> the time xfer[6] occurs, the contents of req->scratch may not be
> >> 0. It was found that the touchscreen controller can end up in
> >> a completely unresponsive state due to it being given a command
> >> the driver does not expect.
> >>
> >> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
> >> transmit all 0 bits and use the scratch variable for the rx_buf for
> >> both the 1 byte command to and 2 byte response from the controller.
> >>
> >> This change was tested on real TSC2046 and ADS7843 controllers,
> >> but not the XPT2046 the workaround was originally created for.
> >> Confirming that the original modification to clear the command
> >> register does not impact either real controller.
> >>
> >> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
> >> Cc: stable@vger.kernel.org
> >> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
> >> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
> >> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
> >> ---
> >>
> >> V1 -> V2: Don't use rx_buf when clearing command reg
> >> V2 -> V3: Modify original 2 xfer command to eliminate dev_err()
> >> output on xfer with len and NULL buffers
> >>
> >> drivers/input/touchscreen/ads7846.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> >> index 4b39f7212d35c..488bcc8393293 100644
> >> --- a/drivers/input/touchscreen/ads7846.c
> >> +++ b/drivers/input/touchscreen/ads7846.c
> >> @@ -403,8 +403,7 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
> >> spi_message_add_tail(&req->xfer[5], &req->msg);
> >>
> >> /* clear the command register */
> >> - req->scratch = 0;
> >> - req->xfer[6].tx_buf = &req->scratch;
> >> + req->xfer[6].rx_buf = &req->scratch;
> >
> > Sashiko (I believe correctly) pointed out that by doing this "scratch"
> > is now write only and this may cause DMA from the device stomp on
> > message status and other unrelated data that shares the same cacheline
> > with scracth. While it was already a problem before now it is even more
> > likely.
> >
> > Since scratch is now write-only I believe moving it below "sample"
> > forces it into separate cacheline and fixes this problem. Could you
> > please try making this change?
>
> Apologies, I'm not quite certain I understand what you mean by
> "moving it below sample." Do you mean relocating the xfer[6] block
> immediately below the xfer[3] block like so? If yes, I can get this
> tested and a v4 patch together. If not, can you please clarify?
I meant doing this:
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 093f4b56cc18..04ba98b62f70 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -328,7 +328,6 @@ struct ser_req {
u8 ref_on;
u8 command;
u8 ref_off;
- u16 scratch;
struct spi_message msg;
struct spi_transfer xfer[8];
/*
@@ -336,6 +335,7 @@ struct ser_req {
* transfer buffers to live in their own cache lines.
*/
__be16 sample ____cacheline_aligned;
+ u16 scratch;
};
struct ads7845_ser_req {
Thanks.
--
Dmitry
^ permalink raw reply related
* Re: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and cleanup
From: Jonathan Cameron @ 2026-05-05 16:33 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Sanjay Chitroda, jikos, dlechner, nuno.sa, andy, sakari.ailus,
linux-input, linux-iio, linux-kernel, Zhang Lixu
In-Reply-To: <15509f5e5a6642d2a4b0ccc13bc7d40d3b79f72a.camel@linux.intel.com>
On Fri, 01 May 2026 04:53:38 -0700
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> + Lixu
>
> On Wed, 2026-04-29 at 23:29 +0530, Sanjay Chitroda wrote:
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Key highlights:
> > - Prepare change as pre-requisite for devm conversion for HID IIO
> > drivers by removing redundant argument
> > - Add devm API to setup trigger and clenaup resource using
> > devm_add_action_or_reset()
> > - few sample driver update using devm conversion to auto release
> > resource
> >
>
> devm_* calls are fine but needs tests particularly when forces ISH PCI
> drivers unbind, while iio-sensor-proxy has open sessions.
>
> Lixu, Please check.
Hold off perhaps until we have a v3 with fixes for the existing devm
calls against wrong struct device.
Thanks,
Jonathan
>
> Thanks,
> Srinivas
>
>
>
> > changes in v2:
> > - Following input from Jonathan and Andy, squash initial patch v1
> > series in single change as individual change should not break
> > anything
> > - Add devm API support and two driver using the same
> > - v1 series ->
> > https://lore.kernel.org/all/20260428071613.1134053-1-sanjayembedded@gmail.com/
> >
> > Testing:
> > - Compiled with W=1
> > - Build-tested on QEMU x86_64
> >
> > Based on further feedback and reviews, I would extend this series to
> > convert all HID IIO driver to use devm_* API.
> >
> > Thanks,
> > Sanjay Chitroda
> >
> > Sanjay Chitroda (4):
> > iio: hid-sensors: drop redundant iio_dev argument
> > iio: hid-sensors: introduce device managed API
> > iio: gyro: drop hid_sensor_remove_trigger() using devm API
> > iio: humidity: drop hid_sensor_remove_trigger() using devm API
> >
> > drivers/iio/accel/hid-sensor-accel-3d.c | 4 +--
> > .../common/hid-sensors/hid-sensor-trigger.c | 27
> > +++++++++++++++++--
> > .../common/hid-sensors/hid-sensor-trigger.h | 5 ++--
> > drivers/iio/gyro/hid-sensor-gyro-3d.c | 10 +++----
> > drivers/iio/humidity/hid-sensor-humidity.c | 10 +++----
> > drivers/iio/light/hid-sensor-als.c | 4 +--
> > drivers/iio/light/hid-sensor-prox.c | 4 +--
> > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 4 +--
> > drivers/iio/orientation/hid-sensor-incl-3d.c | 4 +--
> > drivers/iio/orientation/hid-sensor-rotation.c | 4 +--
> > .../position/hid-sensor-custom-intel-hinge.c | 4 +--
> > drivers/iio/pressure/hid-sensor-press.c | 4 +--
> > .../iio/temperature/hid-sensor-temperature.c | 4 +--
> > 13 files changed, 52 insertions(+), 36 deletions(-)
> >
> >
> > base-commit: eade2b843d9b1f668fc1775f15611bb0a1999cd9
^ permalink raw reply
* Re: [PATCH v2 4/4] iio: humidity: drop hid_sensor_remove_trigger() using devm API
From: Jonathan Cameron @ 2026-05-05 16:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, Andy Shevchenko, jikos, srinivas.pandruvada,
dlechner, nuno.sa, andy, sakari.ailus, linux-input, linux-iio,
linux-kernel
In-Reply-To: <CAHp75VdzPr+SLCPT85zw6aK8pSueBHr-OFpJ1Vmsow61e8=p4w@mail.gmail.com>
On Fri, 1 May 2026 21:25:35 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Apr 30, 2026 at 10:21 PM Sanjay Chitroda
> <sanjayembeddedse@gmail.com> wrote:
> > On 30 April 2026 1:03:56 am IST, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > >On Wed, Apr 29, 2026 at 11:29:18PM +0530, Sanjay Chitroda wrote:
> > >
> > >> Use devm_hid_sensor_setup_trigger() to automatically release resource
>
> resources
>
> > >> during fail, unbind or removal of driver using devres framework.
>
> failure
>
> > >>
> > >> This simplify the setup, remove goto, avoid manual resource cleanup in
>
> simplifies
> removes
> and avoids
>
> OR
>
> "This is done in a way to simplify..."
>
> > >> teardown path.
>
> ...
>
> > >> + ret = devm_hid_sensor_setup_trigger(&indio_dev->dev, indio_dev, name,
> > >> + &humid_st->common_attributes);
> > >
> > >I believe the first parameter is utterly wrong here.
> > >Or other way around, same issue but in the previous patch.
> > >
> > Thank you Andy for the review comment.
> >
> > It looks in same humidity probe of hid sensor with devm API two device pointer are used &pdev->dev and &indio_dev->dev; ideally all devm should have same parent device for devres resource framework and over here preferable and consistent device should be &pdev->dev;
> >
> > I would first update existing devm_* API to have consistent device and on top of that will use same device in devm conversation.
> >
> > While for gyro change device is consistent as &pdev->dev across all devm API.
>
> The idea is that you have to go deeply understanding the object
> lifetimes for the cases of different device instances along with
> userspace communication channels (all possible ABIs the driver uses).
> With only that the proper parameter may be chosen or even confirmed
> that device managed resources must not be used. Yeah, this is one of
> the downsides of devm_*() APIs.
>
FWIW it's always wrong from a design point of view to use iio_dev->dev
for devm. It works but leaves us open to getting the ordering wrong
as some other stuff (including things you can't necessarily see explicitly
in a driver) will be using the parent device.
Jonathan
^ permalink raw reply
* Re: [PATCH v3] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Kris Bahnsen @ 2026-05-05 16:21 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <aflcL6y_ugHV5p8s@google.com>
Dmitry,
On 5/4/26 8:01 PM, Dmitry Torokhov wrote:
> Hi Kris,
>
> On Thu, Apr 30, 2026 at 05:37:38PM +0000, Kris Bahnsen wrote:
>> The workaround for XPT2046 clears the command register, giving the
>> touchscreen controller a NOP. The change incorrectly re-uses the
>> req->scratch variable which is used as rx_buf for xfer[5], so by
>> the time xfer[6] occurs, the contents of req->scratch may not be
>> 0. It was found that the touchscreen controller can end up in
>> a completely unresponsive state due to it being given a command
>> the driver does not expect.
>>
>> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
>> transmit all 0 bits and use the scratch variable for the rx_buf for
>> both the 1 byte command to and 2 byte response from the controller.
>>
>> This change was tested on real TSC2046 and ADS7843 controllers,
>> but not the XPT2046 the workaround was originally created for.
>> Confirming that the original modification to clear the command
>> register does not impact either real controller.
>>
>> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
>> Cc: stable@vger.kernel.org
>> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
>> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
>> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
>> ---
>>
>> V1 -> V2: Don't use rx_buf when clearing command reg
>> V2 -> V3: Modify original 2 xfer command to eliminate dev_err()
>> output on xfer with len and NULL buffers
>>
>> drivers/input/touchscreen/ads7846.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
>> index 4b39f7212d35c..488bcc8393293 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -403,8 +403,7 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
>> spi_message_add_tail(&req->xfer[5], &req->msg);
>>
>> /* clear the command register */
>> - req->scratch = 0;
>> - req->xfer[6].tx_buf = &req->scratch;
>> + req->xfer[6].rx_buf = &req->scratch;
>
> Sashiko (I believe correctly) pointed out that by doing this "scratch"
> is now write only and this may cause DMA from the device stomp on
> message status and other unrelated data that shares the same cacheline
> with scracth. While it was already a problem before now it is even more
> likely.
>
> Since scratch is now write-only I believe moving it below "sample"
> forces it into separate cacheline and fixes this problem. Could you
> please try making this change?
Apologies, I'm not quite certain I understand what you mean by
"moving it below sample." Do you mean relocating the xfer[6] block
immediately below the xfer[3] block like so? If yes, I can get this
tested and a v4 patch together. If not, can you please clarify?
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 4b39f7212d35..6d57865ff505 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -390,6 +390,11 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
req->xfer[3].len = 2;
spi_message_add_tail(&req->xfer[3], &req->msg);
+ /* clear the command register */
+ req->xfer[6].rx_buf = &req->scratch;
+ req->xfer[6].len = 1;
+ spi_message_add_tail(&req->xfer[6], &req->msg);
+
/* REVISIT: take a few more samples, and compare ... */
/* converter in low power mode & enable PENIRQ */
@@ -402,12 +407,6 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
req->xfer[5].len = 2;
spi_message_add_tail(&req->xfer[5], &req->msg);
- /* clear the command register */
- req->scratch = 0;
- req->xfer[6].tx_buf = &req->scratch;
- req->xfer[6].len = 1;
- spi_message_add_tail(&req->xfer[6], &req->msg);
-
req->xfer[7].rx_buf = &req->scratch;
req->xfer[7].len = 2;
CS_CHANGE(req->xfer[7]);
>
> Thanks.
>
--
Kris Bahnsen
Software Engineer
embeddedTS
^ permalink raw reply related
* Re: [PATCH 1/3] Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem
From: Dmitry Torokhov @ 2026-05-05 15:03 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: Nick Dyer, linux-input, linux-kernel, stable
In-Reply-To: <CANiDSCv+h_ry7W1e1mFNLhont-1xigEZj6jL3m=FVgv2UC+KzQ@mail.gmail.com>
Hi Ricardo,
On Tue, May 05, 2026 at 11:08:15AM +0200, Ricardo Ribalda wrote:
> HI Dmitry
>
> FWIW this patch looks correct to me...
Thank you for looking this over.
>
> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
>
> But there are a couple of things that look weird.
>
> 1) The patch line (1503) does not seem to match your tree
> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/tree/drivers/input/touchscreen/atmel_mxt_ts.c#n1503
Yeah, I have an unrelated path in my queue that affects line offsets,
>
> 2) The sscanf just before this check has two conversions (val and
> offset), but you only check for ret != 1. Should't it be ret !=2? or I
> am missing something?
"%n" format specifier does not increment number of successfully parsed
elements returned by sscanf(). It kind of makes sense although may look
surprising.
Thanks.
--
Dmitry
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS e7b91b21755924c2b26bd4f925c1b538a48b2370
From: kernel test robot @ 2026-05-05 14:38 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: e7b91b21755924c2b26bd4f925c1b538a48b2370 Input: atmel_mxt_ts - set byte_offset as signed
elapsed time: 728m
configs tested: 222
configs skipped: 15
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260505 gcc-8.5.0
arc randconfig-002-20260505 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm mmp2_defconfig gcc-15.2.0
arm randconfig-001-20260505 gcc-8.5.0
arm randconfig-002-20260505 gcc-8.5.0
arm randconfig-003-20260505 gcc-8.5.0
arm randconfig-004-20260505 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260505 gcc-14.3.0
arm64 randconfig-002-20260505 gcc-14.3.0
arm64 randconfig-003-20260505 gcc-14.3.0
arm64 randconfig-004-20260505 gcc-14.3.0
csky alldefconfig gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260505 gcc-14.3.0
csky randconfig-002-20260505 gcc-14.3.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260505 clang-23
hexagon randconfig-001-20260505 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260505 clang-23
hexagon randconfig-002-20260505 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260505 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260505 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260505 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260505 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260505 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260505 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260505 clang-20
i386 randconfig-002-20260505 clang-20
i386 randconfig-003-20260505 clang-20
i386 randconfig-004-20260505 clang-20
i386 randconfig-005-20260505 clang-20
i386 randconfig-006-20260505 clang-20
i386 randconfig-007-20260505 clang-20
i386 randconfig-011-20260505 clang-20
i386 randconfig-012-20260505 clang-20
i386 randconfig-013-20260505 clang-20
i386 randconfig-014-20260505 clang-20
i386 randconfig-015-20260505 clang-20
i386 randconfig-016-20260505 clang-20
i386 randconfig-017-20260505 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260505 clang-23
loongarch randconfig-001-20260505 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260505 clang-23
loongarch randconfig-002-20260505 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips decstation_64_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260505 clang-23
nios2 randconfig-001-20260505 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260505 clang-23
nios2 randconfig-002-20260505 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc de0_nano_multicore_defconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc generic-32bit_defconfig gcc-15.2.0
parisc randconfig-001 gcc-14.3.0
parisc randconfig-001-20260505 gcc-14.3.0
parisc randconfig-002 gcc-14.3.0
parisc randconfig-002-20260505 gcc-14.3.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001 gcc-14.3.0
powerpc randconfig-001-20260505 gcc-14.3.0
powerpc randconfig-002 gcc-14.3.0
powerpc randconfig-002-20260505 gcc-14.3.0
powerpc tqm8541_defconfig clang-23
powerpc64 randconfig-001 gcc-14.3.0
powerpc64 randconfig-001-20260505 gcc-14.3.0
powerpc64 randconfig-002 gcc-14.3.0
powerpc64 randconfig-002-20260505 gcc-14.3.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260505 gcc-10.5.0
riscv randconfig-002-20260505 gcc-10.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260505 gcc-10.5.0
s390 randconfig-002-20260505 gcc-10.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260505 gcc-10.5.0
sh randconfig-002-20260505 gcc-10.5.0
sh urquell_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-15.2.0
sparc randconfig-001-20260505 gcc-15.2.0
sparc randconfig-002 gcc-15.2.0
sparc randconfig-002-20260505 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-15.2.0
sparc64 randconfig-001-20260505 gcc-15.2.0
sparc64 randconfig-002 gcc-15.2.0
sparc64 randconfig-002-20260505 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-15.2.0
um randconfig-001-20260505 gcc-15.2.0
um randconfig-002 gcc-15.2.0
um randconfig-002-20260505 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260505 clang-20
x86_64 buildonly-randconfig-002-20260505 clang-20
x86_64 buildonly-randconfig-003-20260505 clang-20
x86_64 buildonly-randconfig-004-20260505 clang-20
x86_64 buildonly-randconfig-005-20260505 clang-20
x86_64 buildonly-randconfig-006-20260505 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001 clang-20
x86_64 randconfig-001-20260505 clang-20
x86_64 randconfig-002 clang-20
x86_64 randconfig-002-20260505 clang-20
x86_64 randconfig-003 clang-20
x86_64 randconfig-003-20260505 clang-20
x86_64 randconfig-004 clang-20
x86_64 randconfig-004-20260505 clang-20
x86_64 randconfig-005 clang-20
x86_64 randconfig-005-20260505 clang-20
x86_64 randconfig-006 clang-20
x86_64 randconfig-006-20260505 clang-20
x86_64 randconfig-011 clang-20
x86_64 randconfig-011-20260505 clang-20
x86_64 randconfig-012 clang-20
x86_64 randconfig-012-20260505 clang-20
x86_64 randconfig-013 clang-20
x86_64 randconfig-013-20260505 clang-20
x86_64 randconfig-014 clang-20
x86_64 randconfig-014-20260505 clang-20
x86_64 randconfig-015 clang-20
x86_64 randconfig-015-20260505 clang-20
x86_64 randconfig-016 clang-20
x86_64 randconfig-016-20260505 clang-20
x86_64 randconfig-071-20260505 clang-20
x86_64 randconfig-071-20260505 gcc-14
x86_64 randconfig-072-20260505 clang-20
x86_64 randconfig-073-20260505 clang-20
x86_64 randconfig-073-20260505 gcc-14
x86_64 randconfig-074-20260505 clang-20
x86_64 randconfig-074-20260505 gcc-14
x86_64 randconfig-075-20260505 clang-20
x86_64 randconfig-076-20260505 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001 gcc-15.2.0
xtensa randconfig-001-20260505 gcc-15.2.0
xtensa randconfig-002 gcc-15.2.0
xtensa randconfig-002-20260505 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 6/6] leds: led-class: mark classdev as unregistering early
From: James Ye @ 2026-05-05 14:16 UTC (permalink / raw)
To: kernel test robot
Cc: jikos, bentiss, lee, pavel, oe-kbuild-all, linux-input,
linux-leds, linux-kernel, denis.benato
In-Reply-To: <202605050414.YJmW3t4y-lkp@intel.com>
On Tue, 5 May 2026 at 12:24, kernel test robot <lkp@intel.com> wrote:
>
> Hi James,
>
> kernel test robot noticed the following build errors:
This is due to CONFIG_HID_BATTERY_STRENGTH being turned off, I will
fix it in the next version.
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-05-05 11:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAD++jLk_SojErY4gxjixzwEF3sfSownH=jBYaoPD2LeoxibhWw@mail.gmail.com>
вт, 5 трав. 2026 р. о 13:39 Linus Walleij <linusw@kernel.org> пише:
>
> On Thu, Apr 30, 2026 at 11:46 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > чт, 30 квіт. 2026 р. о 12:22 Linus Walleij <linusw@kernel.org> пише:
>
> > In you original code
> > /*
> > * This is done in the vendor tree with the commment
> > * "Duty 0x64 == nForce 90", and no force feedback happens
> > * unless we do this.
> > */
> > if (isa->clk)
> > regmap_write(isa->map, ISA1200_HCTRL5, 0x64);
> >
> > 0x64 is actually some conversion of duty cycle, you got this accurately.
>
> I wonder if 0x64 = 100 is simply 100% duty cycle?
> So the value in this register can only be 0..100.
>
Assumption is interesting, but it is still just a guess based on
observation of a single hw configuration. For example, Samsung Galaxy
Tab 10.1 (GT-P7501) passes 133 (0x85) into duty register.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Linus Walleij @ 2026-05-05 10:39 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAPVz0n3h+zWi-b-ZTLqwXR-9JNGcUgVodUgo+ywhBfK-UDQJAw@mail.gmail.com>
On Thu, Apr 30, 2026 at 11:46 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> чт, 30 квіт. 2026 р. о 12:22 Linus Walleij <linusw@kernel.org> пише:
> In you original code
> /*
> * This is done in the vendor tree with the commment
> * "Duty 0x64 == nForce 90", and no force feedback happens
> * unless we do this.
> */
> if (isa->clk)
> regmap_write(isa->map, ISA1200_HCTRL5, 0x64);
>
> 0x64 is actually some conversion of duty cycle, you got this accurately.
I wonder if 0x64 = 100 is simply 100% duty cycle?
So the value in this register can only be 0..100.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/3] Input: atmel_mxt_ts - use __free() for obuf in mxt_object_show
From: Ricardo Ribalda @ 2026-05-05 9:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Nick Dyer, linux-input, linux-kernel
In-Reply-To: <20260504185448.4055973-3-dmitry.torokhov@gmail.com>
On Mon, 4 May 2026 at 20:54, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> Use the __free(kfree) macro for the obuf allocation in mxt_object_show()
> to simplify the code.
>
> Assisted-by: Gemini:gemini-3.1-pro
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index d660cc5b5fe3..6af4db5ed117 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2870,14 +2870,12 @@ static ssize_t mxt_object_show(struct device *dev,
> int count = 0;
> int i, j;
> int error;
> - u8 *obuf;
>
> /* Pre-allocate buffer large enough to hold max sized object. */
> - obuf = kmalloc(256, GFP_KERNEL);
> + u8 *obuf __free(kfree) = kmalloc(256, GFP_KERNEL);
> if (!obuf)
> return -ENOMEM;
>
> - error = 0;
> for (i = 0; i < data->info->object_num; i++) {
> object = data->object_table + i;
>
> @@ -2892,15 +2890,13 @@ static ssize_t mxt_object_show(struct device *dev,
>
> error = __mxt_read_reg(data->client, addr, size, obuf);
> if (error)
> - goto done;
> + return error;
>
> count = mxt_show_instance(buf, count, object, j, obuf);
> }
> }
>
> -done:
> - kfree(obuf);
> - return error ?: count;
> + return count;
> }
>
> static int mxt_check_firmware_format(struct device *dev,
> --
> 2.54.0.545.g6539524ca2-goog
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 1/3] Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem
From: Ricardo Ribalda @ 2026-05-05 9:08 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Nick Dyer, linux-input, linux-kernel, stable
In-Reply-To: <20260504185448.4055973-1-dmitry.torokhov@gmail.com>
HI Dmitry
FWIW this patch looks correct to me...
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
But there are a couple of things that look weird.
1) The patch line (1503) does not seem to match your tree
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/tree/drivers/input/touchscreen/atmel_mxt_ts.c#n1503
2) The sscanf just before this check has two conversions (val and
offset), but you only check for ret != 1. Should't it be ret !=2? or I
am missing something?
On Mon, 4 May 2026 at 20:54, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> When a configuration file provides an object size that is larger than the
> driver's known mxt_obj_size(object), the driver intends to discard the
> extra bytes.
>
> The loop iterates using for (i = 0; i < size; i++). Inside the loop, the
> condition to skip processing extra bytes is:
>
> if (i > mxt_obj_size(object))
> continue;
>
> Since i is a 0-based index, the valid indices for the object are 0 through
> mxt_obj_size(object) - 1.
>
> When i == mxt_obj_size(object), the condition evaluates to false, and the
> code processes the byte instead of discarding it.
>
> This causes the code to calculate byte_offset = reg + i - cfg->start_ofs
> and writes the byte there, overwriting exactly one byte of the adjacent
> instance or object.
>
> Update the boundary check to skip extra bytes correctly by using >=.
>
> Fixes: 50a77c658b80 ("Input: atmel_mxt_ts - download device config using firmware loader")
> Cc: stable@vger.kernel.org
> Assisted-by: Gemini:gemini-3.1-pro
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index d62bf2c95578..28b2bd889c70 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -1503,7 +1503,7 @@ static int mxt_prepare_cfg_mem(struct mxt_data *data, struct mxt_cfg *cfg)
> }
> cfg->raw_pos += offset;
>
> - if (i > mxt_obj_size(object))
> + if (i >= mxt_obj_size(object))
> continue;
>
> byte_offset = reg + i - cfg->start_ofs;
> --
> 2.54.0.545.g6539524ca2-goog
>
--
Ricardo Ribalda
^ permalink raw reply
* [PATCH] Input: xpad - remove unused xpad_init_output intf parameter
From: Tobias Klauser @ 2026-05-05 8:08 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
The intf parameter to xpad_init_output is unused since commit
c01b5e7464f0 ("Input: xpad - don't depend on endpoint order"). Remove
it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/input/joystick/xpad.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index feb8f368f834..4c5528eb94b3 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1388,8 +1388,8 @@ static void xpad_irq_out(struct urb *urb)
}
}
-static int xpad_init_output(struct usb_interface *intf, struct usb_xpad *xpad,
- struct usb_endpoint_descriptor *ep_irq_out)
+static int xpad_init_output(struct usb_xpad *xpad,
+ struct usb_endpoint_descriptor *ep_irq_out)
{
int error;
@@ -2136,7 +2136,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
goto err_free_in_urb;
}
- error = xpad_init_output(intf, xpad, ep_irq_out);
+ error = xpad_init_output(xpad, ep_irq_out);
if (error)
goto err_free_in_urb;
--
2.52.0
^ permalink raw reply related
* [PATCH v2 20/20] Input: rmi4 - update formatting in F12
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Clean up various style and formatting issues in the F12 code.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 120 +++++++++++++++++------------------
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index bf8c4a0e10de..88c28089de99 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -51,7 +51,6 @@ struct f12_data {
const struct rmi_register_desc_item *data6;
u16 data6_offset;
-
/* F12 Data9 reports relative data */
const struct rmi_register_desc_item *data9;
u16 data9_offset;
@@ -124,8 +123,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
return -ENODEV;
}
- ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr + offset, buf,
- item->reg_size);
+ ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr + offset,
+ buf, item->reg_size);
if (ret)
return ret;
@@ -163,7 +162,7 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
if (rmi_get_register_desc_item(&f12->query_reg_desc,
RMI_F12_QUERY_RESOLUTION)) {
offset = rmi_register_desc_calc_reg_offset(&f12->query_reg_desc,
- RMI_F12_QUERY_RESOLUTION);
+ RMI_F12_QUERY_RESOLUTION);
query_dpm_addr = fn->fd.query_base_addr + offset;
ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf);
if (ret) {
@@ -248,18 +247,17 @@ static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1, u32 size)
static irqreturn_t rmi_f12_attention(int irq, void *ctx)
{
- int retval;
struct rmi_function *fn = ctx;
struct rmi_device *rmi_dev = fn->rmi_dev;
struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
struct f12_data *f12 = dev_get_drvdata(&fn->dev);
struct rmi_2d_sensor *sensor = &f12->sensor;
u32 valid_bytes = sensor->pkt_size;
+ int retval;
if (drvdata->attn_data.data) {
valid_bytes = min_t(u32, sensor->attn_size, drvdata->attn_data.size);
- memcpy(sensor->data_pkt, drvdata->attn_data.data,
- valid_bytes);
+ memcpy(sensor->data_pkt, drvdata->attn_data.data, valid_bytes);
drvdata->attn_data.data += valid_bytes;
drvdata->attn_data.size -= valid_bytes;
} else {
@@ -273,70 +271,74 @@ static irqreturn_t rmi_f12_attention(int irq, void *ctx)
}
if (f12->data1)
- rmi_f12_process_objects(f12,
- &sensor->data_pkt[f12->data1_offset], valid_bytes);
+ rmi_f12_process_objects(f12, &sensor->data_pkt[f12->data1_offset],
+ valid_bytes);
input_mt_sync_frame(sensor->input);
return IRQ_HANDLED;
}
-static int rmi_f12_write_control_regs(struct rmi_function *fn)
+static int rmi_f12_update_dribble(struct rmi_function *fn, struct f12_data *f12)
{
- int ret;
const struct rmi_register_desc_item *item;
struct rmi_device *rmi_dev = fn->rmi_dev;
- struct f12_data *f12 = dev_get_drvdata(&fn->dev);
- int control_size;
- char buf[3];
- u16 control_offset = 0;
u8 subpacket_offset = 0;
+ u16 control_offset;
+ u32 control_size;
+ int error;
+ u8 buf[3];
- if (f12->has_dribble
- && (f12->sensor.dribble != RMI_REG_STATE_DEFAULT)) {
- item = rmi_get_register_desc_item(&f12->control_reg_desc, 20);
- if (item) {
- control_offset = rmi_register_desc_calc_reg_offset(
- &f12->control_reg_desc, 20);
-
- /*
- * The byte containing the EnableDribble bit will be
- * in either byte 0 or byte 2 of control 20. Depending
- * on the existence of subpacket 0. If control 20 is
- * larger then 3 bytes, just read the first 3.
- */
- control_size = min(item->reg_size, 3U);
-
- ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr
- + control_offset, buf, control_size);
- if (ret)
- return ret;
-
- if (rmi_register_desc_has_subpacket(item, 0))
- subpacket_offset += 1;
-
- switch (f12->sensor.dribble) {
- case RMI_REG_STATE_OFF:
- buf[subpacket_offset] &= ~BIT(2);
- break;
- case RMI_REG_STATE_ON:
- buf[subpacket_offset] |= BIT(2);
- break;
- case RMI_REG_STATE_DEFAULT:
- default:
- break;
- }
+ item = rmi_get_register_desc_item(&f12->control_reg_desc, 20);
+ if (!item)
+ return 0;
- ret = rmi_write_block(rmi_dev,
- fn->fd.control_base_addr + control_offset,
- buf, control_size);
- if (ret)
- return ret;
- }
+ control_offset = rmi_register_desc_calc_reg_offset(&f12->control_reg_desc, 20);
+
+ /*
+ * The byte containing the EnableDribble bit will be
+ * in either byte 0 or byte 2 of control 20. Depending
+ * on the existence of subpacket 0. If control 20 is
+ * larger then 3 bytes, just read the first 3.
+ */
+ control_size = min(item->reg_size, 3U);
+
+ error = rmi_read_block(rmi_dev, fn->fd.control_base_addr + control_offset,
+ buf, control_size);
+ if (error)
+ return error;
+
+ if (rmi_register_desc_has_subpacket(item, 0))
+ subpacket_offset += 1;
+
+ switch (f12->sensor.dribble) {
+ case RMI_REG_STATE_OFF:
+ buf[subpacket_offset] &= ~BIT(2);
+ break;
+ case RMI_REG_STATE_ON:
+ buf[subpacket_offset] |= BIT(2);
+ break;
+ case RMI_REG_STATE_DEFAULT:
+ default:
+ break;
}
+ error = rmi_write_block(rmi_dev, fn->fd.control_base_addr + control_offset,
+ buf, control_size);
+ if (error)
+ return error;
+
return 0;
+}
+static int rmi_f12_write_control_regs(struct rmi_function *fn)
+{
+ struct f12_data *f12 = dev_get_drvdata(&fn->dev);
+
+ if (f12->has_dribble && f12->sensor.dribble != RMI_REG_STATE_DEFAULT)
+ return rmi_f12_update_dribble(fn, f12);
+
+ return 0;
}
static int rmi_f12_config(struct rmi_function *fn)
@@ -362,7 +364,7 @@ static int rmi_f12_config(struct rmi_function *fn)
ret = rmi_f12_write_control_regs(fn);
if (ret)
dev_warn(&fn->dev,
- "Failed to write F12 control registers: %d\n", ret);
+ "Failed to write F12 control registers: %d\n", ret);
return 0;
}
@@ -433,16 +435,14 @@ static int rmi_f12_probe(struct rmi_function *fn)
}
sensor->pkt_size = pkt_size;
- sensor->axis_align =
- f12->sensor_pdata.axis_align;
+ sensor->axis_align = f12->sensor_pdata.axis_align;
sensor->x_mm = f12->sensor_pdata.x_mm;
sensor->y_mm = f12->sensor_pdata.y_mm;
sensor->dribble = f12->sensor_pdata.dribble;
if (sensor->sensor_type == rmi_sensor_default)
- sensor->sensor_type =
- f12->sensor_pdata.sensor_type;
+ sensor->sensor_type = f12->sensor_pdata.sensor_type;
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: data packet size: %u\n", __func__,
sensor->pkt_size);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 19/20] Input: rmi4 - propagate proper error code in F12 sensor tuning
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Propagate the actual error code returned by rmi_read() in
rmi_f12_read_sensor_tuning() instead of hardcoding -ENODEV.
Also, since rmi_read() returns 0 on success, use 'if (ret)'
instead of 'if (ret < 0)'.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index ea72d5ce8050..bf8c4a0e10de 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -166,9 +166,9 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
RMI_F12_QUERY_RESOLUTION);
query_dpm_addr = fn->fd.query_base_addr + offset;
ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf);
- if (ret < 0) {
+ if (ret) {
dev_err(&fn->dev, "Failed to read DPM value: %d\n", ret);
- return -ENODEV;
+ return ret;
}
dpm_resolution = buf[0];
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 18/20] Input: rmi4 - simplify size calculations in F12
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Use min_t() to simplify the clamping logic when calculating the
number of objects to process and the number of valid bytes in the
attention handler.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 34ed02b7f30f..ea72d5ce8050 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -195,14 +195,11 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
return 0;
}
-static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1, int size)
+static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1, u32 size)
{
- int i;
struct rmi_2d_sensor *sensor = &f12->sensor;
- int objects = f12->data1->num_subpackets;
-
- if ((f12->data1->num_subpackets * F12_DATA1_BYTES_PER_OBJ) > size)
- objects = size / F12_DATA1_BYTES_PER_OBJ;
+ u32 objects = min(f12->data1->num_subpackets, size / F12_DATA1_BYTES_PER_OBJ);
+ int i;
for (i = 0; i < objects; i++) {
struct rmi_2d_sensor_abs_object *obj = &sensor->objs[i];
@@ -260,10 +257,7 @@ static irqreturn_t rmi_f12_attention(int irq, void *ctx)
u32 valid_bytes = sensor->pkt_size;
if (drvdata->attn_data.data) {
- if (sensor->attn_size > drvdata->attn_data.size)
- valid_bytes = drvdata->attn_data.size;
- else
- valid_bytes = sensor->attn_size;
+ valid_bytes = min_t(u32, sensor->attn_size, drvdata->attn_data.size);
memcpy(sensor->data_pkt, drvdata->attn_data.data,
valid_bytes);
drvdata->attn_data.data += valid_bytes;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 17/20] Input: rmi4 - use sizeof(*ptr) and idiomatic checks in f12 allocators
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Using sizeof(*ptr) is preferred over sizeof(struct) because it is
more robust against type changes. Also switch to checking for
allocation failure immediately after each call, and update
formatting.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 01838907c64b..34ed02b7f30f 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -528,16 +528,21 @@ static int rmi_f12_probe(struct rmi_function *fn)
}
/* allocate the in-kernel tracking buffers */
- sensor->tracking_pos = devm_kcalloc(&fn->dev,
- sensor->nbr_fingers, sizeof(struct input_mt_pos),
- GFP_KERNEL);
- sensor->tracking_slots = devm_kcalloc(&fn->dev,
- sensor->nbr_fingers, sizeof(int), GFP_KERNEL);
- sensor->objs = devm_kcalloc(&fn->dev,
- sensor->nbr_fingers,
- sizeof(struct rmi_2d_sensor_abs_object),
- GFP_KERNEL);
- if (!sensor->tracking_pos || !sensor->tracking_slots || !sensor->objs)
+ sensor->tracking_pos = devm_kcalloc(&fn->dev, sensor->nbr_fingers,
+ sizeof(*sensor->tracking_pos),
+ GFP_KERNEL);
+ if (!sensor->tracking_pos)
+ return -ENOMEM;
+
+ sensor->tracking_slots = devm_kcalloc(&fn->dev, sensor->nbr_fingers,
+ sizeof(*sensor->tracking_slots),
+ GFP_KERNEL);
+ if (!sensor->tracking_slots)
+ return -ENOMEM;
+
+ sensor->objs = devm_kcalloc(&fn->dev, sensor->nbr_fingers,
+ sizeof(*sensor->objs), GFP_KERNEL);
+ if (!sensor->objs)
return -ENOMEM;
ret = rmi_2d_sensor_configure_input(fn, sensor);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 16/20] Input: rmi4 - use devm_kmalloc for F12 data packet buffer
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
The sensor->data_pkt buffer is used exclusively to store incoming
hardware data during the attention handler, where it is entirely
overwritten by either memcpy() or rmi_read_block(). Therefore,
there is no need to zero-initialize it during probe.
Switch to devm_kmalloc() to avoid the unnecessary memset overhead.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index b9cd70422b68..01838907c64b 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -452,7 +452,7 @@ static int rmi_f12_probe(struct rmi_function *fn)
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: data packet size: %u\n", __func__,
sensor->pkt_size);
- sensor->data_pkt = devm_kzalloc(&fn->dev, sensor->pkt_size, GFP_KERNEL);
+ sensor->data_pkt = devm_kmalloc(&fn->dev, sensor->pkt_size, GFP_KERNEL);
if (!sensor->data_pkt)
return -ENOMEM;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 15/20] Input: rmi4 - use flexible array member for IRQ masks in F12
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
Use a flexible array member to allocate the IRQ masks at the end of
the f12_data structure, and use the struct_size() helper to
calculate the allocation size safely. This replaces manual pointer
arithmetic.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 752c1d137da0..b9cd70422b68 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -59,8 +59,7 @@ struct f12_data {
const struct rmi_register_desc_item *data15;
u16 data15_offset;
- unsigned long *abs_mask;
- unsigned long *rel_mask;
+ unsigned long irq_mask[];
};
static int rmi_f12_read_register_descs(struct rmi_function *fn,
@@ -350,17 +349,21 @@ static int rmi_f12_config(struct rmi_function *fn)
{
struct rmi_driver *drv = fn->rmi_dev->driver;
struct f12_data *f12 = dev_get_drvdata(&fn->dev);
+ struct rmi_driver_data *drvdata = dev_get_drvdata(&fn->rmi_dev->dev);
+ int irq_mask_size = BITS_TO_LONGS(drvdata->irq_count);
+ unsigned long *abs_mask = f12->irq_mask;
+ unsigned long *rel_mask = f12->irq_mask + irq_mask_size;
struct rmi_2d_sensor *sensor;
int ret;
sensor = &f12->sensor;
if (!sensor->report_abs)
- drv->clear_irq_bits(fn->rmi_dev, f12->abs_mask);
+ drv->clear_irq_bits(fn->rmi_dev, abs_mask);
else
- drv->set_irq_bits(fn->rmi_dev, f12->abs_mask);
+ drv->set_irq_bits(fn->rmi_dev, abs_mask);
- drv->clear_irq_bits(fn->rmi_dev, f12->rel_mask);
+ drv->clear_irq_bits(fn->rmi_dev, rel_mask);
ret = rmi_f12_write_control_regs(fn);
if (ret)
@@ -383,12 +386,12 @@ static int rmi_f12_probe(struct rmi_function *fn)
struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
size_t data_offset = 0;
size_t pkt_size;
- int mask_size;
+ int irq_mask_size;
int i;
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s\n", __func__);
- mask_size = BITS_TO_LONGS(drvdata->irq_count) * sizeof(unsigned long);
+ irq_mask_size = BITS_TO_LONGS(drvdata->irq_count);
ret = rmi_read(fn->rmi_dev, query_addr, &buf);
if (ret < 0) {
@@ -404,18 +407,13 @@ static int rmi_f12_probe(struct rmi_function *fn)
return -ENODEV;
}
- f12 = devm_kzalloc(&fn->dev, sizeof(struct f12_data) + mask_size * 2,
- GFP_KERNEL);
+ f12 = devm_kzalloc(&fn->dev, struct_size(f12, irq_mask, irq_mask_size * 2),
+ GFP_KERNEL);
if (!f12)
return -ENOMEM;
- f12->abs_mask = (unsigned long *)((char *)f12
- + sizeof(struct f12_data));
- f12->rel_mask = (unsigned long *)((char *)f12
- + sizeof(struct f12_data) + mask_size);
-
- set_bit(fn->irq_pos, f12->abs_mask);
- set_bit(fn->irq_pos + 1, f12->rel_mask);
+ set_bit(fn->irq_pos, f12->irq_mask);
+ set_bit(fn->irq_pos + 1, f12->irq_mask + irq_mask_size);
f12->has_dribble = !!(buf & BIT(3));
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v2 12/20] Input: rmi4 - refactor F12 probe function
From: Dmitry Torokhov @ 2026-05-05 4:59 UTC (permalink / raw)
To: linux-input; +Cc: Marge Yang, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20260505045952.1570713-1-dmitry.torokhov@gmail.com>
The F12 probe function contains highly repetitive logic for parsing
register descriptors and their individual data items. Refactor the
function to use loops to eliminate redundancy, and clarify the code.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f12.c | 197 ++++++++++++++---------------------
1 file changed, 81 insertions(+), 116 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index c2b07c6905d7..973288103b6a 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -61,6 +61,36 @@ struct f12_data {
unsigned long *rel_mask;
};
+static int rmi_f12_read_register_descs(struct rmi_function *fn,
+ struct f12_data *f12, u16 query_addr)
+{
+ struct {
+ struct rmi_register_descriptor *desc;
+ const char *name;
+ } descriptors[] = {
+ { &f12->query_reg_desc, "Query" },
+ { &f12->control_reg_desc, "Control" },
+ { &f12->data_reg_desc, "Data" },
+ };
+ struct rmi_device *rmi_dev = fn->rmi_dev;
+ int error;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(descriptors); i++) {
+ error = rmi_read_register_desc(rmi_dev, query_addr,
+ descriptors[i].desc);
+ if (error) {
+ dev_err(&fn->dev,
+ "Failed to read the %s Register Descriptor: %d\n",
+ descriptors[i].name, error);
+ return error;
+ }
+ query_addr += 3;
+ }
+
+ return 0;
+}
+
static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
{
const struct rmi_register_desc_item *item;
@@ -351,6 +381,7 @@ static int rmi_f12_probe(struct rmi_function *fn)
struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
u16 data_offset = 0;
int mask_size;
+ int i;
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s\n", __func__);
@@ -393,35 +424,9 @@ static int rmi_f12_probe(struct rmi_function *fn)
f12->sensor_pdata = pdata->sensor_pdata;
}
- ret = rmi_read_register_desc(rmi_dev, query_addr,
- &f12->query_reg_desc);
- if (ret) {
- dev_err(&fn->dev,
- "Failed to read the Query Register Descriptor: %d\n",
- ret);
- return ret;
- }
- query_addr += 3;
-
- ret = rmi_read_register_desc(rmi_dev, query_addr,
- &f12->control_reg_desc);
- if (ret) {
- dev_err(&fn->dev,
- "Failed to read the Control Register Descriptor: %d\n",
- ret);
- return ret;
- }
- query_addr += 3;
-
- ret = rmi_read_register_desc(rmi_dev, query_addr,
- &f12->data_reg_desc);
- if (ret) {
- dev_err(&fn->dev,
- "Failed to read the Data Register Descriptor: %d\n",
- ret);
+ ret = rmi_f12_read_register_descs(fn, f12, query_addr);
+ if (ret)
return ret;
- }
- query_addr += 3;
sensor = &f12->sensor;
sensor->fn = fn;
@@ -452,101 +457,61 @@ static int rmi_f12_probe(struct rmi_function *fn)
return ret;
/*
- * Figure out what data is contained in the data registers. HID devices
- * may have registers defined, but their data is not reported in the
- * HID attention report. Registers which are not reported in the HID
- * attention report check to see if the device is receiving data from
- * HID attention reports.
+ * Identify available data registers and calculate their offsets within
+ * the attention report. For HID devices, only Data1 and Data5 are
+ * included in the report; other registers may be described but are
+ * not transmitted in the attention packet and thus skipped here.
*/
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 0);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 1);
- if (item) {
- f12->data1 = item;
- f12->data1_offset = data_offset;
- data_offset += item->reg_size;
-
- if (item->num_subpackets > 255) {
- dev_err(&fn->dev, "Too many fingers declared: %d\n",
- item->num_subpackets);
- return -EINVAL;
- }
-
- sensor->nbr_fingers = item->num_subpackets;
- sensor->report_abs = 1;
- sensor->attn_size += item->reg_size;
- }
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 2);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 3);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 4);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 5);
- if (item) {
- f12->data5 = item;
- f12->data5_offset = data_offset;
- data_offset += item->reg_size;
- sensor->attn_size += item->reg_size;
- }
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 6);
- if (item && !drvdata->attn_data.data) {
- f12->data6 = item;
- f12->data6_offset = data_offset;
- data_offset += item->reg_size;
- }
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 7);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 8);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
-
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 9);
- if (item && !drvdata->attn_data.data) {
- f12->data9 = item;
- f12->data9_offset = data_offset;
- data_offset += item->reg_size;
- if (!sensor->report_abs)
- sensor->report_rel = 1;
- }
+ for (i = 0; i < 16; i++) {
+ item = rmi_get_register_desc_item(&f12->data_reg_desc, i);
+ if (!item)
+ continue;
+
+ /* HID attention reports only contain Data1 and Data5 */
+ if (drvdata->attn_data.data && i != 1 && i != 5)
+ continue;
+
+ switch (i) {
+ case 1:
+ f12->data1 = item;
+ f12->data1_offset = data_offset;
+
+ if (item->num_subpackets > 255) {
+ dev_err(&fn->dev,
+ "Too many fingers declared: %d\n",
+ item->num_subpackets);
+ return -EINVAL;
+ }
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 10);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
+ sensor->nbr_fingers = item->num_subpackets;
+ sensor->report_abs = 1;
+ sensor->attn_size += item->reg_size;
+ break;
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 11);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
+ case 5:
+ f12->data5 = item;
+ f12->data5_offset = data_offset;
+ sensor->attn_size += item->reg_size;
+ break;
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 12);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
+ case 6:
+ f12->data6 = item;
+ f12->data6_offset = data_offset;
+ break;
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 13);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
+ case 9:
+ f12->data9 = item;
+ f12->data9_offset = data_offset;
+ if (!sensor->report_abs)
+ sensor->report_rel = 1;
+ break;
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 14);
- if (item && !drvdata->attn_data.data)
- data_offset += item->reg_size;
+ case 15:
+ f12->data15 = item;
+ f12->data15_offset = data_offset;
+ break;
+ }
- item = rmi_get_register_desc_item(&f12->data_reg_desc, 15);
- if (item && !drvdata->attn_data.data) {
- f12->data15 = item;
- f12->data15_offset = data_offset;
data_offset += item->reg_size;
}
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
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