public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Esben Haabendal <esben@geanix.com>
To: Erez <erezgeva2@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>,
	 Tudor Ambarus <tudor.ambarus@linaro.org>,
	 Jaime Liao <jaimeliao@mxic.com.tw>,
	leoyu@mxic.com.tw,  Alvin Zhou <alvinzhou@mxic.com.tw>,
	 Julien Su <juliensu@mxic.com.tw>,
	 Erez Geva <erezgeva@nwtime.org>,
	linux-mtd@lists.infradead.org,
	 Pratyush Yadav <pratyush@kernel.org>,
	linux-kernel@vger.kernel.org,
	 Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 devicetree@vger.kernel.org,  Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
Date: Fri, 12 Jul 2024 10:20:56 +0200	[thread overview]
Message-ID: <878qy7vx5j.fsf@geanix.com> (raw)
In-Reply-To: <CANeKEMNtXb4ZV7kcLbHY+Mti6dPV9UZ2wTyUq5z0qtmtNNqSVA@mail.gmail.com> (Erez's message of "Fri, 12 Jul 2024 00:09:01 +0200")

Erez <erezgeva2@gmail.com> writes:

> On Thu, 11 Jul 2024 at 21:57, Michael Walle <mwalle@kernel.org> wrote:
>> On Thu Jul 11, 2024 at 8:57 PM CEST, Erez wrote:
>> > Yes, I think we should.
>> >
>> > Reading the specification provided publicly by Macronix.
>> > For all the JEDEC IDs with the no SFDP flag in drivers/mtd/spi-nor/macronix.c
>> > All of them have a new version or a new chip with the same JEDEC ID
>> > that supports SFDP.
>> > There are 2 chips that Macronix does not provide spec. in public.
>> > I can ask Macronix technical support on these 2 chips.
>>
>> We don't add flashes we cannot test.
>
> I did not suggest adding anything new.
> I refer to the list of chips we already have in drivers/mtd/spi-nor/macronix.c
> I presume someone tested them before adding them to the list in the past.
> And probably the old chip did not have the SFDP table back then.
>
> What I checked with the chip specifications is that all Macronix chips
> since 2010 have SFDP.
>
> The situation today is that all Macronix chips that are NOT in the
> Macronix table work based on the SFDP table.
> But new chips that use a JEDEC found in the Macronix table, skip the
> SFDP table and use the setting of the old chip.

Not entirely true.

Those that entries in the Macronix table that has SPI_NOR_DUAL_READ
and/or SPI_NOR_QUAD_READ in no_sfdp_flags is caught by
the magic flags matching in spi_nor_init_params_deprecated() and will
have spi_nor_parse_sfdp() called from
spi_nor_sfdp_init_params_deprecated(). So flashes reusing ID for these
will have the SFDP tables parsed.

The rest of the entries in the Macronix table is not so lucky. When a
replacement chip (with the same ID) is used, it will not be configured
with the values found in SFDP table.

> So I suggest we read the SFDP table for all Macronix chips.

Based on their strategy of re-using flash ID, I think this is a sane
approach.

> Old Macronix chips that do not have SFDP will use the setting from the
> Macronix table. i.e backward compatible.
> While new chips which do have an SFDP table will work with the new
> setting we find in the table.

Yes, if we apply the new SPI_NOR_TRY_SFDP flag to the matching table
entries.

> Of course, we might have issues in parsing the SFDP table itself.
> So we fix them as developers report and send chip ID and part number
> with the SFDP table content.
> I do not see the point of "hiding" with the old setting.
> Anyhow, as we do not like the IDs table and keep it for backward-compatible,
> so it only makes sense we should use the SFDP table as much as possible.
>
> My check was to ensure Tudor that all Macronix chips have SFDP whether
> they are in the IDs table or not and we are not wasting a no-op on a
> chip which can not have an SFDP table.
>
> All I suggest is we add the new 'SPI_NOR_TRY_SFDP' flag, to all
> Macronix chips.. Which will try to read the SFDP to any Macronix chip.

Makes sense. But obviously comes with a risk as we won't be able to
test all chips for regression when doing that.

/Esben

  parent reply	other threads:[~2024-07-12  8:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-29 10:39 [PATCH v2 0/4] Add support for SPI-NOR Macronix OTP Erez Geva
2024-06-29 10:39 ` [PATCH v2 1/4] Add generic functions for accessing the SPI-NOR chip Erez Geva
2024-07-01  5:28   ` Tudor Ambarus
2024-06-29 10:39 ` [PATCH v2 2/4] Add support for SPI-NOR Macronix OTP Erez Geva
2024-06-29 10:39 ` [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip Erez Geva
2024-07-01  5:23   ` Tudor Ambarus
     [not found]     ` <CANeKEMOODBNZA6efh0E0Ga_KaVs5Y3WLcUftRhNwYHhnXO=GNw@mail.gmail.com>
2024-07-01  9:46       ` Erez
2024-07-01 10:15         ` Tudor Ambarus
2024-07-01 10:23           ` Tudor Ambarus
2024-07-01 11:03             ` Erez
2024-07-01 12:53               ` Tudor Ambarus
2024-07-01 16:12                 ` Erez
2024-07-01 10:55           ` Erez
2024-07-01 17:08           ` Erez
2024-07-02  5:00             ` Tudor Ambarus
2024-07-02 23:16               ` Erez
2024-07-03  7:12                 ` Tudor Ambarus
2024-07-03  8:23                   ` Erez
2024-07-10 14:34                     ` Esben Haabendal
2024-07-11 18:57                       ` Erez
2024-07-11 19:57                         ` Michael Walle
2024-07-11 22:09                           ` Erez
2024-07-11 22:13                             ` Michael Walle
2024-07-12  5:13                               ` Erez
2024-07-12  8:20                             ` Esben Haabendal [this message]
     [not found]                               ` <CANeKEMPD=nLnor8-oF0t9D8f5D+mLU4XqZ-07avX55BF3TJ8_Q@mail.gmail.com>
2024-08-16 11:29                                 ` Erez
2024-06-29 10:39 ` [PATCH v2 4/4] Add Macronix SPI-NOR mx25l12833f with OTP Erez Geva

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=878qy7vx5j.fsf@geanix.com \
    --to=esben@geanix.com \
    --cc=alvinzhou@mxic.com.tw \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=erezgeva2@gmail.com \
    --cc=erezgeva@nwtime.org \
    --cc=jaimeliao@mxic.com.tw \
    --cc=juliensu@mxic.com.tw \
    --cc=krzk+dt@kernel.org \
    --cc=leoyu@mxic.com.tw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox