On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote: > Remove SMMU shutdown callback since it seems to cause more > problems than benefits. With this callback, we need to make > sure that all clients/consumers of SMMU do not perform any > DMA activity once the SMMU is shutdown and translation is > disabled. In other words we need to add shutdown callbacks > for all those clients to make sure they do not perform any > DMA or else we see all kinds of weird crashes during reboot > or shutdown. This is clearly not scalable as the number of > clients of SMMU would vary across SoCs and we would need to > add shutdown callbacks to almost all drivers eventually. > This callback was added for kexec usecase where it was known > to cause memory corruptions when SMMU was not shutdown but > that does not directly relate to SMMU because the memory > corruption could be because of the client of SMMU which is > not shutdown properly before booting into new kernel. So in > that case, we need to identify the client of SMMU causing > the memory corruption and add appropriate shutdown callback > to the client rather than to the SMMU. > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> > --- > drivers/iommu/arm-smmu-v3.c | 6 ------ > drivers/iommu/arm-smmu.c | 6 ------ > 2 files changed, 12 deletions(-) This feels like a giant bodge to me and I think that any driver which continues to perform DMA after its ->shutdown() function has been invoked is buggy. Wouldn't that cause problems with kexec(), for example? There's a clear shutdown dependency ordering, where the clients of the SMMU need to shutdown before the SMMU itself, but that's not really the SMMU driver's problem to solve. Will
