RE: [PATCH V2] Input: synaptics-rmi4 - filter incomplete relative packet.

[Marge Yang]

Add Synaptics firmware member

Hi Dmitry,
	Update Synaptics firmware's comment.
[Wayne 08/15]
To address the transaction error case in the middle would potential lead to the unexpected data transaction and latency between styk device and host driver.  F$03 didn't really parse any data packet but simply works as bridge functionality to bypass the command and response packets between styk device and driver.

Thanks
Marge Yang

-----Original Message-----
From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 
Sent: Saturday, August 13, 2022 3:28 AM
To: margeyang <marge.yang@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Cc: linux-input@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; hdegoede@xxxxxxxxxx; benjamin.tissoires@xxxxxxxxxx; Marge Yang <Marge.Yang@xxxxxxxxxxxxxxxx>; Derek Cheng <derek.cheng@xxxxxxxxxxxxxxxx>; Vincent Huang <Vincent.huang@xxxxxxxxxxxxxxxx>
Subject: Re: [PATCH V2] Input: synaptics-rmi4 - filter incomplete relative packet.

CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi Marge,

On Fri, Aug 12, 2022 at 04:43:25PM +0800, margeyang wrote:
> From: Marge Yang <marge.yang@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> RMI4 F03 supports the Stick function,
> it's designed to support relative packet.
> This patch supports the following case.
> When relative packet can't be reported completely, it may miss one 
> byte or two byte.
> New Synaptics firmware will report PARITY error.
> When timeout error or parity error happens,
> RMI4 driver will sends 0xFE command and ask FW to Re-send stick packet 
> again.

My understanding is that F03 is intended to be a pass-through mechanism for PS/2-compatible devices. In that spirit all protocol handling and validation should happen in psmouse driver that attaches to a serio port provided by F03.

Historically we did not pay attention to parity and frame errors for
PS/2 mice/touchpads (and for keyboards on x86) but we coudl add such code there. Do we actually observe this with RMI devices? Can RMI firmware handle this better instead?

Thanks.

--
Dmitry