| Message ID | 20220922134824.46758-1-mika.westerberg@linux.intel.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Michael Walle |
| Headers | show |
| Series | Revert "mtd: spi-nor: core: Return error code from set_4byte_addr_mode()" | expand |
Am 2022-09-22 15:48, schrieb Mika Westerberg: > This reverts commit 08412e72afba3a2daef3e7f3378c3753255a0017. > > The Intel SPI-NOR controller does not support this opcode so the driver > ends up returning -EOPNOTSUPP and that makes the SPI flash chip probe > fail like this: > > [ 12.291082] spi-nor: probe of spi0.0 failed with error -524 > > Whereas previously it worked just fine (and hence the return value > probably was ignored in the first place). Can't we just ignore that return code then? -michael
On Thu, Sep 22, 2022 at 04:12:17PM +0200, Michael Walle wrote: > Am 2022-09-22 15:48, schrieb Mika Westerberg: > > This reverts commit 08412e72afba3a2daef3e7f3378c3753255a0017. > > > > The Intel SPI-NOR controller does not support this opcode so the driver > > ends up returning -EOPNOTSUPP and that makes the SPI flash chip probe > > fail like this: > > > > [ 12.291082] spi-nor: probe of spi0.0 failed with error -524 > > > > Whereas previously it worked just fine (and hence the return value > > probably was ignored in the first place). > > Can't we just ignore that return code then? Isn't this revert just doing that? ;-)
Am 2022-09-22 16:16, schrieb Mika Westerberg: > On Thu, Sep 22, 2022 at 04:12:17PM +0200, Michael Walle wrote: >> Am 2022-09-22 15:48, schrieb Mika Westerberg: >> > This reverts commit 08412e72afba3a2daef3e7f3378c3753255a0017. >> > >> > The Intel SPI-NOR controller does not support this opcode so the driver >> > ends up returning -EOPNOTSUPP and that makes the SPI flash chip probe >> > fail like this: >> > >> > [ 12.291082] spi-nor: probe of spi0.0 failed with error -524 >> > >> > Whereas previously it worked just fine (and hence the return value >> > probably was ignored in the first place). >> >> Can't we just ignore that return code then? > > Isn't this revert just doing that? ;-) No? It also ignores other (valid) errors. -michael
On Thu, Sep 22, 2022 at 04:17:10PM +0200, Michael Walle wrote: > Am 2022-09-22 16:16, schrieb Mika Westerberg: > > On Thu, Sep 22, 2022 at 04:12:17PM +0200, Michael Walle wrote: > > > Am 2022-09-22 15:48, schrieb Mika Westerberg: > > > > This reverts commit 08412e72afba3a2daef3e7f3378c3753255a0017. > > > > > > > > The Intel SPI-NOR controller does not support this opcode so the driver > > > > ends up returning -EOPNOTSUPP and that makes the SPI flash chip probe > > > > fail like this: > > > > > > > > [ 12.291082] spi-nor: probe of spi0.0 failed with error -524 > > > > > > > > Whereas previously it worked just fine (and hence the return value > > > > probably was ignored in the first place). > > > > > > Can't we just ignore that return code then? > > > > Isn't this revert just doing that? ;-) > > No? It also ignores other (valid) errors. Okay, I will do that and ignore just -ENOTSUPP in v2. However, there is also similar call in spi_nor_restore() where the error also gets ignored so I wonder if it was originally intentional.
Am 2022-09-22 16:29, schrieb Mika Westerberg: > On Thu, Sep 22, 2022 at 04:17:10PM +0200, Michael Walle wrote: >> Am 2022-09-22 16:16, schrieb Mika Westerberg: >> > On Thu, Sep 22, 2022 at 04:12:17PM +0200, Michael Walle wrote: >> > > Am 2022-09-22 15:48, schrieb Mika Westerberg: >> > > > This reverts commit 08412e72afba3a2daef3e7f3378c3753255a0017. >> > > > >> > > > The Intel SPI-NOR controller does not support this opcode so the driver >> > > > ends up returning -EOPNOTSUPP and that makes the SPI flash chip probe >> > > > fail like this: >> > > > >> > > > [ 12.291082] spi-nor: probe of spi0.0 failed with error -524 >> > > > >> > > > Whereas previously it worked just fine (and hence the return value >> > > > probably was ignored in the first place). >> > > >> > > Can't we just ignore that return code then? >> > >> > Isn't this revert just doing that? ;-) >> >> No? It also ignores other (valid) errors. > > Okay, I will do that and ignore just -ENOTSUPP in v2. > > However, there is also similar call in spi_nor_restore() where the > error > also gets ignored so I wonder if it was originally intentional. Yes that was intentional, because spi_nor_restore() returns void. -michael
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index f2c64006f8d7..3af2fcf1f683 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2724,7 +2724,7 @@ static int spi_nor_init(struct spi_nor *nor) */ WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET, "enabling reset hack; may not recover from unexpected reboots\n"); - return nor->params->set_4byte_addr_mode(nor, true); + nor->params->set_4byte_addr_mode(nor, true); } return 0;
This reverts commit 08412e72afba3a2daef3e7f3378c3753255a0017. The Intel SPI-NOR controller does not support this opcode so the driver ends up returning -EOPNOTSUPP and that makes the SPI flash chip probe fail like this: [ 12.291082] spi-nor: probe of spi0.0 failed with error -524 Whereas previously it worked just fine (and hence the return value probably was ignored in the first place). Reported-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org --- drivers/mtd/spi-nor/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)