From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH - V2] Add NAND lock/unlock routines From: David Woodhouse To: Vimal Singh In-Reply-To: References: <1259915925.8673.9.camel@localhost> <1260178153.25784.28.camel@localhost> <1260185336.3047.0.camel@localhost> <1263372005.2917.21.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Fri, 26 Feb 2010 12:47:40 +0000 Message-ID: <1267188460.30247.10811.camel@macbook.infradead.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Linux MTD , dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2010-01-13 at 14:55 +0530, Vimal Singh wrote: > > >> @@ -2999,8 +3211,8 @@ int nand_scan_tail(struct mtd_info *mtd) > >> mtd->read_oob = nand_read_oob; > >> mtd->write_oob = nand_write_oob; > >> mtd->sync = nand_sync; > >> - mtd->lock = NULL; > >> - mtd->unlock = NULL; > >> + mtd->lock = nand_lock; > >> + mtd->unlock = nand_unlock; > > > > What makes you believe it is safe to assign these call-backs here? > > > > AFAICS, this means it will be done for all flashes. Do all of them > > support lock/unlock? I did not investigate this, but I think that > > probably not. > > OK. In that case I'll rather not do it here and do it in my specific > driver. Hm, I'm not sure that's the best approach. It's a function of the NAND chip, not the controller. We should detect the presence of the feature from the chip ID, if at all possible. I'm happy with your first two patches as part of a three-patch set though. Thanks. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation