All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <p.yadav@ti.com>
To: Michael Walle <michael@walle.cc>
Cc: <Tudor.Ambarus@microchip.com>, <miquel.raynal@bootlin.com>,
	<richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH v2 3/8] mtd: spi-nor: core: Use auto-detection only once
Date: Thu, 31 Mar 2022 00:20:05 +0530	[thread overview]
Message-ID: <20220330185005.ohsb4bczuyav7xzs@ti.com> (raw)
In-Reply-To: <148e6c16421e6a94a2ee41fa251130df@walle.cc>

On 21/03/22 11:38PM, Michael Walle wrote:
> Am 2022-03-21 18:42, schrieb Pratyush Yadav:
> > On 21/03/22 12:50PM, Tudor.Ambarus@microchip.com wrote:
> > > On 3/21/22 14:14, Pratyush Yadav wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > >
> > > > On 28/02/22 01:17PM, Tudor Ambarus wrote:
> > > >> In case spi_nor_match_name() returned NULL, the auto detection was
> > > >> issued twice. There's no reason to try to detect the same chip twice,
> > > >> do the auto detection only once.
> > > >>
> > > >> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > > >> ---
> > > >>  drivers/mtd/spi-nor/core.c | 10 ++++++----
> > > >>  1 file changed, 6 insertions(+), 4 deletions(-)
> > > >>
> > > >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > > >> index f87cb7d3daab..b1d6fa65417d 100644
> > > >> --- a/drivers/mtd/spi-nor/core.c
> > > >> +++ b/drivers/mtd/spi-nor/core.c
> > > >> @@ -2894,13 +2894,15 @@ static const struct flash_info *spi_nor_match_name(struct spi_nor *nor,
> > > >>  static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
> > > >>                                                      const char *name)
> > > >>  {
> > > >> -     const struct flash_info *info = NULL;
> > > >> +     const struct flash_info *info = NULL, *detected_info = NULL;
> > > >>
> > > >>       if (name)
> > > >>               info = spi_nor_match_name(nor, name);
> > > >>       /* Try to auto-detect if chip name wasn't specified or not found */
> > > >> -     if (!info)
> > > >> -             info = spi_nor_read_id(nor);
> > > >> +     if (!info) {
> > > >> +             detected_info = spi_nor_read_id(nor);
> > > >> +             info = detected_info;
> > > >> +     }
> > > >>       if (IS_ERR_OR_NULL(info))
> > > >>               return ERR_PTR(-ENOENT);
> > > >>
> > > >> @@ -2908,7 +2910,7 @@ static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
> > > >>        * If caller has specified name of flash model that can normally be
> > > >>        * detected using JEDEC, let's verify it.
> > > >>        */
> > > >> -     if (name && info->id_len) {
> > > >> +     if (name && !detected_info && info->id_len) {
> > > >>               const struct flash_info *jinfo;
> > > >>
> > > >>               jinfo = spi_nor_read_id(nor);
> > > >
> > > > I think the flow can be a little bit better. How about:
> > > >
> > > >         if (name)
> > > >                 info = spi_nor_match_name();
> > > >
> > > >         if (!info) {
> > > >                 info = spi_nor_read_id();
> > > >                 if (IS_ERR_OR_NULL(info))
> > > >                         return ERR_PTR(-ENOENT);
> > > >
> > > >                 return info;
> > > >         }
> 
> +1 for the flow. But is it correct that we just ignore any former
> error and just replace it with ENOENT? Should we return NULL here
> and let the caller handle the translation from NULL to ENOENT (and
> keeping any other errors)
> 
> > > 
> > > Here we miss the IS_ERR check in case info is retrieved with
> > > spi_nor_match_name().
> > > Do you expect spi_nor_match_name() to ever return an error? As it is
> > > now it doesn't.
> > > I'm fine either way. In case you want me to follow your suggestion,
> > > give me a sign
> > > and I'll make a dedicated patch to move the IS_ERR_OR_NULL check.
> > > Will add your
> > > Suggested-by tag.
> > 
> > I think it should be safe to assume it won't ever return an error since
> > all it does is iterate over an array that is always present. I don't see
> > that changing in the foreseeable future either. So I think not having
> > the IS_ERR check is fine.
> 
> But what does it cost to just add the error check now so it won't
> be forgotten in the future?
> 
>          if (name) {
>                  info = spi_nor_match_name();
>                  if (IS_ERR(info))
>                          return info;
>          }
>          if (!info)
>                   return spi_nor_read_id();
> 
>          <flash model check code follows here>
> 
> And then let the caller handle NULL and translate it to ENOENT.

Sounds good to me.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Yadav <p.yadav@ti.com>
To: Michael Walle <michael@walle.cc>
Cc: <Tudor.Ambarus@microchip.com>, <miquel.raynal@bootlin.com>,
	<richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH v2 3/8] mtd: spi-nor: core: Use auto-detection only once
Date: Thu, 31 Mar 2022 00:20:05 +0530	[thread overview]
Message-ID: <20220330185005.ohsb4bczuyav7xzs@ti.com> (raw)
In-Reply-To: <148e6c16421e6a94a2ee41fa251130df@walle.cc>

On 21/03/22 11:38PM, Michael Walle wrote:
> Am 2022-03-21 18:42, schrieb Pratyush Yadav:
> > On 21/03/22 12:50PM, Tudor.Ambarus@microchip.com wrote:
> > > On 3/21/22 14:14, Pratyush Yadav wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > >
> > > > On 28/02/22 01:17PM, Tudor Ambarus wrote:
> > > >> In case spi_nor_match_name() returned NULL, the auto detection was
> > > >> issued twice. There's no reason to try to detect the same chip twice,
> > > >> do the auto detection only once.
> > > >>
> > > >> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > > >> ---
> > > >>  drivers/mtd/spi-nor/core.c | 10 ++++++----
> > > >>  1 file changed, 6 insertions(+), 4 deletions(-)
> > > >>
> > > >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > > >> index f87cb7d3daab..b1d6fa65417d 100644
> > > >> --- a/drivers/mtd/spi-nor/core.c
> > > >> +++ b/drivers/mtd/spi-nor/core.c
> > > >> @@ -2894,13 +2894,15 @@ static const struct flash_info *spi_nor_match_name(struct spi_nor *nor,
> > > >>  static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
> > > >>                                                      const char *name)
> > > >>  {
> > > >> -     const struct flash_info *info = NULL;
> > > >> +     const struct flash_info *info = NULL, *detected_info = NULL;
> > > >>
> > > >>       if (name)
> > > >>               info = spi_nor_match_name(nor, name);
> > > >>       /* Try to auto-detect if chip name wasn't specified or not found */
> > > >> -     if (!info)
> > > >> -             info = spi_nor_read_id(nor);
> > > >> +     if (!info) {
> > > >> +             detected_info = spi_nor_read_id(nor);
> > > >> +             info = detected_info;
> > > >> +     }
> > > >>       if (IS_ERR_OR_NULL(info))
> > > >>               return ERR_PTR(-ENOENT);
> > > >>
> > > >> @@ -2908,7 +2910,7 @@ static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
> > > >>        * If caller has specified name of flash model that can normally be
> > > >>        * detected using JEDEC, let's verify it.
> > > >>        */
> > > >> -     if (name && info->id_len) {
> > > >> +     if (name && !detected_info && info->id_len) {
> > > >>               const struct flash_info *jinfo;
> > > >>
> > > >>               jinfo = spi_nor_read_id(nor);
> > > >
> > > > I think the flow can be a little bit better. How about:
> > > >
> > > >         if (name)
> > > >                 info = spi_nor_match_name();
> > > >
> > > >         if (!info) {
> > > >                 info = spi_nor_read_id();
> > > >                 if (IS_ERR_OR_NULL(info))
> > > >                         return ERR_PTR(-ENOENT);
> > > >
> > > >                 return info;
> > > >         }
> 
> +1 for the flow. But is it correct that we just ignore any former
> error and just replace it with ENOENT? Should we return NULL here
> and let the caller handle the translation from NULL to ENOENT (and
> keeping any other errors)
> 
> > > 
> > > Here we miss the IS_ERR check in case info is retrieved with
> > > spi_nor_match_name().
> > > Do you expect spi_nor_match_name() to ever return an error? As it is
> > > now it doesn't.
> > > I'm fine either way. In case you want me to follow your suggestion,
> > > give me a sign
> > > and I'll make a dedicated patch to move the IS_ERR_OR_NULL check.
> > > Will add your
> > > Suggested-by tag.
> > 
> > I think it should be safe to assume it won't ever return an error since
> > all it does is iterate over an array that is always present. I don't see
> > that changing in the foreseeable future either. So I think not having
> > the IS_ERR check is fine.
> 
> But what does it cost to just add the error check now so it won't
> be forgotten in the future?
> 
>          if (name) {
>                  info = spi_nor_match_name();
>                  if (IS_ERR(info))
>                          return info;
>          }
>          if (!info)
>                   return spi_nor_read_id();
> 
>          <flash model check code follows here>
> 
> And then let the caller handle NULL and translate it to ENOENT.

Sounds good to me.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2022-03-30 18:50 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 11:17 [PATCH v2 0/8] mtd: spi-nor: Rework Octal DTR methods Tudor Ambarus
2022-02-28 11:17 ` Tudor Ambarus
2022-02-28 11:17 ` [PATCH v2 1/8] mtd: spi-nor: Rename method, s/spi_nor_match_id/spi_nor_match_name Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 11:57   ` Pratyush Yadav
2022-03-21 11:57     ` Pratyush Yadav
2022-03-21 22:14   ` Michael Walle
2022-03-21 22:14     ` Michael Walle
2022-02-28 11:17 ` [PATCH v2 2/8] mtd: spi-nor: Introduce spi_nor_match_id() Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 12:00   ` Pratyush Yadav
2022-03-21 12:00     ` Pratyush Yadav
2022-03-21 22:15   ` Michael Walle
2022-03-21 22:15     ` Michael Walle
2022-02-28 11:17 ` [PATCH v2 3/8] mtd: spi-nor: core: Use auto-detection only once Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 12:14   ` Pratyush Yadav
2022-03-21 12:14     ` Pratyush Yadav
2022-03-21 12:50     ` Tudor.Ambarus
2022-03-21 12:50       ` Tudor.Ambarus
2022-03-21 17:42       ` Pratyush Yadav
2022-03-21 17:42         ` Pratyush Yadav
2022-03-21 22:38         ` Michael Walle
2022-03-21 22:38           ` Michael Walle
2022-03-30 18:50           ` Pratyush Yadav [this message]
2022-03-30 18:50             ` Pratyush Yadav
2022-02-28 11:17 ` [PATCH v2 4/8] mtd: spi-nor: core: Introduce method for RDID op Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 12:21   ` Pratyush Yadav
2022-03-21 12:21     ` Pratyush Yadav
2022-03-21 13:18     ` Tudor.Ambarus
2022-03-21 13:18       ` Tudor.Ambarus
2022-03-21 17:39       ` Pratyush Yadav
2022-03-21 17:39         ` Pratyush Yadav
2022-03-30  6:53         ` Tudor.Ambarus
2022-03-30  6:53           ` Tudor.Ambarus
2022-03-30 18:49           ` Pratyush Yadav
2022-03-30 18:49             ` Pratyush Yadav
2022-03-21 22:56   ` Michael Walle
2022-03-21 22:56     ` Michael Walle
2022-03-22  7:32     ` Pratyush Yadav
2022-03-22  7:32       ` Pratyush Yadav
2022-03-22  8:19       ` Michael Walle
2022-03-22  8:19         ` Michael Walle
2022-02-28 11:17 ` [PATCH v2 5/8] mtd: spi-nor: manufacturers: Use spi_nor_read_id() core method Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 12:27   ` Pratyush Yadav
2022-03-21 12:27     ` Pratyush Yadav
2022-02-28 11:17 ` [PATCH v2 6/8] mtd: spi-nor: core: Add helpers to read/write any register Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 23:13   ` Michael Walle
2022-03-21 23:13     ` Michael Walle
2022-04-11  7:29     ` Tudor.Ambarus
2022-04-11  7:29       ` Tudor.Ambarus
2022-02-28 11:17 ` [PATCH v2 7/8] mtd: spi-nor: micron-st: Rework spi_nor_micron_octal_dtr_enable() Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 12:33   ` Pratyush Yadav
2022-03-21 12:33     ` Pratyush Yadav
2022-02-28 11:17 ` [PATCH v2 8/8] mtd: spi-nor: spansion: Rework spi_nor_cypress_octal_dtr_enable() Tudor Ambarus
2022-02-28 11:17   ` Tudor Ambarus
2022-03-21 12:34   ` Pratyush Yadav
2022-03-21 12:34     ` Pratyush Yadav
2022-03-21 13:19     ` Tudor.Ambarus
2022-03-21 13:19       ` Tudor.Ambarus

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=20220330185005.ohsb4bczuyav7xzs@ti.com \
    --to=p.yadav@ti.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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.