diff mbox series

[v2,1/2] mtd: spi-nor: intel-spi: support chips without software sequencer

Message ID 69f4a8e8-7889-8b00-0adc-7faaef6b42e4@fortanix.com
State Accepted
Delegated to: Ambarus Tudor
Headers show
Series Support for Intel Cannon Lake SPI flash | expand

Commit Message

Jethro Beekman Sept. 4, 2019, 1:15 a.m. UTC
Some flash controllers don't have a software sequencer. Avoid
configuring the register addresses for it, and double check
everywhere that its not accidentally trying to be used.

Every use of `sregs` is now guarded by a check of `sregs` or
`swseq_reg`. The check might be done in the calling function.

Signed-off-by: Jethro Beekman <jethro@fortanix.com>
---
 drivers/mtd/spi-nor/intel-spi.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

Comments

Jethro Beekman Sept. 15, 2019, 8:41 p.m. UTC | #1
Could someone please review this?

On 2019-09-04 03:15, Jethro Beekman wrote:
> Some flash controllers don't have a software sequencer. Avoid
> configuring the register addresses for it, and double check
> everywhere that its not accidentally trying to be used.
> 
> Every use of `sregs` is now guarded by a check of `sregs` or
> `swseq_reg`. The check might be done in the calling function.
> 
> Signed-off-by: Jethro Beekman <jethro@fortanix.com>
> ---
>  drivers/mtd/spi-nor/intel-spi.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
> index 1ccf23f..195cdca 100644
> --- a/drivers/mtd/spi-nor/intel-spi.c
> +++ b/drivers/mtd/spi-nor/intel-spi.c
> @@ -187,12 +187,16 @@ static void intel_spi_dump_regs(struct intel_spi *ispi)
>  		dev_dbg(ispi->dev, "PR(%d)=0x%08x\n", i,
>  			readl(ispi->pregs + PR(i)));
>  
> -	value = readl(ispi->sregs + SSFSTS_CTL);
> -	dev_dbg(ispi->dev, "SSFSTS_CTL=0x%08x\n", value);
> -	dev_dbg(ispi->dev, "PREOP_OPTYPE=0x%08x\n",
> -		readl(ispi->sregs + PREOP_OPTYPE));
> -	dev_dbg(ispi->dev, "OPMENU0=0x%08x\n", readl(ispi->sregs + OPMENU0));
> -	dev_dbg(ispi->dev, "OPMENU1=0x%08x\n", readl(ispi->sregs + OPMENU1));
> +	if (ispi->sregs) {
> +		value = readl(ispi->sregs + SSFSTS_CTL);
> +		dev_dbg(ispi->dev, "SSFSTS_CTL=0x%08x\n", value);
> +		dev_dbg(ispi->dev, "PREOP_OPTYPE=0x%08x\n",
> +			readl(ispi->sregs + PREOP_OPTYPE));
> +		dev_dbg(ispi->dev, "OPMENU0=0x%08x\n",
> +			readl(ispi->sregs + OPMENU0));
> +		dev_dbg(ispi->dev, "OPMENU1=0x%08x\n",
> +			readl(ispi->sregs + OPMENU1));
> +	}
>  
>  	if (ispi->info->type == INTEL_SPI_BYT)
>  		dev_dbg(ispi->dev, "BCR=0x%08x\n", readl(ispi->base + BYT_BCR));
> @@ -367,6 +371,11 @@ static int intel_spi_init(struct intel_spi *ispi)
>  		    !(uvscc & ERASE_64K_OPCODE_MASK))
>  			ispi->erase_64k = false;
>  
> +	if (ispi->sregs == NULL && (ispi->swseq_reg || ispi->swseq_erase)) {
> +		dev_err(ispi->dev, "software sequencer not supported, but required\n");
> +		return -EINVAL;
> +	}
> +
>  	/*
>  	 * Some controllers can only do basic operations using hardware
>  	 * sequencer. All other operations are supposed to be carried out
> @@ -383,7 +392,7 @@ static int intel_spi_init(struct intel_spi *ispi)
>  	val = readl(ispi->base + HSFSTS_CTL);
>  	ispi->locked = !!(val & HSFSTS_CTL_FLOCKDN);
>  
> -	if (ispi->locked) {
> +	if (ispi->locked && ispi->sregs) {
>  		/*
>  		 * BIOS programs allowed opcodes and then locks down the
>  		 * register. So read back what opcodes it decided to support.
>
Mika Westerberg Sept. 16, 2019, 9:11 a.m. UTC | #2
Hi,

On Sun, Sep 15, 2019 at 08:41:55PM +0000, Jethro Beekman wrote:
> Could someone please review this?
> 
> On 2019-09-04 03:15, Jethro Beekman wrote:
> > Some flash controllers don't have a software sequencer. Avoid
> > configuring the register addresses for it, and double check
> > everywhere that its not accidentally trying to be used.

All the supported types in intel_spi_init() set ->sregs so I don't see
how we could end up calling functions with that not set properly. Which
controller we are talking about here? CNL?
Jethro Beekman Sept. 16, 2019, 9:12 a.m. UTC | #3
On 2019-09-16 11:11, Mika Westerberg wrote:
> Hi,
> 
> On Sun, Sep 15, 2019 at 08:41:55PM +0000, Jethro Beekman wrote:
>> Could someone please review this?
>>
>> On 2019-09-04 03:15, Jethro Beekman wrote:
>>> Some flash controllers don't have a software sequencer. Avoid
>>> configuring the register addresses for it, and double check
>>> everywhere that its not accidentally trying to be used.
> 
> All the supported types in intel_spi_init() set ->sregs so I don't see
> how we could end up calling functions with that not set properly. Which
> controller we are talking about here? CNL?
> 

Yes, see 2/2.

--
Jethro Beekman | Fortanix
Mika Westerberg Sept. 16, 2019, 9:19 a.m. UTC | #4
On Mon, Sep 16, 2019 at 09:12:50AM +0000, Jethro Beekman wrote:
> On 2019-09-16 11:11, Mika Westerberg wrote:
> > Hi,
> > 
> > On Sun, Sep 15, 2019 at 08:41:55PM +0000, Jethro Beekman wrote:
> >> Could someone please review this?
> >>
> >> On 2019-09-04 03:15, Jethro Beekman wrote:
> >>> Some flash controllers don't have a software sequencer. Avoid
> >>> configuring the register addresses for it, and double check
> >>> everywhere that its not accidentally trying to be used.
> > 
> > All the supported types in intel_spi_init() set ->sregs so I don't see
> > how we could end up calling functions with that not set properly. Which
> > controller we are talking about here? CNL?
> > 
> 
> Yes, see 2/2.

OK, thanks. Please mention that in the commit log as well.

The patch itself looks good to me.
Jethro Beekman Sept. 16, 2019, 9:22 a.m. UTC | #5
On 2019-09-16 11:19, Mika Westerberg wrote:
> On Mon, Sep 16, 2019 at 09:12:50AM +0000, Jethro Beekman wrote:
>> On 2019-09-16 11:11, Mika Westerberg wrote:
>>> Hi,
>>>
>>> On Sun, Sep 15, 2019 at 08:41:55PM +0000, Jethro Beekman wrote:
>>>> Could someone please review this?
>>>>
>>>> On 2019-09-04 03:15, Jethro Beekman wrote:
>>>>> Some flash controllers don't have a software sequencer. Avoid
>>>>> configuring the register addresses for it, and double check
>>>>> everywhere that its not accidentally trying to be used.
>>>
>>> All the supported types in intel_spi_init() set ->sregs so I don't see
>>> how we could end up calling functions with that not set properly. Which
>>> controller we are talking about here? CNL?
>>>
>>
>> Yes, see 2/2.
> 
> OK, thanks. Please mention that in the commit log as well.

It seems obvious to me that the need for a patch may be further explained by the next patch in the patch set.

--
Jethro Beekman | Fortanix
Mika Westerberg Sept. 16, 2019, 9:42 a.m. UTC | #6
On Mon, Sep 16, 2019 at 09:22:04AM +0000, Jethro Beekman wrote:
> On 2019-09-16 11:19, Mika Westerberg wrote:
> > On Mon, Sep 16, 2019 at 09:12:50AM +0000, Jethro Beekman wrote:
> >> On 2019-09-16 11:11, Mika Westerberg wrote:
> >>> Hi,
> >>>
> >>> On Sun, Sep 15, 2019 at 08:41:55PM +0000, Jethro Beekman wrote:
> >>>> Could someone please review this?
> >>>>
> >>>> On 2019-09-04 03:15, Jethro Beekman wrote:
> >>>>> Some flash controllers don't have a software sequencer. Avoid
> >>>>> configuring the register addresses for it, and double check
> >>>>> everywhere that its not accidentally trying to be used.
> >>>
> >>> All the supported types in intel_spi_init() set ->sregs so I don't see
> >>> how we could end up calling functions with that not set properly. Which
> >>> controller we are talking about here? CNL?
> >>>
> >>
> >> Yes, see 2/2.
> > 
> > OK, thanks. Please mention that in the commit log as well.
> 
> It seems obvious to me that the need for a patch may be further
> explained by the next patch in the patch set.

Yes, that's fine but then you should make sure the intended reviewers
get to see all the patches in the series. For me I got only Cc'd on this
1/2 yesterday. I think I reviewed 2/2 some time ago.
Tudor Ambarus Oct. 23, 2019, 9:22 p.m. UTC | #7
On 09/04/2019 04:15 AM, Jethro Beekman wrote:
> External E-Mail
> 
> 
> Some flash controllers don't have a software sequencer. Avoid
> configuring the register addresses for it, and double check
> everywhere that its not accidentally trying to be used.
> 
> Every use of `sregs` is now guarded by a check of `sregs` or
> `swseq_reg`. The check might be done in the calling function.
> 
> Signed-off-by: Jethro Beekman <jethro@fortanix.com>
> ---
>  drivers/mtd/spi-nor/intel-spi.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)

Applied to spi-nor/next. Thanks.
diff mbox series

Patch

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index 1ccf23f..195cdca 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -187,12 +187,16 @@  static void intel_spi_dump_regs(struct intel_spi *ispi)
 		dev_dbg(ispi->dev, "PR(%d)=0x%08x\n", i,
 			readl(ispi->pregs + PR(i)));
 
-	value = readl(ispi->sregs + SSFSTS_CTL);
-	dev_dbg(ispi->dev, "SSFSTS_CTL=0x%08x\n", value);
-	dev_dbg(ispi->dev, "PREOP_OPTYPE=0x%08x\n",
-		readl(ispi->sregs + PREOP_OPTYPE));
-	dev_dbg(ispi->dev, "OPMENU0=0x%08x\n", readl(ispi->sregs + OPMENU0));
-	dev_dbg(ispi->dev, "OPMENU1=0x%08x\n", readl(ispi->sregs + OPMENU1));
+	if (ispi->sregs) {
+		value = readl(ispi->sregs + SSFSTS_CTL);
+		dev_dbg(ispi->dev, "SSFSTS_CTL=0x%08x\n", value);
+		dev_dbg(ispi->dev, "PREOP_OPTYPE=0x%08x\n",
+			readl(ispi->sregs + PREOP_OPTYPE));
+		dev_dbg(ispi->dev, "OPMENU0=0x%08x\n",
+			readl(ispi->sregs + OPMENU0));
+		dev_dbg(ispi->dev, "OPMENU1=0x%08x\n",
+			readl(ispi->sregs + OPMENU1));
+	}
 
 	if (ispi->info->type == INTEL_SPI_BYT)
 		dev_dbg(ispi->dev, "BCR=0x%08x\n", readl(ispi->base + BYT_BCR));
@@ -367,6 +371,11 @@  static int intel_spi_init(struct intel_spi *ispi)
 		    !(uvscc & ERASE_64K_OPCODE_MASK))
 			ispi->erase_64k = false;
 
+	if (ispi->sregs == NULL && (ispi->swseq_reg || ispi->swseq_erase)) {
+		dev_err(ispi->dev, "software sequencer not supported, but required\n");
+		return -EINVAL;
+	}
+
 	/*
 	 * Some controllers can only do basic operations using hardware
 	 * sequencer. All other operations are supposed to be carried out
@@ -383,7 +392,7 @@  static int intel_spi_init(struct intel_spi *ispi)
 	val = readl(ispi->base + HSFSTS_CTL);
 	ispi->locked = !!(val & HSFSTS_CTL_FLOCKDN);
 
-	if (ispi->locked) {
+	if (ispi->locked && ispi->sregs) {
 		/*
 		 * BIOS programs allowed opcodes and then locks down the
 		 * register. So read back what opcodes it decided to support.