From: Michael Walle <mwalle@kernel.org>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Jaime Liao <jaimeliao.tw@gmail.com>,
linux-mtd@lists.infradead.org, pratyush@kernel.org,
miquel.raynal@bootlin.com, leoyu@mxic.com.tw,
jaimeliao@mxic.com.tw
Subject: Re: [PATCH v2] mtd: spi-nor: core: Discard HW capabilities if no enable function
Date: Wed, 20 Dec 2023 09:50:38 +0100 [thread overview]
Message-ID: <0b3aa661e5151aba8e32633e709fdbdc@kernel.org> (raw)
In-Reply-To: <43eac7ba-1648-4e99-80b8-3132523189c7@linaro.org>
Am 2023-12-20 09:20, schrieb Tudor Ambarus:
> On 19.12.2023 12:21, Jaime Liao wrote:
>> From: JaimeLiao <jaimeliao@mxic.com.tw>
>>
>> Discard corresponding HW capabilities to prevent carrying the
>> wrong protocol if no QUAD/Octal DTR enable function hooked.
>>
>> Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
>> ---
>> changes in v2
>> - Add SNOR_HWCAPS_8_8_8_DTR
>> - Restore the enable function judgement in spi_nor_set_octal_dtr()
>> - Restore the enable function judgement in spi_nor_quad_enable()
>> ---
>> drivers/mtd/spi-nor/core.c | 7 +++++++
>> include/linux/mtd/spi-nor.h | 6 ++++++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 1c443fe568cf..14359101c6cf 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -2621,6 +2621,13 @@ static int spi_nor_default_setup(struct spi_nor
>> *nor,
>> */
>> shared_mask = hwcaps->mask & params->hwcaps.mask;
>>
>> + /* Mask out Octal DTR if no enable function */
>> + if (!params->set_octal_dtr)
>> + shared_mask &= ~SNOR_HWCAPS_8_8_8_DTR;
>> +
>> + if (!params->quad_enable)
>> + shared_mask &= ~SNOR_HWCAPS_4_4_4;
>
> and these should have been in the late init hook, and instead discard
> them from the params->hwcaps.mask.
Maybe there is a better place to mask these bits. But IMHO the core
should do it on itself and we shouldn't need to provide an extra
hook function for every driver ourselves. The core knows that there
is no .octal_enable op and thus it shouldn't even try to enable
this mode.
> And why is this extra check needed in the first place? For octal I
> assume it's needed by macronix, where the flash is octal capable, but
> there's no octal enable method defined yet.
Because it is the generic spi nor flash driver, which doesn't provide
any of these enable x-mode helpers.
> What about the quad mode? Is
> there any flash that has no quad enable method defined but still caries
> quad mode in its hwcaps?
No it is for completeness and correctness. At the moment we are always
setting a (random) default quad enable op, due to legacy reasons.
-michael
>> +
>> if (nor->spimem) {
>> /*
>> * When called from spi_nor_probe(), all caps are set and we
>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
>> index cdcfe0fd2e7d..78a119192ee0 100644
>> --- a/include/linux/mtd/spi-nor.h
>> +++ b/include/linux/mtd/spi-nor.h
>> @@ -266,6 +266,12 @@ struct spi_nor_hwcaps {
>> #define SNOR_HWCAPS_PP_8_8_8 BIT(22)
>> #define SNOR_HWCAPS_PP_8_8_8_DTR BIT(23)
>>
>> +#define SNOR_HWCAPS_4_4_4 (SNOR_HWCAPS_READ_4_4_4 | \
>> + SNOR_HWCAPS_PP_4_4_4)
>> +
>> +#define SNOR_HWCAPS_8_8_8_DTR (SNOR_HWCAPS_READ_8_8_8_DTR | \
>> + SNOR_HWCAPS_PP_8_8_8_DTR)
>> +
>> #define SNOR_HWCAPS_X_X_X (SNOR_HWCAPS_READ_2_2_2 | \
>> SNOR_HWCAPS_READ_4_4_4 | \
>> SNOR_HWCAPS_READ_8_8_8 | \
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-12-20 8:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 10:21 [PATCH v2] mtd: spi-nor: core: Discard HW capabilities if no enable function Jaime Liao
2023-12-19 10:21 ` [PATCH v3] mtd: spi-nor: sfdp: Get the 1-1-8 and 1-8-8 protocol from SFDP Jaime Liao
2023-12-19 12:15 ` Michael Walle
2023-12-20 8:42 ` Tudor Ambarus
2023-12-20 8:51 ` Re (subset): " Tudor Ambarus
2023-12-19 12:12 ` [PATCH v2] mtd: spi-nor: core: Discard HW capabilities if no enable function Michael Walle
2023-12-20 8:07 ` Tudor Ambarus
2023-12-20 8:43 ` Michael Walle
2023-12-20 8:20 ` Tudor Ambarus
2023-12-20 8:50 ` Michael Walle [this message]
2023-12-20 8:58 ` Tudor Ambarus
2023-12-20 9:02 ` 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=0b3aa661e5151aba8e32633e709fdbdc@kernel.org \
--to=mwalle@kernel.org \
--cc=jaimeliao.tw@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=leoyu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=tudor.ambarus@linaro.org \
/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.