mirror of
https://gitlab.freedesktop.org/libfprint/libfprint.git
synced 2025-11-15 07:38:12 +00:00
upekts: Don't choke on non-zero bytes in command response
Alon Bar-Lev's device behaves differently, but seems to work fine with upekts even if we ignore the difference.
This commit is contained in:
@@ -321,10 +321,13 @@ static int __handle_incoming_msg(struct read_msg_data *udata,
|
|||||||
fp_err("cmd response without 28 byte?");
|
fp_err("cmd response without 28 byte?");
|
||||||
return -1;
|
return -1;
|
||||||
}
|
}
|
||||||
if (innerbuf[3] || innerbuf[4]) {
|
|
||||||
fp_err("non-zero bytes in cmd response");
|
/* not really sure what these 2 bytes are. on most people's hardware,
|
||||||
return -1;
|
* these bytes are always 0. However, Alon Bar-Lev's hardware gives
|
||||||
}
|
* 0xfb 0xff during the READ28_OB initsm stage. so don't error out
|
||||||
|
* if they are different... */
|
||||||
|
if (innerbuf[3] || innerbuf[4])
|
||||||
|
fp_dbg("non-zero bytes in cmd response");
|
||||||
|
|
||||||
innerlen = innerbuf[1] | (innerbuf[2] << 8);
|
innerlen = innerbuf[1] | (innerbuf[2] << 8);
|
||||||
innerlen = GUINT16_FROM_LE(innerlen) - 3;
|
innerlen = GUINT16_FROM_LE(innerlen) - 3;
|
||||||
|
|||||||
Reference in New Issue
Block a user