On 10/31/2019 01:05 PM, Boris Brezillon wrote: > External E-Mail > > > On Tue, 29 Oct 2019 11:17:09 +0000 > <Tudor.Ambarus@xxxxxxxxxxxxx> wrote: > >> From: Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx> >> >> Spare the callers of printing error messages by themselves. >> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 165 +++++++++++++++++++++++++++++++----------- >> 1 file changed, 123 insertions(+), 42 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index e5ed9012cd50..bc46b946ac77 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -394,6 +394,8 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len, >> */ >> static int spi_nor_write_enable(struct spi_nor *nor) >> { >> + int ret; >> + >> if (nor->spimem) { >> struct spi_mem_op op = >> SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WREN, 1), >> @@ -401,10 +403,16 @@ static int spi_nor_write_enable(struct spi_nor *nor) >> SPI_MEM_OP_NO_DUMMY, >> SPI_MEM_OP_NO_DATA); >> >> - return spi_mem_exec_op(nor->spimem, &op); >> + ret = spi_mem_exec_op(nor->spimem, &op); >> + } else { >> + ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WREN, >> + NULL, 0); >> } >> >> - return nor->controller_ops->write_reg(nor, SPINOR_OP_WREN, NULL, 0); >> + if (ret) >> + dev_err(nor->dev, "error %d on Write Enable\n", ret); > > I thought we agreed on using dev_err_once() here (applies to other > dev_err() calls). If it fails once it's unlikely to succeed on > subsequent calls, and I don't think spamming the kernel logs is very > useful. > I used dev_err() and not dev_err_once() because if spi_nor_write_enable() fails, we stop the execution and just return the spi_nor_write_enable()'s error. The kernel logs will not be spammed because it will be just an error reported. dev_err_once() would make sense if we change the method's return type from int to void, but why to ignore possible errors from write enable/disable? ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/