On Mon, Oct 07, 2024 at 12:47:22AM GMT, Jonathan Marek wrote:
> The name len field of the CMD_OPEN packet is only 16-bits and the upper
> 16-bits of "param2" are a different field, which can be nonzero in certain
> situations, and CMD_OPEN packets can be unexpectedly dropped because of
> this.
Any idea about the upper 16 bits? Should we care about that data too?
>
> Fix this by masking out the upper 16 bits of param2.
>
> (the commit in this Fixes tag is not where the original code was introduced
> but it should be far back enough not to matter)
Let's be more precise:
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
>
> Fixes: 835764ddd9af ("rpmsg: glink: Move the common glink protocol
> implementation to glink_native.c")
> Signed-off-by: Jonathan Marek <jonat...@marek.ca>
> ---
> drivers/rpmsg/qcom_glink_native.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c
> b/drivers/rpmsg/qcom_glink_native.c
> index 0b2f290069080..e4933b823238c 100644
> --- a/drivers/rpmsg/qcom_glink_native.c
> +++ b/drivers/rpmsg/qcom_glink_native.c
> @@ -1204,7 +1204,7 @@ void qcom_glink_native_rx(struct qcom_glink *glink)
> ret = qcom_glink_rx_open_ack(glink, param1);
> break;
> case GLINK_CMD_OPEN:
> - ret = qcom_glink_rx_defer(glink, param2);
> + ret = qcom_glink_rx_defer(glink, param2 & 0xffff);
> break;
> case GLINK_CMD_TX_DATA:
> case GLINK_CMD_TX_DATA_CONT:
> --
> 2.45.1
>
--
With best wishes
Dmitry
