linux-kernel - Re: [PATCH v2 03/10] i2c: xiic: Switch to Xiic standard mode for i2c-read

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: <80c524c3-8c31-346d-2691-48f93fa6001f@denx.de>
Date:   Wed, 29 Jun 2022 16:05:30 +0200
From:   Marek Vasut <marex@...x.de>
To:     Krzysztof Adamski <krzysztof.adamski@...ia.com>,
        Raviteja Narayanam <raviteja.narayanam@...inx.com>,
        linux-i2c@...r.kernel.org, michal.simek@...inx.com
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        git@...inx.com, joe@...ches.com
Subject: Re: [PATCH v2 03/10] i2c: xiic: Switch to Xiic standard mode for
 i2c-read

On 6/29/22 14:47, Krzysztof Adamski wrote:
> W dniu 26.06.2021 o 12:27, Raviteja Narayanam pisze:
>> Xilinx I2C IP has two modes of operation, both of which implement
>> I2C transactions. The only difference from sw perspective is the
>> programming sequence for these modes.
>> Dynamic mode  -> Simple to program, less number of steps in sequence.
>> Standard mode -> Gives flexibility, more number of steps in sequence.
>>
>> In dynamic mode, during the i2c-read transactions, if there is a
>> delay(> 200us) between the register writes (address & byte count),
>> read transaction fails. On a system with load, this scenario is
>> occurring frequently.
>> To avoid this, switch to standard mode if there is a read request.
>>
>> Added a quirk to identify the IP version effected by this and follow
>> the standard mode.
>>
>> Signed-off-by: Raviteja Narayanam <raviteja.narayanam@...inx.com>
> 
> [...]
> 
> If those two modes only differ in software complexity but we are not
> able to support only the simpler one and we have support for the more
> complicated (standard mode) anyways, we know that standard mode
> can handle or the cases while dynamic mode cannot, we also know that
> dynamic mode is broken on some versions of the core, why do we actually
> keep support for dynamic mode?

If I recall it right, the dynamic mode was supposed to handle transfers 
longer than 255 Bytes, which the core cannot do in Standard mode. It is 
needed e.g. by Atmel MXT touch controller. I spent a lot of time 
debugging the race conditions in the XIIC, which I ultimately fixed (the 
patches are upstream), but the long transfers I rather fixed in the MXT 
driver instead.

I also recall there was supposed to be some update for the XIIC core 
coming with newer vivado, but I might be wrong about that.