2012-05-09 05:54:20

by Dmitry Torokhov

[permalink] [raw]
Subject: Re: [PATCH 03/14 v3] Input: atmel_mxt_ts - refactor mxt_read/write_reg to take a length

Hi Daniel,

On Wed, Apr 18, 2012 at 09:21:48PM +0800, Daniel Kurtz wrote:
> + ret = i2c_transfer(client->adapter, xfer, 2);
> + if (ret != 2) {
> + dev_err(&client->dev, "i2c read reg failed (%d)\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
> }
>
> - return 0;
> + return (ret == 2) ? 0 : ret;
> }

Would prefer:

ret = i2c_transfer(client->adapter, xfer, ARRAY_SIZE(xfer));
if (ret != ARRAY_SIZE(xfer)) {
if (ret >= 0)
ret = -EIO;
dev_err(&client->dev, "i2c read reg failed (%d)\n", ret);
return ret;
}

return 0;


Or maybe we need i2c_transfer_exact() wrapper? Jean?

Thanks.

--
Dmitry


2012-05-09 07:05:16

by Jean Delvare

[permalink] [raw]
Subject: Re: [PATCH 03/14 v3] Input: atmel_mxt_ts - refactor mxt_read/write_reg to take a length

Hi Dmirty,

On Tue, 8 May 2012 22:54:11 -0700, Dmitry Torokhov wrote:
> Hi Daniel,
>
> On Wed, Apr 18, 2012 at 09:21:48PM +0800, Daniel Kurtz wrote:
> > + ret = i2c_transfer(client->adapter, xfer, 2);
> > + if (ret != 2) {
> > + dev_err(&client->dev, "i2c read reg failed (%d)\n", ret);
> > + if (ret >= 0)
> > + ret = -EIO;
> > }
> >
> > - return 0;
> > + return (ret == 2) ? 0 : ret;
> > }
>
> Would prefer:
>
> ret = i2c_transfer(client->adapter, xfer, ARRAY_SIZE(xfer));
> if (ret != ARRAY_SIZE(xfer)) {
> if (ret >= 0)
> ret = -EIO;
> dev_err(&client->dev, "i2c read reg failed (%d)\n", ret);
> return ret;
> }
>
> return 0;
>
>
> Or maybe we need i2c_transfer_exact() wrapper? Jean?

What would this function do? Return 0 on success instead of the number
of transferred messages? And -EIO on partial transfers?

That would make sense. Partial success is a rare case anyway, and
recovery possibilities are even rarer. I think most drivers don't
bother and either retry the whole transaction or fail right away. In
fact the number of messages successfully transferred is more useful to
diagnose problems during driver development or debugging.

Feel free to write and send a patch introducing i2c_transfer_exact().
It would make sense to have it log a debug message on partial success,
as it is a rare case. Bonus points if you also sent one or more patches
converting (some of) the existing callers to make use of the new
function.

--
Jean Delvare

2012-05-09 07:25:26

by Dmitry Torokhov

[permalink] [raw]
Subject: Re: [PATCH 03/14 v3] Input: atmel_mxt_ts - refactor mxt_read/write_reg to take a length

On Wed, May 09, 2012 at 09:05:00AM +0200, Jean Delvare wrote:
> Hi Dmirty,
>
> On Tue, 8 May 2012 22:54:11 -0700, Dmitry Torokhov wrote:
> > Hi Daniel,
> >
> > On Wed, Apr 18, 2012 at 09:21:48PM +0800, Daniel Kurtz wrote:
> > > + ret = i2c_transfer(client->adapter, xfer, 2);
> > > + if (ret != 2) {
> > > + dev_err(&client->dev, "i2c read reg failed (%d)\n", ret);
> > > + if (ret >= 0)
> > > + ret = -EIO;
> > > }
> > >
> > > - return 0;
> > > + return (ret == 2) ? 0 : ret;
> > > }
> >
> > Would prefer:
> >
> > ret = i2c_transfer(client->adapter, xfer, ARRAY_SIZE(xfer));
> > if (ret != ARRAY_SIZE(xfer)) {
> > if (ret >= 0)
> > ret = -EIO;
> > dev_err(&client->dev, "i2c read reg failed (%d)\n", ret);
> > return ret;
> > }
> >
> > return 0;
> >
> >
> > Or maybe we need i2c_transfer_exact() wrapper? Jean?
>
> What would this function do? Return 0 on success instead of the number
> of transferred messages? And -EIO on partial transfers?

Yes, exactly.

>
> That would make sense. Partial success is a rare case anyway, and
> recovery possibilities are even rarer. I think most drivers don't
> bother and either retry the whole transaction or fail right away. In
> fact the number of messages successfully transferred is more useful to
> diagnose problems during driver development or debugging.
>
> Feel free to write and send a patch introducing i2c_transfer_exact().
> It would make sense to have it log a debug message on partial success,
> as it is a rare case. Bonus points if you also sent one or more patches
> converting (some of) the existing callers to make use of the new
> function.

OK, thanks.

--
Dmitry