mbox series

[0/7] Rework block read support among i2cget and i2cdump

Message ID 20210608172338.0cf520a1@endymion
Headers show
Series Rework block read support among i2cget and i2cdump | expand

Message

Jean Delvare June 8, 2021, 3:23 p.m. UTC
Hi all,

This is my attempt to improve the block read support in i2c-tools,
specifically i2cget and i2cdump. The base of this series is the
submission by Crestez Dan Leonard 5 years ago. Sorry for the delay ;-)

First we add support of both I2C and SMBus block read to i2cget:

[PATCH 1/7] i2cget: Add support for I2C block data
[PATCH 2/7] i2cget: Document the support of I2C block reads
[PATCH 3/7] i2cget: Add support for SMBus block read

Then we add support for range selection in I2C block mode to i2cdump:

[PATCH 4/7] i2cdump: Remove dead code
[PATCH 5/7] i2cdump: Add range support with mode i (I2C block)

Lastly we deprecate and eventually remove support for SMBus block mode
from i2cdump:

[PATCH 6/7] i2cdump: Deprecate SMBus block mode
[PATCH 7/7] i2cdump: Remove support for SMBus block mode

The idea would be to get the first 6 patches in the upcoming i2c-tools
v4.3, and apply the 7th patch "later" (either immediately after that
release, or some time later, I'm not sure).

Comments

Wolfram Sang June 26, 2021, 3:30 p.m. UTC | #1
Hi Jean,

> The idea would be to get the first 6 patches in the upcoming i2c-tools

> v4.3, and apply the 7th patch "later" (either immediately after that

> release, or some time later, I'm not sure).


I agree with this approach.

I had a glimpse at the patches and think they look good so far. I would
have squashed patches 1+2, but this minor, of course. I'll try to test
them this weekend, too. Let's see...
Wolfram Sang June 27, 2021, 10:27 a.m. UTC | #2
> The idea would be to get the first 6 patches in the upcoming i2c-tools

> v4.3, and apply the 7th patch "later" (either immediately after that

> release, or some time later, I'm not sure).


So, my tests so far went nicely and looking more at the patches didn't
reveal any major discussion point. So:

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


I'd vote also for an early removal. The code cleanup is too nice and
i2cget is, in deed, the better place for mode 's'.
Jean Delvare July 12, 2021, 9:58 a.m. UTC | #3
Hi Wolfram,

On Sat, 26 Jun 2021 17:30:25 +0200, Wolfram Sang wrote:
> > The idea would be to get the first 6 patches in the upcoming i2c-tools

> > v4.3, and apply the 7th patch "later" (either immediately after that

> > release, or some time later, I'm not sure).  

> 

> I agree with this approach.

> 

> I had a glimpse at the patches and think they look good so far. I would

> have squashed patches 1+2, but this minor, of course.


I would have too but patch 1 was submitted by somebody else. I didn't
want to put more changes in it than was required for committing
acceptance, so as to respect the original submission.

-- 
Jean Delvare
SUSE L3 Support
Jean Delvare July 13, 2021, 8:21 a.m. UTC | #4
Hi Wolfram,

On Sun, 27 Jun 2021 12:27:40 +0200, Wolfram Sang wrote:
> > The idea would be to get the first 6 patches in the upcoming i2c-tools

> > v4.3, and apply the 7th patch "later" (either immediately after that

> > release, or some time later, I'm not sure).  

> 

> So, my tests so far went nicely and looking more at the patches didn't

> reveal any major discussion point. So:

> 

> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

> 

> I'd vote also for an early removal. The code cleanup is too nice and

> i2cget is, in deed, the better place for mode 's'.


Thanks for the review and testing, very much appreciated. I have
committed the first 6 patches, with cosmetic fixes after a last
self-review.

With this, we are ready to release i2c-tools 4.3.

-- 
Jean Delvare
SUSE L3 Support
Wolfram Sang July 19, 2021, 3:19 p.m. UTC | #5
> I would have too but patch 1 was submitted by somebody else. I didn't

> want to put more changes in it than was required for committing

> acceptance, so as to respect the original submission.


I see. This is fine, of course. Glad to see the patches upstream!