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: <828597fc-ec02-488c-99e9-418a7ff266d3@oss.qualcomm.com>
Date: Mon, 12 Jan 2026 19:50:38 +0800
From: Wenmeng Liu <wenmeng.liu@....qualcomm.com>
To: Bryan O'Donoghue <bod@...nel.org>,
        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 1/12/2026 6:21 PM, Bryan O'Donoghue wrote:
> 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.
> 
> 
> 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.

-- if disable gpiod_set_value_cansleep(imx412->reset_gpio, 1); form 
imx412_power_off, the issue will not happen.

Through this analysis, the issue was ultimately identified as the 
Arducam IMX577 sensor module requiring a relatively long wait time after 
the reset pin is pulled high.

The reason why the ID can be read successfully the first time is that 
the GPIO’s default state is not output low. Therefore, to fix this 
problem, it is necessary to increase the delay time in the power_on 
sequence.

 > 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.

I tried this, but it didn't work at all.

Thanks,
Wenmeng









Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ