linux-kernel - Re: [PATCH 2/4] mtd: m25p80: make CONFIG_M25PXX_USE_FAST

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: <20130819084226.GB31036@pengutronix.de>
Date:	Mon, 19 Aug 2013 10:42:26 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	linux-mtd@...ts.infradead.org, Marek Vasut <marex@...x.de>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH 2/4] mtd: m25p80: make CONFIG_M25PXX_USE_FAST_READ safe
 to enable

On Sat, Aug 17, 2013 at 01:17:02PM -0700, Brian Norris wrote:
> On Mon, Aug 12, 2013 at 12:22:24PM +0200, Sascha Hauer wrote:
> > This patch adds a flag to struct flash_info indicating that
> > fast_read is not supported. This now gives the following logic
> > when determing whether to enable fastread:
> > 
> > 1) enable fast_read if device node contains m25p,fast-read
> > 2) enable fast_read unconditionally if forced in Kconfig
> > 3) Disable fast_read if the chip does not support it
> 
> This logic is either unclear or incorrect.
> 
> > This makes enabling CONFIG_M25PXX_USE_FAST_READ a safe option
> > since we no longer enable the fast_read option unconditionally.
> 
> This statement seems to contradict 2 above, depending on the reading
> (how can 2 enable "unconditionally", yet CONFIG_..._FAST_READ "no longer
> enable[s] ... unconditionally"?).
> 
> The problem I have with this description is that it is assuming that
> 1, 2, and 3 are applied sequentially, so that later items in the
> sequence have higher precedence. So it's describing code ordering, not
> really logic. And statement 3 weakens the "unconditionally" of 2.
> 
> And to avoid simply complaining, I propose an alternative explanation:
> 
>   If the flash chip does not support fast_read, then disable it.
>   Otherwise:
>   1) enable fast_read if device node contains m25p,fast-read
>   2) enable fast_read if forced in Kconfig
> 
> If we correct this description, then:
> 
>   Acked-by: Brian Norris <computersforpeace@...il.com>
> 
> I can edit the patch and push the whole thing if this is acceptable.

Yes, that would be great. Your explanation sounds better than mine.

> 
> One related question (not required for this series): do we even need
> Kconfig M25PXX_USE_FAST_READ any more? Are there any SPI controllers
> that can't use FAST_READ? Or perhaps if they have a slow clock, it's
> preferable to use normal read?
> 
> If there are no restrictions from the controller side, I think this
> NO_FR flag gives enough information to determine everything at runtime,
> not compile-time.

This M25PXX_USE_FAST_READ is a no-go for multiplatform Kernels and
should be removed. I have no idea though how we can do this without
risking regressions since we have no idea who intentionally disabled
this option. Maybe we just have to find out by removing it and waiting
for people to complain^B^B^Bsend patches.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/