Thread (78 messages) 78 messages, 3 authors, 2021-11-22

Re: [PATCH v3 12/25] mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined

From: Michael Walle <hidden>
Date: 2021-11-09 10:19:47

Am 2021-10-29 19:26, schrieb Tudor Ambarus:
quoted hunk ↗ jump to hunk
spi_nor_post_sfdp_fixups() was called even when there were no SFDP
tables defined. late_init() should be instead used for flashes that
do not define SFDP tables.

Use spi_nor_post_sfdp_fixups() just to fix SFDP data. post_sfdp()
hook is as of now used just by s28hs512t, mt35xu512aba, and both
support SFDP, there's no functional change with this patch.

Signed-off-by: Tudor Ambarus <redacted>
---
 drivers/mtd/spi-nor/core.c | 56 ++++++++++++++++++--------------------
 1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 4679298c5301..82cc56c9d09e 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2508,6 +2508,25 @@ static void
spi_nor_manufacturer_init_params(struct spi_nor *nor)
 		nor->info->fixups->default_init(nor);
 }

+/**
+ * spi_nor_post_sfdp_fixups() - Updates the flash's parameters and 
settings
+ * after SFDP has been parsed. Called only for flashes that define 
JESD216 SFDP
+ * tables.
+ * @nor:	pointer to a 'struct spi_nor'
+ *
+ * Used to tweak various flash parameters when information provided by 
the SFDP
+ * tables are wrong.
+ */
+static void spi_nor_post_sfdp_fixups(struct spi_nor *nor)
+{
+	if (nor->manufacturer && nor->manufacturer->fixups &&
+	    nor->manufacturer->fixups->post_sfdp)
+		nor->manufacturer->fixups->post_sfdp(nor);
+
+	if (nor->info->fixups && nor->info->fixups->post_sfdp)
+		nor->info->fixups->post_sfdp(nor);
+}
+
 /**
  * spi_nor_sfdp_init_params() - Initialize the flash's parameters and 
settings
  * based on JESD216 SFDP standard.
@@ -2522,7 +2541,9 @@ static void spi_nor_sfdp_init_params(struct 
spi_nor *nor)

 	memcpy(&sfdp_params, nor->params, sizeof(sfdp_params));

-	if (spi_nor_parse_sfdp(nor)) {
+	if (!spi_nor_parse_sfdp(nor)) {
+		spi_nor_post_sfdp_fixups(nor);
I find this function particulary confusing. Why is it
copying the params around? I know the function doc
says rollback, but can't we make this better?

Either make spi_nor_parse_sfdp() commit the nor->params update
atomically, or pass a second parameter sfdp_params, which are
copied to nor->params here if spi_nor_parse_sfdp() was successful.

Also the control flow could be better.

ret = spi_nor_parse_sfdp(nor, &sfdp_params);
if (!ret) {
     /* clever comment, why is addr_width = 0 here */
     nor->addr_width = 0;
     nor->flags &= ~SNOR_F_4B_OPCODES;
     return 0;
}

memcpy(nor->params, &sfdp_params, sizeof(*nor->params));
spi_nor_post_sfdp_fixups(nor);

Having an even closer look, addr_width is set to 0 because
spi_nor_parse_sfdp() is also changing that. nor->flags
is also changed and not only the SNOR_F_4B_OPCODES bit. But
only that one is cleared?!

I think this deserves another cleanup series. Having the
rollback here makes no sense. You'd have to keep both in
sync.

IMHO best would be a second parameter and make sure all
code in sfdp.c don't change anything else. Which would
probably mean that addr_width and flags will move to
nor->params.

Anyway, for now:
Reviewed-by: Michael Walle <redacted>

-michael

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help