All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>, <p.yadav@ti.com>
Cc: <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<Nicolas.Ferre@microchip.com>, <Takahiro.Kuwano@infineon.com>
Subject: Re: [PATCH v3 6/9] mtd: spi-nor: core: Add helpers to read/write any register
Date: Tue, 19 Apr 2022 12:56:24 +0000	[thread overview]
Message-ID: <89083a31-b862-de50-fdca-d427fb908a08@microchip.com> (raw)
In-Reply-To: <996f36b1303d191e472f56393aa6398e@walle.cc>

On 4/19/22 15:46, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2022-04-19 14:32, schrieb Pratyush Yadav:
>> On 19/04/22 12:08PM, Tudor.Ambarus@microchip.com wrote:
>>> On 4/19/22 14:46, Michael Walle wrote:
>>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>> >
>>> > Am 2022-04-19 13:19, schrieb Michael Walle:
>>> >> Am 2022-04-11 11:10, schrieb Tudor Ambarus:
>>> >>> There are manufacturers that use registers indexed by address. Some of
>>> >>> them support "read/write any register" opcodes. Provide core methods
>>> >>> that
>>> >>> can be used by all manufacturers. SPI NOR controller ops are
>>> >>> intentionally
>>> >>> not supported as we intend to move all the SPI NOR controller drivers
>>> >>> under the SPI subsystem.
>>> >>>
>>> >>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>>> >>> Tested-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
>>> >>> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
>>> >>
>>> >> I still don't like it because the function doesn't do
>>> >> anything what the function name might suggest. The read
>>> >> just executes an op, the write executes an op with a
>>> >> write enable before. All the behavior is determined by the
>>> >> 'op' argument.
>>> >>
>>> >> Anyway,
>>> >> Reviewed-by: Michael Walle <michael@walle.cc>
>>> >>
>>> >>> ---
>>> >>> v3: no changes
>>> >>>
>>> >>>  drivers/mtd/spi-nor/core.c | 41
>>> >>> ++++++++++++++++++++++++++++++++++++++
>>> >>>  drivers/mtd/spi-nor/core.h |  4 ++++
>>> >>>  2 files changed, 45 insertions(+)
>>> >>>
>>> >>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>> >>> index 6165dc7bfd17..42794328d3b6 100644
>>> >>> --- a/drivers/mtd/spi-nor/core.c
>>> >>> +++ b/drivers/mtd/spi-nor/core.c
>>> >>> @@ -307,6 +307,47 @@ ssize_t spi_nor_write_data(struct spi_nor *nor,
>>> >>> loff_t to, size_t len,
>>> >>>      return nor->controller_ops->write(nor, to, len, buf);
>>> >>>  }
>>> >>>
>>> >>> +/**
>>> >>> + * spi_nor_read_reg() - read register to flash memory
>>> >>> + * @nor:        pointer to 'struct spi_nor'.
>>> >>> + * @op:             SPI memory operation. op->data.buf must be DMA-able.
>>> >>> + * @proto:  SPI protocol to use for the register operation.
>>> >>> + *
>>> >>> + * Return: zero on success, -errno otherwise
>>> >>> + */
>>> >>> +int spi_nor_read_reg(struct spi_nor *nor, struct spi_mem_op *op,
>>> >>> +                 enum spi_nor_protocol proto)
>>> >>> +{
>>> >>> +    if (!nor->spimem)
>>> >>> +            return -EOPNOTSUPP;
>>> >>> +
>>> >>> +    spi_nor_spimem_setup_op(nor, op, proto);
>>> >>> +    return spi_nor_spimem_exec_op(nor, op);
>>> >>> +}
>>> >>> +
>>> >>> +/**
>>> >>> + * spi_nor_write_reg() - write register to flash memory
>>> >>> + * @nor:        pointer to 'struct spi_nor'
>>> >>> + * @op:             SPI memory operation. op->data.buf must be DMA-able.
>>> >>> + * @proto:  SPI protocol to use for the register operation.
>>> >>> + *
>>> >>> + * Return: zero on success, -errno otherwise
>>> >>> + */
>>> >>> +int spi_nor_write_reg(struct spi_nor *nor, struct spi_mem_op *op,
>>> >>> +                  enum spi_nor_protocol proto)
>>> >>> +{
>>> >>> +    int ret;
>>> >>> +
>>> >>> +    if (!nor->spimem)
>>> >>> +            return -EOPNOTSUPP;
>>> >>> +
>>> >>> +    ret = spi_nor_write_enable(nor);
>>> >>> +    if (ret)
>>> >>> +            return ret;
>>> >>> +    spi_nor_spimem_setup_op(nor, op, proto);
>>> >>> +    return spi_nor_spimem_exec_op(nor, op);
>>> >
>>> > After seeing your next two patches. Shouldn't the
>>> > spi_nor_wait_until_ready() call be here too?
>>> >
>>>
>>> I thought of this too, but seems that for a reason that I don't
>>> remember, we don't call for spi_nor_wait_until_ready after we
>>> write the octal DTR bit. Pratyush, do you remember why?
>>
>> We are not sure the protocol changed correctly so we can't rely on
>> spi_nor_wait_until_ready(). We read the ID instead to be sure.
> 
> So besides the fact that the write_reg only works with the 'correct'
> op parameter, it is also tailored to the special use case. For real
> write_reg(), the user would actually has to poll the status bit
> afterwards? :(
> 
Don't be sad :D. Are the octal DTR methods an exception?
If yes, let's add the call to spi_nor_wait_until_ready() in the
read/write_any_reg() methods, and let the octal methods handle
the specific write themselves, without calling for ready()

Cheers,
ta

WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>, <p.yadav@ti.com>
Cc: <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<Nicolas.Ferre@microchip.com>, <Takahiro.Kuwano@infineon.com>
Subject: Re: [PATCH v3 6/9] mtd: spi-nor: core: Add helpers to read/write any register
Date: Tue, 19 Apr 2022 12:56:24 +0000	[thread overview]
Message-ID: <89083a31-b862-de50-fdca-d427fb908a08@microchip.com> (raw)
In-Reply-To: <996f36b1303d191e472f56393aa6398e@walle.cc>

On 4/19/22 15:46, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2022-04-19 14:32, schrieb Pratyush Yadav:
>> On 19/04/22 12:08PM, Tudor.Ambarus@microchip.com wrote:
>>> On 4/19/22 14:46, Michael Walle wrote:
>>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>> >
>>> > Am 2022-04-19 13:19, schrieb Michael Walle:
>>> >> Am 2022-04-11 11:10, schrieb Tudor Ambarus:
>>> >>> There are manufacturers that use registers indexed by address. Some of
>>> >>> them support "read/write any register" opcodes. Provide core methods
>>> >>> that
>>> >>> can be used by all manufacturers. SPI NOR controller ops are
>>> >>> intentionally
>>> >>> not supported as we intend to move all the SPI NOR controller drivers
>>> >>> under the SPI subsystem.
>>> >>>
>>> >>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>>> >>> Tested-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
>>> >>> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
>>> >>
>>> >> I still don't like it because the function doesn't do
>>> >> anything what the function name might suggest. The read
>>> >> just executes an op, the write executes an op with a
>>> >> write enable before. All the behavior is determined by the
>>> >> 'op' argument.
>>> >>
>>> >> Anyway,
>>> >> Reviewed-by: Michael Walle <michael@walle.cc>
>>> >>
>>> >>> ---
>>> >>> v3: no changes
>>> >>>
>>> >>>  drivers/mtd/spi-nor/core.c | 41
>>> >>> ++++++++++++++++++++++++++++++++++++++
>>> >>>  drivers/mtd/spi-nor/core.h |  4 ++++
>>> >>>  2 files changed, 45 insertions(+)
>>> >>>
>>> >>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>> >>> index 6165dc7bfd17..42794328d3b6 100644
>>> >>> --- a/drivers/mtd/spi-nor/core.c
>>> >>> +++ b/drivers/mtd/spi-nor/core.c
>>> >>> @@ -307,6 +307,47 @@ ssize_t spi_nor_write_data(struct spi_nor *nor,
>>> >>> loff_t to, size_t len,
>>> >>>      return nor->controller_ops->write(nor, to, len, buf);
>>> >>>  }
>>> >>>
>>> >>> +/**
>>> >>> + * spi_nor_read_reg() - read register to flash memory
>>> >>> + * @nor:        pointer to 'struct spi_nor'.
>>> >>> + * @op:             SPI memory operation. op->data.buf must be DMA-able.
>>> >>> + * @proto:  SPI protocol to use for the register operation.
>>> >>> + *
>>> >>> + * Return: zero on success, -errno otherwise
>>> >>> + */
>>> >>> +int spi_nor_read_reg(struct spi_nor *nor, struct spi_mem_op *op,
>>> >>> +                 enum spi_nor_protocol proto)
>>> >>> +{
>>> >>> +    if (!nor->spimem)
>>> >>> +            return -EOPNOTSUPP;
>>> >>> +
>>> >>> +    spi_nor_spimem_setup_op(nor, op, proto);
>>> >>> +    return spi_nor_spimem_exec_op(nor, op);
>>> >>> +}
>>> >>> +
>>> >>> +/**
>>> >>> + * spi_nor_write_reg() - write register to flash memory
>>> >>> + * @nor:        pointer to 'struct spi_nor'
>>> >>> + * @op:             SPI memory operation. op->data.buf must be DMA-able.
>>> >>> + * @proto:  SPI protocol to use for the register operation.
>>> >>> + *
>>> >>> + * Return: zero on success, -errno otherwise
>>> >>> + */
>>> >>> +int spi_nor_write_reg(struct spi_nor *nor, struct spi_mem_op *op,
>>> >>> +                  enum spi_nor_protocol proto)
>>> >>> +{
>>> >>> +    int ret;
>>> >>> +
>>> >>> +    if (!nor->spimem)
>>> >>> +            return -EOPNOTSUPP;
>>> >>> +
>>> >>> +    ret = spi_nor_write_enable(nor);
>>> >>> +    if (ret)
>>> >>> +            return ret;
>>> >>> +    spi_nor_spimem_setup_op(nor, op, proto);
>>> >>> +    return spi_nor_spimem_exec_op(nor, op);
>>> >
>>> > After seeing your next two patches. Shouldn't the
>>> > spi_nor_wait_until_ready() call be here too?
>>> >
>>>
>>> I thought of this too, but seems that for a reason that I don't
>>> remember, we don't call for spi_nor_wait_until_ready after we
>>> write the octal DTR bit. Pratyush, do you remember why?
>>
>> We are not sure the protocol changed correctly so we can't rely on
>> spi_nor_wait_until_ready(). We read the ID instead to be sure.
> 
> So besides the fact that the write_reg only works with the 'correct'
> op parameter, it is also tailored to the special use case. For real
> write_reg(), the user would actually has to poll the status bit
> afterwards? :(
> 
Don't be sad :D. Are the octal DTR methods an exception?
If yes, let's add the call to spi_nor_wait_until_ready() in the
read/write_any_reg() methods, and let the octal methods handle
the specific write themselves, without calling for ready()

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

  reply	other threads:[~2022-04-19 12:56 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11  9:10 [PATCH v3 0/9] mtd: spi-nor: Rework Octal DTR methods Tudor Ambarus
2022-04-11  9:10 ` Tudor Ambarus
2022-04-11  9:10 ` [PATCH v3 1/9] mtd: spi-nor: Rename method, s/spi_nor_match_id/spi_nor_match_name Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-11  9:10 ` [PATCH v3 2/9] mtd: spi-nor: Introduce spi_nor_match_id() Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-11  9:10 ` [PATCH v3 3/9] mtd: spi-nor: core: Use auto-detection only once Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 10:18   ` Michael Walle
2022-04-19 10:18     ` Michael Walle
2022-04-11  9:10 ` [PATCH v3 4/9] mtd: spi-nor: core: Introduce method for RDID op Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 11:10   ` Michael Walle
2022-04-19 11:10     ` Michael Walle
2022-04-11  9:10 ` [PATCH v3 5/9] mtd: spi-nor: manufacturers: Use spi_nor_read_id() core method Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 11:14   ` Michael Walle
2022-04-19 11:14     ` Michael Walle
2022-04-11  9:10 ` [PATCH v3 6/9] mtd: spi-nor: core: Add helpers to read/write any register Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 11:19   ` Michael Walle
2022-04-19 11:19     ` Michael Walle
2022-04-19 11:46     ` Michael Walle
2022-04-19 11:46       ` Michael Walle
2022-04-19 12:08       ` Tudor.Ambarus
2022-04-19 12:08         ` Tudor.Ambarus
2022-04-19 12:32         ` Pratyush Yadav
2022-04-19 12:32           ` Pratyush Yadav
2022-04-19 12:46           ` Michael Walle
2022-04-19 12:46             ` Michael Walle
2022-04-19 12:56             ` Tudor.Ambarus [this message]
2022-04-19 12:56               ` Tudor.Ambarus
2022-04-20  4:34               ` Pratyush Yadav
2022-04-20  4:34                 ` Pratyush Yadav
2022-04-20  5:20                 ` Takahiro Kuwano
2022-04-20  5:20                   ` Takahiro Kuwano
2022-04-20  5:25                 ` Tudor.Ambarus
2022-04-20  5:25                   ` Tudor.Ambarus
2022-04-19 13:02           ` Tudor.Ambarus
2022-04-19 13:02             ` Tudor.Ambarus
2022-04-19 12:59     ` Tudor.Ambarus
2022-04-19 12:59       ` Tudor.Ambarus
2022-04-11  9:10 ` [PATCH v3 7/9] mtd: spi-nor: micron-st: Rework spi_nor_micron_octal_dtr_enable() Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 11:43   ` Michael Walle
2022-04-19 11:43     ` Michael Walle
2022-04-11  9:10 ` [PATCH v3 8/9] mtd: spi-nor: spansion: Rework spi_nor_cypress_octal_dtr_enable() Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 11:44   ` Michael Walle
2022-04-19 11:44     ` Michael Walle
2022-04-11  9:10 ` [PATCH v3 9/9] mtd: spi-nor: Introduce templates for SPI NOR operations Tudor Ambarus
2022-04-11  9:10   ` Tudor Ambarus
2022-04-19 11:45   ` Michael Walle
2022-04-19 11:45     ` Michael Walle
2022-04-20  7:49     ` Pratyush Yadav
2022-04-20  7:49       ` Pratyush Yadav

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=89083a31-b862-de50-fdca-d427fb908a08@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Takahiro.Kuwano@infineon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.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.