linux-kernel - RE: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes.

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: <SN6PR02MB4093ACD6E6A349BA9740ABB9CAEA9@SN6PR02MB4093.namprd02.prod.outlook.com>
Date:   Wed, 28 Jul 2021 10:11:22 +0000
From:   Raviteja Narayanam <rna@...inx.com>
To:     Marek Vasut <marex@...x.de>, Michal Simek <michals@...inx.com>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        git <git@...inx.com>, "joe@...ches.com" <joe@...ches.com>
Subject: RE: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes.



> -----Original Message-----
> From: Marek Vasut <marex@...x.de>
> Sent: Monday, July 26, 2021 6:43 PM
> To: Raviteja Narayanam <rna@...inx.com>; Michal Simek
> <michals@...inx.com>; linux-i2c@...r.kernel.org
> Cc: linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; git
> <git@...inx.com>; joe@...ches.com
> Subject: Re: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes.
> 
> On 7/26/21 7:26 AM, Raviteja Narayanam wrote:
> 
> Hi,
> 
> [...]
> 
> >>>>> I have tested this again on our boards with eeprom and other
> >>>>> sensors, this
> >>>> is working fine for us.
> >>>>
> >>>> Can you share details of how those tests were performed ?
> >>>
> >>> Stress test - 1:
> >>> Heavy ethernet traffic running in the background.
> >>> I2c commands script (like below) running. We can see visible stutter
> >>> in the
> >> output as expected, but nothing failed.
> >>>
> >>> i=0
> >>> while [ 1 ]
> >>> do
> >>> 		i2ctransfer -y -f 2 w1@...4 0X00 r31@...4
> >>> 		i2ctransfer -y -f 2 w1@...4 0X00 r32@...4
> >>> 		i2ctransfer -y -f 2 w1@...4 0X00 r255@...4
> >>> 		i2ctransfer -y -f 2 w1@...4 0X00 r273@...4
> >>>                                i2ctransfer -y -f 2 w1@...4 0X00
> >>> r1@...4
> >>
> >> Could it be that you never see the problem because you always talk to
> >> one single device ?
> >
> > There are transfers to other devices as well.
> 
> The above test only accesses device at address 0x54, right ?

Above code is just one part.
We are doing read/writes to all devices present on this board https://www.xilinx.com/support/documentation/boards_and_kits/zcu102/ug1182-zcu102-eval-bd.pdf 

> 
> > Our board has multiple power monitors, eeprom and other misc devices
> > that are accessed through the same driver and are working fine.
> 
> That does not seem to be what the test above does .
> 
> >> Do you also test writes which are not 1 byte long ?
> >>
> >
> > Yes, like for eeprom 1 page (16 bytes)  is written.
> 
> I suspect the atmel mxt does much longer writes, try 255 bytes or so.

Ok, I will do longer writes (in the range of 255) on supported slave devices.

> 
> >>>           i=$(expr $i + 1)
> >>>           echo "$i"
> >>> done
> >>>
> >>> Stress test - 2:
> >>> Two i2c scripts running in parallel with commands as shown above
> >>> with
> >> different bus numbers (as a result of mux), but going into same XIIC
> adapter.
> >>> This is also working fine.
> >>
> >> Could it be the i2c-dev serializes each of those transfers , so no
> >> race can be triggered ?
> >>
> >
> > Yes, that is true because all our tests are going through the i2c-core
> > only and there is a lock at adapter level in the core.
> > It has to be reproducible through the i2c standard interface, which is
> > not happening at our setup.
> >
> > I can take your patches that are targeted for this issue, rebase, test
> > and send them.
> 
> I think you and Michal talked about getting the atmel mxt touchscreen, so
> you can test that yourself as well.

Yes, that is the plan, we are trying to get the part. Only problem is it is subject to
availability and may take more time to get it delivered to our place.

Regards,
Raviteja N