From d4822283256e153b1d8b61c4126617abcf291f43 Mon Sep 17 00:00:00 2001 From: Daniel Drake Date: Thu, 20 Nov 2008 19:59:43 +0000 Subject: [PATCH] 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. --- libfprint/drivers/upekts.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/libfprint/drivers/upekts.c b/libfprint/drivers/upekts.c index 5553d8e..a67cd94 100644 --- a/libfprint/drivers/upekts.c +++ b/libfprint/drivers/upekts.c @@ -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;