All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Renjun Wang <renjunw0@foxmail.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 Michael Walle <mwalle@kernel.org>,
	 Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: extend description of size member of struct flash_info
Date: Thu, 19 Dec 2024 10:38:56 +0100	[thread overview]
Message-ID: <87r064c8r3.fsf@bootlin.com> (raw)
In-Reply-To: <20241219-spi-nor-flash-info-size-desc-v1-1-6b53cf011027@linaro.org> (Tudor Ambarus's message of "Thu, 19 Dec 2024 09:20:04 +0000")

On 19/12/2024 at 09:20:04 GMT, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> We use the size as an indicator whether to parse SFDP or not. We don't
> introduce a dedicated member for SFDP parsing because we'd like to keep
> the struct size at a minimum, as it's used for every flash declaration.
> Ideally we won't have flash entries at all, but there are still flash
> parameters that aren't defined by SFDP, thus we need to statically
> specify them.

TBH I'd be perfectly fine (and prefer) a dedicated member, because
code clarity is IMO more important than memory footprint today.

However for now I am totally agreeing with changes clarifying what we
currently do, so:

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

One minor nit below though:

> + * @size:           the size of the flash in bytes. The flash size is one
> + *                  property parsed by the SFDP. We use it as an indicator
> + *                  whether we need SFDP parsing for a particular flash.
> + *                  I.e. non-legacy flash entries in flash_info will have
> + *                  a size of zero iff SFDP should be used.

typo, 'if'                            ^^^

Cheers,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Renjun Wang <renjunw0@foxmail.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 Michael Walle <mwalle@kernel.org>,
	 Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: extend description of size member of struct flash_info
Date: Thu, 19 Dec 2024 10:38:56 +0100	[thread overview]
Message-ID: <87r064c8r3.fsf@bootlin.com> (raw)
In-Reply-To: <20241219-spi-nor-flash-info-size-desc-v1-1-6b53cf011027@linaro.org> (Tudor Ambarus's message of "Thu, 19 Dec 2024 09:20:04 +0000")

On 19/12/2024 at 09:20:04 GMT, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> We use the size as an indicator whether to parse SFDP or not. We don't
> introduce a dedicated member for SFDP parsing because we'd like to keep
> the struct size at a minimum, as it's used for every flash declaration.
> Ideally we won't have flash entries at all, but there are still flash
> parameters that aren't defined by SFDP, thus we need to statically
> specify them.

TBH I'd be perfectly fine (and prefer) a dedicated member, because
code clarity is IMO more important than memory footprint today.

However for now I am totally agreeing with changes clarifying what we
currently do, so:

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

One minor nit below though:

> + * @size:           the size of the flash in bytes. The flash size is one
> + *                  property parsed by the SFDP. We use it as an indicator
> + *                  whether we need SFDP parsing for a particular flash.
> + *                  I.e. non-legacy flash entries in flash_info will have
> + *                  a size of zero iff SFDP should be used.

typo, 'if'                            ^^^

Cheers,
Miquèl

  reply	other threads:[~2024-12-19  9:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19  9:20 [PATCH] mtd: spi-nor: extend description of size member of struct flash_info Tudor Ambarus
2024-12-19  9:20 ` Tudor Ambarus
2024-12-19  9:38 ` Miquel Raynal [this message]
2024-12-19  9:38   ` Miquel Raynal
2024-12-19 10:01   ` Tudor Ambarus
2024-12-19 10:01     ` Tudor Ambarus
2024-12-19 16:15     ` Miquel Raynal
2024-12-19 16:15       ` Miquel Raynal
2024-12-20  8:36       ` Michael Walle
2024-12-20  8:36         ` Michael Walle
2024-12-20  8:59         ` Miquel Raynal
2024-12-20  8:59           ` Miquel Raynal
2025-01-13 17:52 ` Pratyush Yadav
2025-01-13 17:52   ` 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=87r064c8r3.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=renjunw0@foxmail.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --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 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.