Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756816Ab1ESIgg (ORCPT ); Thu, 19 May 2011 04:36:36 -0400 Received: from mx0.aculab.com ([213.249.233.131]:37840 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1756054Ab1ESIge convert rfc822-to-8bit (ORCPT ); Thu, 19 May 2011 04:36:34 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic Date: Thu, 19 May 2011 09:35:19 +0100 Message-ID: In-Reply-To: <1305780360.2576.20.camel@mulgrave.site> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic thread-index: AcwV4IaA6VpZHGVaQdm8cLPpe983xAAHW3ug From: "David Laight" To: "James Bottomley" , "Hitoshi Mitake" Cc: "linux-arch" , "Prakash,Sathya" , "Roland Dreier" , "Desai, Kashyap" , "linux scsi dev" , "Matthew Wilcox" , "Moore, Eric" , "linux pci" , "linux powerpc dev" , "Milton Miller" , "linux kernel" , "Ingo Molnar" , , "Ingo Molnar" , "Sam Ravnborg" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1487 Lines: 37 > The specific mpt2sas problem is that if we write a 64 bit register non > atomically, we can't allow any interleaving writes for any other region > on the chip, otherwise the HW will take the write as complete in the 64 > bit register and latch the wrong value. The only way to achieve that > given the semantics of writeq is a global static spinlock. That sounds like very specific and slightly dodgy hardware. You don't say what the scope of 'region on the chip' is, but it looks like you need to disable ALL writes to the memory area between the first and second writes of the 64bit value and not just those coming from writeq(). I don't see how this can possibly be done by normal mutexing around the writeq() sequence, surely you need to lock the bus between the two transfers. Even dma writes would be a problem. The only way I can think to stop other cpus doing writes is to use IPIs for force them into a busy wait loop. All rather reminds me of a PCI slave that got things horribly wrong when a read was done while a write was still 'posted', or a 2nd master did a cycle did a read while a read rerun sequence was still in progress. (required a mutex and dummy cycles). At least than one wqs confined to one driver. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/