| Message ID | 1386680236-21698-3-git-send-email-ezequiel.garcia@free-electrons.com |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Dec 10, 2013 at 09:57:16AM -0300, Ezequiel Garcia wrote: ... > This fixes a current bug that can be reproduced on PXA boards by writing > blank (all 0xff'ed) to a page: ... This patch doesn't apply to 3.13-rc1, so how am I supposed to send it for the 3.13 cycle? It seems that you based this on l2-mtd.git, which has code queued for 3.14. Please rebase on linux-mtd.git, give it a test, and resend it so I can get it out soon. Thanks, Brian
On Thu, Dec 12, 2013 at 12:35:22PM -0800, Brian Norris wrote: > On Tue, Dec 10, 2013 at 09:57:16AM -0300, Ezequiel Garcia wrote: > ... > > This fixes a current bug that can be reproduced on PXA boards by writing > > blank (all 0xff'ed) to a page: > ... > > This patch doesn't apply to 3.13-rc1, so how am I supposed to send it > for the 3.13 cycle? It seems that you based this on l2-mtd.git, which > has code queued for 3.14. > Ugh... crap!! This patch is *not* for v3.13, and I've no idea why I said so in the first place. The bug this patch fixes was introduced with the device ready completion mess in: commit 8524028ee90d177580b496e2740efd673f8e7910 Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Date: Thu Nov 14 18:25:26 2013 -0300 mtd: nand: pxa3xx: Use a completion to signal device ready So, this fix goes on top of l2-mtd.git (for v3.14), while the ones appropriate for v3.13 are: http://patchwork.ozlabs.org/patch/299645/ and http://patchwork.ozlabs.org/patch/299202/ Can you pick them, or do you prefer me to resend everything?
On Thu, Dec 12, 2013 at 07:38:31PM -0300, Ezequiel Garcia wrote: > On Thu, Dec 12, 2013 at 12:35:22PM -0800, Brian Norris wrote: > > On Tue, Dec 10, 2013 at 09:57:16AM -0300, Ezequiel Garcia wrote: > > ... > > > This fixes a current bug that can be reproduced on PXA boards by writing > > > blank (all 0xff'ed) to a page: > > ... > > > > This patch doesn't apply to 3.13-rc1, so how am I supposed to send it > > for the 3.13 cycle? It seems that you based this on l2-mtd.git, which > > has code queued for 3.14. > > > > Ugh... crap!! This patch is *not* for v3.13, and I've no idea why I said so in > the first place. The bug this patch fixes was introduced with the device ready > completion mess in: > > commit 8524028ee90d177580b496e2740efd673f8e7910 > Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > Date: Thu Nov 14 18:25:26 2013 -0300 > > mtd: nand: pxa3xx: Use a completion to signal device ready I see :) And yes, that makes sense. > So, this fix goes on top of l2-mtd.git (for v3.14), while the ones appropriate > for v3.13 are: > > http://patchwork.ozlabs.org/patch/299645/ > > and > > http://patchwork.ozlabs.org/patch/299202/ > > Can you pick them, or do you prefer me to resend everything? Got 'em already. Will tag them for upstream within the day, hopefully. Please resubmit the remaining patch (for 3.14, against l2-mtd.git) separately once I get everything else queued up properly, and we can work from there. Thanks, Brian
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index 4cdc134..53a1862 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -694,6 +694,7 @@ static void prepare_start_command(struct pxa3xx_nand_info *info, int command) info->retcode = ERR_NONE; info->ecc_err_cnt = 0; info->ndcb3 = 0; + info->need_wait = 0; switch (command) { case NAND_CMD_READ0:
Currently the driver assumes all commands will eventually trigger a RnB transition, and thus a "device is ready" IRQ. This assumption means that on every issued command, the dev_ready completion handler is init'ed and the need_wait flag is set. However this is incorrect: some commands (such as NAND_CMD_STATUS) don't make the device 'busy' and thus a RnB transition never occurs. Given, the NAND core never calls waitfunc() after such commands, this is not a problem. Therefore, it's possible to only clear the need_wait flag on every command that is started. This fixes a current bug that can be reproduced on PXA boards by writing blank (all 0xff'ed) to a page: 1. The kernel issues NAND_CMD_STATUS and sets need_wait=1. The flag won't be cleared for this command since no RnB transition is involved. 2. NAND_CMD_PAGEPROG is issued but since the data is blank, the driver decides not to execute the command (and no IRQ activity is involved). 3. The NAND core calls waitfunc() and waits for the dev_ready completion, which will never end since the device _is_ already ready. Tested-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> --- drivers/mtd/nand/pxa3xx_nand.c | 1 + 1 file changed, 1 insertion(+)