linux-kernel - Re: [PATCH v13 09/15] mtd: spi-nor: core: enable octal DTR mode when possible

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]

Date:   Tue, 29 Sep 2020 13:05:14 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <p.yadav@...com>
CC:     <miquel.raynal@...tlin.com>, <richard@....at>, <vigneshr@...com>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <nsekhar@...com>, <boris.brezillon@...labora.com>
Subject: Re: [PATCH v13 09/15] mtd: spi-nor: core: enable octal DTR mode when
 possible

On 9/29/20 3:51 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 29/09/20 11:26AM, Tudor.Ambarus@...rochip.com wrote:
>> Hi,
>>
>> On 9/16/20 3:44 PM, Pratyush Yadav wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Allow flashes to specify a hook to enable octal DTR mode. Use this hook
>>> whenever possible to get optimal transfer speeds.
>>>
>>> Signed-off-by: Pratyush Yadav <p.yadav@...com>
>>> ---
>>>  drivers/mtd/spi-nor/core.c | 35 +++++++++++++++++++++++++++++++++++
>>>  drivers/mtd/spi-nor/core.h |  2 ++
>>>  2 files changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>> index 87c568debf14..6ee93544d72f 100644
>>> --- a/drivers/mtd/spi-nor/core.c
>>> +++ b/drivers/mtd/spi-nor/core.c
>>> @@ -3069,6 +3069,35 @@ static int spi_nor_init_params(struct spi_nor *nor)
>>>         return 0;
>>>  }
>>>
>>> +/** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
>>> + * @nor:                 pointer to a 'struct spi_nor'
>>> + * @enable:              whether to enable or disable Octal DTR
>>> + *
>>> + * Return: 0 on success, -errno otherwise.
>>> + */
>>> +static int spi_nor_octal_dtr_enable(struct spi_nor *nor, bool enable)
>>> +{
>>> +       int ret;
>>> +
>>> +       if (!nor->params->octal_dtr_enable)
>>> +               return 0;
>>> +
>>> +       if (!(nor->read_proto == SNOR_PROTO_8_8_8_DTR &&
>>> +             nor->write_proto == SNOR_PROTO_8_8_8_DTR))
>>> +               return 0;
>>> +
>>> +       ret = nor->params->octal_dtr_enable(nor, enable);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       if (enable)
>>> +               nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
>>> +       else
>>> +               nor->reg_proto = SNOR_PROTO_1_1_1;
>>> +
>>> +       return 0;
>>> +}
>>> +
>>>  /**
>>>   * spi_nor_quad_enable() - enable/disable Quad I/O if needed.
>>>   * @nor:                pointer to a 'struct spi_nor'
>>> @@ -3109,6 +3138,12 @@ static int spi_nor_init(struct spi_nor *nor)
>>>  {
>>>         int err;
>>>
>>> +       err = spi_nor_octal_dtr_enable(nor, true);
>>> +       if (err) {
>>> +               dev_dbg(nor->dev, "octal mode not supported\n");
>>> +               return err;
>>> +       }
>>> +
>>>         err = spi_nor_quad_enable(nor, true);
>>
>> Is it possible to enable octal dtr and quad at the same time?
>> Maybe an 'if/else if' here depending on the values of nor->read_proto and
>> nor->write_proto
> 
> No it is not. If you look inside spi_nor_octal_dtr_enable() and
> spi_nor_quad_enable(), they both are a no-op if the protocol does not
> match. spi_nor_quad_enable() was already doing it this way so I made
> spi_nor_octal_dtr_enable() follow suit. So this is effectively an
> if-else on the value of nor->read_proto. I don't think an explicit one
> is needed.

you're right! thanks