All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Aaron Sierra <asierra@xes-inc.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH RESEND] mtd: cfi: Support early CFI fixups
Date: Mon, 30 Apr 2018 16:49:36 +0200	[thread overview]
Message-ID: <20180430164936.5a7012c6@bbrezillon> (raw)
In-Reply-To: <370277171.65649.1525099125471.JavaMail.zimbra@xes-inc.com>

On Mon, 30 Apr 2018 09:38:45 -0500 (CDT)
Aaron Sierra <asierra@xes-inc.com> wrote:

> >> --- a/include/linux/mtd/cfi.h
> >> +++ b/include/linux/mtd/cfi.h
> >> @@ -353,6 +353,15 @@ void __xipram cfi_qry_mode_off(uint32_t base, struct
> >> map_info *map,
> >>  
> >>  struct cfi_extquery *cfi_read_pri(struct map_info *map, uint16_t adr, uint16_t
> >>  size,
> >>  			     const char* name);
> >> +
> >> +/* CFI fixup that can occur immediately after reading */  
> > 
> >					   ^ "after reading the ID" ?  
> 
> After reading the CFI structure out of the device, not just the ID. These
> fixups apply to the just-read, byte-swapped, in-memory representation of
> the CFI structure. Is more clarification necessary?

Yep, you should say after reading what. "after reading the CFI
structure out of the device" sounds good.

> 
> >> +struct cfi_early_fixup {
> >> +	uint16_t mfr;
> >> +	uint16_t id;
> >> +	void (*fixup)(struct cfi_private *cfi);
> >> +};
> >> +
> >> +/* CFI fixup that can only occur after MTD device exists */
> >>  struct cfi_fixup {
> >>  	uint16_t mfr;
> >>  	uint16_t id;
> >> @@ -380,6 +389,7 @@ struct cfi_fixup {
> >>  #define CFI_MFR_TOSHIBA		0x0098
> >>  #define CFI_MFR_WINBOND		0x00DA
> >>  
> >> +void cfi_early_fixup(struct cfi_private *cfi, struct cfi_early_fixup *fixups);  
> > 
> > Is cfi_early_fixup() intended to be used outside of cfi_probe.c? If
> > that's not the case, I'd recommend to keep the struct and function def
> > in cfi_probe.c.  
> 
> It is not, but since this is adding a second fixup mechanism for CFI, I
> thought there may be value in defining both of them in close proximity to
> each  other. That way anyone looking for available mechanisms would find
> both instead of only one or the other. Does that value outweigh it only
> being used in one file?

Well, we try to avoid exposing symbols when they're only used from the
file itself. If someone ever needs a similar mechanism in a different
file (cfi_jedec.c for example), we'll consider exposing it in
cfi_util.c/cfi.h, but that's not the case yet, so let's keep it private
to cfi_probe.c for now.

      reply	other threads:[~2018-04-30 14:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18  0:53 [PATCH RESEND] mtd: cfi: Support early CFI fixups Aaron Sierra
2018-04-30 10:39 ` Boris Brezillon
2018-04-30 14:38   ` Aaron Sierra
2018-04-30 14:49     ` Boris Brezillon [this message]

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=20180430164936.5a7012c6@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=asierra@xes-inc.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    /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.