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