From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f179.google.com (mail-wy0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 349CD1007D5 for ; Thu, 19 May 2011 14:08:44 +1000 (EST) Received: by wyg36 with SMTP id 36so1874623wyg.38 for ; Wed, 18 May 2011 21:08:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4565AEA676113A449269C2F3A549520F80BE7F37@cosmail03.lsi.com> References: <20110504115324.GE17855@lsi.com> <1305616571.6008.23.camel@mulgrave.site> <20110518041551.GL15227@parisc-linux.org> <1305692584.2580.3.camel@mulgrave.site> <1305702010.2781.33.camel@pasglop> <4565AEA676113A449269C2F3A549520F80B66280@cosmail03.lsi.com> <4565AEA676113A449269C2F3A549520F80BE7F37@cosmail03.lsi.com> Date: Thu, 19 May 2011 13:08:38 +0900 Message-ID: Subject: Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic From: Hitoshi Mitake To: "Moore, Eric" Content-Type: text/plain; charset=ISO-8859-1 Cc: linux-arch , "Prakash, Sathya" , "Desai, Kashyap" , linux scsi dev , Matthew Wilcox , linux powerpc dev , Milton Miller , linux kernel , James Bottomley , Ingo Molnar , "paulus@samba.org" , linux pci , Ingo Molnar , Sam Ravnborg List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, May 19, 2011 at 04:11, Moore, Eric wrote: > On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote: >> Ingo I would propose the following commits added in 2.6.29 be reverted. >> I think the current concensus is drivers must know if the writeq is >> not atomic so they can provide their own locking or other workaround. >> > > > Exactly. > The original motivation of preparing common readq/writeq is that letting each driver have their own readq/writeq is bad for maintenance of source code. But if you really dislike them, there might be two solutions: 1. changing the name of readq/writeq to readq_nonatomic/writeq_nonatomic 2. adding new C file to somewhere and defining spinlock for them. With spin_lock_irqsave() and spin_unlock_irqrestore() on the spinlock, readq/writeq can be atomic. How do you think about them? If you cannot agree with the above two solutions, I'll agree with reverting them. -- Hitoshi Mitake h.mitake@gmail.com