On 31/03/2021 12:10, Joakim Zhang wrote:

...

quoted

quoted

quoted

quoted

quoted

quoted

quoted

You mean one of your boards? Does other boards with STMMAC can
work

fine?

We have two devices with the STMMAC and one works OK and the
other

fails.

quoted

quoted

They are different generation of device and so there could be
some architectural differences which is causing this to only be
seen on one

device.

quoted

quoted

quoted

It's really strange, but I also don't know what architectural
differences could

affect this. Sorry.

I realised that for the board which fails after this change is made,
it has the IOMMU enabled. The other board does not at the moment
(although work is in progress to enable). If I add
'iommu.passthrough=1' to cmdline for the failing board, then it works
again. So in my case, the problem is linked to the IOMMU being enabled.

Does you platform enable the IOMMU?

Hi Jon,

There is no IOMMU hardware available on our boards. But why IOMMU would
affect it during suspend/resume, and no problem in normal mode?

One more add, I saw drivers/iommu/tegra-gart.c(not sure if is this) support suspend/resume, is it possible iommu resume back after stmmac?

This board is the tegra186-p2771-0000 (Jetson TX2) and uses the
arm,mmu-500 and not the above driver.

In answer to your question, resuming from suspend does work on this
board without your change. We have been testing suspend/resume now on
this board since Linux v5.8 and so we have the ability to bisect such
regressions. So it is clear to me that this is the change that caused
this, but I am not sure why.

Thanks
Jon

-- 
nvpublic