lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 30 Jan 2015 08:47:29 -0300
From:	Ezequiel Garcia <ezequiel.garcia@...tec.com>
To:	"Peter Pan 潘栋 (peterpandong)" 
	<peterpandong@...ron.com>,
	"Qi Wang 王起 (qiwang)" 
	<qiwang@...ron.com>, Brian Norris <computersforpeace@...il.com>
CC:	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"Frank Liu 刘群 (frankliu)" 
	<frankliu@...ron.com>,
	"Melanie Zhang 张燕 (melaniezhang)" <melaniezhang@...ron.com>,
	James Hartley <james.hartley@...tec.com>,
	"Andrew Bresticker" <abrestic@...omium.org>
Subject: Re: [PATCH 0/3] An alternative to SPI NAND



On 01/29/2015 09:57 PM, Peter Pan 潘栋 (peterpandong) wrote:
[..]
> 
> Currently, we are working on sharing the bbt code. I think your and Brain's suggestion
> will be very helpful.
> 
> There are two options. We can put struct nand_bbt pointer in either nand_chip
> or mtd_info structure.

I'm sorry, you lost me here. Do you mean struct nand_bbt_descr ?

> If put nand_bbt in nand_chip, we need to change the

I thought the plan was NOT to base spi-nand on nand, so you can't put
this in nand_chip, can you?

Also: After looking at the nand_bbt.c file, I'm wondering how promising
is to separate it from NAND. It seems the BBT code is quite attached to
NAND!

Are you planning to do this in just one patch? Maybe it's better to
start simple and prepare small patches that gradually make the
nand_base.c and nand_bbt.c files less dependent.

For instance, you can get rid of the memory release in a first patch:

        /* Free bad block table memory */
        kfree(chip->bbt);
        if (!(chip->options & NAND_OWN_BUFFERS))
                kfree(chip->buffers);

        /* Free bad block descriptor memory */
        if (chip->badblock_pattern && chip->badblock_pattern->options
                        & NAND_BBT_DYNAMICSTRUCT)
                kfree(chip->badblock_pattern);

by moving it to some nand_bbt_release() function.

I might be pushing some patches to do this, as I think it can be useful
in general to clean this code.
-- 
Ezequiel
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ