From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Roger Quadros <rogerq@ti.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
<linux-mtd@lists.infradead.org>,
Richard Weinberger <richard@nod.at>, <linux-mips@linux-mips.org>,
Krzysztof Kozlowski <k.kozlowski@samsung.com>,
Harvey Hunt <harvey.hunt@imgtec.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Stefan Agner <stefan@agner.ch>, <linux-sunxi@googlegroups.com>,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
punnaiah choudary kalluri <punnaia@xilinx.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
<devel@driverdev.osuosl.org>,
Archit Taneja <architt@codeaurora.org>,
<linux-samsung-soc@vger.kernel.org>,
Kamal Dasu <kdasu.kdev@gmail.com>,
Josh Wu <rainyfeeling@outlook.com>, Chen-Yu Tsai <wens@csie.org>,
Kukjin Kim <kgene@kernel.org>,
<bcm-kernel-feedback-list@broadcom.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Huang Shijie <shijie.huang@arm.com>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Han Xu <b45815@freescale.com>,
<linux-arm-kernel@lists.infradead.org>,
Priit Laes <plaes@plaes.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
<linux-kernel@vger.kernel.org>,
Ralf Baechle <ralf@linux-mips.org>,
Wenyou Yang <wenyou.yang@atmel.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
<linux-api@vger.kernel.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Daniel Mack <daniel@zonque.org>
Subject: Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
Date: Mon, 18 Apr 2016 17:05:18 +0200 [thread overview]
Message-ID: <20160418170518.363f732d@bbrezillon> (raw)
In-Reply-To: <5714F011.5080409@ti.com>
On Mon, 18 Apr 2016 17:32:49 +0300
Roger Quadros <rogerq@ti.com> wrote:
> Boris,
>
> On 30/03/16 19:14, Boris Brezillon wrote:
> > Implementing the mtd_ooblayout_ops interface is the new way of exposing
> > ECC/OOB layout to MTD users.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > drivers/mtd/nand/omap2.c | 194 +++++++++++++++++++++++++++--------------------
> > 1 file changed, 113 insertions(+), 81 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index 4ebf16b..bca154a 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -169,8 +169,6 @@ struct omap_nand_info {
> > u_char *buf;
> > int buf_len;
> > struct gpmc_nand_regs reg;
> > - /* generated at runtime depending on ECC algorithm and layout selected */
> > - struct nand_ecclayout oobinfo;
> > /* fields specific for BCHx_HW ECC scheme */
> > struct device *elm_dev;
> > struct device_node *of_node;
> > @@ -1639,19 +1637,108 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
> > return true;
> > }
> >
> > +static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
> > + struct mtd_oob_region *oobregion)
> > +{
> > + struct nand_chip *chip = mtd_to_nand(mtd);
> > + int off = chip->options & NAND_BUSWIDTH_16 ?
> > + BADBLOCK_MARKER_LENGTH : 1;
>
> IMO "off = 1" is valid only for OMAP_ECC_HAM1_CODE_HW and 8-bit NAND.
> For all other layouts it is always set to BADBLOCK_MARKER_LENGTH.
Indeed.
[...]
> > - /* all OOB bytes from oobfree->offset till end off OOB are free */
> > - ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
> > /* check if NAND device's OOB is enough to store ECC signatures */
> > - if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
> > + min_oobbytes = (oobbytes_per_step *
> > + (mtd->writesize / nand_chip->ecc.size)) +
> > + (nand_chip->options & NAND_BUSWIDTH_16 ?
> > + BADBLOCK_MARKER_LENGTH : 1);
>
> would it affect this as well?
And here as well.
I've generated a patch (see below) fixing those problems.
>
> > + if (mtd->oobsize < min_oobbytes) {
> > dev_err(&info->pdev->dev,
> > "not enough OOB bytes required = %d, available=%d\n",
> > - ecclayout->eccbytes, mtd->oobsize);
> > + min_oobbytes, mtd->oobsize);
> > err = -EINVAL;
> > goto return_error;
> > }
> >
>
> I will need to test this change with all possible configurations.
> The number of configurations on OMAP is a bit overwhelming :(.
Sorry about that, but at least now I have someone who can test it :).
Thanks,
Boris
--->8---
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 9b96f56..07d4039 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1640,9 +1640,13 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
{
- struct nand_chip *chip = mtd_to_nand(mtd);
- int off = chip->options & NAND_BUSWIDTH_16 ?
- BADBLOCK_MARKER_LENGTH : 1;
+ struct omap_nand_info *info = mtd_to_omap(mtd);
+ struct nand_chip *chip = &info->nand;
+ int off = BADBLOCK_MARKER_LENGTH;
+
+ if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
+ !(chip->options & NAND_BUSWIDTH_16))
+ off = 1;
if (section)
return -ERANGE;
@@ -1656,9 +1660,13 @@ static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
static int omap_ooblayout_free(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
{
- struct nand_chip *chip = mtd_to_nand(mtd);
- int off = chip->options & NAND_BUSWIDTH_16 ?
- BADBLOCK_MARKER_LENGTH : 1;
+ struct omap_nand_info *info = mtd_to_omap(mtd);
+ struct nand_chip *chip = &info->nand;
+ int off = BADBLOCK_MARKER_LENGTH;
+
+ if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
+ !(chip->options & NAND_BUSWIDTH_16))
+ off = 1;
if (section)
return -ERANGE;
@@ -1682,8 +1690,7 @@ static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
{
struct nand_chip *chip = mtd_to_nand(mtd);
- int off = chip->options & NAND_BUSWIDTH_16 ?
- BADBLOCK_MARKER_LENGTH : 1;
+ int off = BADBLOCK_MARKER_LENGTH;
if (section >= chip->ecc.steps)
return -ERANGE;
@@ -1702,8 +1709,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
{
struct nand_chip *chip = mtd_to_nand(mtd);
- int off = chip->options & NAND_BUSWIDTH_16 ?
- BADBLOCK_MARKER_LENGTH : 1;
+ int off = BADBLOCK_MARKER_LENGTH;
if (section)
return -ERANGE;
@@ -1737,7 +1743,7 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
- int min_oobbytes;
+ int min_oobbytes = BADBLOCK_MARKER_LENGTH;
int oobbytes_per_step;
pdata = dev_get_platdata(&pdev->dev);
@@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->ecc.correct = omap_correct_data;
mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
oobbytes_per_step = nand_chip->ecc.bytes;
+
+ if (nand_chip->options & NAND_BUSWIDTH_16)
+ min_oobbytes = 1;
break;
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
@@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device *pdev)
}
/* check if NAND device's OOB is enough to store ECC signatures */
- min_oobbytes = (oobbytes_per_step *
- (mtd->writesize / nand_chip->ecc.size)) +
- (nand_chip->options & NAND_BUSWIDTH_16 ?
- BADBLOCK_MARKER_LENGTH : 1);
+ min_oobbytes += (oobbytes_per_step *
+ (mtd->writesize / nand_chip->ecc.size));
if (mtd->oobsize < min_oobbytes) {
dev_err(&info->pdev->dev,
"not enough OOB bytes required = %d, available=%d\n",
next prev parent reply other threads:[~2016-04-18 15:05 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 16:14 [PATCH v5 00/52] mtd: rework ECC layout definition Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 01/50] mtd: add mtd_ooblayout_xxx() helper functions Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 02/50] mtd: use mtd_ooblayout_xxx() helpers where appropriate Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 03/50] mtd: nand: core: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 04/50] mtd: nand: atmel: " Boris Brezillon
2016-04-13 14:40 ` Boris Brezillon
2016-04-13 15:28 ` Nicolas Ferre
2016-04-13 15:53 ` [PATCH v6 " Boris Brezillon
2016-04-13 16:05 ` Nicolas Ferre
2016-03-30 16:14 ` [PATCH v5 05/50] mtd: nand: fsl_ifc: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 06/50] mtd: nand: gpmi: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 07/50] mtd: nand: lpc32xx: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 08/50] mtd: nand: omap2: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 09/50] mtd: nand: qcom: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 10/50] mtd: onenand: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 11/50] mtd: add mtd_set_ecclayout() helper function Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 12/50] mtd: use mtd_set_ecclayout() where appropriate Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 13/50] mtd: nand: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 14/50] mtd: onenand: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 15/50] mtd: docg3: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 16/50] mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 17/50] mtd: docg3: switch to mtd_ooblayout_ops Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 18/50] mtd: nand: implement the default mtd_ooblayout_ops Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 19/50] mtd: nand: bch: switch to mtd_ooblayout_ops Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 20/50] mtd: nand: sharpsl: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 21/50] mtd: nand: jz4740: " Boris Brezillon
2016-03-30 19:17 ` Lars-Peter Clausen
2016-03-30 16:14 ` [PATCH v5 22/50] mtd: nand: atmel: " Boris Brezillon
2016-04-13 14:41 ` Boris Brezillon
2016-04-13 15:15 ` Nicolas Ferre
2016-03-30 16:14 ` [PATCH v5 23/50] mtd: nand: bf5xx: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 24/50] mtd: nand: brcm: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 25/50] mtd: nand: cafe: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 26/50] mtd: nand: davinci: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 27/50] mtd: nand: denali: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 28/50] mtd: nand: diskonchip: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 29/50] mtd: nand: docg4: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 30/50] mtd: nand: fsl_elbc: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 31/50] mtd: nand: fsl_ifc: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 32/50] mtd: nand: fsmc: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 33/50] mtd: nand: fsmc: get rid of the fsmc_nand_eccplace struct Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 34/50] mtd: nand: gpmi: switch to mtd_ooblayout_ops Boris Brezillon
[not found] ` <DB5PR0401MB1845A6EE26FD2734CDBBE20F97950@DB5PR0401MB1845.eurprd04.prod.outlook.com>
2016-04-12 22:31 ` Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 35/50] mtd: nand: hisi504: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 36/50] mtd: nand: jz4780: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 37/50] mtd: nand: lpc32xx: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 38/50] mtd: nand: mxc: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 39/50] mtd: nand: omap2: " Boris Brezillon
2016-04-18 14:32 ` Roger Quadros
2016-04-18 15:05 ` Boris Brezillon [this message]
2016-04-19 10:28 ` Roger Quadros
2016-04-19 11:22 ` Boris Brezillon
2016-04-19 12:30 ` Roger Quadros
2016-04-19 12:41 ` Boris Brezillon
2016-04-19 12:49 ` Roger Quadros
2016-03-30 16:14 ` [PATCH v5 40/50] mtd: nand: pxa3xx: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 41/50] mtd: nand: s3c2410: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 42/50] mtd: nand: sh_flctl: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 43/50] mtd: nand: sm_common: " Boris Brezillon
2016-03-30 16:14 ` [PATCH v5 44/50] mtd: nand: sunxi: " Boris Brezillon
2016-03-30 16:15 ` [PATCH v5 45/50] mtd: nand: vf610: " Boris Brezillon
2016-04-01 16:38 ` Stefan Agner
2016-03-30 16:15 ` [PATCH v5 46/50] mtd: nand: qcom: " Boris Brezillon
2016-03-30 16:15 ` [PATCH v5 47/50] mtd: onenand: " Boris Brezillon
2016-03-30 16:15 ` [PATCH v5 48/50] staging: mt29f_spinand: " Boris Brezillon
2016-03-30 16:15 ` [PATCH v5 49/50] mtd: nand: kill the ecc->layout field Boris Brezillon
2016-03-30 16:15 ` [PATCH v5 50/50] mtd: kill the nand_ecclayout struct Boris Brezillon
2016-03-30 16:18 ` [PATCH v5 00/52] mtd: rework ECC layout definition Boris Brezillon
2016-04-13 16:14 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160418170518.363f732d@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=architt@codeaurora.org \
--cc=b45815@freescale.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=daniel@zonque.org \
--cc=devel@driverdev.osuosl.org \
--cc=dwmw2@infradead.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gregkh@linuxfoundation.org \
--cc=haojian.zhuang@gmail.com \
--cc=harvey.hunt@imgtec.com \
--cc=k.kozlowski@samsung.com \
--cc=kdasu.kdev@gmail.com \
--cc=kgene@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=maxime.ripard@free-electrons.com \
--cc=nicolas.ferre@atmel.com \
--cc=plaes@plaes.org \
--cc=plagnioj@jcrosoft.com \
--cc=punnaia@xilinx.com \
--cc=rainyfeeling@outlook.com \
--cc=ralf@linux-mips.org \
--cc=richard@nod.at \
--cc=robert.jarzmik@free.fr \
--cc=rogerq@ti.com \
--cc=shijie.huang@arm.com \
--cc=stefan@agner.ch \
--cc=wens@csie.org \
--cc=wenyou.yang@atmel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).