public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Peter Pan <peterpandong@micron.com>
Cc: <richard@nod.at>, <computersforpeace@gmail.com>,
	<arnaud.mouiche@gmail.com>, <thomas.petazzoni@free-electrons.com>,
	<marex@denx.de>, <cyrille.pitchen@atmel.com>,
	<linux-mtd@lists.infradead.org>, <peterpansjtu@gmail.com>,
	<linshunquan1@hisilicon.com>
Subject: Re: [PATCH v5 1/6] nand: spi: add basic blocks for infrastructure
Date: Mon, 17 Apr 2017 22:53:31 +0200	[thread overview]
Message-ID: <20170417225331.4f5c53fd@bbrezillon> (raw)
In-Reply-To: <1491810713-27795-2-git-send-email-peterpandong@micron.com>

On Mon, 10 Apr 2017 15:51:48 +0800
Peter Pan <peterpandong@micron.com> wrote:

> +
> +struct spinand_ecc_engine_ops {
> +	void (*get_ecc_status)(struct spinand_device *chip,
> +			       unsigned int status, unsigned int *corrected,
> +			       unsigned int *ecc_errors);

No need to specify ecc, we're interacting with an ECC engine, so I
guess it's already assumed.

	void (*get_stats)(struct spinand_device *chip,
			  unsigned int status,
			  unsigned int *corrected,
			  unsigned int *errors);

BTW, we probably need max_bitflips, unless corrected already contains
this information, in which case it should probably be clarified (better
name + kernel doc).

> +	void (*disable_ecc)(struct spinand_device *chip);
> +	void (*enable_ecc)(struct spinand_device *chip);

Ditto, just enable()/disable().

> +};
> +
> +enum spinand_ecc_type {
> +	SPINAND_ECC_ONDIE,
> +	SPINAND_ECC_HW,
> +};

Probably something we should extract from rawnand.h and move to nand.h
so that we can share the same definition (until we also share the ECC
engine interface).

> +
> +struct spinand_ecc_engine {
> +	u32 strength;
> +	u32 steps;
> +	const struct spinand_ecc_engine_ops *ops;
> +};

The same ECC engine engine can possibly be used with different NAND
devices. So what you're describing here is more an ECC engine user than
the ECC engine itself.

Ideally we should have:

struct nand_ecc_engine {
	/* Some info describing engine caps. */
	const struct spinand_ecc_engine_ops *ops;
};

struct nand_ecc_engine_user {
	u32 strength;
	u32 steps;
	struct nand_ecc_engine *engine;
};

Anyway, I think we can keep that for later.

BTW, would you mind keeping all that is ECC related outside of this
initial series, or at least, add it in separate patches?

  parent reply	other threads:[~2017-04-17 20:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10  7:51 [PATCH v5 0/6] Introduction to SPI NAND framework Peter Pan
2017-04-10  7:51 ` [PATCH v5 1/6] nand: spi: add basic blocks for infrastructure Peter Pan
2017-04-10  8:28   ` Boris Brezillon
2017-04-14 13:18   ` Marek Vasut
2017-04-17 20:34   ` Boris Brezillon
2017-04-17 20:53   ` Boris Brezillon [this message]
2017-04-18  7:29   ` Boris Brezillon
2017-04-10  7:51 ` [PATCH v5 2/6] nand: spi: add basic operations support Peter Pan
2017-04-17 21:05   ` Boris Brezillon
2017-04-10  7:51 ` [PATCH v5 3/6] nand: spi: Add bad block support Peter Pan
2017-04-17 21:23   ` Boris Brezillon
2017-04-10  7:51 ` [PATCH v5 4/6] nand: spi: add Micron spi nand support Peter Pan
2017-04-14 13:23   ` Marek Vasut
2017-04-18  7:20   ` Boris Brezillon
2017-04-10  7:51 ` [PATCH v5 5/6] nand: spi: Add generic SPI controller support Peter Pan
2017-04-14 13:26   ` Marek Vasut
2017-04-18  7:41     ` Boris Brezillon
2017-04-18  7:26   ` Boris Brezillon
2017-04-10  7:51 ` [PATCH v5 6/6] MAINTAINERS: Add SPI NAND entry Peter Pan
2017-04-18  7:42 ` [PATCH v5 0/6] Introduction to SPI NAND framework Boris Brezillon
2017-04-19  6:01   ` Peter Pan

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=20170417225331.4f5c53fd@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=arnaud.mouiche@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=linshunquan1@hisilicon.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    --cc=peterpandong@micron.com \
    --cc=peterpansjtu@gmail.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@free-electrons.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