On 12-03-31 02:19 AM, Jean Delvare wrote:
On Thu, 15 Mar 2012 18:08:35 +0100, Jean Delvare wrote:
As the bus driver side implementation of I2C_M_RECV_LEN is heavily
tied to SMBus, we can't support received length over 32 bytes, but
let's at least support that.
In practice, the caller will have to setup a buffer large enough to
cover the case where received length byte has value 32, so minimum
32 + 1 = 33 bytes, possibly more if there is a fixed number of bytes
added for the specific slave (for example a checksum.)
Signed-off-by: Jean Delvare<khali@xxxxxxxxxxxx>
Cc: Douglas Gilbert<dgilbert@xxxxxxxxxxxx>
---
This is an alternative to Doug's implementation. Doug, I sent this to
you one week ago, did you have the time to give it a try, do you have
any comment? Again I can't test this myself so someone else will have
to do it.
Douglas, please?
Jean,
Sorry about the delay in responding. The patch didn't work
in the case of the Sonmicro SM130 RFID but I could see it was close.
The correct response (for the SM130) when reading the firmware
version is this 10 byte response:
08 81 49 32 43 20 32 2e 38 ff ["I2C 2.8"]
so the count in the first byte excludes itself and the checksum
trailing byte. With the I2C_M_RECV_LEN patch I see this response:
08 81 49 32 43 20 32 2e 00 00
so the count (leading) byte includes itself and makes no
provision for a checksum. [So 8 bytes are returned and the two
trailing zeros are just buffer pre-fill.]
You might argue that the I2C_M_RECV_LEN patch is sensible
and the SM130 is strange. My solution is to read 32 bytes
which is more than I ever expect.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
