[PATCH v3 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver

[Andrew Lunn]

> The only platform-specific part is the message format exchanged between Linux and the remote processors.
> As long as the remote processor follows the same message protocol, the driver should work as expected.
> 
> Here's the layout of the message packets:
> 
> +--------+--------+--------+--------+--------+----------------+--------+--------+---------------+---------------+
> |0x00    |0x01    |0x02    |0x03    |0x04    |0x05..0x09      |0x0A    |0x0B    |0x0C           |0x0D           |
> |cate    |major   |minor   |type    |cmd     |reserved[5]     |pin_idx |port_idx|out:{evt/rc/v} |in:{wkup/val}  |
> +--------+--------+--------+--------+--------+----------------+--------+--------+---------------+---------------+
> 
> Cate (Category field ): can be GPIO /I2C/PMIC/AUDIO ... etc
> Major : Major version number
> Minor: Minor version number
> Type (Message Type): Can be SETUP / REPLY /NOTIFY for GPIO category
> Cmd (Command): Can be Input INIT / Output INIT / Input GET for GPIO category
> Pin_idx: The GPIO line index
> Port_idx: The GPIO controller index
> 
> For Out packet:  
> 	if it is OUPUT INIT, the out field value is the gpio output level.
> 	If it is INPUT INIT, the out filed is 0.
> 
> For In packet:
> 	If it is a REPLY message, the out field is return code. 0 means success.  
> 	If it is a REPLY of INPUT GET, the in field is the value of GPIO line level.
> 	If it is an NOTIFY type of message, it simulates an interrupt event from the remote processor.
> 
> I can add above comments in the commit log or the beginning of the driver source file.

Maybe Documentation/admin-guide/gpio-rpmsg.rst would be better.  You
should also document how to handle features the device does not
support. e.g. i _think_ your hardware supports all 4 interrupt
types. But maybe other hardware needs to return something meaning
-EOPNOTSUP?

	Andrew