Re: [PATCH v4 1/2] Input: synaptics-rmi4 - fix irq[] overrun with 7 interrupt sources

[Dmitry Torokhov]

Hi Wei,

On Tue, Aug 25, 2026 at 06:31:22PM +0800, Wei Jie Law wrote:
> rmi_read_pdt_entry() takes the interrupt source count straight out of the
> Page Description Table entry the device supplies:
>
> 	entry->interrupt_source_count = buf[4] & RMI_PDT_INT_SOURCE_COUNT_MASK;
>
> RMI_PDT_INT_SOURCE_COUNT_MASK is 0x07, so the value can be 7, and
> rmi_create_function() copies it verbatim into fn->num_of_irqs.  But
> struct rmi_function declares
>
> 	int irq[RMI_FN_MAX_IRQS];
>
> with RMI_FN_MAX_IRQS == 6, and both rmi_create_function_irq() and
> rmi_unregister_function() index that array up to fn->num_of_irqs.
...
> Size the array to match the three bit field that feeds it.  Clamping
> num_of_irqs instead would silently drop an interrupt source a device is
> allowed to declare, and would desynchronise irq_pos for every function
> created after it.

Per the Synaptics RMI4 specification (Section "Function Descriptor
registers"), only values 0 through 6 directly specify an interrupt
count, while value 7 is reserved to indicate "more than 6 interrupt
sources" (which is why the comment above RMI_FN_MAX_IRQS states "up
to 6 interrupt sources in the normal manner").

Since the driver does not implement support for functions with more than
6 interrupt sources, we should keep RMI_FN_MAX_IRQS as 6 and reject
functions reporting interrupt_source_count > RMI_FN_MAX_IRQS with
-EINVAL during PDT scanning in rmi_scan_pdt_page() (after the
RMI4_END_OF_PDT() check so unpopulated 0xff entries still terminate the
scan cleanly).

Thanks.

-- 
Dmitry