From: Boris Brezillon <bbrezillon@kernel.org>
To: "Bean Huo (beanhuo)" <beanhuo@micron.com>
Cc: "richard@nod.at" <richard@nod.at>,
"boris.brezillon@bootlin.com" <boris.brezillon@bootlin.com>,
"Zoltan Szubbocsev \(zszubbocsev\)" <zszubbocsev@micron.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [EXT] Re: [RESEND PATCH V2 1/2] mtd: core: add erase preparation hook function pointer
Date: Thu, 24 Jan 2019 17:25:00 +0100 [thread overview]
Message-ID: <20190124172500.0cab6ce4@bbrezillon> (raw)
In-Reply-To: <BYASPR01MB003118C655FAC3F9A85D81DDDB9A0@BYASPR01MB0031.namprd08.prod.outlook.com>
On Thu, 24 Jan 2019 15:52:03 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> Hi, Boris
>
> >> >> struct nand_manufacturer_ops {
> >> >> void (*detect)(struct nand_chip *chip); @@ -49,6 +50,7 @@ struct
> >> >> nand_manufacturer_ops {
> >> >> void (*cleanup)(struct nand_chip *chip);
> >> >> void (*fixup_onfi_param_page)(struct nand_chip *chip,
> >> >> struct nand_onfi_params *p);
> >> >> + int (*erase_pre)(struct nand_chip *chip, int page);
> >> >
> >> >Let's move this hook to nand_chip and name it ->pre_erase() or
> >> >->erase_preparation().
> >> >
> >>
> >> Can you tell us more reasons why moves this hook to nand_chip?
> >
> >Because it's supposed to be a per-chip thing. I mean, not all of your chips have
> >this bug (at least I hope), so we want to only have a
> >->pre_erase() implementation when it's really needed. The manufacturer
> >specific ->init() hook will decide when it's appropriate to populate this -
> >>pre_erase pointer based on the NAND chip id (or the NAND chip model).
> >
>
> >> In my opinion, it is better to add this hook in nand_manufacturer_ops,
> >> since nand_manufacturer_ops Already exists in nand_chip, also this function is
> >related to specific NAND manufacturer.
> I still think, keep this hook in nand_manufacturer_ops is better, otherwise, just add one
> Function hook pointer in nand_chip, it is very weird.
>
And I tell you it's not. What's the point of adding a hook at the
nand_manufacturer_ops level (which is the same for all NAND chips
produced by a manufacturer) if you then have to check whether a
specific chip has anything to do inside the hook itself. When we added
nand_manufacturer and the associated ops it was created to address
chip detection and initialization, nothing more. Anything that is
needed at runtime and is manufacturer specific should have a hook/flag
in nand_chip.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-01-24 16:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 22:11 [RESEND PATCH V2 1/2] mtd: core: add erase preparation hook function pointer Bean Huo (beanhuo)
2019-01-18 22:42 ` Boris Brezillon
2019-01-20 15:25 ` Miquel Raynal
2019-01-21 10:33 ` [EXT] " Bean Huo (beanhuo)
2019-01-21 9:25 ` Bean Huo (beanhuo)
2019-01-21 9:32 ` Boris Brezillon
2019-01-24 15:52 ` Bean Huo (beanhuo)
2019-01-24 16:25 ` Boris Brezillon [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-02-25 15:48 Piotr Wojtaszczyk
2019-02-25 15:55 ` Bean Huo (beanhuo)
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=20190124172500.0cab6ce4@bbrezillon \
--to=bbrezillon@kernel.org \
--cc=beanhuo@micron.com \
--cc=boris.brezillon@bootlin.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tglx@linutronix.de \
--cc=zszubbocsev@micron.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.