drivers/mtd/spi-nor/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Fix flash probing by name. Flash entries without a name are allowed
since commit 15eb8303bb42 ("mtd: spi-nor: mark the flash name as
obsolete"). But it was just until recently that a flash entry without a
name was actually introduced. This triggers a bug in the legacy probe by
name path. Skip entries without a name to fix it.
Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
drivers/mtd/spi-nor/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index d8e551fd2e2a..101ee5b0ddeb 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3281,7 +3281,8 @@ static const struct flash_info *spi_nor_match_name(struct spi_nor *nor,
for (i = 0; i < ARRAY_SIZE(manufacturers); i++) {
for (j = 0; j < manufacturers[i]->nparts; j++) {
- if (!strcmp(name, manufacturers[i]->parts[j].name)) {
+ if (manufacturers[i]->parts[j].name &&
+ !strcmp(name, manufacturers[i]->parts[j].name)) {
nor->manufacturer = manufacturers[i];
return &manufacturers[i]->parts[j];
}
--
2.39.2
Hi Michael, Thanks for the quick fix! On Mon, Sep 09 2024, Michael Walle wrote: > Fix flash probing by name. Flash entries without a name are allowed > since commit 15eb8303bb42 ("mtd: spi-nor: mark the flash name as > obsolete"). But it was just until recently that a flash entry without a > name was actually introduced. This triggers a bug in the legacy probe by > name path. Skip entries without a name to fix it. We also use name in a couple other places: 1. spi_nor_get_flash_info() prints jinfo->name and info->name() in the dev_warn() call. 2. spi_nor_params_show() prints nor->info->name for the debugfs entry. Since both of these are prints, it should probably be fine since they should be converted to "(null)" instead. Still, something we should fix. I don't think those are critical so those can be fixed as follow up patches. I unfortunately am swamped and don't have the time to fix them right now. I also did a quick check to make sure we don't have other flashes without a name. Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Applied to spi-nor/next. Thanks! > > Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") > Reported-by: Jon Hunter <jonathanh@nvidia.com> > Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/ > Tested-by: Jon Hunter <jonathanh@nvidia.com> > Signed-off-by: Michael Walle <mwalle@kernel.org> [...] -- Regards, Pratyush Yadav
On 9/9/24 8:28 AM, Michael Walle wrote: > Fix flash probing by name. Flash entries without a name are allowed > since commit 15eb8303bb42 ("mtd: spi-nor: mark the flash name as > obsolete"). But it was just until recently that a flash entry without a > name was actually introduced. This triggers a bug in the legacy probe by > name path. Skip entries without a name to fix it. > > Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") > Reported-by: Jon Hunter <jonathanh@nvidia.com> > Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/ > Tested-by: Jon Hunter <jonathanh@nvidia.com> > Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> > --- > drivers/mtd/spi-nor/core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index d8e551fd2e2a..101ee5b0ddeb 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -3281,7 +3281,8 @@ static const struct flash_info *spi_nor_match_name(struct spi_nor *nor, > > for (i = 0; i < ARRAY_SIZE(manufacturers); i++) { > for (j = 0; j < manufacturers[i]->nparts; j++) { > - if (!strcmp(name, manufacturers[i]->parts[j].name)) { > + if (manufacturers[i]->parts[j].name && > + !strcmp(name, manufacturers[i]->parts[j].name)) { > nor->manufacturer = manufacturers[i]; > return &manufacturers[i]->parts[j]; > }
Hey, tudor.ambarus@linaro.org wrote on Mon, 9 Sep 2024 08:35:23 +0100: > On 9/9/24 8:28 AM, Michael Walle wrote: > > Fix flash probing by name. Flash entries without a name are allowed > > since commit 15eb8303bb42 ("mtd: spi-nor: mark the flash name as > > obsolete"). But it was just until recently that a flash entry without a > > name was actually introduced. This triggers a bug in the legacy probe by > > name path. Skip entries without a name to fix it. > > > > Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") > > Reported-by: Jon Hunter <jonathanh@nvidia.com> > > Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/ > > Tested-by: Jon Hunter <jonathanh@nvidia.com> > > Signed-off-by: Michael Walle <mwalle@kernel.org> > > Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> This patch will only apply on top of spi-nor/next. It would spend more time in -next if one of you applied it to this branch before sending the MR? Cheers, Miquèl
On 9/9/24 8:52 AM, Miquel Raynal wrote: > Hey, > Hiya > tudor.ambarus@linaro.org wrote on Mon, 9 Sep 2024 08:35:23 +0100: > >> On 9/9/24 8:28 AM, Michael Walle wrote: >>> Fix flash probing by name. Flash entries without a name are allowed >>> since commit 15eb8303bb42 ("mtd: spi-nor: mark the flash name as >>> obsolete"). But it was just until recently that a flash entry without a >>> name was actually introduced. This triggers a bug in the legacy probe by >>> name path. Skip entries without a name to fix it. >>> >>> Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") >>> Reported-by: Jon Hunter <jonathanh@nvidia.com> >>> Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/ >>> Tested-by: Jon Hunter <jonathanh@nvidia.com> >>> Signed-off-by: Michael Walle <mwalle@kernel.org> >> >> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> > > This patch will only apply on top of spi-nor/next. It would spend more > time in -next if one of you applied it to this branch before sending > the MR? > The patch is intended for spi-nor/next indeed, as the blamed commit was just recently queued. No need to take it through mtd/fixes. Pratyush will take it via spi-nor/next. Cheers, ta
Hi Tudor, > >>> Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") > >>> Reported-by: Jon Hunter <jonathanh@nvidia.com> > >>> Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/ > >>> Tested-by: Jon Hunter <jonathanh@nvidia.com> > >>> Signed-off-by: Michael Walle <mwalle@kernel.org> > >> > >> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> > > > > This patch will only apply on top of spi-nor/next. It would spend more > > time in -next if one of you applied it to this branch before sending > > the MR? > > > > The patch is intended for spi-nor/next indeed, as the blamed commit was > just recently queued. No need to take it through mtd/fixes. Pratyush > will take it via spi-nor/next. Ok perfect, thanks! Miquèl
On Mon, Sep 09 2024, Miquel Raynal wrote: > Hi Tudor, > >> >>> Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") >> >>> Reported-by: Jon Hunter <jonathanh@nvidia.com> >> >>> Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/ >> >>> Tested-by: Jon Hunter <jonathanh@nvidia.com> >> >>> Signed-off-by: Michael Walle <mwalle@kernel.org> >> >> >> >> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> >> > >> > This patch will only apply on top of spi-nor/next. It would spend more >> > time in -next if one of you applied it to this branch before sending >> > the MR? >> > >> >> The patch is intended for spi-nor/next indeed, as the blamed commit was >> just recently queued. No need to take it through mtd/fixes. Pratyush >> will take it via spi-nor/next. Right. I have applied this to spi-nor/next. I plan to send the pull request by Wednesday/Thursday so it should get at least a couple days of testing in linux-next. > > Ok perfect, thanks! -- Regards, Pratyush Yadav
© 2016 - 2024 Red Hat, Inc.