All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Pratyush Yadav <p.yadav@ti.com>, Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org,
	Julien Su <juliensu@mxic.com.tw>,
	Jaime Liao <jaimeliao@mxic.com.tw>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Xiangsheng Hou <xiangsheng.hou@mediatek.com>
Subject: Re: [PATCH v5 12/13] spi: mxic: Use spi_mem_generic_supports_op()
Date: Thu, 16 Dec 2021 10:01:47 +0100	[thread overview]
Message-ID: <20211216100147.46c307ff@xps13> (raw)
In-Reply-To: <Ybo/r8neydqTxN6N@sirena.org.uk>

Hi Mark,

broonie@kernel.org wrote on Wed, 15 Dec 2021 19:19:11 +0000:

> On Wed, Dec 15, 2021 at 08:05:48PM +0100, Boris Brezillon wrote:
> 
> > There's also a second option that doesn't involve patching existing
> > users: add a spi_mem_controller_caps to the spi_controller struct, and
> > check this instance in your spi_mem_default_supports_op()
> > implementation. Note that the buswidth check done in the generic
> > helper is already based on caps exposed by the controller
> > through spi_controller.mode_bits ({RX/TX}_{DUAL,QUAD,OCTAL} bits).  
> 
> This approach is quite nice for things like this - having things as data
> rather than code.  The only issue is if any of the caps end up varying
> by operation and we need different capabilities but that doesn't look
> too likely here I think?

Indeed that was the main point of the original review from Boris, the
capabilities should be fixed on the controller's lifetime. So I believe
we are safe.

I think I am going to propose the following:
	const struct spi_controller_mem_ops *mem_ops;
+	struct spi_controller_mem_caps mem_caps;

As the structure is not supposed to enlarge dramatically in the near
future, I guess it's fine to have it defined statically. Please tell me
if you prefer a *mem_caps pointer.

I'll send a proposal soon.

Thanks,
Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Pratyush Yadav <p.yadav@ti.com>, Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org,
	Julien Su <juliensu@mxic.com.tw>,
	Jaime Liao <jaimeliao@mxic.com.tw>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Xiangsheng Hou <xiangsheng.hou@mediatek.com>
Subject: Re: [PATCH v5 12/13] spi: mxic: Use spi_mem_generic_supports_op()
Date: Thu, 16 Dec 2021 10:01:47 +0100	[thread overview]
Message-ID: <20211216100147.46c307ff@xps13> (raw)
In-Reply-To: <Ybo/r8neydqTxN6N@sirena.org.uk>

Hi Mark,

broonie@kernel.org wrote on Wed, 15 Dec 2021 19:19:11 +0000:

> On Wed, Dec 15, 2021 at 08:05:48PM +0100, Boris Brezillon wrote:
> 
> > There's also a second option that doesn't involve patching existing
> > users: add a spi_mem_controller_caps to the spi_controller struct, and
> > check this instance in your spi_mem_default_supports_op()
> > implementation. Note that the buswidth check done in the generic
> > helper is already based on caps exposed by the controller
> > through spi_controller.mode_bits ({RX/TX}_{DUAL,QUAD,OCTAL} bits).  
> 
> This approach is quite nice for things like this - having things as data
> rather than code.  The only issue is if any of the caps end up varying
> by operation and we need different capabilities but that doesn't look
> too likely here I think?

Indeed that was the main point of the original review from Boris, the
capabilities should be fixed on the controller's lifetime. So I believe
we are safe.

I think I am going to propose the following:
	const struct spi_controller_mem_ops *mem_ops;
+	struct spi_controller_mem_caps mem_caps;

As the structure is not supposed to enlarge dramatically in the near
future, I guess it's fine to have it defined statically. Please tell me
if you prefer a *mem_caps pointer.

I'll send a proposal soon.

Thanks,
Miquèl

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

  parent reply	other threads:[~2021-12-16  9:01 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 11:41 [PATCH v5 00/13] Pipelined ECC engines & Macronix support Miquel Raynal
2021-12-14 11:41 ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 01/13] mtd: nand: ecc: Provide a helper to retrieve a pilelined engine device Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 02/13] mtd: nand: mxic-ecc: Support SPI pipelined mode Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 03/13] mtd: spinand: Delay a little bit the dirmap creation Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 04/13] spi: spi-mem: Create a helper to gather all the supports_op checks Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 19:53   ` Pratyush Yadav
2021-12-14 19:53     ` Pratyush Yadav
2021-12-15 16:11     ` Miquel Raynal
2021-12-15 16:11       ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 05/13] spi: spi-mem: Export the spi_mem_generic_supports_op() helper Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 06/13] spi: spi-mem: Add an ecc_en parameter to the spi_mem_op structure Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 16:29   ` Boris Brezillon
2021-12-14 16:29     ` Boris Brezillon
2021-12-14 11:41 ` [PATCH v5 07/13] mtd: spinand: Create direct mapping descriptors for ECC operations Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 08/13] spi: mxic: Fix the transmit path Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 09/13] spi: mxic: Create a helper to configure the controller before an operation Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 10/13] spi: mxic: Create a helper to ease the start of " Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 11/13] spi: mxic: Add support for direct mapping Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 12/13] spi: mxic: Use spi_mem_generic_supports_op() Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal
2021-12-14 16:24   ` Boris Brezillon
2021-12-14 16:24     ` Boris Brezillon
2021-12-15 17:44     ` Miquel Raynal
2021-12-15 17:44       ` Miquel Raynal
2021-12-15 18:45       ` Boris Brezillon
2021-12-15 18:45         ` Boris Brezillon
2021-12-16  8:11         ` Miquel Raynal
2021-12-16  8:11           ` Miquel Raynal
2021-12-15 18:52       ` Boris Brezillon
2021-12-15 18:52         ` Boris Brezillon
2021-12-16  8:14         ` Miquel Raynal
2021-12-16  8:14           ` Miquel Raynal
2021-12-15 19:05       ` Boris Brezillon
2021-12-15 19:05         ` Boris Brezillon
2021-12-15 19:19         ` Mark Brown
2021-12-15 19:19           ` Mark Brown
2021-12-16  8:07           ` Miquel Raynal
2021-12-16  8:07             ` Miquel Raynal
2021-12-16  9:01           ` Miquel Raynal [this message]
2021-12-16  9:01             ` Miquel Raynal
2021-12-16  9:57             ` Miquel Raynal
2021-12-16  9:57               ` Miquel Raynal
2021-12-16 14:04               ` Mark Brown
2021-12-16 14:04                 ` Mark Brown
2021-12-16 14:27                 ` Miquel Raynal
2021-12-16 14:27                   ` Miquel Raynal
2021-12-14 11:41 ` [PATCH v5 13/13] spi: mxic: Add support for pipelined ECC operations Miquel Raynal
2021-12-14 11:41   ` Miquel Raynal

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=20211216100147.46c307ff@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=boris.brezillon@collabora.com \
    --cc=broonie@kernel.org \
    --cc=jaimeliao@mxic.com.tw \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@ti.com \
    --cc=xiangsheng.hou@mediatek.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.