lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YkQ31VMqj1MXqBd3@shikoro>
Date:   Wed, 30 Mar 2022 12:58:29 +0200
From:   Wolfram Sang <wsa+renesas@...g-engineering.com>
To:     Eugeniu Rosca <erosca@...adit-jv.com>
Cc:     Andrew Gabbasov <andrew_gabbasov@...tor.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Bhuvanesh Surachari <bhuvanesh_surachari@...tor.com>,
        Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: [PATCH v2] i2c: rcar: add SMBus block read support

Hi Eugeniu,

coming back to this topic, thanks for your patience everyone.

> > 
> > You could wire up two R-Car I2C instances, set up one as an I2C slave
> > handled by the I2C testunit and then use the other instance with
> > SMBUS_BLOCK_PROC_CALL which also needs RECV_LEN. Check
> > Documentation/i2c/slave-testunit-backend.rst for details.
> 
> I am obviously not an SMBus expert, but I wonder if simply testing the
> PCA9654 I/O Expander with SMBus support on the H3-Salvator-X target
> could be acceptable as a test procedure? See some test results below.

As long as the first read value is 8 (or lower than 32), it will work.
But it is testing only this one value while my method above is more
flexible and allows for arbitrary test patterns. However, your tests
already showed that Andrew's patch seems to be not correct.

> ############################################################
> #################### ANDREW'S V2 PATCH #####################
> ############################################################
> root@...r-gen3:# i2cget -y 4 0x68 0 i 8
> 0x08 0xff 0x06 0xff 0x5f 0xff 0x11 0x08
> 
> root@...r-gen3:# i2cget -y 4 0x68 0 s
> 0x08 0xff 0x06 0xff 0x5f 0xff 0x11 0x08

This is wrong. The first byte is the length byte and should not be seen
here. Check the i2c_smbus_read_block_data() implementation in i2c-tools.

> ############################################################
> ##################### WOLFRAM'S PATCH ######################
> ############################################################
> root@...r-gen3:# i2cget -y 4 0x68 0 i 8
> 0x08 0xff 0x06 0xff 0x5f 0xff 0x11 0x08
> 
> root@...r-gen3:# i2cget -y 4 0x68 0 s
> 0xff 0x06 0xff 0x5f 0xff 0x11 0x08 0x08

This is how it should look like IMO.

Happy hacking,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ