All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: <Tudor.Ambarus@microchip.com>
Cc: <marek.vasut@gmail.com>, <dwmw2@infradead.org>,
	<computersforpeace@gmail.com>, <richard@nod.at>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<yogeshnarayan.gaur@nxp.com>, <cyrille.pitchen@wedev4u.fr>
Subject: Re: [PATCH 3/7] mtd: spi-nor: add restriction for nmaps in smpt parser
Date: Thu, 8 Nov 2018 15:15:09 +0100	[thread overview]
Message-ID: <20181108151509.364e3a85@bbrezillon> (raw)
In-Reply-To: <86d16e39-15df-c12c-7bf3-25996db0c3a9@microchip.com>

On Thu, 8 Nov 2018 13:58:45 +0000
<Tudor.Ambarus@microchip.com> wrote:

> On 11/08/2018 02:54 PM, Boris Brezillon wrote:
> > On Thu, 8 Nov 2018 11:07:11 +0000
> > <Tudor.Ambarus@microchip.com> wrote:
> >   
> >> The map selector is limited to a maximum of 8 bits, allowing
> >> for a maximum of 256 possible map configurations. The total
> >> number of map configurations should be addressable by the
> >> total number of bits described by the detection commands.
> >>
> >> For example: if there are five to eight possible sector map
> >> configurations, at least three configuration detection commands
> >> will be needed to extract three bits of configuration selection
> >> information from the device in order to identify which configuration
> >> is currently in use.
> >>
> >> Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com>  
> > 
> > I don't remember suggesting this :-).  
> 
> I see this when you discussed with Yogesh:
> 
> +       for (nmaps = 0; i< smpt_len; nmaps++) {
> +               if(!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> +                       i += 2;
> +                       continue;
> +               }
> +
> +               if(!map_id_is_valid) {
> +                       if (nmaps) {
> +                               ret = NULL;
> +                               break;
> +                       }
> 
> If I understand correctly, you meant that if there are no detection commands,
> and more than a configuration map, then return an error.

Yes, because in this case we have no way to know what config is
currently selected.

> 
> This is correct in my opinion. What I did was to generalize this idea. If smtp
> defines more maps than you can select using detection commands, return error.

AFAICT you're no longer checking that map_id is valid (see below).

> 
> +
> +                       ret = smpt+i;
> +               } else if (map_id == SMPT_MAP_ID(smpt[i])) {
> +                       ret = smpt+i;
> +                       break;
> +               }
> +
>                 /* increment the table index to the next map */
>                 i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
>         }
> 
> >   
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> >> ---
> >>  drivers/mtd/spi-nor/spi-nor.c | 15 +++++++++++++--
> >>  1 file changed, 13 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> >> index 59dcedb08691..bd1866d714f2 100644
> >> --- a/drivers/mtd/spi-nor/spi-nor.c
> >> +++ b/drivers/mtd/spi-nor/spi-nor.c
> >> @@ -2868,7 +2868,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
> >>  	const u32 *ret = NULL;
> >>  	u32 addr;
> >>  	int err;
> >> -	u8 i;
> >> +	u8 i, ncmds, nmaps;
> >>  	u8 addr_width, read_opcode, read_dummy;
> >>  	u8 read_data_mask, data_byte, map_id;
> >>  
> >> @@ -2877,6 +2877,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
> >>  	read_opcode = nor->read_opcode;
> >>  
> >>  	map_id = 0;
> >> +	ncmds = 0;
> >>  	/* Determine if there are any optional Detection Command Descriptors */
> >>  	for (i = 0; i < smpt_len; i += 2) {
> >>  		if (smpt[i] & SMPT_DESC_TYPE_MAP)
> >> @@ -2896,6 +2897,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
> >>  		 * Configuration that is currently in use.
> >>  		 */
> >>  		map_id = map_id << 1 | !!(data_byte & read_data_mask);
> >> +		ncmds++;
> >>  	}
> >>  
> >>  	/*
> >> @@ -2905,7 +2907,16 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
> >>  	 *
> >>  	 * Find the matching configuration map.
> >>  	 */
> >> -	while (i < smpt_len) {
> >> +	for (nmaps = 0; i < smpt_len; nmaps++) {
> >> +		/*
> >> +		 * The map selector is limited to a maximum of 8 bits, allowing
> >> +		 * for a maximum of 256 possible map configurations. The total
> >> +		 * number of map configurations should be addressable by the
> >> +		 * total number of bits described by the detection commands.
> >> +		 */
> >> +		if (ncmds && nmaps >= (1 << (ncmds + 1)))
> >> +			break;

You're no longer checking that when ncmds == 0 nmaps has to be 1. So,
say the chip exposed no smpt commands and has several maps defined,
map_id will be 0 while it should have be "undefined". My version
would return an error, but yours tries to find map_id 0.

> >> +  
> > 
> > Maybe I missed something but it sounds like this change is just
> > optimizing the SPMT parsing a bit, and to be honest, I'm not sure this
> > is really needed. Most of the time, smpt_len will be rather small, so
> > trying to bail out earlier is not bringing much perf improvements.  
> 
> It's rather a smtp validity check. I want to return an error if there are not
> enough detection commands to identify the map id.

You would have failed the same way without this validity check after a
maximum of smpt_len iterations, right?

  reply	other threads:[~2018-11-08 14:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 11:07 [PATCH 0/7] mtd: spi-nor: fixes found when debugging smpt Tudor.Ambarus
2018-11-08 11:07 ` [PATCH 1/7] mtd: spi-nor: don't drop sfdp data if optional parsers fail Tudor.Ambarus
2018-11-08 11:07 ` [PATCH 2/7] mtd: spi-nor: fix iteration over smpt array Tudor.Ambarus
2018-11-08 12:50   ` Boris Brezillon
2018-11-08 11:07 ` [PATCH 3/7] mtd: spi-nor: add restriction for nmaps in smpt parser Tudor.Ambarus
2018-11-08 12:54   ` Boris Brezillon
2018-11-08 13:08     ` Boris Brezillon
2018-11-08 13:58     ` Tudor.Ambarus
2018-11-08 14:15       ` Boris Brezillon [this message]
2018-11-08 14:48         ` Tudor.Ambarus
2018-11-08 14:54           ` Boris Brezillon
2018-11-08 15:00             ` Tudor.Ambarus
2018-11-08 11:07 ` [PATCH 4/7] mtd: spi-nor: don't overwrite errno in spi_nor_get_map_in_use() Tudor.Ambarus
2018-11-08 11:07 ` [PATCH 5/7] mtd: spi_nor: pass DMA-able buffer to spi_nor_read_raw() Tudor.Ambarus
2018-11-08 13:01   ` Boris Brezillon
2018-11-08 11:07 ` [PATCH 6/7] mtd: spi-nor: ensure memory used for nor->read() is DMA safe Tudor.Ambarus
2018-11-08 13:03   ` Boris Brezillon
2018-11-08 11:07 ` [PATCH 7/7] mtd: spi-nor: remove unneeded smpt zeroization 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=20181108151509.364e3a85@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    --cc=yogeshnarayan.gaur@nxp.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.