lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9db2f4c2-cc41-9c06-e0ec-7480529cad13@gmail.com>
Date:   Fri, 29 Jul 2022 10:00:08 +0900
From:   Takahiro Kuwano <tkuw584924@...il.com>
To:     Michael Walle <michael@...le.cc>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Pratyush Yadav <p.yadav@...com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>
Cc:     linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 3/6] mtd: spi-nor: remember full JEDEC flash ID

On 5/13/2022 10:35 PM, Michael Walle wrote:
> At the moment, we print the JEDEC ID that is stored in our database. The
> generic flash support won't have such an entry in our database. To find
> out the JEDEC ID later we will have to cache it. There is also another
> advantage: If the flash is found in the database, the ID could be
> truncated because the ID of the entry is used which can be shorter. Some
> flashes still holds valuable information in the bytes after the JEDEC ID
> and come in handy during debugging of when coping with INFO6() entries.
> These are not accessible for now.
> 
> Save a copy of the ID bytes after reading and display it via debugfs.
> 
> Signed-off-by: Michael Walle <michael@...le.cc>
> ---
>  drivers/mtd/spi-nor/core.c    | 5 +++++
>  drivers/mtd/spi-nor/debugfs.c | 2 +-
>  include/linux/mtd/spi-nor.h   | 3 +++
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ce5d69317d46..65cd8e668579 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1664,6 +1664,11 @@ static const struct flash_info *spi_nor_detect(struct spi_nor *nor)
>  		return ERR_PTR(ret);
>  	}
>  
> +	/* Cache the complete flash ID. */
> +	nor->id = devm_kmemdup(nor->dev, id, SPI_NOR_MAX_ID_LEN, GFP_KERNEL);
> +	if (!nor->id)
> +		return ERR_PTR(-ENOMEM);
> +
>  	info = spi_nor_match_id(nor, id);
>  	if (!info) {
>  		dev_err(nor->dev, "unrecognized JEDEC id bytes: %*ph\n",
> diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
> index eaf84f7a0676..23d51e7ba0a7 100644
> --- a/drivers/mtd/spi-nor/debugfs.c
> +++ b/drivers/mtd/spi-nor/debugfs.c
> @@ -81,7 +81,7 @@ static int spi_nor_params_show(struct seq_file *s, void *data)
>  	int i;
>  
>  	seq_printf(s, "name\t\t%s\n", info->name);
> -	seq_printf(s, "id\t\t%*ph\n", info->id_len, info->id);
> +	seq_printf(s, "id\t\t%*ph\n", SPI_NOR_MAX_ID_LEN, nor->id);
>  	string_get_size(params->size, 1, STRING_UNITS_2, buf, sizeof(buf));
>  	seq_printf(s, "size\t\t%s\n", buf);
>  	seq_printf(s, "write size\t%u\n", params->writesize);
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 1ede4c89805a..4dd6cd7389ca 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -349,6 +349,8 @@ struct spi_nor_flash_parameter;
>   * @bouncebuf:		bounce buffer used when the buffer passed by the MTD
>   *                      layer is not DMA-able
>   * @bouncebuf_size:	size of the bounce buffer
> + * @id:			The flash's ID bytes. Always contains
> + *			SPI_NOR_MAX_ID_LEN bytes.
>   * @info:		SPI NOR part JEDEC MFR ID and other info
>   * @manufacturer:	SPI NOR manufacturer
>   * @addr_width:		number of address bytes
> @@ -379,6 +381,7 @@ struct spi_nor {
>  	struct spi_mem		*spimem;
>  	u8			*bouncebuf;
>  	size_t			bouncebuf_size;
> +	u8			*id;
>  	const struct flash_info	*info;
>  	const struct spi_nor_manufacturer *manufacturer;
>  	u8			addr_width;

Reviewed-by: Takahiro Kuwano <Takahiro.Kuwano@...ineon.com>

Thanks,
Takahiro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ