[PATCH] HID: intel-thc-hid: intel-quicki2c: Fix the return value in quicki2c_dev_init() kernel-doc

[PATCH] HID: intel-thc-hid: intel-quicki2c: Fix the return value in quicki2c_dev_init() kernel-doc

[Karl Mehltretter]

quicki2c_dev_init() returns an ERR_PTR() on failure, but its kernel-doc
says that failure returns NULL. This mismatch was present in the
original driver skeleton.

Document the error pointer returned by the initialization paths.

Fixes: 61bb2714dc3a ("HID: intel-thc-hid: intel-quicki2c: Add THC QuickI2C driver skeleton")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
index 0d2ad7bc3648a2f227db2ed27ad9cbe18955bc0f..aa601ef613c91729f4fc90bdc1674cb838921421 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
@@ -380,7 +380,7 @@ exit:
  * If success, enable THC hardware interrupt.
  *
  * Return: Pointer to the quicki2c_device structure if success
- * or NULL on failure.
+ * or an ERR_PTR() on failure.
  */
 static struct quicki2c_device *quicki2c_dev_init(struct pci_dev *pdev, void __iomem *mem_addr,
 						 const struct quicki2c_ddata *ddata)
-- 
2.39.5 (Apple Git-154)

Re: [PATCH] HID: intel-thc-hid: intel-quicki2c: Fix the return value in quicki2c_dev_init() kernel-doc

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Transport drivers use hid_input_report() instead of the safer hid_safe_input_report() when feeding data from interrupts.
--

commit e849f07638d5d777d058d1762033819d3087f020
Author: Karl Mehltretter <kmehltretter@gmail.com>

HID: intel-thc-hid: intel-quicki2c: Fix the return value in quicki2c_dev_init() kernel-doc

This commit corrects the kernel-doc for quicki2c_dev_init() to accurately
reflect that it returns an ERR_PTR() on failure instead of NULL.

> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 0d2ad7bc3648a..aa601ef613c91 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but does this code in quicki2c_hid_send_report()
bypass the HID core's bounds checks?

drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-hid.c:quicki2c_hid_send_report() {
    ...
    ret = hid_input_report(qcdev->hid_dev, HID_INPUT_REPORT, data, data_len, 1);
    ...
}

If a malicious or malfunctioning device sends an interrupt with a spoofed
length larger than the allocated buffer, the hardware could send an inflated
length over DMA. When this is passed as data_len to hid_input_report(), which
does not know the actual allocated size of the buffer, could it blindly read
data_len bytes and cause an out-of-bounds read in the HID core?

Should this transport driver use hid_safe_input_report() instead when feeding
data from interrupts to prevent local memory disclosure or a kernel oops?

This same pattern also appears to exist in the QuickSPI driver:

drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c:quickspi_hid_send_report() {
    ...
    ret = hid_input_report(qsdev->hid_dev, HID_INPUT_REPORT, data, data_len, 1);
    ...
}

Should both of these transport drivers be updated to use the safer
hid_safe_input_report() API?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912002143.35091-1-kmehltretter@gmail.com?part=1

Re: [PATCH] HID: intel-thc-hid: intel-quicki2c: Fix the return value in quicki2c_dev_init() kernel-doc

[Andy Shevchenko]

On Sat, Sep 12, 2026 at 02:21:43AM +0200, Karl Mehltretter wrote:
> quicki2c_dev_init() returns an ERR_PTR() on failure, but its kernel-doc
> says that failure returns NULL. This mismatch was present in the
> original driver skeleton.
> 
> Document the error pointer returned by the initialization paths.

...

>   * Return: Pointer to the quicki2c_device structure if success
> - * or NULL on failure.
> + * or an ERR_PTR() on failure.

" * or an error pointer on failure."

>   */

...

The rule of thumb: Among options always choose the one that is less cryptic and
uses more plain English.

-- 
With Best Regards,
Andy Shevchenko