On 05/24/2018 05:19 PM, James Bottomley wrote: > On Thu, 2018-05-24 at 17:12 +0200, Tomas Henzl wrote: >> A barrier should be added to ensure proper ordering of memory mapped >> writes. >> >> Signed-off-by: Tomas Henzl <thenzl@xxxxxxxxxx> >> --- >> drivers/scsi/mpt3sas/mpt3sas_base.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c >> b/drivers/scsi/mpt3sas/mpt3sas_base.c >> index bf04fa90f..569392d0d 100644 >> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c >> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c >> @@ -3348,6 +3348,7 @@ _base_mpi_ep_writeq(__u64 b, volatile void >> __iomem *addr, >> spin_lock_irqsave(writeq_lock, flags); >> writel((u32)(data_out), addr); >> writel((u32)(data_out >> 32), (addr + 4)); >> + mmiowb(); >> spin_unlock_irqrestore(writeq_lock, flags); >> } > I thought, assuming mpt3sas has this right, that this construction is > only used on 32 bit platforms that don't have a writeq instruction? I > don't believe there's any overlap with the NUMA systems that need io > and memory domain synchronization, so either this problem is purely > theoretical or mpt3sas doesn't have the use of writeq correct and if > the latter case it should be fixed correctly. The _base_mpi_ep_writeq is used regardless to 32/64 bit arch for example in _base_put_smid_mpi_ep_scsi_io, mpt3sas_base_put_smid_hi_priority and so on. > > James >
