Hi,

Le 16/03/2026 à 04:28, 未君 a écrit :

	
Vous n’obtenez pas souvent d’e-mail à partir de 1742789905@qq.com. 
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