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@gmail.com> 
Sent: Saturday, August 13, 2022 3:28 AM
To: margeyang <redacted>
Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; hdegoede@redhat.com; benjamin.tissoires@redhat.com; Marge Yang <redacted>; Derek Cheng <redacted>; Vincent Huang <redacted>
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 <redacted>

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