Fix the openamp_rsc_table sample by specifying the IPM capability for maximum data transfer size

[arnopo]

The samples/subsys/ipc/openamp_rsc_table sample requests to transfer data for mailboxes that support data transfer.
Some existing drivers return an error if size is non-null or print a warning message on each transfer.
Update these drivers to be compatible with the subsys/ipc/openamp_rsc_table sample, using LOG_WRN_ONCE to indicate only the first time that the driver does not support data transfers.

This fixes issue introduced in e50a2ba

[erwango]

ipm_send api specificies:

 * @retval -EMSGSIZE If the supplied data size is unsupported by the driver.

Based on this, is that ok not to return an error in the driver?

Alternatively, could the sample first check driver support (be resilient to a first error EMSGSIZE received) before actually trying to send data ?

[erwango]

I'm surprised CI didn't complain but please add {}

[erwango]

Ditto

[arnopo]

ipm_send api specificies:

 * @retval -EMSGSIZE If the supplied data size is unsupported by the driver.

Based on this, is that ok not to return an error in the driver?

For me yes. This is the way of working in Linux kernel.

Alternatively, could the sample first check driver support (be resilient to a first error EMSGSIZE received) before actually trying to send data?

That would mean that the sample takes into account drivers specificity. I would prefer to keep the sample simple.

That said if your concern is about HSEM driver, I can remove HSEM update. the driver is not used by the subsys/ipc/openamp_rsc_table sample.

[erwango]

For me yes. This is the way of working in Linux kernel.

Ok.

That would mean that the sample takes into account drivers specificity. I would prefer to keep the sample simple.

My issue is that this change will prevent application to detect driver specificity. So yes user will be informed (if subsystem logs are enabled), but application won't be able to detect issue (underlying hw is not able to transmit data as expected) and report an error to higher levels.
If the issue is that ywe need to keep the sample simple run w/o errors, then it would be better to find ways (sample.yaml filters for instance) to not run it on HW that don't support the feature.

That said if your concern is about HSEM driver, I can remove HSEM update.

No need, I prefer we find a consistent behavior across drivers.

[arnopo]

For me yes. This is the way of working in Linux kernel.

Ok.

That would mean that the sample takes into account drivers specificity. I would prefer to keep the sample simple.

My issue is that this change will prevent application to detect driver specificity. So yes user will be informed (if subsystem logs are enabled), but application won't be able to detect issue (underlying hw is not able to transmit data as expected) and report an error to higher levels. If the issue is that ywe need to keep the sample simple run w/o errors, then it would be better to find ways (sample.yaml filters for instance) to not run it on HW that don't support the feature.

There are (at least) two types of mailbox:

• mailbox that works as a dorbell ( non data transmitted only an inter processor notification)
• mailbox that allow to transmit and receive data with a notification

We should support both.

for that an alternative could be to add an IPM config to indicate the type of IPM used.

• in drivers/ipm/Kconfig

config IPM_DATA_TRANSFER
	bool "IPM data transfer support"
	default y
	help
	  Enable this if the IPM device support data transmission and reception.

In subsys/ipc/openamp_rsc_table sample

 int mailbox_notify(void *priv, uint32_t id)
{
	ARG_UNUSED(priv);

	LOG_DBG("%s: msg received", __func__);
-	ipm_send(ipm_handle, 0, id, &id, 4);
+	if (!IS_ENABLED(CONFIG_IPM_DATA_TRANSFER)) {
+		ipm_send(ipm_handle, 0, id, NULL, 0);
+	} else {
+		ipm_send(ipm_handle, 0, id, &id, 4);

	return 0;
}

Does this implementation align with your expectations?

[erwango]

Does this implementation align with your expectations?

Yes, fine for me. Thanks!

[arnopo]

Finally, I replaced the IPM_DATA_TRANSFER configuration with IPM_MAX_DATA_SIZE, which can be reused later by other IPM drivers to specify their capabilities in terms of data transfer.

[arnopo]

@anangl , @masz-nordic: Could you review please