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: <468ce093-7704-4497-a538-c54baacbd8ae@oss.qualcomm.com>
Date: Mon, 12 Jan 2026 18:09:15 +0800
From: Wenmeng Liu <wenmeng.liu@....qualcomm.com>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: Bryan O'Donoghue <bod@...nel.org>, 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 5:06 PM, Sakari Ailus wrote:
> Hi Wenmeng, Bryan,
> 
> On Mon, Jan 12, 2026 at 11:07:39AM +0800, Wenmeng Liu wrote:
>>
>>
>> On 1/9/2026 8:32 PM, Bryan O'Donoghue 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


> Also see
> <URL:https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/pm-resume-delay>.
> I haven't posted these yet, but I think it'd be useful to avoid extra
> delays here and elsewhere.

compile failed in my side...
+void pm_runtime_resume_fsleep(struct device *dev, u64 sleep_us)
+{
+       u64 ns_diff = ktime_get_mono_fast_ns() - 
READ_ONCE(dev->power.last_busy);
+
+       if (ns_diff < NSEC_PER_USEC * sleep_us)
+               fsleep(sleep_us - (ns_diff >> 10)); /* avoid div_u64 */
+}
use this func in imx412.c for all usleep_range, have no effect.

> 
>>>
>>> The delay after the stream write, should be related to the stream write
>>> command, not the antecedent - the command that came before
>>> start_streaming.
>>>
>>> Basically I think you need to put your delay into the CCI_ID read NVM
>>> parameter load routine so that it guarantees its own completion.
>>>
>>> Because for argument's sake if start_streaming() were not to be the
>>> thing to happen after CCI_ID/NVM loading, the logic would no longer
>>> work.
>>>
>>> And you need a Fixes: tag for this patch too.
>>
>> Reading the sensor ID only occurs during the sensor probe process. After the
>> probe is completed, the IMX577 will power down. When stream on occurs, the
>> driver will power on again and then start streaming, but the sensor ID is
>> not read during the stream on process.I have tested this change on imx577
>> modules of different models.
>>
>> So this change can only happen during power on or stream on.
>>
>> Hi Bryan, Sakari,
>> May I ask if you have any suggestions regarding this?
> 
> Could you add a comment this delay is there for the Arducam module (and
> which one), that doesn't work without it?
>
https://www.arducam.com/arducam-imx577-mini-camera-module-for-qualcomm-rb3g2.html
https://www.arducam.com/arducam-imx477-camera-module-for-depthai-oak-b0369.html

I have tested on these two IMX577 sensor module form Arducam,all have 
this issue.Did not encounter this problem when using one non-arducam 
IMX577.

Thanks,
Wenmeng



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ