On Thu, 2018-05-24 at 17:31 +0200, Tomas Henzl wrote: > 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. So it's the latter ... but my point is that that should be fixed rather than adding barriers to what should be a corner case work around. James
