Linux Input/HID development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Emfox Zhou" <emfox@debian.org>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v3 3/5] HID: intel-thc-hid: intel-ipts: register the HID device
Date: Sat, 14 Nov 2026 18:59:45 +0000	[thread overview]
Message-ID: <sashiko-outbox-214934@kernel.org> (raw)
In-Reply-To: <20261114183624.2379573-4-emfox@debian.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] HID: intel-thc-hid: intel-ipts: check recovering in
  thc_ipts_send()
--

commit 4354955543093e96e544cc3b320f82723b8a7849
Author: Emfox Zhou <emfox@debian.org>

HID: intel-thc-hid: intel-ipts: register the HID device

This commit registers a HID device for the IPTS port and implements report
descriptor parsing, input report forwarding, and feature/output report
requests over DMA.

> diff --git a/drivers/hid/intel-thc-hid/intel-ipts/ipts.c b/drivers/hid/intel-thc-hid/intel-ipts/ipts.c
> index ac0074a85bfa4..bf75f8cc7994e 100644
> --- a/drivers/hid/intel-thc-hid/intel-ipts/ipts.c
> +++ b/drivers/hid/intel-thc-hid/intel-ipts/ipts.c
[ ... ]
> @@ -139,8 +141,79 @@ static int thc_ipts_touch_set(struct thc_ipts *idev, bool enable)
>  				 &touch);
>  }
>  
> +/*
> + * One frame to the controller: code, length, then the payload padded to four
> + * bytes. The frame is built in @idev->tx_frame, so callers serialise with
> + * @idev->req_lock.
> + */
> +static int thc_ipts_send(struct thc_ipts *idev, u32 code, const void *data,
> +			 size_t len)
> +{
> +	size_t padded = round_up(len, 4);
> +	u8 *frame = idev->tx_frame;
> +
> +	if (READ_ONCE(idev->stopping))
> +		return -ESHUTDOWN;
> +	if (!READ_ONCE(idev->dma_ready))
> +		return -EAGAIN;
> +	if (THC_IPTS_TX_HDR_SIZE + padded > idev->max_tx)
> +		return -EMSGSIZE;
> +
> +	put_unaligned_le32(code, frame);
> +	put_unaligned_le32((u32)len, frame + 4);
> +	memset(frame + THC_IPTS_TX_HDR_SIZE, 0, padded);
> +	if (len && data)
> +		memcpy(frame + THC_IPTS_TX_HDR_SIZE, data, len);
> +
> +	return thc_dma_write(idev->thc, frame, THC_IPTS_TX_HDR_SIZE + padded);
> +}

[Severity: Medium]
Should thc_ipts_send() also check READ_ONCE(idev->recovering) before
calling thc_dma_write()?

When a transfer or receive error occurs, thc_ipts_thread() leaves the port
interrupts masked, sets idev->recovering, and schedules idev->recover_work:

CPU0                              CPU1 (kworker)
thc_ipts_thread()
  WRITE_ONCE(idev->recovering, true)
  schedule_work(&idev->recover_work)
  return IRQ_HANDLED (port stays masked)

thc_ipts_send()
  thc_dma_write()
    mutex_lock_interruptible(&dev->thc_bus_lock)
    dma_set_start_bit(...)
                                  thc_ipts_recover()
                                    thc_rxdma_reset()
                                      mutex_lock_interruptible(&dev->thc_bus_lock)
    wait_event_interruptible_timeout(dev->write_complete_wait, ...)
      <-- stalls 1s for masked IRQ while blocking thc_ipts_recover()

Because thc_ipts_recover() cannot unmask the port until it acquires
thc_bus_lock inside thc_rxdma_reset(), thc_dma_write() always times out
after 1 second and aborts the retry loop in thc_ipts_hid_parse() or
thc_ipts_get_feature().  Also, if thc_rxdma_reset() fails in
thc_ipts_recover(), the port stays masked with idev->recovering set while
idev->dma_ready remains true, so every subsequent thc_ipts_send() call will
start TxDMA on the masked port and stall for 1 second holding req_lock and
thc_bus_lock.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261114183624.2379573-1-emfox@debian.org?part=3

  reply	other threads:[~2026-11-14 18:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 18:36 [PATCH v3 0/5] HID: intel-thc-hid: intel-ipts: support THC IPTS ports Emfox Zhou
2026-11-14 18:36 ` [PATCH v3 1/5] HID: intel-thc-hid: intel-ipts: bring up the port Emfox Zhou
2026-11-14 18:55   ` sashiko-bot
2026-11-14 18:36 ` [PATCH v3 2/5] HID: intel-thc-hid: intel-ipts: receive reports Emfox Zhou
2026-11-14 19:10   ` sashiko-bot
2026-11-14 18:36 ` [PATCH v3 3/5] HID: intel-thc-hid: intel-ipts: register the HID device Emfox Zhou
2026-11-14 18:59   ` sashiko-bot [this message]
2026-11-14 18:36 ` [PATCH v3 4/5] HID: intel-thc-hid: intel-ipts: handle system sleep Emfox Zhou
2026-11-14 19:02   ` sashiko-bot
2026-11-14 18:36 ` [PATCH v3 5/5] HID: intel-thc-hid: intel-ipts: document the IPTS mode Emfox Zhou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-214934@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=emfox@debian.org \
    --cc=linux-input@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox