linux-kernel - Re: [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode

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:   Tue, 8 Oct 2019 09:28:32 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     masonccyang@...c.com.tw
Cc:     "Miquel Raynal" <miquel.raynal@...tlin.com>, bbrezillon@...nel.org,
        computersforpeace@...il.com, dwmw2@...radead.org,
        frieder.schrempf@...tron.de, gregkh@...uxfoundation.org,
        juliensu@...c.com.tw, linux-kernel@...r.kernel.org,
        linux-mtd@...ts.infradead.org, marcel.ziswiler@...adex.com,
        marek.vasut@...il.com, richard@....at, tglx@...utronix.de,
        vigneshr@...com
Subject: Re: [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down
 mode

On Tue, 8 Oct 2019 10:06:50 +0800
masonccyang@...c.com.tw wrote:

> > > +   nand_select_target(chip, 0);  
> > 
> > On several NAND controllers there is no way to act on the CS line
> > without actually writing bytes to the NAND chip. So basically this
> > is very likely to not work.  
> 
> any other way to make it work ? GPIO ?
> or just have some comments description here.
> i.e,.
> 
> /* The NAND chip will exit the deep power down mode with #CS toggling, 
>  * please refer to datasheet for the timing requirement of tCRDP and tRDP.
>  */
> 

Good luck with that. As Miquel said, on most NAND controllers
select_target() is a dummy operation that just assigns nand_chip->target
to the specified value but doesn't assert the CS line. You could send a
dummy command here, like a READ_ID, but I guess you need CS to be
asserted for at least 20ns before asserting any other signals (CLE/ALE)
which might be an issue.

> >   
> > > +   ndelay(20);  
> > 
> > Is this delay known somewhere? Is this purely experimental?  
> 
> it's timing requirement tCRDP 20 ns(min) to release device
> from deep power-down mode. 
> You may download datasheet at
> https://www.macronix.com/zh-tw/products/NAND-Flash/SLC-NAND-Flash/Pages/spec.aspx?p=MX30LF4G28AD&m=SLC%20NAND&n=PM2579 

Just looked at the datasheet, and there's actually more than tCRDP:

- you have to make sure you entered power-down state for at least tDPDD
  before you try to wake up the device
- the device goes back to stand-by state tRDP after the CS pin has been
  deasserted.

I guess we can use ndelay() for those, since they happen before/after
the CS pin is asserted/de-asserted. Be careful with ndelay() though,
it's not guaranteed to wait the the time you pass, it can return
before (maybe we should add a helper to deal with that).
Another solution would be to describe CS assertion/de-assertion in
the instruction flow, but that requires patching all exec_op() drivers.

For the tCRDP timing, I think we should use a nand_operation, this way
we can check if the controller is able to deal with dummy CS-assertion
before entering deep-power mode.
In order to do that you'll have to add a NAND_OP_DUMMY_INSTR (or
NAND_OP_DELAY_INSTR), and then have something like:

struct nand_op_instr instrs[] = {
	NAND_OP_DUMMY(tCRDP),
};