* [PATCH v2] HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert
From: Jinmo Yang @ 2026-05-28 17:59 UTC (permalink / raw)
To: linux-input, dmitry.torokhov
Cc: jikos, benjamin.tissoires, stable, Jinmo Yang
In-Reply-To: <20260524135203.1996265-1-jinmo44.yang@gmail.com>
wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo
doesn't have enough space for the incoming report. If the kfifo is
empty, kfifo_skip() reads stale data left in the kmalloc'd buffer
via __kfifo_peek_n() and interprets it as a record length, advancing
fifo->out by that garbage value. This corrupts the internal kfifo
state, causing kfifo_unused() to return a value much larger than the
actual buffer size, which bypasses __kfifo_in_r()'s guard:
if (len + recsize > kfifo_unused(fifo))
return 0;
kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to
3842 bytes past the 256-byte buffer.
Add a !kfifo_is_empty() condition to the while loop so kfifo_skip()
is never called on an empty fifo, and check the return value of
kfifo_in() to reject reports that are too large for the fifo.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit")
Cc: stable@vger.kernel.org
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
Changes in v2:
- Instead of a size check at the top, add !kfifo_is_empty() to the
while loop condition to prevent kfifo_skip() on an empty fifo
(Suggested by Dmitry Torokhov)
- Check kfifo_in() return value to reject oversized reports instead
of a separate guard
drivers/hid/wacom_sys.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index a32320b35..489ca68f1 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -54,7 +54,7 @@ static void wacom_wac_queue_insert(struct hid_device *hdev,
{
bool warned = false;
- while (kfifo_avail(fifo) < size) {
+ while (kfifo_avail(fifo) < size && !kfifo_is_empty(fifo)) {
if (!warned)
hid_warn(hdev, "%s: kfifo has filled, starting to drop events\n", __func__);
warned = true;
@@ -62,7 +62,9 @@ static void wacom_wac_queue_insert(struct hid_device *hdev,
kfifo_skip(fifo);
}
- kfifo_in(fifo, raw_data, size);
+ if (!kfifo_in(fifo, raw_data, size))
+ hid_warn_ratelimited(hdev, "%s: report is too large (%d)\n",
+ __func__, size);
}
static void wacom_wac_queue_flush(struct hid_device *hdev,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Conor Dooley @ 2026-05-28 17:10 UTC (permalink / raw)
To: sashiko-reviews
Cc: Hendrik Noack, robh, dmitry.torokhov, conor+dt, devicetree,
linux-input
In-Reply-To: <20260528083225.3A5101F00A3A@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]
On Thu, May 28, 2026 at 08:32:24AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Low] Vendor-specific property 'flash-mode-gpios' is missing the vendor prefix.
> - [Low] Node name 'digitizer@56' in the example should be a standard generic name such as 'touchscreen@56'.
> - [Low] The binding file is named after a specific variant ('wacom,w9007a-lt03.yaml') rather than the first compatible string ('wacom,w9002.yaml').
> --
>
> commit d38ecd0efb12cc8efc9000f9c78e8a14387d40c6
> Author: Hendrik Noack <hendrik-noack@gmx.de>
> Subject: dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
>
> This commit adds bindings for the Wacom W9002, W9007A LT03, and W9007A V1
> touchscreen controllers. These controllers differ slightly in their return
> message formats.
>
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
> > new file mode 100644
> > index 0000000000000..6d1da6a435d39
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
>
> [Severity: Low]
> Should this file be named wacom,w9002.yaml after the first compatible string,
> rather than being named after a specific variant?
This doesn't matter, w9002 is as much of a "variant" as the others.
>
> > @@ -0,0 +1,73 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
>
> [ ... ]
>
> > + vdd-supply: true
> > +
> > + flash-mode-gpios:
> > + maxItems: 1
>
> [Severity: Low]
> Does this property need a vendor prefix (wacom,flash-mode-gpios) since it is
> hardware-specific?
No, cos it is a gpios property. Just like how supplies don't have
prefixes.
>
> [ ... ]
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + digitizer@56 {
>
> [Severity: Low]
> Should this node name be changed to a generic class name such as
> touchscreen@56?
"digitiser" is generic enough for this not to matter IMO.
>
> > + compatible = "wacom,w9007a-lt03";
> > + reg = <0x56>;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260528074818.12151-1-hendrik-noack@gmx.de?part=1
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RESEND 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Benjamin Tissoires @ 2026-05-28 16:01 UTC (permalink / raw)
To: Ping Cheng, Jason Gerecke, Jiri Kosina, linux-input, linux-kernel,
Lee Jones
Cc: stable
In-Reply-To: <20260527160528.847928-1-lee@kernel.org>
On Wed, 27 May 2026 17:05:26 +0100, Lee Jones wrote:
> wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
> usage is always located in the first field (field[0]) of the feature report.
> However, a device can specify HID_DG_INPUTMODE in a different field.
>
> If HID_DG_INPUTMODE is in a field other than the first one and the first
> field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
> this leads to an out-of-bounds write to r->field[0]->value.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.1/upstream-fixes), thanks!
[1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
https://git.kernel.org/hid/hid/c/c0a8899e02dd
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH 00/11] HID: storing pointers in 'hid_device_id::driver_data'
From: Benjamin Tissoires @ 2026-05-28 16:00 UTC (permalink / raw)
To: Pawel Zalewski
Cc: Jiri Kosina, Ping Cheng, Jason Gerecke, linux-kernel, linux-input,
Christian A. Ehrhardt, Christian A. Ehrhardt
In-Reply-To: <ahBgYbMWR4VwFAy3@commodore64>
On May 22 2026, Pawel Zalewski wrote:
> > I would agree with sashiko that the series introduces an anti-pattern by
> > allowing .driver_data to be an arbitrary pointer. The reason is that we
> > can dynamically set driver_data through the kernel command line, and
> > when it's used as a pointer, bad things will happen.
>
> I have not considered the command line override ! This indeed would not
> be a good case for having a pointer at all in there - in the current
> form of the codebase.
>
> The series does not introduce this anti-pattern - this is already the
> current status quo in the codebase and�the problem predates the patch
> series itself. The series makes the problem more visible and validates
> the existing status quo - agreed on this.
Oh, yes sure. But the series makes the anti-pattern official, which
would encourage people to use it. (we are saying the same thing).
>
> > I would think we should fix the 2 offenders to enforce not using a
> > direct pointer but an offset in a table of pointers.
> >
> > How does that sound for you?
>
> That could work, probably via a named enum (so that the idx is bounded
> and validated to avoid out of bounds memory access) with its items mapped
> into a table of const pointers. That way the command line override still
> works as before and my goals set out in the series are met as well.
>
> Perhaps an alternative solution would be to sanitize the user-input instead in
> the 'hid-core::new_id_store' function, such that only 'driver_data' values
> that match an existing entry in the driver's 'id_table' are accepted, this
> is how it is done currently in the PCI subsystem in 'pci-driver::new_id_store',
> so it would be consistent as well.
>
> The bonus here is that all other drivers in the HID subsystem benefit from
> this aproach as opposed to just the two current offenders, as providing
> 'driver_data' from the command line is now mandatory and must match the
> existing table entry - which is what we want ?
>
> So something among the lines of:
>
> @hid-core::new_id_store
>
> ```
> struct hid_driver *hdrv = to_hid_driver(drv);
> const struct hid_device_id *ids = hdrv->id_table;
>
> (...)
>
> /* Only accept driver_data values that match an existing id_table
> entry */
> if (ids) {
> ret = -EINVAL;
> while (ids->vendor || ids->product) {
> if (driver_data == ids->driver_data) {
> ret = 0;
> break;
> }
> ids++;
> }
> if (ret) /* No match */
> return ret;
> }
> ```
>
> Would that approach work for you ?
Yes, sanityzing the input seems like a good idea.
> Do help in what is the correct
> termination for the while loop - for this demo I went with 'ids->vendor'
> and 'ids->product' fields as common-sense would indicate that quirks need
> to be device-specific by definition but that was without any actual research.
hid-core.c does:
const struct hid_device_id *hid_match_id(const struct hid_device *hdev,
const struct hid_device_id *id)
{
for (; id->bus; id++)
if (hid_match_one_id(hdev, id))
return id;
return NULL;
}
So I guess you can simply rely on id-bus being set.
>
> The downside is that 'new_id' drivers that actually use a pointer for the
> 'driver_data' will be rejected - which would be actually covered by the
> solution that you have proposed in the first place. To think of it the
> input sanitizer could work additionaly in tandem with the enum-based
> solution if this fact is an issue, so it might not be an alternative
> actually but a complement for it.
Agree, we need both.
>
> In the meantime I think that patches 1-8 can be reviewed regardless
> without any changes (as they predate patch 9 that adds the union and the
> commit messages does not mention anything about it).
I'd drop patches 1-4. I don't see the point of just rewriting the list
of hid_device_id if we ensure we have just one type.
I need to have a closer look at 5-8 TBH.
Cheers,
Benjamin
>
> Best regards,
> Pawel
>
>
^ permalink raw reply
* Re: [PATCH v2 3/7] platform/surface: SAM: Add support for Surface Pro 12in
From: Ilpo Järvinen @ 2026-05-28 13:43 UTC (permalink / raw)
To: Harrison Vanderbyl
Cc: airlied, andersson, bentiss, conor+dt, davem, devicetree,
dianders, dri-devel, Hans de Goede, herbert, jesszhan0024, jikos,
konradybcio, krzk+dt, linux-arm-msm, linux-crypto, linux-input,
LKML, luzmaximilian, maarten.lankhorst, mripard, neil.armstrong,
platform-driver-x86, robh, simona, tzimmermann
In-Reply-To: <20260528133353.33312-1-harrison.vanderbyl@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Thu, 28 May 2026, Harrison Vanderbyl wrote:
> On Thu, 28 May 2026, Ilpo Järvinen wrote:
> > Could you please confirm this penstash is correct (sam vs kip)?
> >
> > Sashiko suggested it might be wrong but take it's report with a grain of
> > salt, it's AI after all and sometimes seems to extrapolate about HW to a
> > sibling HW without any real knowledge:
>
> Sam is correct here, unlike the surface pro 11,
> The pen stash is on the reverse of the screen,
> not on the detachable keyboard.
>
> An image of the pen stash in use is available here:
> https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/B04-Surface-Pro-12-inch-1Ed-Family-Rear?wid=1200&hei=900&qlt=90&bgc=F2F2F2F2&fmt=jpg
>
> When using the above config,
> pen stash events can be seen with evtest.
Thanks for confirming (not a big surprise AI couldn't know the spec but
it was worth checking if it would have been because of copy-paste).
I've applied this patch 3 now to the review-ilpo-next branch.
--
i.
^ permalink raw reply
* Re: [PATCH v2 3/7] platform/surface: SAM: Add support for Surface Pro 12in
From: Harrison Vanderbyl @ 2026-05-28 13:33 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: airlied, andersson, bentiss, conor+dt, davem, devicetree,
dianders, dri-devel, hansg, herbert, jesszhan0024, jikos,
konradybcio, krzk+dt, linux-arm-msm, linux-crypto, linux-input,
linux-kernel, luzmaximilian, maarten.lankhorst, mripard,
neil.armstrong, platform-driver-x86, robh, simona, tzimmermann
In-Reply-To: <6808166a-423c-c801-497a-ed95cccc8d0c@linux.intel.com>
On Thu, 28 May 2026, Ilpo Järvinen wrote:
> Could you please confirm this penstash is correct (sam vs kip)?
>
> Sashiko suggested it might be wrong but take it's report with a grain of
> salt, it's AI after all and sometimes seems to extrapolate about HW to a
> sibling HW without any real knowledge:
Sam is correct here, unlike the surface pro 11,
The pen stash is on the reverse of the screen,
not on the detachable keyboard.
An image of the pen stash in use is available here:
https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/B04-Surface-Pro-12-inch-1Ed-Family-Rear?wid=1200&hei=900&qlt=90&bgc=F2F2F2F2&fmt=jpg
When using the above config,
pen stash events can be seen with evtest.
Thanks,
Harrison
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: Add Microsoft Surface Pro 12in
From: Dmitry Baryshkov @ 2026-05-28 13:19 UTC (permalink / raw)
To: Harrison Vanderbyl
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, Herbert Xu,
davem, neil.armstrong, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, jikos, bentiss, luzmaximilian, hansg,
ilpo.jarvinen, Douglas Anderson, Jessica Zhang, linux-arm-msm,
devicetree, linux-kernel, linux-crypto, dri-devel, linux-input,
platform-driver-x86
In-Reply-To: <8ac29ee38ba80a3fbde8bfe43b74b9b936b31cb1.1778822464.git.harrison.vanderbyl@gmail.com>
On Fri, May 15, 2026 at 03:41:52PM +1000, Harrison Vanderbyl wrote:
> Initial device tree for Microsoft Surface Pro 12in
>
> Currently supported:
> - UFS
> - Touchscreen
> - Pen
> - USB 3.2 x2 (DP Alt Mode)
> - Audio
> - Wifi
> - Bluetooth
> - CDSP
> - ADSP
> - GPU
>
> Not currently supported:
> - Accelerometer
> - Front, Back and IR cameras
> - IRIS video decoder
>
> Tested on Surface_Pro_12in_1st_Ed_with_Snapdragon_2110
>
> Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> .../dts/qcom/x1p42100-microsoft-sp12in.dts | 1201 +++++++++++++++++
> 2 files changed, 1203 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/x1p42100-microsoft-sp12in.dts
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/7] platform/surface: SAM: Add support for Surface Pro 12in
From: Ilpo Järvinen @ 2026-05-28 12:42 UTC (permalink / raw)
To: Harrison Vanderbyl
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, Herbert Xu,
davem, neil.armstrong, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, jikos, bentiss, luzmaximilian, Hans de Goede,
Douglas Anderson, Jessica Zhang, linux-arm-msm, devicetree, LKML,
linux-crypto, dri-devel, linux-input, platform-driver-x86
In-Reply-To: <ab458aadea651396d9ea7629419a32dc7510c593.1778822464.git.harrison.vanderbyl@gmail.com>
On Fri, 15 May 2026, Harrison Vanderbyl wrote:
> Add a SAM client device node group and registry entry for the
> Microsoft Surface Pro, 12-inch with Snapdragon.
>
> This set enables the use of the following devices.
> 1: cover keyboard
> 2: cover touchpad
> 3: pen stash events.
>
> The battery info and charger info devices have been
> purposefully omitted as they are also reported by
> other drivers and cause conflicts.
>
> Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
> ---
> .../surface/surface_aggregator_registry.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/platform/surface/surface_aggregator_registry.c b/drivers/platform/surface/surface_aggregator_registry.c
> index 0599d5adf02e..884049961415 100644
> --- a/drivers/platform/surface/surface_aggregator_registry.c
> +++ b/drivers/platform/surface/surface_aggregator_registry.c
> @@ -422,6 +422,19 @@ static const struct software_node *ssam_node_group_sp11[] = {
> NULL,
> };
>
> +/* Devices for Surface Pro 12" first edition (ARM/QCOM) */
> +static const struct software_node *ssam_node_group_sp12in[] = {
> + &ssam_node_root,
> + &ssam_node_hub_kip,
> + &ssam_node_tmp_sensors,
> + &ssam_node_hid_kip_keyboard,
> + &ssam_node_hid_sam_penstash,
Hi,
Could you please confirm this penstash is correct (sam vs kip)?
Sashiko suggested it might be wrong but take it's report with a grain of
salt, it's AI after all and sometimes seems to extrapolate about HW to a
sibling HW without any real knowledge:
https://sashiko.dev/#/patchset/cover.1778822464.git.harrison.vanderbyl%40gmail.com
--
i.
> + &ssam_node_hid_kip_touchpad,
> + &ssam_node_hid_kip_fwupd,
> + &ssam_node_pos_tablet_switch,
> + NULL,
> +};
> +
> /* -- SSAM platform/meta-hub driver. ---------------------------------------- */
>
> static const struct acpi_device_id ssam_platform_hub_acpi_match[] = {
> @@ -500,6 +513,8 @@ static const struct of_device_id ssam_platform_hub_of_match[] __maybe_unused = {
> { .compatible = "microsoft,arcata", (void *)ssam_node_group_sp9_5g },
> /* Surface Pro 11 (ARM/QCOM) */
> { .compatible = "microsoft,denali", (void *)ssam_node_group_sp11 },
> + /* Surface Pro 12in First Edition (ARM/QCOM) */
> + { .compatible = "microsoft,surface-pro-12in", (void *)ssam_node_group_sp12in },
> /* Surface Laptop 7 */
> { .compatible = "microsoft,romulus13", (void *)ssam_node_group_sl7 },
> { .compatible = "microsoft,romulus15", (void *)ssam_node_group_sl7 },
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: atmel_mxt_ts: Allow per-machine config via DT compatible
From: sashiko-bot @ 2026-05-28 9:28 UTC (permalink / raw)
To: Hendrik Noack; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260528074317.9604-2-hendrik-noack@gmx.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Concurrent execution of 'mxt_load_fw' via the 'update_fw' sysfs attribute lacks locking, leading to double-free of the input device, TOCTOU races, and interleaved I2C commands.
--
commit eb7b8b6b98800084b750dc1b902ad664e878e3d8
Author: Hendrik Noack <hendrik-noack@gmx.de>
Input: atmel_mxt_ts: Allow per-machine config via DT compatible
The Atmel maXTouch config is machine-dependent, different panels and
layouts require different configs even when the same controller and
firmware is used.
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index a88dc7e6827c7..5ac123d4ed036 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
[ ... ]
> @@ -2291,12 +2351,9 @@ static int mxt_initialize(struct mxt_data *data)
> return -EBUSY;
> }
>
> - error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
> - &client->dev, GFP_KERNEL, data,
> - mxt_config_cb);
> + error = mxt_invoke_config_loader(data, true);
> if (error) {
> - dev_err(&client->dev, "Failed to invoke firmware loader: %d\n",
> - error);
> + dev_err(&client->dev, "Failed to invoke config loader: %d\n", error);
> complete(&data->config_completion);
> return error;
> }
[Severity: High]
This is a pre-existing issue, but I noticed that mxt_update_fw_store()
invokes mxt_load_fw() without any locking to serialize concurrent execution.
Since sysfs write operations don't hold a global lock like device_lock,
could multiple threads concurrently writing to the update_fw attribute race
when checking and setting data->in_bootloader?
If so, could both threads concurrently execute mxt_free_input_device(),
observe a non-null data->input_dev, and invoke input_unregister_device() on
the same pointer before it is set to NULL?
This seems like it might lead to a double-free or use-after-free since
input_unregister_device() drops the reference count.
Could this also race with PM callbacks like mxt_suspend() attempting to
acquire input_dev->mutex, operating on freed memory if
mxt_free_input_device() is executed concurrently?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528074317.9604-1-hendrik-noack@gmx.de?part=2
^ permalink raw reply
* Re: [PATCH v8 2/2] Input: Add support for Wacom W9000-series penabled touchscreens
From: sashiko-bot @ 2026-05-28 9:01 UTC (permalink / raw)
To: Hendrik Noack; +Cc: robh, conor+dt, devicetree, dmitry.torokhov, linux-input
In-Reply-To: <20260528074818.12151-3-hendrik-noack@gmx.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver uses stack-allocated buffers for I2C transfers, which violates the DMA API and can cause panics or memory corruption.
--
commit 5c60cba7d031762dd1ed0e3769ce031bf93c9b48
Author: Hendrik Noack <hendrik-noack@gmx.de>
Input: Add support for Wacom W9000-series penabled touchscreens
This commit adds a new input driver for the Wacom W9000-series penabled
touchscreens, supporting passive Wacom pens over an I2C interface.
> diff --git a/drivers/input/touchscreen/wacom_w9000.c b/drivers/input/touchscreen/wacom_w9000.c
> new file mode 100644
> index 0000000000000..7795508f93b29
> --- /dev/null
> +++ b/drivers/input/touchscreen/wacom_w9000.c
[ ... ]
> +static int wacom_w9000_read(struct i2c_client *client, u8 command, u8 len, u8 *data)
> +{
> + int error, res;
> + struct i2c_msg msg[] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .buf = &command,
> + .len = sizeof(command),
[Severity: High]
Is it safe to pass a stack-allocated variable (&command) as an I2C transfer
buffer?
If the underlying I2C adapter uses DMA, transferring from a stack address
can lead to kernel panics or silent memory corruption. This happens because
stack memory is often virtually mapped (when CONFIG_VMAP_STACK is enabled)
and is not guaranteed to be safely cacheline aligned.
Would it be better to allocate these buffers dynamically or embed a
DMA-safe buffer inside the wacom_w9000_data structure?
> + }, {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .buf = data,
> + .len = len,
> + }
> + };
> +
> + res = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
> + if (res != ARRAY_SIZE(msg)) {
> + error = res < 0 ? res : -EIO;
> + dev_err(&client->dev, "%s: i2c transfer failed: %d (%d)\n", __func__, error, res);
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static int wacom_w9000_query(struct wacom_w9000_data *wacom_data)
> +{
> + struct i2c_client *client = wacom_data->client;
> + struct device *dev = &wacom_data->client->dev;
> + int error;
> + int retry = 0;
> + u8 data[CMD_QUERY_NUM_MAX];
[Severity: High]
Similarly, does passing this stack-allocated array down to wacom_w9000_read()
violate the DMA API requirements for the same reasons?
> +
> + for (; retry < CMD_QUERY_RETRIES; retry++) {
> + error = wacom_w9000_read(client, CMD_QUERY, wacom_data->variant->cmd_query_num,
> + data);
[ ... ]
> +static void wacom_w9000_coord(struct wacom_w9000_data *wacom_data)
> +{
> + struct i2c_client *client = wacom_data->client;
> + struct device *dev = &wacom_data->client->dev;
> + int error;
> + u8 data[MSG_COORD_NUM_MAX];
> + bool touch, rubber, side_button;
> + u16 x, y, pressure;
> + u8 distance = 0;
> +
> + error = i2c_master_recv(client, data, wacom_data->variant->msg_coord_num);
[Severity: High]
Can this call to i2c_master_recv() corrupt memory by DMAing into the
stack-allocated data array? Using a dedicated buffer allocated with kzalloc
or similar might prevent this issue on the coordinate data path.
> + if (error != wacom_data->variant->msg_coord_num) {
> + if (error >= 0)
> + error = -EIO;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528074818.12151-1-hendrik-noack@gmx.de?part=2
^ permalink raw reply
* Re: [PATCH v8 7/7] power: supply: Add charger driver for Asus Transformers
From: sashiko-bot @ 2026-05-28 8:58 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, dmitry.torokhov, conor+dt, linux-input, devicetree
In-Reply-To: <20260528053203.9339-8-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Strict equality check on `action` bitmask may cause dropped events.
--
commit 55ed27a4bfa91a64727ac41721ebdb9163ebef2a
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
power: supply: Add charger driver for Asus Transformers
This commit adds a new driver to support charger detection capabilities
provided by the embedded controller on ASUS Transformer devices. It
reports properties like USB type, charging behaviour, and online status.
> diff --git a/drivers/power/supply/asus-transformer-ec-charger.c b/drivers/power/supply/asus-transformer-ec-charger.c
> new file mode 100644
> index 0000000000000..c7a6bd2ba533f
> --- /dev/null
> +++ b/drivers/power/supply/asus-transformer-ec-charger.c
[ ... ]
> +static int asus_ec_charger_notify(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct asus_ec_charger_data *priv =
> + container_of(nb, struct asus_ec_charger_data, nb);
> +
> + switch (action) {
> + case ASUSEC_SMI_ACTION(POWER_NOTIFY):
> + case ASUSEC_SMI_ACTION(ADAPTER_EVENT):
[Severity: Medium]
Will this strict equality check cause charger events to be dropped if multiple
interrupt flags are set simultaneously?
The action parameter appears to be constructed by the parent MFD driver by
taking the raw ASUSEC_IRQ_STATUS byte and OR'ing it with the SMI code shifted
by 8 bits. Since ASUSEC_IRQ_STATUS is a bitmask, if an SMI event occurs
concurrently with another event (such as a keyboard press), the action bitmask
will contain additional bits.
Could this strict switch check be replaced by checking the ASUSEC_SMI_MASK with
a bitwise AND operation, and then evaluating the SMI code separately?
> + power_supply_changed(priv->psy);
> + break;
> + }
> +
> + return NOTIFY_DONE;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH v3 1/2] Input: atmel_mxt_ts: Fix async config use-after-free
From: sashiko-bot @ 2026-05-28 8:48 UTC (permalink / raw)
To: Hendrik Noack; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260528074317.9604-1-hendrik-noack@gmx.de>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Low] The `shutting_down` flag and `complete_all()` logic introduced to serialize shutdown are completely unreachable dead code and contain misleading logging.
Pre-existing issues:
- [High] Concurrent sysfs operations lack synchronization, leading to severe use-after-free and double-free vulnerabilities.
- [High] The `wait_for_completion(&data->config_completion)` in `mxt_initialize()` is placed too late, failing to protect against concurrent execution with the firmware callback when triggered via sysfs.
- [High] Accessing the `update_fw` sysfs attribute before probe completes leads to a NULL pointer dereference.
--
commit f95104521ff6a213450d681f2eb88830307206ae
Author: Hendrik Noack <hendrik-noack@gmx.de>
Input: atmel_mxt_ts: Fix async config use-after-free
The driver starts asynchronous config loading from probe and sysfs. If the
driver is removed while a request is pending, devres frees mxt_data, leading
to a use-after-free in the callback. The patch introduces a completion to
serialize request_firmware_nowait() and remove().
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index a9e86ad7ed5ef..a88dc7e6827c7 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
[ ... ]
> @@ -2271,12 +2278,26 @@ static int mxt_initialize(struct mxt_data *data)
> if (error)
> return error;
>
> + wait_for_completion(&data->config_completion);
[Severity: High]
This is a pre-existing issue, but does wait_for_completion() happen too late
here to protect against concurrent execution with the firmware callback when
triggered via sysfs?
When mxt_update_fw_store() is invoked, it first calls mxt_load_fw(), which
clears data->info via mxt_free_object_table(), before mxt_initialize() is
even called.
It then calls mxt_initialize(), which waits for the completion. However, if
a previously initiated mxt_config_cb() is executing concurrently, it uses
data->info inside mxt_configure_objects().
Since mxt_load_fw() frees and clears this pointer without waiting for the
async callback to finish, mxt_config_cb() will suffer a null pointer
dereference or use-after-free. The wait seems placed too late to prevent
this sysfs race.
[Severity: High]
This is a pre-existing issue, but do concurrent sysfs operations lack
synchronization?
The driver exposes sysfs attributes like update_fw without internal
serialization. The sysfs framework permits multiple threads to write to the
same attribute concurrently.
mxt_update_fw_store() directly invokes mxt_load_fw(), which destructively
modifies device state by calling mxt_free_object_table().
Without a mutex protecting this path, concurrent writes to update_fw will
cause multiple threads to enter these teardown functions simultaneously,
leading to a double free of data->raw_info_block and data->msg_buf.
> +
> + if (data->shutting_down) {
> + /* complete() only signals one waiter, signal all waiters once during shutdown */
> + if (!completion_done(&data->config_completion)) {
> + complete_all(&data->config_completion);
> + dev_info(&client->dev, "Shutting down, not loading new config: %d\n",
> + error);
[Severity: Low]
Is this block actually reachable? mxt_initialize() is only invoked by
mxt_probe() and the sysfs attribute mxt_update_fw_store().
The driver core strictly serializes mxt_probe() and mxt_remove() via the
device lock. For the sysfs path, the driver core drains active sysfs
operations via device_remove_groups() before invoking the bus remove()
callback (which calls mxt_remove()).
Because of this, it seems mxt_initialize() and mxt_remove() can never run
concurrently.
Also, error here is mathematically guaranteed to be 0 since we just passed
if (error) return error, making the log message semantically misleading.
> + }
> +
> + return -EBUSY;
> + }
> +
[ ... ]
> @@ -3237,6 +3258,9 @@ static int mxt_probe(struct i2c_client *client)
> init_completion(&data->bl_completion);
> init_completion(&data->reset_completion);
> init_completion(&data->crc_completion);
> + init_completion(&data->config_completion);
> + complete(&data->config_completion);
> + data->shutting_down = false;
[Severity: High]
This is a pre-existing issue, but could accessing the update_fw sysfs
attribute before probe completes lead to a null pointer dereference?
Sysfs attributes defined via mxt_driver.driver.dev_groups are registered by
the driver core (device_add_groups()) before the driver's probe function is
called.
An early write to update_fw during this window executes
mxt_update_fw_store() before i2c_set_clientdata() is called in mxt_probe().
In this scenario, dev_get_drvdata(dev) returns a null pointer, which is then
immediately dereferenced in mxt_load_fw():
drivers/input/touchscreen/atmel_mxt_ts.c:mxt_load_fw() {
...
if (!data->in_bootloader) {
...
}
Would this cause a kernel panic?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528074317.9604-1-hendrik-noack@gmx.de?part=1
^ permalink raw reply
* Re: [PATCH v8 6/7] power: supply: Add driver for ASUS Transformer battery
From: sashiko-bot @ 2026-05-28 8:32 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: linux-input, conor+dt, devicetree, dmitry.torokhov, robh
In-Reply-To: <20260528053203.9339-7-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Short I2C reads return a positive value that bypasses the caller's error check, leading to uninitialized data access and cache bypass.
- [Medium] Off-by-one error in length bounds check allows reading outside the valid EC payload.
--
commit 04954fc98984d98f0039fee1c123ecdf16dc2ff7
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
power: supply: Add driver for ASUS Transformer battery
This commit adds a new driver for ASUS Transformer batteries, which implements
one battery cell per EC controller and supports reading battery status for the
pad and mobile dock.
> diff --git a/drivers/power/supply/asus-transformer-ec-battery.c b/drivers/power/supply/asus-transformer-ec-battery.c
> new file mode 100644
> index 0000000000000..db6331352f7d4
> --- /dev/null
> +++ b/drivers/power/supply/asus-transformer-ec-battery.c
[ ... ]
> +static int asus_ec_battery_refresh(struct asus_ec_battery_data *priv)
> +{
> + struct i2c_client *client = priv->ec->dockram;
> + struct device *dev = &client->dev;
> + int ret = 0;
> +
> + if (time_before(jiffies, priv->batt_data_ts))
> + return ret;
> +
> + memset(priv->batt_data, 0, ASUSEC_ENTRY_BUFSIZE);
> + ret = i2c_smbus_read_i2c_block_data(client, ASUSEC_DOCKRAM_BATT_CTL,
> + ASUSEC_ENTRY_SIZE, priv->batt_data);
> + if (ret < ASUSEC_ENTRY_SIZE)
> + return ret;
[Severity: Medium]
Since i2c_smbus_read_i2c_block_data() returns the number of bytes read on
success, could this return a positive value on a short read?
If this returns a positive value less than ASUSEC_ENTRY_SIZE, it bypasses
updating the batt_data_ts timestamp, which breaks the 5-second caching
mechanism and triggers an I2C transaction on every subsequent property read.
Additionally, asus_ec_battery_get_value() below only checks for errors with
if (ret < 0), which would fail to catch this positive short read value as
an error, potentially leading to the use of uninitialized data.
[ ... ]
> +static int asus_ec_battery_get_value(struct asus_ec_battery_data *priv,
> + enum power_supply_property psp)
> +{
> + int ret, offs;
> +
> + guard(mutex)(&priv->battery_lock);
> +
> + if (psp >= ARRAY_SIZE(asus_ec_battery_prop_offs))
> + return -EINVAL;
> +
> + offs = asus_ec_battery_prop_offs[psp];
> + if (!offs)
> + return -EINVAL;
> +
> + ret = asus_ec_battery_refresh(priv);
> + if (ret < 0)
> + return ret;
> +
> + if (offs >= priv->batt_data[0])
> + return -ENODATA;
> +
> + return get_unaligned_le16(priv->batt_data + offs);
> +}
[Severity: Medium]
Does this bounds check properly account for the 16-bit read?
Since get_unaligned_le16() reads two bytes, if offs exactly equals
priv->batt_data[0] - 1, the bounds check passes. However, the second byte
read (offs + 1) would fall outside the valid payload length.
Could this silently combine one byte of valid data with a zero-padded byte
from the buffer, returning a corrupted value?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: sashiko-bot @ 2026-05-28 8:32 UTC (permalink / raw)
To: Hendrik Noack; +Cc: robh, dmitry.torokhov, conor+dt, devicetree, linux-input
In-Reply-To: <20260528074818.12151-2-hendrik-noack@gmx.de>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] Vendor-specific property 'flash-mode-gpios' is missing the vendor prefix.
- [Low] Node name 'digitizer@56' in the example should be a standard generic name such as 'touchscreen@56'.
- [Low] The binding file is named after a specific variant ('wacom,w9007a-lt03.yaml') rather than the first compatible string ('wacom,w9002.yaml').
--
commit d38ecd0efb12cc8efc9000f9c78e8a14387d40c6
Author: Hendrik Noack <hendrik-noack@gmx.de>
Subject: dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
This commit adds bindings for the Wacom W9002, W9007A LT03, and W9007A V1
touchscreen controllers. These controllers differ slightly in their return
message formats.
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
> new file mode 100644
> index 0000000000000..6d1da6a435d39
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
[Severity: Low]
Should this file be named wacom,w9002.yaml after the first compatible string,
rather than being named after a specific variant?
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
[ ... ]
> + vdd-supply: true
> +
> + flash-mode-gpios:
> + maxItems: 1
[Severity: Low]
Does this property need a vendor prefix (wacom,flash-mode-gpios) since it is
hardware-specific?
[ ... ]
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + digitizer@56 {
[Severity: Low]
Should this node name be changed to a generic class name such as
touchscreen@56?
> + compatible = "wacom,w9007a-lt03";
> + reg = <0x56>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528074818.12151-1-hendrik-noack@gmx.de?part=1
^ permalink raw reply
* [PATCH v8 2/2] Input: Add support for Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-05-28 7:48 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hendrik Noack, Ferass El Hafidi, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260528074818.12151-1-hendrik-noack@gmx.de>
Add driver for Wacom W9002 and two Wacom W9007A variants. These are
penabled touchscreens supporting passive Wacom Pens and use I2C.
Co-developed-by: Ferass El Hafidi <funderscore@postmarketos.org>
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/wacom_w9000.c | 448 ++++++++++++++++++++++++
3 files changed, 461 insertions(+)
create mode 100644 drivers/input/touchscreen/wacom_w9000.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 484522d8d675..9b9ae8ac3f7f 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -610,6 +610,18 @@ config TOUCHSCREEN_WACOM_I2C
To compile this driver as a module, choose M here: the module
will be called wacom_i2c.
+config TOUCHSCREEN_WACOM_W9000
+ tristate "Wacom W9000-series penabled touchscreen (I2C)"
+ depends on I2C
+ help
+ Say Y here if you have a Wacom W9000-series penabled I2C touchscreen.
+ This driver supports models W9002 and W9007A.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module
+ will be called wacom_w9000.
+
config TOUCHSCREEN_LPC32XX
tristate "LPC32XX touchscreen controller"
depends on ARCH_LPC32XX
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 6d397268d2e3..bfd9de83389d 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -100,6 +100,7 @@ tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO) += tsc2007_iio.o
obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o
obj-$(CONFIG_TOUCHSCREEN_WACOM_I2C) += wacom_i2c.o
+obj-$(CONFIG_TOUCHSCREEN_WACOM_W9000) += wacom_w9000.o
obj-$(CONFIG_TOUCHSCREEN_WDT87XX_I2C) += wdt87xx_i2c.o
obj-$(CONFIG_TOUCHSCREEN_WM831X) += wm831x-ts.o
obj-$(CONFIG_TOUCHSCREEN_WM97XX) += wm97xx-ts.o
diff --git a/drivers/input/touchscreen/wacom_w9000.c b/drivers/input/touchscreen/wacom_w9000.c
new file mode 100644
index 000000000000..7795508f93b2
--- /dev/null
+++ b/drivers/input/touchscreen/wacom_w9000.c
@@ -0,0 +1,448 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Wacom W9000-series penabled I2C touchscreen driver
+ *
+ * Copyright (c) 2026 Hendrik Noack <hendrik-noack@gmx.de>
+ *
+ * Partially based on vendor driver:
+ * Copyright (C) 2012, Samsung Electronics Co. Ltd.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/touchscreen.h>
+#include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
+#include <linux/unaligned.h>
+
+/* Some chips have flaky firmware that requires many retries before responding. */
+#define CMD_QUERY_RETRIES 8
+
+/* Message length */
+#define CMD_QUERY_NUM_MAX 9
+#define MSG_COORD_NUM_MAX 12
+
+/* Commands */
+#define CMD_QUERY 0x2a
+
+struct wacom_w9000_variant {
+ const u8 cmd_query_num;
+ const u8 msg_coord_num;
+ const char *name;
+};
+
+struct wacom_w9000_data {
+ struct i2c_client *client;
+ struct input_dev *input_dev;
+ const struct wacom_w9000_variant *variant;
+ u16 fw_version;
+
+ struct touchscreen_properties prop;
+ u16 max_pressure;
+
+ struct regulator *regulator;
+ bool powered;
+
+ struct gpio_desc *flash_mode_gpio;
+ struct gpio_desc *reset_gpio;
+
+ unsigned int irq;
+
+ bool pen_proximity;
+};
+
+static int wacom_w9000_read(struct i2c_client *client, u8 command, u8 len, u8 *data)
+{
+ int error, res;
+ struct i2c_msg msg[] = {
+ {
+ .addr = client->addr,
+ .flags = 0,
+ .buf = &command,
+ .len = sizeof(command),
+ }, {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .buf = data,
+ .len = len,
+ }
+ };
+
+ res = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
+ if (res != ARRAY_SIZE(msg)) {
+ error = res < 0 ? res : -EIO;
+ dev_err(&client->dev, "%s: i2c transfer failed: %d (%d)\n", __func__, error, res);
+ return error;
+ }
+
+ return 0;
+}
+
+static int wacom_w9000_query(struct wacom_w9000_data *wacom_data)
+{
+ struct i2c_client *client = wacom_data->client;
+ struct device *dev = &wacom_data->client->dev;
+ int error;
+ int retry = 0;
+ u8 data[CMD_QUERY_NUM_MAX];
+
+ for (; retry < CMD_QUERY_RETRIES; retry++) {
+ error = wacom_w9000_read(client, CMD_QUERY, wacom_data->variant->cmd_query_num,
+ data);
+
+ if (!error && (data[0] == 0x0f))
+ break;
+ }
+
+ if (error || (data[0] != 0x0f))
+ return error ? error : -EIO;
+
+ dev_dbg(dev, "query: %*ph, %d\n", wacom_data->variant->cmd_query_num, data, retry);
+
+ wacom_data->prop.max_x = get_unaligned_be16(&data[1]);
+ wacom_data->prop.max_y = get_unaligned_be16(&data[3]);
+ wacom_data->max_pressure = get_unaligned_be16(&data[5]);
+ wacom_data->fw_version = get_unaligned_be16(&data[7]);
+
+ dev_dbg(dev, "max_x:%d, max_y:%d, max_pressure:%d, fw:%#x", wacom_data->prop.max_x,
+ wacom_data->prop.max_y, wacom_data->max_pressure,
+ wacom_data->fw_version);
+
+ return 0;
+}
+
+/* Must be called with wacom_data->input_dev->mutex held */
+static int wacom_w9000_power_on(struct wacom_w9000_data *wacom_data)
+{
+ int error;
+
+ if (wacom_data->powered)
+ return 0;
+
+ error = regulator_enable(wacom_data->regulator);
+ if (error) {
+ dev_err(&wacom_data->client->dev, "Failed to enable regulators: %d\n", error);
+ return error;
+ }
+
+ msleep(200);
+
+ gpiod_set_value_cansleep(wacom_data->reset_gpio, 0);
+ enable_irq(wacom_data->irq);
+
+ wacom_data->powered = true;
+
+ return error;
+}
+
+/* Must be called with wacom_data->input_dev->mutex held */
+static int wacom_w9000_power_off(struct wacom_w9000_data *wacom_data)
+{
+ if (!wacom_data->powered)
+ return 0;
+
+ disable_irq(wacom_data->irq);
+ gpiod_set_value_cansleep(wacom_data->reset_gpio, 1);
+ regulator_disable(wacom_data->regulator);
+
+ wacom_data->powered = false;
+
+ return 0;
+}
+
+static void wacom_w9000_coord(struct wacom_w9000_data *wacom_data)
+{
+ struct i2c_client *client = wacom_data->client;
+ struct device *dev = &wacom_data->client->dev;
+ int error;
+ u8 data[MSG_COORD_NUM_MAX];
+ bool touch, rubber, side_button;
+ u16 x, y, pressure;
+ u8 distance = 0;
+
+ error = i2c_master_recv(client, data, wacom_data->variant->msg_coord_num);
+ if (error != wacom_data->variant->msg_coord_num) {
+ if (error >= 0)
+ error = -EIO;
+ dev_err_ratelimited(dev, "%s: i2c receive failed (%d)\n", __func__, error);
+ return;
+ }
+
+ dev_dbg(dev, "data: %*ph", wacom_data->variant->msg_coord_num, data);
+
+ if (data[0] & BIT(7)) {
+ wacom_data->pen_proximity = true;
+
+ touch = !!(data[0] & BIT(4));
+ side_button = !!(data[0] & BIT(5));
+ rubber = !!(data[0] & BIT(6));
+
+ x = get_unaligned_be16(&data[1]);
+ y = get_unaligned_be16(&data[3]);
+ pressure = get_unaligned_be16(&data[5]);
+
+ if (wacom_data->variant->msg_coord_num > 7)
+ distance = data[7];
+
+ if (x > wacom_data->prop.max_x || y > wacom_data->prop.max_y) {
+ dev_warn_ratelimited(dev, "Coordinates out of range x=%d, y=%d", x, y);
+ return;
+ }
+
+ if (pressure > wacom_data->max_pressure) {
+ dev_warn_ratelimited(dev, "Pressure out of range %d", pressure);
+ return;
+ }
+
+ touchscreen_report_pos(wacom_data->input_dev, &wacom_data->prop, x, y, false);
+ input_report_abs(wacom_data->input_dev, ABS_PRESSURE, pressure);
+
+ if (wacom_data->variant->msg_coord_num > 7)
+ input_report_abs(wacom_data->input_dev, ABS_DISTANCE, distance);
+
+ input_report_key(wacom_data->input_dev, BTN_STYLUS, side_button);
+ input_report_key(wacom_data->input_dev, BTN_TOUCH, touch);
+ input_report_key(wacom_data->input_dev, BTN_TOOL_PEN, !rubber);
+ input_report_key(wacom_data->input_dev, BTN_TOOL_RUBBER, rubber);
+ input_sync(wacom_data->input_dev);
+ } else if (wacom_data->pen_proximity) {
+ input_report_abs(wacom_data->input_dev, ABS_PRESSURE, 0);
+
+ if (wacom_data->variant->msg_coord_num > 7)
+ input_report_abs(wacom_data->input_dev, ABS_DISTANCE, 255);
+
+ input_report_key(wacom_data->input_dev, BTN_STYLUS, 0);
+ input_report_key(wacom_data->input_dev, BTN_TOUCH, 0);
+ input_report_key(wacom_data->input_dev, BTN_TOOL_PEN, 0);
+ input_report_key(wacom_data->input_dev, BTN_TOOL_RUBBER, 0);
+ input_sync(wacom_data->input_dev);
+
+ wacom_data->pen_proximity = false;
+ }
+}
+
+static irqreturn_t wacom_w9000_interrupt(int irq, void *dev_id)
+{
+ struct wacom_w9000_data *wacom_data = dev_id;
+
+ wacom_w9000_coord(wacom_data);
+
+ return IRQ_HANDLED;
+}
+
+static int wacom_w9000_open(struct input_dev *dev)
+{
+ struct wacom_w9000_data *wacom_data = input_get_drvdata(dev);
+
+ return wacom_w9000_power_on(wacom_data);
+}
+
+static void wacom_w9000_close(struct input_dev *dev)
+{
+ struct wacom_w9000_data *wacom_data = input_get_drvdata(dev);
+
+ wacom_w9000_power_off(wacom_data);
+}
+
+static int wacom_w9000_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct wacom_w9000_data *wacom_data;
+ struct input_dev *input_dev;
+ int error;
+ u32 val;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ dev_err(dev, "i2c_check_functionality error\n");
+ return -EIO;
+ }
+
+ wacom_data = devm_kzalloc(dev, sizeof(*wacom_data), GFP_KERNEL);
+ if (!wacom_data)
+ return -ENOMEM;
+
+ wacom_data->variant = i2c_get_match_data(client);
+ if (!wacom_data->variant) {
+ dev_err(dev, "No i2c match_data available\n");
+ return -EINVAL;
+ }
+
+ if (wacom_data->variant->cmd_query_num > CMD_QUERY_NUM_MAX ||
+ wacom_data->variant->msg_coord_num > MSG_COORD_NUM_MAX) {
+ dev_err(dev, "Length of message for %s exceeds the maximum\n",
+ wacom_data->variant->name);
+ return -EINVAL;
+ }
+
+ if (wacom_data->variant->msg_coord_num < 7) {
+ dev_err(dev, "Length of coordinates message for %s too short\n",
+ wacom_data->variant->name);
+ return -EINVAL;
+ }
+
+ wacom_data->client = client;
+ wacom_data->irq = client->irq;
+ i2c_set_clientdata(client, wacom_data);
+
+ wacom_data->regulator = devm_regulator_get(dev, "vdd");
+ if (IS_ERR(wacom_data->regulator))
+ return dev_err_probe(dev, PTR_ERR(wacom_data->regulator),
+ "Failed to get regulators\n");
+
+ wacom_data->flash_mode_gpio = devm_gpiod_get_optional(dev, "flash-mode", GPIOD_OUT_LOW);
+ if (IS_ERR(wacom_data->flash_mode_gpio))
+ return dev_err_probe(dev, PTR_ERR(wacom_data->flash_mode_gpio),
+ "Failed to get flash-mode gpio\n");
+
+ wacom_data->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(wacom_data->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(wacom_data->reset_gpio),
+ "Failed to get reset gpio\n");
+
+ error = regulator_enable(wacom_data->regulator);
+ if (error)
+ return dev_err_probe(dev, error, "Failed to enable regulators\n");
+
+ msleep(200);
+
+ gpiod_set_value_cansleep(wacom_data->reset_gpio, 0);
+
+ error = wacom_w9000_query(wacom_data);
+
+ gpiod_set_value_cansleep(wacom_data->reset_gpio, 1);
+ regulator_disable(wacom_data->regulator);
+
+ wacom_data->powered = false;
+
+ if (error)
+ return dev_err_probe(dev, error, "Failed to query\n");
+
+ error = devm_request_threaded_irq(dev, wacom_data->irq, NULL, wacom_w9000_interrupt,
+ IRQF_ONESHOT | IRQF_NO_AUTOEN, client->name, wacom_data);
+ if (error)
+ return dev_err_probe(dev, error, "Failed to register interrupt\n");
+
+ input_dev = devm_input_allocate_device(dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ wacom_data->input_dev = input_dev;
+ input_set_drvdata(input_dev, wacom_data);
+
+ input_dev->name = wacom_data->variant->name;
+ input_dev->id.bustype = BUS_I2C;
+ input_dev->dev.parent = dev;
+ input_dev->id.vendor = 0x56a;
+ input_dev->id.version = wacom_data->fw_version;
+ input_dev->open = wacom_w9000_open;
+ input_dev->close = wacom_w9000_close;
+
+ input_set_capability(input_dev, EV_KEY, BTN_TOUCH);
+ input_set_capability(input_dev, EV_KEY, BTN_TOOL_PEN);
+ input_set_capability(input_dev, EV_KEY, BTN_TOOL_RUBBER);
+ input_set_capability(input_dev, EV_KEY, BTN_STYLUS);
+
+ input_set_abs_params(input_dev, ABS_X, 0, wacom_data->prop.max_x, 4, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0, wacom_data->prop.max_y, 4, 0);
+ input_set_abs_params(input_dev, ABS_PRESSURE, 0, wacom_data->max_pressure, 0, 0);
+
+ if (wacom_data->variant->msg_coord_num > 7)
+ input_set_abs_params(input_dev, ABS_DISTANCE, 0, 255, 0, 0);
+
+ touchscreen_parse_properties(input_dev, false, &wacom_data->prop);
+
+ dev_info(dev, "%s size X%uY%u\n", wacom_data->variant->name,
+ wacom_data->prop.max_x, wacom_data->prop.max_y);
+
+ error = device_property_read_u32(dev, "touchscreen-x-mm", &val);
+ if (!error && val)
+ input_abs_set_res(input_dev, wacom_data->prop.swap_x_y ? ABS_Y : ABS_X,
+ wacom_data->prop.max_x / val);
+ error = device_property_read_u32(dev, "touchscreen-y-mm", &val);
+ if (!error && val)
+ input_abs_set_res(input_dev, wacom_data->prop.swap_x_y ? ABS_X : ABS_Y,
+ wacom_data->prop.max_y / val);
+
+ error = input_register_device(wacom_data->input_dev);
+ if (error)
+ return dev_err_probe(dev, error, "Failed to register input device\n");
+
+ return 0;
+}
+
+static int wacom_w9000_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct wacom_w9000_data *wacom_data = i2c_get_clientdata(client);
+
+ guard(mutex)(&wacom_data->input_dev->mutex);
+
+ return wacom_w9000_power_off(wacom_data);
+}
+
+static int wacom_w9000_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct wacom_w9000_data *wacom_data = i2c_get_clientdata(client);
+
+ guard(mutex)(&wacom_data->input_dev->mutex);
+
+ if (input_device_enabled(wacom_data->input_dev))
+ return wacom_w9000_power_on(wacom_data);
+ else
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(wacom_w9000_pm, wacom_w9000_suspend, wacom_w9000_resume);
+
+static const struct wacom_w9000_variant w9002 = {
+ .cmd_query_num = 9,
+ .msg_coord_num = 7,
+ .name = "Wacom W9002 Digitizer",
+};
+
+static const struct wacom_w9000_variant w9007a_lt03 = {
+ .cmd_query_num = 9,
+ .msg_coord_num = 8,
+ .name = "Wacom W9007A LT03 Digitizer",
+};
+
+static const struct wacom_w9000_variant w9007a_v1 = {
+ .cmd_query_num = 9,
+ .msg_coord_num = 12,
+ .name = "Wacom W9007A V1 Digitizer",
+};
+
+static const struct of_device_id wacom_w9000_of_match[] = {
+ { .compatible = "wacom,w9002", .data = &w9002 },
+ { .compatible = "wacom,w9007a-lt03", .data = &w9007a_lt03, },
+ { .compatible = "wacom,w9007a-v1", .data = &w9007a_v1, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wacom_w9000_of_match);
+
+static const struct i2c_device_id wacom_w9000_id[] = {
+ { .name = "w9002", .driver_data = (kernel_ulong_t)&w9002 },
+ { .name = "w9007a-lt03", .driver_data = (kernel_ulong_t)&w9007a_lt03 },
+ { .name = "w9007a-v1", .driver_data = (kernel_ulong_t)&w9007a_v1 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, wacom_w9000_id);
+
+static struct i2c_driver wacom_w9000_driver = {
+ .driver = {
+ .name = "wacom_w9000",
+ .of_match_table = wacom_w9000_of_match,
+ .pm = pm_sleep_ptr(&wacom_w9000_pm),
+ },
+ .probe = wacom_w9000_probe,
+ .id_table = wacom_w9000_id,
+};
+module_i2c_driver(wacom_w9000_driver);
+
+/* Module information */
+MODULE_AUTHOR("Hendrik Noack <hendrik-noack@gmx.de>");
+MODULE_DESCRIPTION("Wacom W9000-series penabled touchscreen driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v8 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-05-28 7:48 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hendrik Noack, Ferass El Hafidi, linux-input, devicetree,
linux-kernel
In-Reply-To: <20260528074818.12151-1-hendrik-noack@gmx.de>
Add bindings for Wacom W9002 and two Wacom W9007 variants which can be
found in tablets.
W9002, W9007A LT03, and W9007A V1 differ in the length of the return
message containing coordinates, distance, pressure and button status.
Co-developed-by: Ferass El Hafidi <funderscore@postmarketos.org>
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../input/touchscreen/wacom,w9007a-lt03.yaml | 73 +++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
new file mode 100644
index 000000000000..6d1da6a435d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/wacom,w9007a-lt03.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wacom W9000-series penabled I2C touchscreen
+
+maintainers:
+ - Hendrik Noack <hendrik-noack@gmx.de>
+
+description: |
+ The W9000-series are penabled touchscreen controllers by Wacom.
+
+ The firmware of controllers in different devices may differ. This can also
+ affect the controller's behavior.
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - wacom,w9002
+ - wacom,w9007a-lt03
+ - wacom,w9007a-v1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ flash-mode-gpios:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ digitizer@56 {
+ compatible = "wacom,w9007a-lt03";
+ reg = <0x56>;
+ interrupt-parent = <&gpd1>;
+ interrupts = <1 IRQ_TYPE_EDGE_RISING>;
+
+ vdd-supply = <&stylus_reg>;
+
+ flash-mode-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpx0 1 GPIO_ACTIVE_LOW>;
+
+ touchscreen-x-mm = <216>;
+ touchscreen-y-mm = <135>;
+ touchscreen-inverted-x;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v8 0/2] Add support for Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-05-28 7:48 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hendrik Noack, Ferass El Hafidi, linux-input, devicetree,
linux-kernel
Add devicetree bindings and a driver for the Wacom W9000-series penabled
touchscreens.
The driver currently only contains the information for the W9002 and
W9007A, which I or Ferass could test on devices. It should also work with
other chips, such as W9001 or W9010. However, I couldn't test it on these
and the message length would need to be added.
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
Changes in v2:
- remove pdct-gpios, as it's unnecessary
- fix devicetree example
- adopt to kernel coding style
---
Changes in v3:
- fix missing include (thanks lkp@intel.com)
---
Changes in v4:
- adopt to feedback (thanks dmitry.torokhov@gmail.com)
- add W9002 support (thanks funderscore@postmarketos.org)
- add reset-gpios, necessary for some chips
- remove R-b from krzk due to changes in dt-bindings
---
Changes in v5:
- adopt dt-bindings format to suggestion (thanks krzk@kernel.org)
- remove pen-inserted functionality as suggested (thanks dmitry.torokhov@gmail.com)
---
Changes in v6:
- add info on difference between variants
- add A-b from conor
- add warning for out of range pressure
---
Changes in v7:
- address feedback of sashiko (thanks dmitry.torokhov@gmail.com)
---
Changes in v8:
- add regulator and interrupt headers explicitely
- adjust some data types
---
Hendrik Noack (2):
dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
Input: Add support for Wacom W9000-series penabled touchscreens
.../input/touchscreen/wacom,w9007a-lt03.yaml | 73 +++
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/wacom_w9000.c | 448 ++++++++++++++++++
4 files changed, 534 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
create mode 100644 drivers/input/touchscreen/wacom_w9000.c
--
2.43.0
^ permalink raw reply
* [PATCH v3 2/2] Input: atmel_mxt_ts: Allow per-machine config via DT compatible
From: Hendrik Noack @ 2026-05-28 7:43 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov; +Cc: Hendrik Noack, linux-input, linux-kernel
In-Reply-To: <20260528074317.9604-1-hendrik-noack@gmx.de>
The Atmel maXTouch config is machine-dependent, different panels and
layouts require different configs even when the same controller and
firmware is used.
Extend the driver to support per-machine config files keyed by the device
tree compatible prop. For DT-based systems, the driver now looks up the
primary compatible of the machine and searches for a config file named:
atmel/maxtouch.<compatible>.cfg
If such a file exists, it is used as the machine-specific config. If the
system is not DT-based or if the per-machine file is not present, the
driver reverts to the original behaviour and searches for a config file
named:
maxtouch.cfg
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
Changes in v2:
- fix leak of fw_name (thanks sashiko.dev)
- adopt to added patch
---
Changes in v3:
- fix bypass of of_node_put (thanks sashiko.dev)
---
drivers/input/touchscreen/atmel_mxt_ts.c | 69 +++++++++++++++++++++---
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index a88dc7e6827c..0081fa5c7802 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -36,7 +36,9 @@
/* Firmware files */
#define MXT_FW_NAME "maxtouch.fw"
-#define MXT_CFG_NAME "maxtouch.cfg"
+#define MXT_CFG_FOLDER "atmel"
+#define MXT_CFG_NAME "maxtouch"
+#define MXT_CFG_EXTENSION ".cfg"
#define MXT_CFG_MAGIC "OBP_RAW V1"
/* Registers */
@@ -2232,6 +2234,64 @@ static void mxt_config_cb(const struct firmware *cfg, void *ctx)
complete(&data->config_completion);
}
+static int mxt_invoke_config_loader(struct mxt_data *data, bool device_specific);
+
+static void mxt_board_config_cb(const struct firmware *cfg, void *ctx)
+{
+ if (!cfg) {
+ struct mxt_data *data = ctx;
+ int error;
+
+ error = mxt_invoke_config_loader(data, false);
+ /* request_firmware_nowait() succeeded and mxt_config_cb() will be called at end */
+ if (!error)
+ return;
+
+ dev_err(&data->client->dev, "Failed to invoke general config loader: %d\n", error);
+ }
+
+ mxt_config_cb(cfg, ctx);
+}
+
+static int mxt_invoke_config_loader(struct mxt_data *data, bool device_specific)
+{
+ struct device_node *root;
+ char *board_type = NULL;
+ char *fw_name;
+ void (*cb)(const struct firmware *fw, void *context);
+ int error;
+
+ /* Get first string of the machine compatible prop */
+ root = of_find_node_by_path("/");
+ if (device_specific && root) {
+ const char *tmp;
+
+ if (!of_property_read_string_index(root, "compatible", 0, &tmp))
+ board_type = kstrdup(tmp, GFP_KERNEL);
+ }
+ of_node_put(root);
+
+ if (board_type) {
+ /* get rid of '/' in the compatible string to be able to find the FW */
+ strreplace(board_type, '/', '-');
+
+ fw_name = kasprintf(GFP_KERNEL, "%s/%s.%s%s", MXT_CFG_FOLDER, MXT_CFG_NAME,
+ board_type, MXT_CFG_EXTENSION);
+ cb = mxt_board_config_cb;
+ kfree(board_type);
+ } else {
+ fw_name = kasprintf(GFP_KERNEL, "%s%s", MXT_CFG_NAME, MXT_CFG_EXTENSION);
+ cb = mxt_config_cb;
+ }
+ if (!fw_name)
+ return -ENOMEM;
+
+ error = request_firmware_nowait(THIS_MODULE, true, fw_name, &data->client->dev, GFP_KERNEL,
+ data, cb);
+ kfree(fw_name);
+ return error;
+}
+
static int mxt_initialize(struct mxt_data *data)
{
struct i2c_client *client = data->client;
@@ -2291,12 +2351,9 @@ static int mxt_initialize(struct mxt_data *data)
return -EBUSY;
}
- error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
- &client->dev, GFP_KERNEL, data,
- mxt_config_cb);
+ error = mxt_invoke_config_loader(data, true);
if (error) {
- dev_err(&client->dev, "Failed to invoke firmware loader: %d\n",
- error);
+ dev_err(&client->dev, "Failed to invoke config loader: %d\n", error);
complete(&data->config_completion);
return error;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/2] Input: atmel_mxt_ts: Fix async config use-after-free
From: Hendrik Noack @ 2026-05-28 7:43 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov; +Cc: Hendrik Noack, linux-input, linux-kernel
The Atmel maXTouch driver starts asynchronous config loading from both
probe and a sysfs trigger via request_firmware_nowait() and passes the
devm-managed struct mxt_data as the callback context. If the driver is
removed while an asynchronous request is still pending, devres will free
mxt_data before the firmware callback runs. When the callback eventually
executes, it dereferences the freed mxt_data pointer, leading to a
use-after-free.
This is resolved by introducing a completion that serialises the
request_firmware_nowait() and remove():
Before calling request_firmware_nowait(), a completion serialises the
calls. If remove() has started, the asynchronous loading will no longer be
started and all waiters will be signaled. The completion is completed at
the end of the callback or if request_firmware_nowait() fails.
In mxt_remove(), the completion of pending request_firmware_nowait() is
awaited and all waiters will be signaled.
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
Changes in v2:
- this fix is added to the patch series (thanks sashiko.dev)
---
Changes in v3:
- remove unnecessary lock
---
drivers/input/touchscreen/atmel_mxt_ts.c | 34 +++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index a9e86ad7ed5e..a88dc7e6827c 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -347,6 +347,10 @@ struct mxt_data {
/* for config update handling */
struct completion crc_completion;
+ /* for loading config */
+ struct completion config_completion;
+ bool shutting_down;
+
u32 *t19_keymap;
unsigned int t19_num_keys;
@@ -2221,8 +2225,11 @@ static int mxt_configure_objects(struct mxt_data *data,
static void mxt_config_cb(const struct firmware *cfg, void *ctx)
{
- mxt_configure_objects(ctx, cfg);
+ struct mxt_data *data = ctx;
+
+ mxt_configure_objects(data, cfg);
release_firmware(cfg);
+ complete(&data->config_completion);
}
static int mxt_initialize(struct mxt_data *data)
@@ -2271,12 +2278,26 @@ static int mxt_initialize(struct mxt_data *data)
if (error)
return error;
+ wait_for_completion(&data->config_completion);
+
+ if (data->shutting_down) {
+ /* complete() only signals one waiter, signal all waiters once during shutdown */
+ if (!completion_done(&data->config_completion)) {
+ complete_all(&data->config_completion);
+ dev_info(&client->dev, "Shutting down, not loading new config: %d\n",
+ error);
+ }
+
+ return -EBUSY;
+ }
+
error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
&client->dev, GFP_KERNEL, data,
mxt_config_cb);
if (error) {
dev_err(&client->dev, "Failed to invoke firmware loader: %d\n",
error);
+ complete(&data->config_completion);
return error;
}
@@ -3237,6 +3258,9 @@ static int mxt_probe(struct i2c_client *client)
init_completion(&data->bl_completion);
init_completion(&data->reset_completion);
init_completion(&data->crc_completion);
+ init_completion(&data->config_completion);
+ complete(&data->config_completion);
+ data->shutting_down = false;
data->suspend_mode = dmi_check_system(chromebook_T9_suspend_dmi) ?
MXT_SUSPEND_T9_CTRL : MXT_SUSPEND_DEEP_SLEEP;
@@ -3342,6 +3366,14 @@ static void mxt_remove(struct i2c_client *client)
{
struct mxt_data *data = i2c_get_clientdata(client);
+ data->shutting_down = true;
+
+ wait_for_completion(&data->config_completion);
+
+ /* complete() only signals one waiter, signal all waiters once during shutdown */
+ if (!completion_done(&data->config_completion))
+ complete_all(&data->config_completion);
+
disable_irq(data->irq);
mxt_free_input_device(data);
mxt_free_object_table(data);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v8 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: sashiko-bot @ 2026-05-28 7:41 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: linux-input, devicetree, robh, conor+dt, dmitry.torokhov
In-Reply-To: <20260528053203.9339-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The driver registers a global input handler to snoop keystrokes from all input devices in the system, violating driver boundaries.
- [High] The input_dev's name, phys, and keycode fields point to devres-managed memory that is freed when the driver unbinds, causing a Use-After-Free if userspace holds the input device open.
- [Medium] The state flags `special_key_pressed` and `special_key_mode` are accessed and modified concurrently from multiple contexts without any locking or synchronization.
- [Low] The driver unregisters the input handler before unregistering the hardware event notifier in the remove function, violating the reverse-order teardown principle.
--
commit ed5ee673506765c49f751d4f9cce6ec50eda686c
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Subject: input: keyboard: Add driver for ASUS Transformer dock multimedia keys
This commit adds support for the multimedia top button row of the
ASUS Transformer's Mobile Dock keyboard. It switches to multimedia keys
when ScreenLock + AltGr are pressed.
> diff --git a/drivers/input/keyboard/asus-transformer-ec-keys.c b/drivers/input/keyboard/asus-transformer-ec-keys.c
> new file mode 100644
> index 0000000000000..bf6db002a8537
> --- /dev/null
> +++ b/drivers/input/keyboard/asus-transformer-ec-keys.c
> @@ -0,0 +1,286 @@
[ ... ]
> +static void asus_ec_input_event(struct input_handle *handle,
> + unsigned int event_type,
> + unsigned int event_code, int value)
> +{
> + struct asus_ec_keys_data *priv = handle->handler->private;
> +
> + /* Store special key state */
> + if (event_type == EV_KEY && event_code == KEY_RIGHTALT)
> + priv->special_key_pressed = !!value;
[Severity: Medium]
Can this result in a data race on special_key_pressed?
The asus_ec_input_event() function writes to special_key_pressed from the
input event delivery context, which often runs in hardirq or softirq.
Concurrently, asus_ec_keys_process_key() reads this flag and modifies
special_key_mode from a process context via the blocking notifier chain.
Could concurrent execution lead to missed key modifiers or lost mode updates
without synchronization primitives or READ_ONCE() annotations?
> +}
[ ... ]
> +static const struct input_device_id asus_ec_input_ids[] = {
> + {
> + .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> + .evbit = { BIT_MASK(EV_KEY) },
> + },
> + { }
> +};
[Severity: High]
Does this input_device_id match any device with EV_KEY capabilities, causing
the driver to intercept key events globally?
If a user unplugs an unrelated external USB keyboard while the RIGHTALT key
is currently held down, could the special_key_pressed state remain
permanently stuck?
[ ... ]
> +static int asus_ec_keys_probe(struct platform_device *pdev)
> +{
[ ... ]
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
[ ... ]
> + priv->xidev = devm_input_allocate_device(dev);
> + if (!priv->xidev)
> + return -ENOMEM;
> +
> + priv->xidev->name = devm_kasprintf(dev, GFP_KERNEL, "%s Keyboard Ext",
> + ec->model);
> + priv->xidev->phys = devm_kasprintf(dev, GFP_KERNEL, "i2c-%u-%04x",
> + i2c_adapter_id(parent->adapter),
> + parent->addr);
[Severity: High]
Does this code introduce a use-after-free regression if userspace holds the
input device open during an unbind?
The priv->xidev->name and priv->xidev->phys strings, as well as the
priv->keymap array assigned to dev->keycode, are managed by devres and will
be freed when the driver unbinds.
However, if a userspace process holds a file descriptor to the evdev node,
the input_dev object is kept alive via reference counting.
Could a subsequent ioctl from userspace, such as EVIOCGNAME, attempt to
read from these already-freed pointers?
[ ... ]
> +static void asus_ec_keys_remove(struct platform_device *pdev)
> +{
> + struct asus_ec_keys_data *priv = platform_get_drvdata(pdev);
> + struct asusec_core *ec = priv->ec;
> +
> + input_unregister_handler(&priv->input_handler);
> + blocking_notifier_chain_unregister(&ec->notify_list, &priv->nb);
[Severity: Low]
Does this remove sequence violate the reverse-order teardown principle?
In asus_ec_keys_probe(), the driver registers the input handler first,
followed by the EC notifier chain.
Unregistering the handler first opens a race window where the software
tracking is disconnected but the driver is still registered to receive
hardware events from the EC.
Can the driver still process events in a partially dismantled state?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v8 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: sashiko-bot @ 2026-05-28 7:06 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: devicetree, robh, dmitry.torokhov, linux-input, conor+dt
In-Reply-To: <20260528053203.9339-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The serio->write callback calls a sleeping I2C API, violating the atomic context requirements of the serio subsystem.
- [High] Serio ports are registered before the EC notifier is active, which can lead to dropped hardware ACKs and driver probe timeouts.
--
commit c384b4357257c7b443531cb85e3b65aa83067d31
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
This commit adds a serio input driver for the ASUS Transformer dock keyboard
and touchpad. It handles incoming scancodes, remaps specific keys to match
the standard AT layout, and forwards the data to the serio subsystem.
Co-developed-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
[ ... ]
> diff --git a/drivers/input/serio/asus-transformer-ec-kbc.c b/drivers/input/serio/asus-transformer-ec-kbc.c
> new file mode 100644
> index 0000000000000..6f10b7f1baae5
> --- /dev/null
> +++ b/drivers/input/serio/asus-transformer-ec-kbc.c
> @@ -0,0 +1,158 @@
[ ... ]
> +static int asus_ec_serio_write(struct serio *port, unsigned char data)
> +{
> + struct asus_ec_kbc_data *priv = port->port_data;
> +
> + return i2c_smbus_write_word_data(priv->parent, ASUSEC_WRITE_BUF,
> + (data << 8) | port->id.extra);
> +}
[Severity: High]
Does this code sleep in an atomic context?
The i2c_smbus_write_word_data() function takes the I2C adapter's mutex and
sleeps while waiting for the synchronous transaction to complete.
However, the serio core and keyboard/mouse drivers frequently call
serio_write() from atomic contexts. For example, the core serio_interrupt()
function holds the port's spinlock with interrupts disabled:
serio_interrupt() {
guard(spinlock_irqsave)(&serio->lock);
...
serio->drv->interrupt(...) // calls driver interrupt which may write
}
If a driver like atkbd needs to resend a command or respond to a hardware
NAK, it calls serio_write() directly from this interrupt handler.
Executing a sleeping I2C write while holding a spinlock with interrupts
disabled will trigger a "scheduling while atomic" bug or cause a system
deadlock.
[ ... ]
> +static int asus_ec_kbc_probe(struct platform_device *pdev)
> +{
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct asus_ec_kbc_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->ec = ec;
> + priv->parent = to_i2c_client(pdev->dev.parent);
> +
> + error = asus_ec_register_serio(pdev, 0, "Keyboard", 0);
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 1, "Touchpad", I8042_CMD_AUX_SEND);
> + if (error)
> + return error;
> +
> + priv->nb.notifier_call = asus_ec_kbc_notify;
> +
> + return blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
> +}
[Severity: High]
Can this cause driver probe timeouts by dropping hardware ACKs?
The asus_ec_register_serio() calls are exposing the keyboard and touchpad
to the serio subsystem before the EC notifier is attached. The serio port
registration asynchronously queues work on the kseriod workqueue, which
finds and binds drivers.
Since the kseriod workqueue can run concurrently on another CPU, it may send
initialization commands and the hardware may respond before this probe
function reaches blocking_notifier_chain_register().
Because the notifier is not yet attached to receive and forward these ACKs,
the events will be dropped. This causes the bound driver's probe to time out
and fail, leaving the input devices non-functional.
Should the notifier be fully registered before the serio ports are exposed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v8 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: sashiko-bot @ 2026-05-28 6:16 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, linux-input, conor+dt, devicetree, dmitry.torokhov
In-Reply-To: <20260528053203.9339-3-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Short I2C block reads return positive values or zero, violating API contract and causing false probe success or uninitialized variable usage.
--
commit 66708f4a4bcbbc5908e6fc11660dc174e28d7ee4
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
mfd: Add driver for ASUS Transformer embedded controller
Support Nuvoton NPCE795-based ECs as used in Asus Transformer TF201,
TF300T, TF300TG, TF300TL and TF700T pad and dock, as well as TF101 dock
and TF600T, P1801-T and TF701T pad. This is a glue driver handling
detection and common operations for EC's functions.
> --- /dev/null
> +++ b/drivers/mfd/asus-transformer-ec.c
[ ... ]
> +int asus_dockram_access_ctl(struct i2c_client *client, u64 *out, u64 mask,
> + u64 xor)
> +{
> + struct dockram_ec_data *ddata = i2c_get_clientdata(client);
> + u8 *buf = ddata->ctl_buf;
> + u64 val;
> + int ret = 0;
> +
> + guard(mutex)(&ddata->ctl_lock);
> +
> + memset(buf, 0, ASUSEC_ENTRY_BUFSIZE);
> + ret = i2c_smbus_read_i2c_block_data(client, ASUSEC_DOCKRAM_CONTROL,
> + ASUSEC_ENTRY_SIZE, buf);
> + if (ret < ASUSEC_ENTRY_SIZE) {
> + dev_err(&client->dev, "failed to access control buffer: %d\n",
> + ret);
> + return ret;
[Severity: High]
If i2c_smbus_read_i2c_block_data() returns a positive short read, will this
return a positive error code?
This positive value could propagate up to asus_ec_probe(). Returning a
positive value from probe causes __device_attach_driver() to interpret it
as a successful match and probe, leaving the device in an unbound, broken
state without a proper failure log.
Additionally, if it returns 0, the function will return success (0) without
populating output variables, potentially leading to uninitialized memory
usage in callers like asus_ec_susb_on_status().
> + }
> +
> + if (buf[0] != ASUSEC_CTL_SIZE) {
[ ... ]
> +static int asus_ec_log_info(struct asus_ec_data *ddata, unsigned int reg,
> + const char *name, const char **out)
> +{
> + struct device *dev = &ddata->client->dev;
> + u8 buf[ASUSEC_ENTRY_BUFSIZE];
> + int ret;
> +
> + memset(buf, 0, ASUSEC_ENTRY_BUFSIZE);
> + ret = i2c_smbus_read_i2c_block_data(ddata->ec.dockram, reg,
> + ASUSEC_ENTRY_SIZE, buf);
> + if (ret < ASUSEC_ENTRY_SIZE)
> + return ret;
[Severity: High]
Could this also return a positive short read or 0 to the caller?
Similar to asus_dockram_access_ctl(), this might propagate positive values
to the probe function or mask zero-byte read failures.
> +
> + if (buf[0] > ASUSEC_ENTRY_SIZE) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v8 1/7] dt-bindings: embedded-controller: document ASUS Transformer EC
From: sashiko-bot @ 2026-05-28 5:44 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: dmitry.torokhov, linux-input, robh, devicetree, conor+dt
In-Reply-To: <20260528053203.9339-2-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The 'reg' property array lacks an explicit upper bound ('maxItems' or 'items' list).
--
commit 51056b233d45625f7f08ea91a021eae296836600
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: embedded-controller: document ASUS Transformer EC
This commit documents the embedded controllers used in the ASUS Transformer
device series, adding a new YAML binding for the Nuvoton-based controllers
found in these tablets and docks.
> diff --git a/Documentation/devicetree/bindings/embedded-controller/asus,tf201-ec-pad.yaml b/Documentation/devicetree/bindings/embedded-controller/asus,tf201-ec-pad.yaml
> new file mode 100644
> index 0000000000000..60b6375864aaf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/embedded-controller/asus,tf201-ec-pad.yaml
[ ... ]
> + reg:
> + description:
> + The ASUS Transformer EC has a main I2C address and an associated
> + DockRAM device, which provides power-related functions for the
> + embedded controller. Both addresses are required for operation.
> + minItems: 2
[Severity: Low]
Should this reg property also specify maxItems: 2 or an explicit items array?
While reg-names restricts the size indirectly, standard dt-schema meta-schema
rules generally require array properties like reg to define strict upper bounds
explicitly to pass make dt_binding_check without warnings.
> +
> + reg-names:
> + items:
> + - const: ec
> + - const: dockram
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260528053203.9339-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-05-28 5:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Svyatoslav Ryhel,
Linus Walleij
In-Reply-To: <20260512102445.55372-3-clamor95@gmail.com>
вт, 12 трав. 2026 р. о 13:24 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> From: Linus Walleij <linusw@kernel.org>
>
> The ISA1200 is a haptic feedback unit from Imagis Technology using two
> motors for haptic feedback in mobile phones. Used in many mobile devices
> c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
>
> 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> # GT-I9070 Janice
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/misc/Kconfig | 12 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/isa1200.c | 524 +++++++++++++++++++++++++++++++++++
> 3 files changed, 537 insertions(+)
> create mode 100644 drivers/input/misc/isa1200.c
>
Hello Dmitry! Do I need to make any further adjustments to this driver?
^ permalink raw reply
* [PATCH v8 7/7] power: supply: Add charger driver for Asus Transformers
From: Svyatoslav Ryhel @ 2026-05-28 5:32 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Sebastian Reichel, Svyatoslav Ryhel,
Ion Agorria, Michał Mirosław
Cc: devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-1-clamor95@gmail.com>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Add support for charger detection capabilities found in the embedded
controller of ASUS Transformer devices.
Suggested-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Suggested-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/power/supply/Kconfig | 11 +
drivers/power/supply/Makefile | 1 +
.../supply/asus-transformer-ec-charger.c | 208 ++++++++++++++++++
3 files changed, 220 insertions(+)
create mode 100644 drivers/power/supply/asus-transformer-ec-charger.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 1dc3d0b2e021..ebc6d5c01330 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -508,6 +508,17 @@ config CHARGER_88PM860X
help
Say Y here to enable charger for Marvell 88PM860x chip.
+config CHARGER_ASUS_TRANSFORMER_EC
+ tristate "Asus Transformer's charger driver"
+ depends on MFD_ASUS_TRANSFORMER_EC
+ help
+ Say Y here to enable support AC plug detection on Asus Transformer
+ Dock.
+
+ This sub-driver supports charger detection mechanism found in Asus
+ Transformer tablets and mobile docks and controlled by special
+ embedded controller.
+
config CHARGER_PF1550
tristate "NXP PF1550 battery charger driver"
depends on MFD_PF1550
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 1313f367715c..93d17d28081e 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_CHARGER_RT9471) += rt9471.o
obj-$(CONFIG_CHARGER_RT9756) += rt9756.o
obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
obj-$(CONFIG_CHARGER_88PM860X) += 88pm860x_charger.o
+obj-$(CONFIG_CHARGER_ASUS_TRANSFORMER_EC) += asus-transformer-ec-charger.o
obj-$(CONFIG_CHARGER_PF1550) += pf1550-charger.o
obj-$(CONFIG_BATTERY_RX51) += rx51_battery.o
obj-$(CONFIG_AB8500_BM) += ab8500_bmdata.o ab8500_charger.o ab8500_fg.o ab8500_btemp.o ab8500_chargalg.o
diff --git a/drivers/power/supply/asus-transformer-ec-charger.c b/drivers/power/supply/asus-transformer-ec-charger.c
new file mode 100644
index 000000000000..c7a6bd2ba533
--- /dev/null
+++ b/drivers/power/supply/asus-transformer-ec-charger.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/err.h>
+#include <linux/mfd/asus-transformer-ec.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/property.h>
+
+struct asus_ec_charger_data {
+ struct notifier_block nb;
+ struct asusec_core *ec;
+ struct power_supply *psy;
+ struct power_supply_desc psy_desc;
+};
+
+static enum power_supply_property asus_ec_charger_properties[] = {
+ POWER_SUPPLY_PROP_USB_TYPE,
+ POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_MODEL_NAME,
+};
+
+static int asus_ec_charger_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct asus_ec_charger_data *priv = power_supply_get_drvdata(psy);
+ enum power_supply_usb_type psu;
+ int ret;
+ u64 ctl;
+
+ /* Check if model name is requested first since it needs no hw access */
+ if (psp == POWER_SUPPLY_PROP_MODEL_NAME) {
+ val->strval = priv->ec->model;
+ return 0;
+ }
+
+ ret = asus_dockram_access_ctl(priv->ec->dockram, &ctl, 0, 0);
+ if (ret)
+ return ret;
+
+ switch (ctl & (ASUSEC_CTL_FULL_POWER_SOURCE | ASUSEC_CTL_DIRECT_POWER_SOURCE)) {
+ case ASUSEC_CTL_FULL_POWER_SOURCE:
+ psu = POWER_SUPPLY_USB_TYPE_CDP; /* DOCK */
+ break;
+ case ASUSEC_CTL_DIRECT_POWER_SOURCE:
+ psu = POWER_SUPPLY_USB_TYPE_SDP; /* USB */
+ break;
+ case 0:
+ psu = POWER_SUPPLY_USB_TYPE_UNKNOWN; /* no power source connected */
+ break;
+ default:
+ psu = POWER_SUPPLY_USB_TYPE_ACA; /* power adapter */
+ break;
+ }
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = psu != POWER_SUPPLY_USB_TYPE_UNKNOWN;
+ return 0;
+
+ case POWER_SUPPLY_PROP_USB_TYPE:
+ val->intval = psu;
+ return 0;
+
+ case POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR:
+ if (ctl & ASUSEC_CTL_TEST_DISCHARGE)
+ val->intval = POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE;
+ else if (ctl & ASUSEC_CTL_USB_CHARGE)
+ val->intval = POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO;
+ else
+ val->intval = POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE;
+ return 0;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int asus_ec_charger_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct asus_ec_charger_data *priv = power_supply_get_drvdata(psy);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR:
+ switch ((enum power_supply_charge_behaviour)val->intval) {
+ case POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO:
+ return asus_dockram_access_ctl(priv->ec->dockram, NULL,
+ ASUSEC_CTL_TEST_DISCHARGE | ASUSEC_CTL_USB_CHARGE,
+ ASUSEC_CTL_USB_CHARGE);
+
+ case POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE:
+ return asus_dockram_access_ctl(priv->ec->dockram, NULL,
+ ASUSEC_CTL_TEST_DISCHARGE | ASUSEC_CTL_USB_CHARGE, 0);
+
+ case POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE:
+ return asus_dockram_access_ctl(priv->ec->dockram, NULL,
+ ASUSEC_CTL_TEST_DISCHARGE | ASUSEC_CTL_USB_CHARGE,
+ ASUSEC_CTL_TEST_DISCHARGE);
+ default:
+ return -EINVAL;
+ }
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static int asus_ec_charger_property_is_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct power_supply_desc asus_ec_charger_desc = {
+ .name = "asus-ec-charger",
+ .type = POWER_SUPPLY_TYPE_USB,
+ .charge_behaviours = BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO) |
+ BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE) |
+ BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE),
+ .usb_types = BIT(POWER_SUPPLY_USB_TYPE_UNKNOWN) |
+ BIT(POWER_SUPPLY_USB_TYPE_SDP) |
+ BIT(POWER_SUPPLY_USB_TYPE_CDP) |
+ BIT(POWER_SUPPLY_USB_TYPE_ACA),
+ .properties = asus_ec_charger_properties,
+ .num_properties = ARRAY_SIZE(asus_ec_charger_properties),
+ .get_property = asus_ec_charger_get_property,
+ .set_property = asus_ec_charger_set_property,
+ .property_is_writeable = asus_ec_charger_property_is_writeable,
+ .no_thermal = true,
+};
+
+static int asus_ec_charger_notify(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct asus_ec_charger_data *priv =
+ container_of(nb, struct asus_ec_charger_data, nb);
+
+ switch (action) {
+ case ASUSEC_SMI_ACTION(POWER_NOTIFY):
+ case ASUSEC_SMI_ACTION(ADAPTER_EVENT):
+ power_supply_changed(priv->psy);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static int asus_ec_charger_probe(struct platform_device *pdev)
+{
+ struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
+ struct asus_ec_charger_data *priv;
+ struct device *dev = &pdev->dev;
+ struct power_supply_config cfg = { };
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+ priv->ec = ec;
+
+ cfg.fwnode = dev_fwnode(dev->parent);
+ cfg.drv_data = priv;
+
+ memcpy(&priv->psy_desc, &asus_ec_charger_desc, sizeof(priv->psy_desc));
+ priv->psy_desc.name = devm_kasprintf(dev, GFP_KERNEL, "%s-charger",
+ priv->ec->name);
+ if (!priv->psy_desc.name)
+ return -ENOMEM;
+
+ priv->psy = devm_power_supply_register(dev, &priv->psy_desc, &cfg);
+ if (IS_ERR(priv->psy))
+ return dev_err_probe(dev, PTR_ERR(priv->psy),
+ "Failed to register power supply\n");
+
+ priv->nb.notifier_call = asus_ec_charger_notify;
+
+ return blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
+}
+
+static void asus_ec_charger_remove(struct platform_device *pdev)
+{
+ struct asus_ec_charger_data *priv = platform_get_drvdata(pdev);
+ struct asusec_core *ec = priv->ec;
+
+ blocking_notifier_chain_unregister(&ec->notify_list, &priv->nb);
+}
+
+static struct platform_driver asus_ec_charger_driver = {
+ .driver.name = "asus-transformer-ec-charger",
+ .probe = asus_ec_charger_probe,
+ .remove = asus_ec_charger_remove,
+};
+module_platform_driver(asus_ec_charger_driver);
+
+MODULE_ALIAS("platform:asus-transformer-ec-charger");
+MODULE_AUTHOR("Michał Mirosław <mirq-linux@rere.qmqm.pl>");
+MODULE_DESCRIPTION("ASUS Transformer Pad battery charger driver");
+MODULE_LICENSE("GPL");
--
2.51.0
^ 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