> Convert the struct i2c_msg initialization to C99 format. This makes
> maintaining and editing the code simpler. Also helps once other fields
> like transferred are added in future.
> Thanks to Julia Lawall <julia.lawall@...> for automating the conversion
Looks good to me,
Reviewed-by: Peter Huewe <peter.huewe@...>
BUT maybe we should probably wait for the outcome of the
"introduce macros for i2c_msg initialization" discussion also by Julia:
https://lkml.org/lkml/2012/10/7/92
which would wrap this initialization into a macro:
struct i2c_msg msg1 = I2C_MSG_WRITE(tpm_dev.client->addr, 1, &addr);
struct i2c_msg msg2 I2C_MSG_READ(tpm_dev.client->addr, len, buffer);
...
struct i2c_msg msg1 = I2C_MSG_WRITE(tpm_dev.client->addr, len + 1, tpm_dev.buf);
When the discussion is settled I'd probably go directly to I2C_MSG_ macros in order to avoid a double conversion.
Thanks,
Peter

On Tue, 9 Oct 2012 16:07:18 +0000, Peter.Huewe@... wrote:
> > Convert the struct i2c_msg initialization to C99 format. This makes
> > maintaining and editing the code simpler. Also helps once other fields
> > like transferred are added in future.
>
> > Thanks to Julia Lawall <julia.lawall@...> for automating the conversion
>
> Looks good to me,
> Reviewed-by: Peter Huewe <peter.huewe@...>
>
> BUT maybe we should probably wait for the outcome of the
> "introduce macros for i2c_msg initialization" discussion also by Julia:
> https://lkml.org/lkml/2012/10/7/92
> which would wrap this initialization into a macro:
>
> struct i2c_msg msg1 = I2C_MSG_WRITE(tpm_dev.client->addr, 1, &addr);
> struct i2c_msg msg2 I2C_MSG_READ(tpm_dev.client->addr, len, buffer);
> ...
> struct i2c_msg msg1 = I2C_MSG_WRITE(tpm_dev.client->addr, len + 1, tpm_dev.buf);
>
> When the discussion is settled I'd probably go directly to I2C_MSG_ macros in order to avoid a double conversion.
I thought about it, but actually I'd rather pick Shubhrajyoti's patches
first. We don't know where Julia's patch will be going at this point,
and other patches depend on the patches Shubhrajyoti sent, which I do
not want to delay. Julia's changes, if applied, will touch over 200
drivers anyway, so 4 more or less don't make any difference. I also
suspect that Julia's scripts won't catch the non-C99 initializations,
so she probably won't see them Shubhrajyoti's patches are applied -
that's one more reason to apply them immediately.
--
Jean Delvare

Hi Jean,
>> When the discussion is settled I'd probably go directly to I2C_MSG_ macros in order to avoid a double conversion.
> I thought about it, but actually I'd rather pick Shubhrajyoti's patches
> first. We don't know where Julia's patch will be going at this point,
> and other patches depend on the patches Shubhrajyoti sent, which I do
> not want to delay. Julia's changes, if applied, will touch over 200
> drivers anyway, so 4 more or less don't make any difference. I also
> suspect that Julia's scripts won't catch the non-C99 initializations,
> so she probably won't see them Shubhrajyoti's patches are applied -
> that's one more reason to apply them immediately.
Thanks for your input, I just read also your reply to Julia's patchset - so I'm fine with the patch.
> so she probably won't see them Shubhrajyoti's patches are applied...
Hehe, I tend to look at the i2c subsystem from time to time to catch-up with the new features (e.g. __i2c_transfer for this driver)
and apply them to stuff I'm aware of ;) - but of course you're right.
Reviewed-by: Peter Huewe <peter.huewe@...>
And as the driver's author:
Acked-by: Peter Huewe <peter.huewe@...>
Thanks,
Peter