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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <dc68db73-163e-4443-b334-31e2ae529e99@kernel.org>
Date: Fri, 9 Jan 2026 12:32:52 +0000
From: Bryan O'Donoghue <bod@...nel.org>
To: Wenmeng Liu <wenmeng.liu@....qualcomm.com>, sakari.ailus@...ux.intel.com,
 mchehab@...nel.org
Cc: 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 09/01/2026 04:49, Wenmeng Liu wrote:
> During sensor bring-up, the IMX412 performs CCI ID read (T6 ~0.6 ms) and
> parameter loading from NVM (T7 ≤ 8 ms) after INCK/XCLR rise. Writing the
> mode register list while T7 is in progress can cause  failed
> register programming.
> 
> Move the usleep_range(7400, 8000) to the beginning of
> imx412_start_streaming(), so the driver waits for the NVM read window (T7)
> to complete before pushing the mode registers and sending the streaming
> command (T8). This change preserves the original delay length but fixes
> the ordering to match the datasheet timing:
> 
> - T6: CCI ID read wait (~0.6 ms)
> - T7: NVM parameter read (≤ 8 ms) — now fully elapsed before any
>        register writes
> - T8: start of first streaming after issuing MODE_SELECT
> 
> Signed-off-by: Wenmeng Liu <wenmeng.liu@....qualcomm.com>
> ---
> Changes in v2:
> - Move the 7.4–8 ms delay before mode-register programming to satisfy T7 (NVM read).
> - Link to v1: https://lore.kernel.org/all/20251222-imx412-v1-1-51c7e724b376@oss.qualcomm.com/
> ---
>   drivers/media/i2c/imx412.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx412.c b/drivers/media/i2c/imx412.c
> index b3826f803547..ed249a95ff35 100644
> --- a/drivers/media/i2c/imx412.c
> +++ b/drivers/media/i2c/imx412.c
> @@ -798,6 +798,9 @@ static int imx412_start_streaming(struct imx412 *imx412)
>   	const struct imx412_reg_list *reg_list;
>   	int ret;
> 
> +	/* Wait T7 (≤8ms) so NVM read finishes; avoid I2C NACK when writing mode regs */
> +	usleep_range(7400, 8000);
> +
>   	/* Write sensor mode registers */
>   	reg_list = &imx412->cur_mode->reg_list;
>   	ret = imx412_write_regs(imx412, reg_list->regs,
> @@ -814,9 +817,6 @@ static int imx412_start_streaming(struct imx412 *imx412)
>   		return ret;
>   	}
> 
> -	/* Delay is required before streaming*/
> -	usleep_range(7400, 8000);
> -
>   	/* Start streaming */
>   	ret = imx412_write_reg(imx412, IMX412_REG_MODE_SELECT,
>   			       1, IMX412_MODE_STREAMING);
> --
> 2.34.1
> 
> 

This delay should go at the end of the operation that requires the delay 
not at the start of the streaming operation.

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.

---
bod