| Message ID | 20220104083631.40776-2-miquel.raynal@bootlin.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | External ECC engines & Macronix support | expand |
On 04/01/22 09:36AM, Miquel Raynal wrote: > Create a spi_controller_mem_caps structure and put it within the > spi_controller structure close to the spi_controller_mem_ops > strucure. So far the only field in this structure is the support for dtr > operations, but soon we will add another parameter. > > Also create a helper to parse the capabilities and check if the > requested capability has been set or not. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
On Tue, 2022-01-04 at 08:36:19 UTC, Miquel Raynal wrote: > Create a spi_controller_mem_caps structure and put it within the > spi_controller structure close to the spi_controller_mem_ops > strucure. So far the only field in this structure is the support for dtr > operations, but soon we will add another parameter. > > Also create a helper to parse the capabilities and check if the > requested capability has been set or not. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc. Miquel
On Wed, Jan 26, 2022 at 11:53:33AM +0100, Miquel Raynal wrote:
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc.
I was hoping to review this stuff? I think I was expecting it to be
rebased after the merge window...
Hi Mark, broonie@kernel.org wrote on Wed, 26 Jan 2022 16:35:30 +0000: > On Wed, Jan 26, 2022 at 11:53:33AM +0100, Miquel Raynal wrote: > > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-mem-ecc. > > I was hoping to review this stuff? I think I was expecting it to be > rebased after the merge window... Sorry for the misunderstanding, I thought you were fine with these spi bits so I didn't ping you before applying. Can you review the v9 then? There is nothing different in the series I applied. Depending on the outcome I'll either fix inline if you ack the patches or drop the patches from that branch and send a v10 otherwise. Thanks, Miquèl
On Wed, Jan 26, 2022 at 06:36:01PM +0100, Miquel Raynal wrote: > > I was hoping to review this stuff? I think I was expecting it to be > > rebased after the merge window... > Sorry for the misunderstanding, I thought you were fine with these > spi bits so I didn't ping you before applying. Can you review the v9 > then? There is nothing different in the series I applied. > Depending on the outcome I'll either fix inline if you ack the patches > or drop the patches from that branch and send a v10 otherwise. I don't recall seeing anything but I'd dropped them due to the merge window, like I say I was expecting a repost for -rc1. I'll try to fish them out and have a look tomorrow.
Hi Mark, broonie@kernel.org wrote on Wed, 26 Jan 2022 17:41:31 +0000: > On Wed, Jan 26, 2022 at 06:36:01PM +0100, Miquel Raynal wrote: > > > > I was hoping to review this stuff? I think I was expecting it to be > > > rebased after the merge window... > > > Sorry for the misunderstanding, I thought you were fine with these > > spi bits so I didn't ping you before applying. Can you review the v9 > > then? There is nothing different in the series I applied. > > > Depending on the outcome I'll either fix inline if you ack the patches > > or drop the patches from that branch and send a v10 otherwise. > > I don't recall seeing anything but I'd dropped them due to the merge > window, like I say I was expecting a repost for -rc1. I'll try to fish > them out and have a look tomorrow. No worries, I've re-sent exactly the patches currently applied on the spi-mem-ecc branch (so the rebased ones). Take your time for reviewing them and depending on how it goes I will introduce your Acks inline or send a v11 if it is needed. Thanks, Miquèl
Hi Mark, broonie@kernel.org wrote on Wed, 26 Jan 2022 17:41:31 +0000: > On Wed, Jan 26, 2022 at 06:36:01PM +0100, Miquel Raynal wrote: > > > > I was hoping to review this stuff? I think I was expecting it to be > > > rebased after the merge window... > > > Sorry for the misunderstanding, I thought you were fine with these > > spi bits so I didn't ping you before applying. Can you review the v9 > > then? There is nothing different in the series I applied. > > > Depending on the outcome I'll either fix inline if you ack the patches > > or drop the patches from that branch and send a v10 otherwise. > > I don't recall seeing anything but I'd dropped them due to the merge > window, like I say I was expecting a repost for -rc1. I'll try to fish > them out and have a look tomorrow. No worries, I've re-sent exactly the patches currently applied on the spi-mem-ecc branch (so the rebased ones). Take your time for reviewing them and depending on how it goes I will introduce your Acks inline or send a v11 if it is needed. Thanks, Miquèl
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h index 85e2ff7b840d..38e5d45c9842 100644 --- a/include/linux/spi/spi-mem.h +++ b/include/linux/spi/spi-mem.h @@ -285,6 +285,17 @@ struct spi_controller_mem_ops { unsigned long timeout_ms); }; +/** + * struct spi_controller_mem_caps - SPI memory controller capabilities + * @dtr: Supports DTR operations + */ +struct spi_controller_mem_caps { + bool dtr; +}; + +#define spi_mem_controller_is_capable(ctlr, cap) \ + ((ctlr)->mem_caps && (ctlr)->mem_caps->cap) + /** * struct spi_mem_driver - SPI memory driver * @spidrv: inherit from a SPI driver diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 8371bca13729..7ec6450142e0 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -23,6 +23,7 @@ struct software_node; struct spi_controller; struct spi_transfer; struct spi_controller_mem_ops; +struct spi_controller_mem_caps; /* * INTERFACES between SPI master-side drivers and SPI slave protocol handlers, @@ -419,6 +420,7 @@ extern struct spi_device *spi_new_ancillary_device(struct spi_device *spi, u8 ch * @mem_ops: optimized/dedicated operations for interactions with SPI memory. * This field is optional and should only be implemented if the * controller has native support for memory like operations. + * @mem_caps: controller capabilities for the handling of memory operations. * @unprepare_message: undo any work done by prepare_message(). * @slave_abort: abort the ongoing transfer request on an SPI slave controller * @cs_gpios: LEGACY: array of GPIO descs to use as chip select lines; one per @@ -640,6 +642,7 @@ struct spi_controller { /* Optimized handlers for SPI memory-like operations. */ const struct spi_controller_mem_ops *mem_ops; + const struct spi_controller_mem_caps *mem_caps; /* gpio chip select */ int *cs_gpios;
Create a spi_controller_mem_caps structure and put it within the spi_controller structure close to the spi_controller_mem_ops strucure. So far the only field in this structure is the support for dtr operations, but soon we will add another parameter. Also create a helper to parse the capabilities and check if the requested capability has been set or not. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> --- include/linux/spi/spi-mem.h | 11 +++++++++++ include/linux/spi/spi.h | 3 +++ 2 files changed, 14 insertions(+)