linux-kernel - Re: [PATCH v2] media: i2c: imx412: wait for NVM read (T7) before programming mode registers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ca5e24d7-94ea-47f0-9e02-cb6ecb3b9b24@kernel.org>
Date: Mon, 12 Jan 2026 10:21:18 +0000
From: Bryan O'Donoghue <bod@...nel.org>
To: Wenmeng Liu <wenmeng.liu@....qualcomm.com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: mchehab@...nel.org, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] media: i2c: imx412: wait for NVM read (T7) before
 programming mode registers

On 12/01/2026 10:09, Wenmeng Liu wrote:
>>>> This delay should go at the end of the operation that requires the delay
>>>> not at the start of the streaming operation.
>> I would have thought that, too, but I understand there's an issue with an
>> Arducam module. It's also not exactly clear to me if all other registers
>> are writable at the sensor identification time or is the required delay
>> only concerning starting streaming (I'd hope so).
>>
> Hi Sakari,
> 
> I tried adding a read ID at the end of power_on func and found that it
> could only read the ID during probe; subsequent attempts during stream
> on would fail to read every power on read.
> 
> [   11.298460] imx412 2-001a: read reg chip id: 577
> [   11.310703] imx412 2-001a: read reg chip id: 577
> [   35.392396] imx412 2-001a: read reg failed ret = -5
> [   39.583990] imx412 2-001a: read reg failed ret = -5

This "smell wrong" points to the power_on() sequence not being correct.

You should be able to read the identity register at the end of 
power_on() every single time, if not, power_on - isn't working.

In fact, looking at the power_on() sequence, I'd say we should have put 
reset 1, switched on power, and clock and then taken the part out of reset.

You should be able to put exactly the same delay into power_on() and 
have the same result as having no delay in power_on() instead having it 
in start_streaming().

Are you sure something else isn't happening - a reset line, pm_runtime .. ?

I think either power_off() is happening without you knowing it or more 
likely the reset line logic in the power_on() sequence isn't correct, 
which is why detecting the chip then fails.

---
bod