[PATCH 0/4] spi: intel: Add support for SFDP opcode

[PATCH 0/4] spi: intel: Add support for SFDP opcode

[Mika Westerberg]

Hi,

This series adds support for SFDP (Serial Flash Discoverable Parameter)
opcode to the Intel SPI driver. This allows the SPI-NOR core to query
the flash chip what it supports.

Mika Westerberg (4):
  spi: intel: Use ->replacement_op in intel_spi_hw_cycle()
  spi: intel: Implement adjust_op_size()
  spi: intel: Take possible chip address into account in intel_spi_read/write_reg()
  spi: intel: Add support for SFDP opcode

 drivers/spi/spi-intel.c | 78 +++++++++++++++++++++--------------------
 1 file changed, 40 insertions(+), 38 deletions(-)

-- 
2.35.1

[PATCH 1/4] spi: intel: Use ->replacement_op in intel_spi_hw_cycle()

[Mika Westerberg]

This way we do not need the SPI-NOR opcode -> Intel controller opcode
mapping in the function anymore.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi-intel.c | 52 ++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index acd8ec4f86a7..b3685460d848 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -352,34 +352,25 @@ static int intel_spi_opcode_index(struct intel_spi *ispi, u8 opcode, int optype)
 	return 0;
 }
 
-static int intel_spi_hw_cycle(struct intel_spi *ispi, u8 opcode, size_t len)
+static int intel_spi_hw_cycle(struct intel_spi *ispi,
+			      const struct intel_spi_mem_op *iop, size_t len)
 {
 	u32 val, status;
 	int ret;
 
+	if (!iop->replacement_op)
+		return -EINVAL;
+
 	val = readl(ispi->base + HSFSTS_CTL);
 	val &= ~(HSFSTS_CTL_FCYCLE_MASK | HSFSTS_CTL_FDBC_MASK);
 
-	switch (opcode) {
-	case SPINOR_OP_RDID:
-		val |= HSFSTS_CTL_FCYCLE_RDID;
-		break;
-	case SPINOR_OP_WRSR:
-		val |= HSFSTS_CTL_FCYCLE_WRSR;
-		break;
-	case SPINOR_OP_RDSR:
-		val |= HSFSTS_CTL_FCYCLE_RDSR;
-		break;
-	default:
-		return -EINVAL;
-	}
-
 	if (len > INTEL_SPI_FIFO_SZ)
 		return -EINVAL;
 
 	val |= (len - 1) << HSFSTS_CTL_FDBC_SHIFT;
 	val |= HSFSTS_CTL_FCERR | HSFSTS_CTL_FDONE;
 	val |= HSFSTS_CTL_FGO;
+	val |= iop->replacement_op;
 	writel(val, ispi->base + HSFSTS_CTL);
 
 	ret = intel_spi_wait_hw_busy(ispi);
@@ -483,7 +474,7 @@ static int intel_spi_read_reg(struct intel_spi *ispi, const struct spi_mem *mem,
 		ret = intel_spi_sw_cycle(ispi, opcode, nbytes,
 					 OPTYPE_READ_NO_ADDR);
 	else
-		ret = intel_spi_hw_cycle(ispi, opcode, nbytes);
+		ret = intel_spi_hw_cycle(ispi, iop, nbytes);
 
 	if (ret)
 		return ret;
@@ -548,7 +539,7 @@ static int intel_spi_write_reg(struct intel_spi *ispi, const struct spi_mem *mem
 	if (ispi->swseq_reg)
 		return intel_spi_sw_cycle(ispi, opcode, nbytes,
 					  OPTYPE_WRITE_NO_ADDR);
-	return intel_spi_hw_cycle(ispi, opcode, nbytes);
+	return intel_spi_hw_cycle(ispi, iop, nbytes);
 }
 
 static int intel_spi_read(struct intel_spi *ispi, const struct spi_mem *mem,
@@ -912,18 +903,21 @@ static const struct spi_controller_mem_ops intel_spi_mem_ops = {
  */
 #define INTEL_SPI_GENERIC_OPS						\
 	/* Status register operations */				\
-	INTEL_SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1),		\
-			 SPI_MEM_OP_NO_ADDR,				\
-			 INTEL_SPI_OP_DATA_IN(1),			\
-			 intel_spi_read_reg),				\
-	INTEL_SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDSR, 1),		\
-			 SPI_MEM_OP_NO_ADDR,				\
-			 INTEL_SPI_OP_DATA_IN(1),			\
-			 intel_spi_read_reg),				\
-	INTEL_SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRSR, 1),		\
-			 SPI_MEM_OP_NO_ADDR,				\
-			 INTEL_SPI_OP_DATA_OUT(1),			\
-			 intel_spi_write_reg),				\
+	INTEL_SPI_MEM_OP_REPL(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1),	\
+			      SPI_MEM_OP_NO_ADDR,			\
+			      INTEL_SPI_OP_DATA_IN(1),			\
+			      intel_spi_read_reg,			\
+			      HSFSTS_CTL_FCYCLE_RDID),			\
+	INTEL_SPI_MEM_OP_REPL(SPI_MEM_OP_CMD(SPINOR_OP_RDSR, 1),	\
+			      SPI_MEM_OP_NO_ADDR,			\
+			      INTEL_SPI_OP_DATA_IN(1),			\
+			      intel_spi_read_reg,			\
+			      HSFSTS_CTL_FCYCLE_RDSR),			\
+	INTEL_SPI_MEM_OP_REPL(SPI_MEM_OP_CMD(SPINOR_OP_WRSR, 1),	\
+			      SPI_MEM_OP_NO_ADDR,			\
+			      INTEL_SPI_OP_DATA_OUT(1),			\
+			      intel_spi_write_reg,			\
+			      HSFSTS_CTL_FCYCLE_WRSR),			\
 	/* Normal read */						\
 	INTEL_SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_READ, 1),		\
 			 INTEL_SPI_OP_ADDR(3),				\
-- 
2.35.1

[PATCH 2/4] spi: intel: Implement adjust_op_size()

[Mika Westerberg]

This allows us to get rid of the checks in the intel_spi_[sh]w_cycle()
and makes it possible for the SPI-NOR core to split the transaction into
smaller chunks as needed.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi-intel.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index b3685460d848..13a3a61239d2 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -363,10 +363,6 @@ static int intel_spi_hw_cycle(struct intel_spi *ispi,
 
 	val = readl(ispi->base + HSFSTS_CTL);
 	val &= ~(HSFSTS_CTL_FCYCLE_MASK | HSFSTS_CTL_FDBC_MASK);
-
-	if (len > INTEL_SPI_FIFO_SZ)
-		return -EINVAL;
-
 	val |= (len - 1) << HSFSTS_CTL_FDBC_SHIFT;
 	val |= HSFSTS_CTL_FCERR | HSFSTS_CTL_FDONE;
 	val |= HSFSTS_CTL_FGO;
@@ -397,9 +393,6 @@ static int intel_spi_sw_cycle(struct intel_spi *ispi, u8 opcode, size_t len,
 	if (ret < 0)
 		return ret;
 
-	if (len > INTEL_SPI_FIFO_SZ)
-		return -EINVAL;
-
 	/*
 	 * Always clear it after each SW sequencer operation regardless
 	 * of whether it is successful or not.
@@ -704,6 +697,12 @@ static int intel_spi_erase(struct intel_spi *ispi, const struct spi_mem *mem,
 	return 0;
 }
 
+static int intel_spi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+	op->data.nbytes = clamp_val(op->data.nbytes, 0, INTEL_SPI_FIFO_SZ);
+	return 0;
+}
+
 static bool intel_spi_cmp_mem_op(const struct intel_spi_mem_op *iop,
 				 const struct spi_mem_op *op)
 {
@@ -844,6 +843,7 @@ static ssize_t intel_spi_dirmap_write(struct spi_mem_dirmap_desc *desc, u64 offs
 }
 
 static const struct spi_controller_mem_ops intel_spi_mem_ops = {
+	.adjust_op_size = intel_spi_adjust_op_size,
 	.supports_op = intel_spi_supports_mem_op,
 	.exec_op = intel_spi_exec_mem_op,
 	.get_name = intel_spi_get_name,
-- 
2.35.1

Re: [PATCH 2/4] spi: intel: Implement adjust_op_size()

[Gole, Dhruva]

Hi Mika,

On 10/25/2022 12:16 PM, Mika Westerberg wrote:
> This allows us to get rid of the checks in the intel_spi_[sh]w_cycle()
> and makes it possible for the SPI-NOR core to split the transaction into
> smaller chunks as needed.

If I understand correctly, the controller ops are called from spi-mem.c, 
and

spi_mem_adjust_op does exist and on it's own does "split a data transfer
  operation into multiple ones"

So is this really something that you require the controller to do and

can we not rely on spi-mem.c to do it's thing instead?

I would like to point you to another controller spi-cadence-quadspi.c

that also doesn't have it's own adjust_op_size but I haven't seen any 
issues as such

inspite. This is because everything first goes through spi-mem.c then 
onto the controllers drivers.

This atleast is my understanding, please correct me if I am mistaken.

>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
>   drivers/spi/spi-intel.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
> index b3685460d848..13a3a61239d2 100644
> --- a/drivers/spi/spi-intel.c
> +++ b/drivers/spi/spi-intel.c
> @@ -363,10 +363,6 @@ static int intel_spi_hw_cycle(struct intel_spi *ispi,
>   
>   	val = readl(ispi->base + HSFSTS_CTL);
>   	val &= ~(HSFSTS_CTL_FCYCLE_MASK | HSFSTS_CTL_FDBC_MASK);
> -
> -	if (len > INTEL_SPI_FIFO_SZ)
> -		return -EINVAL;
> -
>   	val |= (len - 1) << HSFSTS_CTL_FDBC_SHIFT;
>   	val |= HSFSTS_CTL_FCERR | HSFSTS_CTL_FDONE;
>   	val |= HSFSTS_CTL_FGO;
> @@ -397,9 +393,6 @@ static int intel_spi_sw_cycle(struct intel_spi *ispi, u8 opcode, size_t len,
>   	if (ret < 0)
>   		return ret;
>   
> -	if (len > INTEL_SPI_FIFO_SZ)
> -		return -EINVAL;
> -
>   	/*
>   	 * Always clear it after each SW sequencer operation regardless
>   	 * of whether it is successful or not.
> @@ -704,6 +697,12 @@ static int intel_spi_erase(struct intel_spi *ispi, const struct spi_mem *mem,
>   	return 0;
>   }
>   
> +static int intel_spi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
> +{
> +	op->data.nbytes = clamp_val(op->data.nbytes, 0, INTEL_SPI_FIFO_SZ);
> +	return 0;
> +}
> +
>   static bool intel_spi_cmp_mem_op(const struct intel_spi_mem_op *iop,
>   				 const struct spi_mem_op *op)
>   {
> @@ -844,6 +843,7 @@ static ssize_t intel_spi_dirmap_write(struct spi_mem_dirmap_desc *desc, u64 offs
>   }
>   
>   static const struct spi_controller_mem_ops intel_spi_mem_ops = {
> +	.adjust_op_size = intel_spi_adjust_op_size,
>   	.supports_op = intel_spi_supports_mem_op,
>   	.exec_op = intel_spi_exec_mem_op,
>   	.get_name = intel_spi_get_name,

Re: [PATCH 2/4] spi: intel: Implement adjust_op_size()

[Mika Westerberg]

Hi,

On Fri, Oct 28, 2022 at 11:42:09AM +0530, Gole, Dhruva wrote:
> Hi Mika,
> 
> On 10/25/2022 12:16 PM, Mika Westerberg wrote:
> > This allows us to get rid of the checks in the intel_spi_[sh]w_cycle()
> > and makes it possible for the SPI-NOR core to split the transaction into
> > smaller chunks as needed.
> 
> If I understand correctly, the controller ops are called from spi-mem.c, and
> 
> spi_mem_adjust_op does exist and on it's own does "split a data transfer
>  operation into multiple ones"
> 
> So is this really something that you require the controller to do and
> 
> can we not rely on spi-mem.c to do it's thing instead?

How does it know the size supported by the hardware? I think this is the
reason spi_mem_adjust_op was introduced but I may be mistaken.

> I would like to point you to another controller spi-cadence-quadspi.c
> 
> that also doesn't have it's own adjust_op_size but I haven't seen any issues
> as such
> 
> inspite. This is because everything first goes through spi-mem.c then onto
> the controllers drivers.

Well Intel SPI driver did not not have any issues previously either
because it handled the read/write split internally but SFDP read is done
through "register read side" which only supported max 64-byte read until
now :-)

Re: Re: [PATCH 2/4] spi: intel: Implement adjust_op_size()

[Gole, Dhruva]

On 10/28/2022 11:55 AM, Mika Westerberg wrote:
> Hi,
>
> On Fri, Oct 28, 2022 at 11:42:09AM +0530, Gole, Dhruva wrote:
>> Hi Mika,
>>
>> On 10/25/2022 12:16 PM, Mika Westerberg wrote:
>>> This allows us to get rid of the checks in the intel_spi_[sh]w_cycle()
>>> and makes it possible for the SPI-NOR core to split the transaction into
>>> smaller chunks as needed.
>> If I understand correctly, the controller ops are called from spi-mem.c, and
>>
>> spi_mem_adjust_op does exist and on it's own does "split a data transfer
>>   operation into multiple ones"
>>
>> So is this really something that you require the controller to do and
>>
>> can we not rely on spi-mem.c to do it's thing instead?
> How does it know the size supported by the hardware? I think this is the
> reason spi_mem_adjust_op was introduced but I may be mistaken.'

The following piece of code might help:

         op->data.nbytes = min3((size_t)op->data.nbytes,
                        spi_max_transfer_size(mem->spi),
                        spi_max_message_size(mem->spi)

I believe this will help it know the size supported by the hardware.

and on the controller side:

in case of cadence I have seen it pickup the fifo depth from DTSI, for eg.

arch/arm64/boot/dts/ti/k3-am62-main.dtsi: cdns,fifo-depth = <256>;

>
>> I would like to point you to another controller spi-cadence-quadspi.c
>>
>> that also doesn't have it's own adjust_op_size but I haven't seen any issues
>> as such
>>
>> inspite. This is because everything first goes through spi-mem.c then onto
>> the controllers drivers.
> Well Intel SPI driver did not not have any issues previously either
> because it handled the read/write split internally but SFDP read is done
> through "register read side" which only supported max 64-byte read until
> now :-)

-- 
Regards,
Dhruva Gole <d-gole@ti.com>

Re: Re: [PATCH 2/4] spi: intel: Implement adjust_op_size()

[Mika Westerberg]

Hi,

On Fri, Oct 28, 2022 at 12:16:43PM +0530, Gole, Dhruva wrote:
> 
> On 10/28/2022 11:55 AM, Mika Westerberg wrote:
> > Hi,
> > 
> > On Fri, Oct 28, 2022 at 11:42:09AM +0530, Gole, Dhruva wrote:
> > > Hi Mika,
> > > 
> > > On 10/25/2022 12:16 PM, Mika Westerberg wrote:
> > > > This allows us to get rid of the checks in the intel_spi_[sh]w_cycle()
> > > > and makes it possible for the SPI-NOR core to split the transaction into
> > > > smaller chunks as needed.
> > > If I understand correctly, the controller ops are called from spi-mem.c, and
> > > 
> > > spi_mem_adjust_op does exist and on it's own does "split a data transfer
> > >   operation into multiple ones"
> > > 
> > > So is this really something that you require the controller to do and
> > > 
> > > can we not rely on spi-mem.c to do it's thing instead?
> > How does it know the size supported by the hardware? I think this is the
> > reason spi_mem_adjust_op was introduced but I may be mistaken.'
> 
> The following piece of code might help:
> 
>         op->data.nbytes = min3((size_t)op->data.nbytes,
>                        spi_max_transfer_size(mem->spi),
>                        spi_max_message_size(mem->spi)
> 
> I believe this will help it know the size supported by the hardware.
> 
> and on the controller side:
> 
> in case of cadence I have seen it pickup the fifo depth from DTSI, for eg.
> 
> arch/arm64/boot/dts/ti/k3-am62-main.dtsi: cdns,fifo-depth = <256>;

I'm not entirely sure I understand what you are suggesting to be honest? ;-)

For example the Intel SPI controller does not have any sort of device
tree description, it does not really understand anything about SPI
either (internally yes but the operations it exposes to software are
higher level), and it has fixed 64 byte FIFO.

Can I get the SFDP opcode supported with that without implementing
custom spi_mem_adjust_op() and if yes, how? Thanks!

[PATCH 3/4] spi: intel: Take possible chip address into account in intel_spi_read/write_reg()

[Mika Westerberg]

The SPI-NOR operation can have non-zero chip address as well so take
this into account in intel_spi_read/write_reg().

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi-intel.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index 13a3a61239d2..8b07e41daafe 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -457,11 +457,12 @@ static int intel_spi_read_reg(struct intel_spi *ispi, const struct spi_mem *mem,
 			      const struct intel_spi_mem_op *iop,
 			      const struct spi_mem_op *op)
 {
+	u32 addr = intel_spi_chip_addr(ispi, mem) + op->addr.val;
 	size_t nbytes = op->data.nbytes;
 	u8 opcode = op->cmd.opcode;
 	int ret;
 
-	writel(intel_spi_chip_addr(ispi, mem), ispi->base + FADDR);
+	writel(addr, ispi->base + FADDR);
 
 	if (ispi->swseq_reg)
 		ret = intel_spi_sw_cycle(ispi, opcode, nbytes,
@@ -479,6 +480,7 @@ static int intel_spi_write_reg(struct intel_spi *ispi, const struct spi_mem *mem
 			       const struct intel_spi_mem_op *iop,
 			       const struct spi_mem_op *op)
 {
+	u32 addr = intel_spi_chip_addr(ispi, mem) + op->addr.val;
 	size_t nbytes = op->data.nbytes;
 	u8 opcode = op->cmd.opcode;
 	int ret;
@@ -522,7 +524,7 @@ static int intel_spi_write_reg(struct intel_spi *ispi, const struct spi_mem *mem
 	if (opcode == SPINOR_OP_WRDI)
 		return 0;
 
-	writel(intel_spi_chip_addr(ispi, mem), ispi->base + FADDR);
+	writel(addr, ispi->base + FADDR);
 
 	/* Write the value beforehand */
 	ret = intel_spi_write_block(ispi, op->data.buf.out, nbytes);
-- 
2.35.1

[PATCH 4/4] spi: intel: Add support for SFDP opcode

[Mika Westerberg]

The Intel SPI-NOR controller supports SFDP (Serial Flash Discoverable
Parameter) opcode so add it to the list of supported opcodes.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
 drivers/spi/spi-intel.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index 8b07e41daafe..049c81717101 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -33,6 +33,7 @@
 #define HSFSTS_CTL_FCYCLE_WRITE		(0x02 << HSFSTS_CTL_FCYCLE_SHIFT)
 #define HSFSTS_CTL_FCYCLE_ERASE		(0x03 << HSFSTS_CTL_FCYCLE_SHIFT)
 #define HSFSTS_CTL_FCYCLE_ERASE_64K	(0x04 << HSFSTS_CTL_FCYCLE_SHIFT)
+#define HSFSTS_CTL_FCYCLE_RDSFDP	(0x05 << HSFSTS_CTL_FCYCLE_SHIFT)
 #define HSFSTS_CTL_FCYCLE_RDID		(0x06 << HSFSTS_CTL_FCYCLE_SHIFT)
 #define HSFSTS_CTL_FCYCLE_WRSR		(0x07 << HSFSTS_CTL_FCYCLE_SHIFT)
 #define HSFSTS_CTL_FCYCLE_RDSR		(0x08 << HSFSTS_CTL_FCYCLE_SHIFT)
@@ -920,6 +921,11 @@ static const struct spi_controller_mem_ops intel_spi_mem_ops = {
 			      INTEL_SPI_OP_DATA_OUT(1),			\
 			      intel_spi_write_reg,			\
 			      HSFSTS_CTL_FCYCLE_WRSR),			\
+	INTEL_SPI_MEM_OP_REPL(SPI_MEM_OP_CMD(SPINOR_OP_RDSFDP, 1),	\
+			      INTEL_SPI_OP_ADDR(3),			\
+			      INTEL_SPI_OP_DATA_IN(1),			\
+			      intel_spi_read_reg,			\
+			      HSFSTS_CTL_FCYCLE_RDSFDP),		\
 	/* Normal read */						\
 	INTEL_SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_READ, 1),		\
 			 INTEL_SPI_OP_ADDR(3),				\
-- 
2.35.1

Re: [PATCH 0/4] spi: intel: Add support for SFDP opcode

[Mika Westerberg]

Hi Mark,

On Tue, Oct 25, 2022 at 09:46:19AM +0300, Mika Westerberg wrote:
> Hi,
> 
> This series adds support for SFDP (Serial Flash Discoverable Parameter)
> opcode to the Intel SPI driver. This allows the SPI-NOR core to query
> the flash chip what it supports.
> 
> Mika Westerberg (4):
>   spi: intel: Use ->replacement_op in intel_spi_hw_cycle()
>   spi: intel: Implement adjust_op_size()
>   spi: intel: Take possible chip address into account in intel_spi_read/write_reg()
>   spi: intel: Add support for SFDP opcode
> 
>  drivers/spi/spi-intel.c | 78 +++++++++++++++++++++--------------------
>  1 file changed, 40 insertions(+), 38 deletions(-)

Any chance getting this queued for v6.2? Thanks!

Re: [PATCH 0/4] spi: intel: Add support for SFDP opcode

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Tue, Nov 22, 2022 at 02:30:53PM +0200, Mika Westerberg wrote:

> Any chance getting this queued for v6.2? Thanks!

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/4] spi: intel: Add support for SFDP opcode

[Mark Brown]

On Tue, 25 Oct 2022 09:46:19 +0300, Mika Westerberg wrote:
> This series adds support for SFDP (Serial Flash Discoverable Parameter)
> opcode to the Intel SPI driver. This allows the SPI-NOR core to query
> the flash chip what it supports.
> 
> Mika Westerberg (4):
>   spi: intel: Use ->replacement_op in intel_spi_hw_cycle()
>   spi: intel: Implement adjust_op_size()
>   spi: intel: Take possible chip address into account in intel_spi_read/write_reg()
>   spi: intel: Add support for SFDP opcode
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/4] spi: intel: Use ->replacement_op in intel_spi_hw_cycle()
      commit: f73f6bd200c399d52d7147f66b956a01c93d7606
[2/4] spi: intel: Implement adjust_op_size()
      commit: 8a9a784fb337cfd07f305faf5358335d4c12a788
[3/4] spi: intel: Take possible chip address into account in intel_spi_read/write_reg()
      commit: 43f173e7e508ede3d6f5411b9ffbb33d6d284211
[4/4] spi: intel: Add support for SFDP opcode
      commit: ec4a04aa6962fff3cfa63d70536537844f7446d2

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark