| 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
| ||
|
Date: Wed, 28 Oct 2020 09:45:30 +0000
From: <Tudor.Ambarus@...rochip.com>
To: <masonccyang@...c.com.tw>, <broonie@...nel.org>,
<miquel.raynal@...tlin.com>, <richard@....at>, <vigneshr@...com>,
<boris.brezillon@...labora.com>, <matthias.bgg@...il.com>
CC: <juliensu@...c.com.tw>, <linux-kernel@...r.kernel.org>,
<linux-spi@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
<p.yadav@...com>, <ycllin@...c.com.tw>
Subject: Re: [PATCH v4 3/7] mtd: spi-nor: sfdp: parse command sequences to
change octal DTR mode
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> A set of simple command sequences is provided which can be executed
> directly by the host controller to enable octal DTR mode.
>
> Each command sequence is 8 per byte for single SPI mode.
>
> Signed-off-by: Mason Yang <masonccyang@...c.com.tw>
> ---
> drivers/mtd/spi-nor/core.h | 20 +++++++++
> drivers/mtd/spi-nor/sfdp.c | 104 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index a33f807..8de7f53 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -183,6 +183,23 @@ struct spi_nor_locking_ops {
> };
>
> /**
> + * struct cmd_seq_octal_dtr - command sequences to change to octal DTR mode
> + * Each command sequence is 8 per byte for single SPI mode.
> + * @len: commmand length of each command sequence.
> + * @opcode: command code.
> + * @addr: address offset to device.
> + * @data: data write to device.
> + */
> +struct cmd_seq_octal_dtr {
> + u8 len;
> + u8 opcode;
> + u32 addr;
> + u8 data;
> +};
You define seven bytes for the command sequence, while the table defines
eight bytes: first byte indicates the length of the sequence, and the
following seven bytes are values to be output by the controller.
How did you choose this cmd seq organization? The standard refers to the
7-byte sequence as "byte values to be output by the controller", it doesn't
indicate at which offset the opcode, addr and data are.
> +
> +#define CMD_SEQ_NUM 4
> +
> +/**
> * struct spi_nor_flash_parameter - SPI NOR flash parameters and settings.
> * Includes legacy flash parameters and settings that can be overwritten
> * by the spi_nor_fixups hooks, or dynamically when parsing the JESD216
> @@ -205,6 +222,7 @@ struct spi_nor_locking_ops {
> * higher index in the array, the higher priority.
> * @erase_map: the erase map parsed from the SFDP Sector Map Parameter
> * Table.
> + * @cmd_seq: command sequence to change to octal DTR mode.
> * @quad_enable: enables SPI NOR quad mode.
> * @set_4byte_addr_mode: puts the SPI NOR in 4 byte addressing mode.
> * @convert_addr: converts an absolute address into something the flash
> @@ -232,6 +250,8 @@ struct spi_nor_flash_parameter {
>
> struct spi_nor_erase_map erase_map;
>
> + struct cmd_seq_octal_dtr cmd_seq[CMD_SEQ_NUM];
> +
> int (*quad_enable)(struct spi_nor *nor);
> int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
> u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 27a4de4..ef19290 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -21,6 +21,7 @@
> #define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
> #define SFDP_4BAIT_ID 0xff84 /* 4-byte Address Instruction Table */
> #define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
> +#define SFDP_CMD_TO_8DTR_ID 0xff0a /* Command Sequences to Octal DTR */
>
> #define SFDP_SIGNATURE 0x50444653U
> #define SFDP_JESD216_MAJOR 1
> @@ -49,6 +50,19 @@ struct xspi_dummy_cycles {
> u8 shift; /* Bit shift */
> };
>
> +#define CMD_TO_8DTR_LEN GENMASK(31, 24)
> +#define CMD_TO_8DTR_OPCODE GENMASK(23, 16)
> +#define CMD_TO_8DTR_1_ADDR GENMASK(15, 8)
> +#define CMD_TO_8DTR_1_ADDR_DATA GENMASK(7, 0)
> +#define CMD_TO_8DTR_4_ADDR_MSB GENMASK(15, 0)
> +#define CMD_TO_8DTR_4_ADDR_LSB GENMASK(31, 16)
> +#define CMD_TO_8DTR_4_ADDR_DATA GENMASK(15, 8)
> +#define CMD_TO_8DTR_SIZE_MAX 8
> +
> +struct sfdp_cmd_to_8dtr {
> + u32 dwords[CMD_TO_8DTR_SIZE_MAX];
> +};
> +
> /* Basic Flash Parameter Table 20th DWORD, Max operation speed of device */
> struct octal_max_speed {
> u8 idx; /* Bits value */
> @@ -1219,6 +1233,91 @@ static int spi_nor_parse_profile1(struct spi_nor *nor,
> }
>
> /**
> + * spi_nor_parse_cmd_to_8dtr() - parse the command sequence to octal DTR
> + * @nor: pointer to a 'struct spi_nor'
> + * @param_header: command sequence to octal DTR parameter table header.
> + * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +static int spi_nor_parse_cmd_to_8dtr(struct spi_nor *nor,
> + const struct sfdp_parameter_header *header,
> + struct spi_nor_flash_parameter *params)
> +{
> + struct sfdp_cmd_to_8dtr cmd_seq;
you'll need to kmalloc cmd_seq because spi_nor_read_sfdp expects a DMA-able
buffer.
> + u32 i, j, addr;
> + size_t len;
> + int ret;
> +
> + if (header->major != SFDP_JESD216_MAJOR ||
> + header->length < CMD_TO_8DTR_SIZE_MAX)
> + return -EINVAL;
> +
> + len = min_t(size_t, sizeof(cmd_seq),
> + header->length * sizeof(u32));
> +
> + memset(&cmd_seq, 0, sizeof(cmd_seq));
no need to set the contents to zero, cmd_seq will be overwritten with
the values read from sfdp.
> +
> + addr = SFDP_PARAM_HEADER_PTP(header);
> + ret = spi_nor_read_sfdp(nor, addr, len, &cmd_seq);
> + if (ret)
> + goto out;
> +
> + /* Fix endianness of the Command Sequences to octal DTR. */
> + le32_to_cpu_array(cmd_seq.dwords, CMD_TO_8DTR_SIZE_MAX);
> +
> + memset(params->cmd_seq, 0, sizeof(params->cmd_seq[CMD_SEQ_NUM]));
params->cmd_seq is already filled with zeroes, no need to memset its
contents to zero
> +
> + for (i = 0, j = 0;
> + i < CMD_SEQ_NUM && j < CMD_TO_8DTR_SIZE_MAX; i++, j += 2) {
> + params->cmd_seq[i].len = FIELD_GET(CMD_TO_8DTR_LEN,
> + cmd_seq.dwords[j]);
> + if (!params->cmd_seq[i].len)
> + break;
> +
> + switch (params->cmd_seq[i].len) {
> + case 1:
> + params->cmd_seq[i].opcode =
> + FIELD_GET(CMD_TO_8DTR_OPCODE,
> + cmd_seq.dwords[j]);
> + break;
> +
> + case 3:
> + params->cmd_seq[i].opcode =
> + FIELD_GET(CMD_TO_8DTR_OPCODE,
> + cmd_seq.dwords[j]);
> + params->cmd_seq[i].addr =
> + FIELD_GET(CMD_TO_8DTR_1_ADDR,
> + cmd_seq.dwords[j]);
> + params->cmd_seq[i].data =
> + FIELD_GET(CMD_TO_8DTR_1_ADDR_DATA,
> + cmd_seq.dwords[j]);
> + break;
> +
> + case 6:
> + params->cmd_seq[i].opcode =
> + FIELD_GET(CMD_TO_8DTR_OPCODE,
> + cmd_seq.dwords[j]);
> + params->cmd_seq[i].addr =
> + FIELD_GET(CMD_TO_8DTR_4_ADDR_MSB,
> + cmd_seq.dwords[j]) << 16 |
> + FIELD_GET(CMD_TO_8DTR_4_ADDR_LSB,
> + cmd_seq.dwords[j + 1]);
> + params->cmd_seq[i].data =
> + FIELD_GET(CMD_TO_8DTR_4_ADDR_DATA,
> + cmd_seq.dwords[j + 1]);
> + break;
how should we treat case 2, 5 and 7? From where the assumptions on how
data is organized in the cmd sequence?
Thanks,
ta
> +
> + default:
> + break;
> + }
> + }
> +
> +out:
> + return ret;
> +}
> +
> +/**
> * spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters.
> * @nor: pointer to a 'struct spi_nor'
> * @params: pointer to the 'struct spi_nor_flash_parameter' to be
> @@ -1323,6 +1422,11 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
> err = spi_nor_parse_profile1(nor, param_header, params);
> break;
>
> + case SFDP_CMD_TO_8DTR_ID:
> + err = spi_nor_parse_cmd_to_8dtr(nor,
> + param_header, params);
> + break;
> +
> default:
> break;
> }
>
Powered by blists - more mailing lists