[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1265389504.18186.4.camel@maxim-laptop>
Date: Fri, 05 Feb 2010 19:05:04 +0200
From: Maxim Levitsky <maximlevitsky@...il.com>
To: "stanley.miao" <stanley.miao@...driver.com>
Cc: David Woodhouse <dwmw2@...radead.org>,
Alex Dubov <oakad@...oo.com>,
Artem Bityutskiy <dedekind1@...il.com>,
joern <joern@...fs.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-mtd <linux-mtd@...ts.infradead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 13/17] MTD: export few functions from nand_base.c
On Fri, 2010-02-05 at 10:32 +0800, stanley.miao wrote:
> Maxim Levitsky wrote:
> > This exports:
> >
> > nand_do_read_oob
> > nand_do_write_oob
> >
>
> nand_do_read_oob and nand_do_write_oob can't be exported. They are internal
> functions in NAND subsystem. If you want use them, please use mtd->read_oob
> and mtd->write_oob.
>
> Stanley.
>
> > nand_get_device
> > nand_put_device
> >
> > This functions will be used to implement custom oob based
> > bad block handling in upcoming smartmedia common module
> >
Actually I don't like this patch ether.
The problem is that nand_erase_nand first takes the lock, and then calls
the ->block_bad.
I could make the ->block_bad always take the lock (and this will allow
using ->read_oob) by first checking that all erase blocks are good, and
then doing the erase.
This would change the behavior slightly (Now if you attempt to erase
several erase blocks and one of them is marked as bad, erase stops at
first bad block. With the change, erase will fail completely.
Is this ok?
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists