linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] i2c-dev: Add support for I2C_M_RECV_LEN
Date: Thu, 05 Apr 2012 20:01:43 -0400	[thread overview]
Message-ID: <4F7E3267.9040306@interlog.com> (raw)
In-Reply-To: <20120405092422.453edecf-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>

On 12-04-05 03:24 AM, Jean Delvare wrote:
> Hi Douglas,
>
> On Wed, 04 Apr 2012 18:54:20 -0400, Douglas Gilbert wrote:
>> 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.]
>
> What value did you set msg->buf[0] to before calling? You were supposed
> to set it to 2 in your case, exactly because the driver can't guess how
> many extra bytes the chip will return, that aren't included in the byte
> count. Your results suggest that you let msg->buf[0] to 0.
>
> I've improved my patch to properly reject the transaction if buf[0] is
> not set properly. Please test and report.
>
>> 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.
>
> The SM130 is a bit strange but it should be supportable.
>
> * * * * *
>
> 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.)

Jean,
Either I am misunderstanding how to use this new patch or it is
broken. After replacing the original patch with this one, setting
msg->buf[0] to 2, my test program only sees the first two bytes
of expected data:
   08 81
That is down from 8 bytes from the previous patch and 10 bytes
expected from the SM130.

Doug Gilbert


> Signed-off-by: Jean Delvare<khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
> Cc: Douglas Gilbert<dgilbert-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
> ---
>   drivers/i2c/i2c-dev.c |   30 ++++++++++++++++++++++++++----
>   1 file changed, 26 insertions(+), 4 deletions(-)
>
> --- linux-3.4-rc1.orig/drivers/i2c/i2c-dev.c	2012-04-02 17:16:53.000000000 +0200
> +++ linux-3.4-rc1/drivers/i2c/i2c-dev.c	2012-04-05 09:12:26.385033151 +0200
> @@ -265,19 +265,41 @@ static noinline int i2cdev_ioctl_rdrw(st
>
>   	res = 0;
>   	for (i = 0; i<  rdwr_arg.nmsgs; i++) {
> -		/* Limit the size of the message to a sane amount;
> -		 * and don't let length change either. */
> -		if ((rdwr_pa[i].len>  8192) ||
> -		    (rdwr_pa[i].flags&  I2C_M_RECV_LEN)) {
> +		/* Limit the size of the message to a sane amount */
> +		if (rdwr_pa[i].len>  8192) {
>   			res = -EINVAL;
>   			break;
>   		}
> +
>   		data_ptrs[i] = (u8 __user *)rdwr_pa[i].buf;
>   		rdwr_pa[i].buf = memdup_user(data_ptrs[i], rdwr_pa[i].len);
>   		if (IS_ERR(rdwr_pa[i].buf)) {
>   			res = PTR_ERR(rdwr_pa[i].buf);
>   			break;
>   		}
> +
> +		/*
> +		 * If the message length is received from the slave (similar
> +		 * to SMBus block read), we must ensure that the buffer will
> +		 * be large enough to cope with a message length of
> +		 * I2C_SMBUS_BLOCK_MAX as this is the maximum underlying bus
> +		 * drivers allow. The first byte in the buffer must be
> +		 * pre-filled with the number of extra bytes, which must be
> +		 * at least one to hold the message length, but can be
> +		 * greater (for example to account for a checksum byte at
> +		 * the end of the message.)
> +		 */
> +		if (rdwr_pa[i].flags&  I2C_M_RECV_LEN) {
> +			if (!(rdwr_pa[i].flags&  I2C_M_RD) ||
> +			    rdwr_pa[i].buf[0]<  1 ||
> +			    rdwr_pa[i].len<  rdwr_pa[i].buf[0] +
> +					     I2C_SMBUS_BLOCK_MAX) {
> +				res = -EINVAL;
> +				break;
> +			}
> +
> +			rdwr_pa[i].len = rdwr_pa[i].buf[0];
> +		}
>   	}
>   	if (res<  0) {
>   		int j;
>
>

  parent reply	other threads:[~2012-04-06  0:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15 17:08 [PATCH] i2c-dev: Add support for I2C_M_RECV_LEN Jean Delvare
     [not found] ` <20120315180835.2e669111-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-03-31  6:19   ` Jean Delvare
     [not found]     ` <20120331081927.2438ea9e-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-04-04 22:54       ` Douglas Gilbert
     [not found]         ` <4F7CD11C.2090801-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
2012-04-05  7:24           ` Jean Delvare
     [not found]             ` <20120405092422.453edecf-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-04-06  0:01               ` Douglas Gilbert [this message]
     [not found]                 ` <4F7E3267.9040306-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
2012-04-06  6:37                   ` Jean Delvare
     [not found]                     ` <20120406083751.46fd23c5-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-04-06 16:16                       ` Douglas Gilbert
     [not found]                         ` <4F7F16D3.6080307-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
2012-04-06 16:25                           ` Jean Delvare
     [not found]                             ` <20120406182534.68d7f53d-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-04-06 17:04                               ` Douglas Gilbert
     [not found]                                 ` <4F7F2220.50003-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
2012-04-07 16:00                                   ` Jean Delvare
2012-04-16  7:40                                   ` Voss, Nikolaus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7E3267.9040306@interlog.com \
    --to=dgilbert-qazkctl6wrfwk0htik3j/w@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).