Re: [PATCH v16 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] gpio-rpmsg: lost edge interrupts due to SET_IRQ_TYPE unmasking
- [Medium] gpio-rpmsg: unaligned 16-bit line field in interrupt message
--

commit 2049dbbf3b708aaa525f92e4899cb8a65c3fd69f
Author: Shenwei Wang <shenwei.wang@nxp.com>

docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus

Describes the gpio rpmsg transport protocol over the rpmsg bus between
the remote system and Linux.

> diff --git a/Documentation/driver-api/gpio/gpio-rpmsg.rst b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> new file mode 100644
> index 0000000000000..9af75cc759ba7
> --- /dev/null
> +++ b/Documentation/driver-api/gpio/gpio-rpmsg.rst

[ ... ]

> +Interrupt Messages
> +------------------
> +
> +Interrupt messages are sent by the remote core and they have
> +**Type=1 (GPIO_RPMSG_NOTIFY)**:
> +
> +When a GPIO line asserts an interrupt on the remote processor, the firmware
> +should immediately mask the corresponding interrupt source and send a
> +notification message to the Linux. Upon completion of the interrupt
> +handling on the Linux side, the driver should issue a
> +command **SET_IRQ_TYPE** to the firmware to unmask the interrupt.

[Severity: High]
Does this mechanism risk losing edge interrupts?

If a secondary edge interrupt occurs while the interrupt is masked during
processing on the Linux side, it will be latched by the remote hardware.

When the firmware receives the SET_IRQ_TYPE command as an unmask signal,
writing the trigger configuration to hardware will inadvertently clear this
latched edge on many platforms, such as the i.MX platforms this driver
targets.

Should the protocol separate MASK and UNMASK commands from configuration
commands to prevent clearing latched pending bits or resetting the
edge-detection state machine?

> +
> +.. code-block:: none
> +
> +   +------+------+--------+
> +   | 0x00 | 0x01 |  0x02  |
> +   |   1  |     line      |
> +   +------+------+--------+

[Severity: Medium]
Will this message layout cause hardware faults or performance penalties on
remote processors?

The layout places the 2-byte line field immediately after the 1-byte type
field, creating an unaligned multi-byte field. Without padding, this requires
packed structs on Linux and could cause hardware faults or performance
penalties on remote firmware processors lacking hardware unaligned access
support (like ARM Cortex-M0 or M0+).

Should a 1-byte padding field be introduced to ensure natural alignment and
cross-architecture compatibility?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923184255.299034-1-shenwei.wang@oss.nxp.com?part=1