| Message ID | 20190620104519.16917-1-tautvydas.b@8devices.com |
|---|---|
| State | Accepted |
| Delegated to: | Koen Vandeputte |
| Headers | show |
| Series | [OpenWrt-Devel,v5] uqmi: add explicit check for message type when expecting a response | expand |
On 20.06.19 12:45, Tautvydas Belgeras wrote: > When the utility sends a request it expects a response type message, > but does not explicitly check for it. When a device stays idle for > some time, it switches into a sleep mode, and notifies the utility with an > identification type message. In some configurations the device only sends > this identification message when triggered by the utility, in this case by > the request message. What the utility gets is two messages at the same time - > an identification and a response. When it tries to decode former it obviously > fails, because it is not what it expected. > > Signed-off-by: Tautvydas Belgeras <tautvydas.b@8devices.com> > --- > dev.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dev.c b/dev.c > index 4bca429..bd10207 100644 > --- a/dev.c > +++ b/dev.c > @@ -96,6 +96,9 @@ static void qmi_process_msg(struct qmi_dev *qmi, struct qmi_msg *msg) > struct qmi_request *req; > uint16_t tid; > > + if (msg->flags != QMI_CTL_FLAG_RESPONSE && msg->flags != QMI_SERVICE_FLAG_RESPONSE) > + return; > + > if (msg->qmux.service == QMI_SERVICE_CTL) > tid = msg->ctl.transaction; > else Merged in Uqmi master Thanks for the fix! Regards, Koen
diff --git a/dev.c b/dev.c index 4bca429..bd10207 100644 --- a/dev.c +++ b/dev.c @@ -96,6 +96,9 @@ static void qmi_process_msg(struct qmi_dev *qmi, struct qmi_msg *msg) struct qmi_request *req; uint16_t tid; + if (msg->flags != QMI_CTL_FLAG_RESPONSE && msg->flags != QMI_SERVICE_FLAG_RESPONSE) + return; + if (msg->qmux.service == QMI_SERVICE_CTL) tid = msg->ctl.transaction; else
When the utility sends a request it expects a response type message, but does not explicitly check for it. When a device stays idle for some time, it switches into a sleep mode, and notifies the utility with an identification type message. In some configurations the device only sends this identification message when triggered by the utility, in this case by the request message. What the utility gets is two messages at the same time - an identification and a response. When it tries to decode former it obviously fails, because it is not what it expected. Signed-off-by: Tautvydas Belgeras <tautvydas.b@8devices.com> --- dev.c | 3 +++ 1 file changed, 3 insertions(+)