> > > Cc: stable@xxxxxxxxxx > > > Signed-off-by: Kashyap Desai <kashyap.desai@xxxxxxx> > > > --- > > > diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c > > > index efa0255..5778334 100644 > > > --- a/drivers/scsi/mpt2sas/mpt2sas_base.c > > > +++ b/drivers/scsi/mpt2sas/mpt2sas_base.c > > > @@ -1558,7 +1558,6 @@ mpt2sas_base_free_smid(struct MPT2SAS_ADAPTER *ioc, u16 smid) > > > * care of 32 bit environment where its not quarenteed to send the entire word > > > * in one transfer. > > > */ > > > -#ifndef writeq > > > > Why not make this #ifndef CONFIG_64BIT? You know that all 64 bit > > systems have writeq implemented correctly; you suspect 32 bit systems > > don't. > > > > James > > > > James, This issue was observed on PPC64 system. So what you have > suggested will not solve this issue. > > If we are sure that writeq() is atomic across all architecture, we > can use it safely. As we have seen issue on ppc64, we are not > confident to use > > "writeq" call. > > So have you told the powerpc people that they have a broken writeq? > And why do you obfuscate your report by talking about i386 when it's > really about powerpc64? Well, our writeq isn't supposed to be broken :-) It's defined as an std instruction (and "ld" for readq) so that's perfectly atomic ... provided your access is aligned. Is it ? Cheers, Be -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
