Re: [PATCH v5 01/11] Documentation: Correction in HID output_report callback description.

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hid: documentation incorrectly relaxes asynchronous requirement for output_report
--

commit 6d8fa62fc058c7f5630a13cc92c85b7867bc9869
Author: Jarrett Schultz <jaschultz@microsoft.com>

Documentation: Correction in HID output_report callback description.

This commit updates the documentation for the HID output_report callback.
It changes the description to state that the callback might be asynchronous
rather than strictly requiring it, citing i2c-hid as an example.

> diff --git a/Documentation/hid/hid-transport.rst b/Documentation/hid/hid-transport.rst
> index 6f1692da296cf..2008cf432af12 100644
> --- a/Documentation/hid/hid-transport.rst
> +++ b/Documentation/hid/hid-transport.rst
> @@ -327,8 +327,8 @@ The available HID callbacks are:
>  
>     Send raw output report via intr channel. Used by some HID device drivers
>     which require high throughput for outgoing requests on the intr channel. This
> -   must not cause SET_REPORT calls! This must be implemented as asynchronous
> -   output report on the intr channel!
> +   must not cause SET_REPORT calls! This call might be asynchronous, so the
> +   caller should not expect an immediate response!

[Severity: Medium]
Does this documentation change contradict the strict architectural guarantees
of the HID subsystem?

The HID subsystem design rules mandate that the output_report callback must
be asynchronous to prevent latency spikes, performance degradation, or
deadlocks on the high-throughput interrupt channel.

By stating that the call "might be asynchronous", could this inadvertently
mislead future transport driver authors into implementing blocking,
synchronous callbacks where they are not permitted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009-send-upstream-v5-0-384af01da3ee@chromium.org?part=1