Hi Robin, On Wed, Dec 14, 2022 at 08:33:10PM +0000, Robin Murphy wrote: > > Does looking at the CTTW bit make any sense for MMU-500? > > In general, yes. The result above does imply that NXP have inadvertently set > cfg_cttw wrong. For the avoidance of doubt, here's another MMU-500 showing > SMMU_IDR0.CTTW set: > > [ 3.014972] arm-smmu arm-smmu.0.auto: probing hardware configuration... > [ 3.014974] arm-smmu arm-smmu.0.auto: SMMUv2 with: > [ 3.014976] arm-smmu arm-smmu.0.auto: stage 2 translation > [ 3.014977] arm-smmu arm-smmu.0.auto: coherent table walk > [ 3.014979] arm-smmu arm-smmu.0.auto: stream matching with 128 register groups > [ 3.014981] arm-smmu arm-smmu.0.auto: 128 context banks (128 stage-2 only) > [ 3.014984] arm-smmu arm-smmu.0.auto: Supported page sizes: 0x60211000 > [ 3.014986] arm-smmu arm-smmu.0.auto: Stage-2: 48-bit IPA -> 48-bit PA Thanks for the explanations and the patch you've sent separately. I have a side question, why is the dev_name() of your SMMU set to "arm-smmu.0.auto" (determined by PLATFORM_DEVID_AUTO if I'm not mistaken)? I'm asking because I would like to study the mechanism through which your SMMU platform device get probed, to make sure that it's not possible, during shutdown, for both platform_driver :: shutdown() and platform_driver :: remove() methods to get called by the driver core. This is generally not disallowed, and even possible if the entity who registers these platform devices has its ->shutdown() method pointing at ->remove().
