depau/libfprint
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

upekts: Don't choke on non-zero bytes in command response

Browse source 
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:
Daniel Drake 2008-11-20 19:59:43 +00:00
parent 7c44c86d4c
commit d482228325
1 changed files with 7 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
libfprint/drivers/upekts.c
View file

@ -321,10 +321,13 @@ static int __handle_incoming_msg(struct read_msg_data *udata,
fp_err("cmd response without 28 byte?");
return -1;
}
if (innerbuf[3] || innerbuf[4]) {
fp_err("non-zero bytes in cmd response");
return -1;
}
/* not really sure what these 2 bytes are. on most people's hardware,
* 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 = GUINT16_FROM_LE(innerlen) - 3;