> 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
