linux-kernel - Re: Sony IMX290/462 image sensors I2C xfer peculiarity

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: <m3bkd5tks3.fsf@t19.piap.pl>
Date:   Wed, 11 Oct 2023 14:18:20 +0200
From:   Krzysztof Hałasa <khalasa@...p.pl>
To:     Alexander Stein <alexander.stein@...tq-group.com>
Cc:     Stefan Lengfeld <contact@...fanchrist.eu>,
        linux-media <linux-media@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>, linux-i2c@...r.kernel.org
Subject: Re: Sony IMX290/462 image sensors I2C xfer peculiarity

Hi Alexander,

Alexander Stein <alexander.stein@...tq-group.com> writes:

> I assume that the master clock is running independently to I2C from the SoC 
> the sensor is attached to. Your calculations indicate you are assuming ~400kHz 
> I2C clock frequency.

This is correct.

> But nothing is preventing that sensor from running on a 100kHz I2C bus. Even 
> this "atomic" hack will not be sufficient in that case.

It will be sufficient. Even if all times are 4x longer (they shouldn't
since the CPU won't get slower), they wouldn't reach, say, 1200 us.
There would still be quite a lot of a margin (the timeout is 7 ms).
Even with the faster MCLK (these sensors can operate on 37.125 and on
74.250 MHz) and IF the timeout is still 2^18 in the latter case (meaning
3.5 ms), it would most probably work.

Of course, the atomic hack is not meant for general consumption (at
least for now in its current shape), only the udelay() reduction
(100 -> 1) could probably go in.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa