On Thu, Feb 13, 2025 at 01:11:37PM +0100, Thomas Gleixner wrote: > On Sat, Feb 08 2025 at 01:02, Nicolin Chen wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > > The new function is used to take in a u64 MSI address and store it in the Assuming Nicolin moves the hunk as I suggested for patch 1 lets say: genirq/msi: Refactor iommu_dma_compose_msi_msg() The two step process to translate the MSI address involves two functions, iommu_dma_prepare_msi() and iommu_dma_compose_msi_msg(). Previously iommu_dma_compose_msi_msg() needed to be in the iommu layer as it had to dereference the opaque cookie pointer. The previous patch changed the cookie pointer into an integer so there is no longer any need for the iommu layer to be involved. Further, the call sites of iommu_dma_compose_msi_msg() all follow the same pattern of setting the MSI message address_hi/lo to non-translated and then immediately calling iommu_dma_compose_msi_msg(). Refactor iommu_dma_compose_msi_msg() into msi_msg_set_addr() which directly accepts the u64 version of the address and simplifies all the callers. Move the implementation to linux/msi.h since it has nothing to do with iommu. Aside from refactoring, this logically prepares for the next patch which allows multiple implementation options for iommu_dma_prepare_msi(). It does not make sense to have the iommu_dma_compose_msi_msg() in dma-iommu.c when it no longer provides the only iommu_dma_prepare_msi() implementation. Ok? > > -static inline void iommu_dma_compose_msi_msg(struct msi_desc *desc, > > - struct msi_msg *msg) > > +static inline void msi_msg_set_addr(struct msi_desc *desc, struct msi_msg *msg, > > + u64 msi_addr) > > No line break required. You have 100 characters available. Sure, I make alot of patches for places that only accept 80 :\ It is hard to keep track of everyones preferences. Thank you for having patience, it will get fixed - I think following a 100 char limit will resolve all of these notes. Thanks, Jason
