linux-kernel - Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a write access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 2 Feb 2019 14:20:29 +0100
From:   Boris Brezillon <bbrezillon@...nel.org>
To:     <Tudor.Ambarus@...rochip.com>
Cc:     <mark.rutland@....com>, <devicetree@...r.kernel.org>,
        <alexandre.belloni@...tlin.com>, <linux-kernel@...r.kernel.org>,
        <Cyrille.Pitchen@...rochip.com>, <robh+dt@...nel.org>,
        <linux-spi@...r.kernel.org>, <Ludovic.Desroches@...rochip.com>,
        <broonie@...nel.org>, <linux-mtd@...ts.infradead.org>,
        <bugalski.piotr@...il.com>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a
 write access

On Sat, 2 Feb 2019 08:38:40 +0000
<Tudor.Ambarus@...rochip.com> wrote:

> On 02/02/2019 09:06 AM, Boris Brezillon wrote:
> > On Sat, 2 Feb 2019 04:07:13 +0000
> > <Tudor.Ambarus@...rochip.com> wrote:
> >   
> >> From: Tudor Ambarus <tudor.ambarus@...rochip.com>
> >>
> >> Cache Serial Memory Mode (SMM) value to avoid write access when
> >> setting the controller in serial memory mode. SMM is set in
> >> exec_op() and not at probe time, to let room for future regular
> >> SPI support.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@...rochip.com>
> >> ---
> >> v3: update smm value when different. rename mr/smm
> >> v2: cache MR value instead of moving the write access at probe
> >>
> >>  drivers/spi/atmel-quadspi.c | 7 ++++++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> >> index ddc712410812..645284c6ec9a 100644
> >> --- a/drivers/spi/atmel-quadspi.c
> >> +++ b/drivers/spi/atmel-quadspi.c
> >> @@ -155,6 +155,7 @@ struct atmel_qspi {
> >>  	struct clk		*clk;
> >>  	struct platform_device	*pdev;
> >>  	u32			pending;
> >> +	u32			smm;
> >>  	struct completion	cmd_completion;
> >>  };
> >>  
> >> @@ -238,7 +239,11 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
> >>  	icr = QSPI_ICR_INST(op->cmd.opcode);
> >>  	ifr = QSPI_IFR_INSTEN;
> >>  
> >> -	qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
> >> +	/* Set the QSPI controller in Serial Memory Mode */
> >> +	if (aq->smm != QSPI_MR_SMM) {  
> > 
> > Sorry, I think I misunderstood your previous suggestion, I thought the
> > reg was called SMM. If the reg is called MR and the value you expect in
> > there is SMM, then the field should be named ->mr as it caches the
> > whole reg, not only the SMM bit. So it's actually:
> > 
> > 	if (aq->mr != QSPI_MR_SMM) {  
> 
> No worries. When keeping the reg name, and not the bit itself, I would expect to
> do the check as in v2, to let room for checking other bits too:
> 
> +	if (!(aq->mr & QSPI_MR_SMM))
> 
> I don't have any problems to keep "mr" name, but I would like to understand your
> reasons.

Either you want to only set the SMM bit and keep the other bits
untouched or you want to make sure the register contains the value you
expect for all bitfields. If you're trying to achieve the former, you
should only update SMM instead of setting SMM + clearing all other
bits. In the other hand, if you want to apply a new MR setting where
you know exactly that only SMM should be set, that means you should
test the value in the cache (->mr) against the value you expect, and
not only the check that QSPI_MR_SMM is set.

BTW, you should probably initialize ->mr at probe time (using a
readl_relaxed()).