public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>, <p.yadav@ti.com>, <miquel.raynal@bootlin.com>,
	<richard@nod.at>, <vigneshr@ti.com>
Cc: <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<heiko.thiery@gmail.com>
Subject: Re: [PATCH v1] mtd: spi-nor: unset quad_enable if SFDP doesn't specify it
Date: Tue, 19 Jul 2022 04:57:41 +0000	[thread overview]
Message-ID: <43041ef1-2b1b-5729-9611-00964d617f63@microchip.com> (raw)
In-Reply-To: <20220304185137.3376011-1-michael@walle.cc>

On 3/4/22 20:51, Michael Walle wrote:

Hi!

> While the first version of JESD216 specify the opcode for 4 bit I/O
> accesses, it lacks information on how to actually enable this mode.
> 
> For now, the one set in spi_nor_init_default_params() will be used.
> But this one is likely wrong for some flashes, in particular the
> Macronix MX25L12835F. Thus we need to clear the enable method when
> parsing the SFDP. Flashes with such an SFDP revision will have to use a
> flash (and SFDP revision) specific fixup.

This is equivalent to clearing the default QE method for all those flashes
that support SFDP, with implications for those that support SFDP Rev A.
If I continue the logic, I could remove the default QE method from
spi_nor_init_default_params(), but I don't think I would like that.
You could use a post_bfpt hook without explicitly clearing it here.

Would you please explain more why is clearing the default method better
than using a wrong default one, and why you chose to do this just for
the Rev A SFDP flashes and you didn't include the no-SFDP flashes as well?

thanks,
ta

> 
> This might break quad I/O for some flashes which relied on the
> spi_nor_sr2_bit1_quad_enable() that was formerly set. If your bisect
> turns up this commit, you'll probably have to set the proper
> quad_enable method in a post_bfpt() fixup for your flash.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
> ---
> changes since RFC:
>  - reworded commit message
>  - added comment about post_bfpt hook
> 
> Tudor, I'm not sure what you meant with
>   Maybe you can update the commit message and explain why would some
>   flashes fail to enable quad mode, similar to what I did.
> 
> It doesn't work because the wrong method is chosen? ;)
> 
>  drivers/mtd/spi-nor/sfdp.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index a5211543d30d..6bba9b601846 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -549,6 +549,16 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>  	map->uniform_erase_type = map->uniform_region.offset &
>  				  SNOR_ERASE_TYPE_MASK;
>  
> +	/*
> +	 * The first JESD216 revision doesn't specify a method to enable
> +	 * quad mode. spi_nor_init_default_params() will set a legacy
> +	 * default method to enable quad mode. We have to disable it
> +	 * again.
> +	 * Flashes with this JESD216 revision need to set the quad_enable
> +	 * method in their post_bfpt() fixup if they want to use quad I/O.
> +	 */
> +	params->quad_enable = NULL;
> +
>  	/* Stop here if not JESD216 rev A or later. */
>  	if (bfpt_header->length == BFPT_DWORD_MAX_JESD216)
>  		return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt);
> @@ -562,7 +572,6 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>  	/* Quad Enable Requirements. */
>  	switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
>  	case BFPT_DWORD15_QER_NONE:
> -		params->quad_enable = NULL;
>  		break;
>  
>  	case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:

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

  parent reply	other threads:[~2022-07-19  4:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 18:51 [PATCH v1] mtd: spi-nor: unset quad_enable if SFDP doesn't specify it Michael Walle
2022-03-07  7:12 ` Tudor.Ambarus
2022-03-07  9:23   ` Tudor.Ambarus
2022-03-07 18:56     ` Michael Walle
2022-03-09  4:49       ` Tudor.Ambarus
2022-03-14 20:42         ` Michael Walle
2022-03-15  5:55           ` Tudor.Ambarus
2022-03-15  7:24             ` Michael Walle
2022-03-15  7:47               ` Tudor.Ambarus
2022-03-16 19:07                 ` Pratyush Yadav
2022-07-19  4:57 ` Tudor.Ambarus [this message]
2022-07-20 13:48   ` Michael Walle

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=43041ef1-2b1b-5729-9611-00964d617f63@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=heiko.thiery@gmail.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