On Wed, Jul 22, 2020 at 10:31:28AM -0700, Dey, Megha wrote: > > > I didn't notice any of this in the patch series? What is the calling > > > context for the platform_msi_ops ? I think I already mentioned that > > > ideally we'd need blocking/sleeping. The big selling point is that IMS > > > allows this data to move off-chip, which means accessing it is no > > > longer just an atomic write to some on-chip memory. > > > > > > These details should be documented in the comment on top of > > > platform_msi_ops > > so the platform_msi_ops care called from the same context as the existing > msi_ops for instance, we are not adding anything new. I think the above > comment is a little misleading I will remove it next time around. If it is true that all calls are under driver control then I think it would be good to document that. I actually don't know off hand if mask/unmask are restricted like that As this is a op a driver has to implement vs the arch it probably need a bit more hand holding. > Also, I thought even the current write to on-chip memory is not > atomic.. The writel to the MSI-X table in MMIO memory is 'atomic' Jason
