Re: [PATCH] soc: fsl: qe: Fix potential NULL pointer dereference inqe_reset()

[Christophe Leroy (CS GROUP)]

Hi,

Le 16/03/2026 à 04:28, 未君 a écrit :
> 	
> Vous n’obtenez pas souvent d’e-mail à partir de 1742789905@xxxxxx. 
> Pourquoi c’est important <https://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Hi,
>
> Thank you for the detailed review. You are completely right.
>
> My commit message was confusing, and returning early in qe_reset() just 
> shifts the NULL pointer dereference to the dependent drivers later on, 
> without actually fixing the root cause.
>
> To achieve what you suggested ("if qe_immr remap fails, all drivers 
> depending on it don't get probed"), I plan to do the following in the v2 
> patch:
>
> 1. Change the return type of qe_reset() from `void` to `int`.
> 2. Return `-ENOMEM` if the ioremap() fails.
> 3. Update the callers of qe_reset() (e.g., qe_probe() and other board- 
> specific setup functions) to check this return value. If qe_reset() 
> fails, the callers will abort their initialization/probing, which will 
> properly prevent the child devices from being probed.
>
> Does this approach sound correct to you? If so, I will prepare and 
> submit the v2 patch accordingly.

Well, it would probably work but is it worth it ?

If the board is already unable to get a few bytes of memory that early 
in the boot process it is unlikely that it will be able to do much more 
work.

Wouldn't it be good enough to just panic() when ioremap() fails, similar 
to what happens when qe_sdma_init() fails, see 
https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/soc/fsl/qe/qe.c#L101

Christophe