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 <jonathan@xxxxxxxx> > --- > 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