linux-kernel - Re: [PATCH] mtd: cfi_cmdset_0001.c: fix resume for LH28F640BF chips

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]

Message-ID: <20141028222511.GB23619@ld-irv-0074>
Date:	Tue, 28 Oct 2014 15:25:11 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Andrea Adami <andrea.adami@...il.com>
Cc:	linux-mtd@...ts.infradead.org,
	David Woodhouse <dwmw2@...radead.org>,
	Christian Riesch <christian.riesch@...cron.at>,
	Jingoo Han <jg1.han@...sung.com>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: cfi_cmdset_0001.c: fix resume for LH28F640BF chips

On Thu, Oct 23, 2014 at 01:23:01AM +0200, Andrea Adami wrote:
> After '#echo mem > /sys/power/state' some devices can not be properly resumed
> because apparently the MTD Partition Configuration Register has been reset
> to default thus the rootfs cannot be mounted cleanly on resume.
> An example of this can be found in the SA-1100 Developer's Manual at 9.5.3.3
> where the second step of the Sleep Shutdown Sequence is described:
> "An internal reset is applied to the SA-1100. All units are reset...".
> 
> As workaround we refresh the PCR value as done initially on chip setup.
> 
> This behavior and the fix are confirmed by our tests done on 2 different Zaurus
> collie units with kernel 3.17.
> 
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
> Signed-off-by: Andrea Adami <andrea.adami@...il.com>

Who's the author? I have a 'From' header (which becomes the patch
author) of Andrea, but the sign-off is Dmitry. If you add a
'From: xxx <yyy@....tld>' line to the beginning of the email, that can
clarify the author, even when the author is not emailing.

git-send-email will also handle that for you, if the original git commit
has the proper author.

> ---
>  drivers/mtd/chips/cfi_cmdset_0001.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index a7543ba..59e2355 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -2590,6 +2590,8 @@ static void cfi_intelext_resume(struct mtd_info *mtd)
>  
>  		/* Go to known state. Chip may have been power cycled */
>  		if (chip->state == FL_PM_SUSPENDED) {
> +			/* Refresh LH28F640BF Partition Config. Register */
> +			fixup_LH28F640BF(mtd);

OK, that looks fine.

But while we're at it, it seems like any chip which has a boot-time
fixup hook in cfi_fixup_table[] should be run at resume time, since
those chips may have lost power too. For instance, it looks like
fixup_unlock_powerup_lock() would need rerun.

I'm not sure if we should do a more invasive patch like that without any
testing, though.

>  			map_write(map, CMD(0xFF), cfi->chips[i].start);
>  			chip->oldstate = chip->state = FL_READY;
>  			wake_up(&chip->wq);

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/