mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <miquel.raynal@bootlin.com>, <richard@nod.at>,
	<vigneshr@ti.com>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH v2 4/4] mtd: spi-nor: sfdp: Keep SFDP definitions private
Date: Mon, 4 Apr 2022 06:19:22 +0000	[thread overview]
Message-ID: <ed093fa5-b514-b0a6-166f-ecf117582b0b@microchip.com> (raw)
In-Reply-To: <20220401200133.gyyvoe7xdbsww7cv@ti.com>

On 4/1/22 23:01, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 09/03/22 04:42PM, Tudor Ambarus wrote:
>> Keep the SFDP definitions private and expose just the definitions that are
>> required by the core and manufacturer drivers.
> 
> I am not so sure about this. Since the post_bfpt hook passes in the bfpt
> table to flash drivers, they might end up wanting to use these for some
> checks like issi.c does for DWORD 1. They would have to move them back
> to sfdp.h for that, which just causes extra churn, and also puts some
> BFPT related defines in sfdp.h and some in sfdp.c.
> 

That's correct, but I think exposing just the public defines in sfdp.h is
the path to follow. We should keep private all the definitions that we can
private in sfdp.c and expose publicly in sfdp.h just the ones that are shared.
Flash collisions, and implicitly the need of public SFDP definitions, should be
an exception, so I expect sfdp.h to be short in size.

Cheers,
ta

  reply	other threads:[~2022-04-04  6:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 14:42 [PATCH v2 0/4] mtd: spi-nor: Parse BFPT to determine the 4-Byte Address Mode Tudor Ambarus
2022-03-09 14:42 ` [PATCH v2 1/4] mtd: spi-nor: Parse BFPT to determine the 4-Byte Address Mode methods Tudor Ambarus
2022-04-01 10:54   ` Pratyush Yadav
2022-03-09 14:42 ` [PATCH v2 2/4] mtd: spi-nor: Update name and description of the set_4byte_addr_mode BFPT methods Tudor Ambarus
2022-04-01 12:26   ` Pratyush Yadav
2022-03-09 14:42 ` [PATCH v2 3/4] mtd: spi-nor: Favor the BFPT-parsed set_4byte_addr_mode method Tudor Ambarus
2022-04-01 19:55   ` Pratyush Yadav
2022-03-09 14:42 ` [PATCH v2 4/4] mtd: spi-nor: sfdp: Keep SFDP definitions private Tudor Ambarus
2022-04-01 20:01   ` Pratyush Yadav
2022-04-04  6:19     ` Tudor.Ambarus [this message]
2022-04-05 19:31       ` Pratyush Yadav
2022-04-06 10:31         ` Michael Walle
2022-04-06 11:10           ` Tudor.Ambarus
2022-04-06 12:17             ` Pratyush Yadav

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=ed093fa5-b514-b0a6-166f-ecf117582b0b@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.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

all inboxes | Powered by JetHome®