Re: [PATCH i2c-tools] Revert "tools: i2ctransfer: add check for returned length from driver"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 4 Jun 2021 21:21:17 +0200, Wolfram Sang wrote:
> > If we only want *one* I2C block read at a specified offset then i2cget
> > seems more appropriate indeed.  
> 
> I don't have a clear opinion here. On the one hand, if we want just one
> block read, this is more a "get" than a "dump". On the other hand,
> i2cdump already has a range-parameter. So, from a user perspective,
> keeping i2cget to single values and update the range parameter in
> i2cdump might be least confusing?

The feature doesn't clearly fit in either tool but could be made to fit
in both ;-) Which isn't a situation I like.

I think this is really a conceptual difference. For certain devices
(like EEPROMs) I2C Block read means reading from a range of register
addresses, which is i2cdump's realm. But for other devices, I2C Block
read means reading multiple register values from a single address
(which is typically what _SMBus_ Block reads are always about, but
nothing prevents devices from using I2C Block reads for the same
purpose). Which is more like i2cget's realm.

The problem is that, depending on which device our users are working
with, they will *expect* the feature to be in one tool or the other.
And most probably won't even have the idea of trying the other. Of
course we could add a redirection note in the manual page, but users
will have wasted time already. If they read the manual page at all. And
even then, the way the data is presented could be confusing if they
need to use the "other" tool.

As a matter of fact, I have at least two more records of people asking
for this very feature without realizing it was already (partially)
available in another tool (Aleksandr Amelkin in 2015 and Gina Ko in
2019). The fact that i2cset does support Block writes (since 2011!)
when i2cget does not support Block reads is definitely confusing.

So I'm actually tempted to add the feature to *both* tools. Crestez's
patch would be the base for the i2cget implementation, to which I would
happily add SMBus block read support. For i2cdump, it's about adding
support for register range to the "i" mode. I took a quick look already
and it seems fairly trivial to implement.

Stay tuned,
-- 
Jean Delvare
SUSE L3 Support



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux