Re: [PATCH v11 06/11] iommu/arm-smmu-v3: Add ARM_SMMU_OPT_KDUMP_ADOPT for kdump kernel

[John Garry]

On 10/21/26 18:50, Nicolin Chen wrote:
> > Earlier the event queue feature flag was unset - should we still be going
> > with that decision?
> Yes. EVETQ and PRIQ are disabled in kdump mode, even today:
>
> 	if (is_kdump_kernel())
> 		enables &= ~(CR0_EVTQEN | CR0_PRIQEN);

ok

> > Did you consider to just re-probe the SMMU driver without trying this
> > adoption method when problems occur?
> You mean -EPROBE_DEFER? 

Yes, and it should play ok with the IOMMU probe ordering "replay" mechanism.

> I don't think it would be cleaner..
>
> And it would retry the "adopt" mode again? 

No, that's the point. Currently you first try the adopt mechanism; if a 
problem is found there, you fall back to the normal full reset. My idea 
is that if a problem is found with the adopt mechanism, you just 
re-probe with the normal full reset method, so that you don't need to 
undo some adopt work during the probe.

> This is a per-smmu
> option, no global flag. When it re-probes, smmu pointer would
> be reallocated. So it won't disable the adopt path during the
> re-probe.
>
> Here, we just have three lines to fallback immediately, which
> is much less expensive than a re-probe, IMHO.

ok, if you think so.

BTW, on another point, nobody checks the specific error code returned 
value from arm_smmu_kdump_adopt_strtab(), so you can consider making it 
return a bool.