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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2024-07-12 8:21 UTC|newest]
Thread overview: 54+ 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 ` Erez Geva
2024-06-29 10:39 ` [PATCH v2 1/4] Add generic functions for accessing the SPI-NOR chip Erez Geva
2024-06-29 10:39 ` Erez Geva
2024-07-01 5:28 ` Tudor Ambarus
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 ` Erez Geva
2024-06-29 10:39 ` [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip Erez Geva
2024-06-29 10:39 ` Erez Geva
2024-07-01 5:23 ` Tudor Ambarus
2024-07-01 5:23 ` Tudor Ambarus
[not found] ` <CANeKEMOODBNZA6efh0E0Ga_KaVs5Y3WLcUftRhNwYHhnXO=GNw@mail.gmail.com>
2024-07-01 9:46 ` Erez
2024-07-01 9:46 ` Erez
2024-07-01 10:15 ` Tudor Ambarus
2024-07-01 10:15 ` Tudor Ambarus
2024-07-01 10:23 ` Tudor Ambarus
2024-07-01 10:23 ` Tudor Ambarus
2024-07-01 11:03 ` Erez
2024-07-01 11:03 ` Erez
2024-07-01 12:53 ` Tudor Ambarus
2024-07-01 12:53 ` Tudor Ambarus
2024-07-01 16:12 ` Erez
2024-07-01 16:12 ` Erez
2024-07-01 10:55 ` Erez
2024-07-01 10:55 ` Erez
2024-07-01 17:08 ` Erez
2024-07-01 17:08 ` Erez
2024-07-02 5:00 ` Tudor Ambarus
2024-07-02 5:00 ` Tudor Ambarus
2024-07-02 23:16 ` Erez
2024-07-02 23:16 ` Erez
2024-07-03 7:12 ` Tudor Ambarus
2024-07-03 7:12 ` Tudor Ambarus
2024-07-03 8:23 ` Erez
2024-07-03 8:23 ` Erez
2024-07-10 14:34 ` Esben Haabendal
2024-07-10 14:34 ` Esben Haabendal
2024-07-11 18:57 ` Erez
2024-07-11 18:57 ` Erez
2024-07-11 19:57 ` Michael Walle
2024-07-11 19:57 ` Michael Walle
2024-07-11 22:09 ` Erez
2024-07-11 22:09 ` Erez
2024-07-11 22:13 ` Michael Walle
2024-07-11 22:13 ` Michael Walle
2024-07-12 5:13 ` Erez
2024-07-12 5:13 ` Erez
2024-07-12 8:20 ` Esben Haabendal [this message]
2024-07-12 8:20 ` Esben Haabendal
[not found] ` <CANeKEMPD=nLnor8-oF0t9D8f5D+mLU4XqZ-07avX55BF3TJ8_Q@mail.gmail.com>
2024-08-16 11:29 ` Erez
2024-08-16 11:29 ` Erez
2024-06-29 10:39 ` [PATCH v2 4/4] Add Macronix SPI-NOR mx25l12833f with OTP Erez Geva
2024-06-29 10:39 ` 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 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.