Last minute urgent pull request to prevent file system corruption

on Nokia N900.
 
 Looks like we have a GPMC bus timing bug that has gone unnoticed
 because of bootloader configured registers until few days ago. We
 are not detecting the onenand clock rate properly unless we have
 CONFIG_OMAP_GPMC_DEBUG set and this causes onenand corruption
 that can be easily be reproduced.
 
 There seems to be also an additional bug still lurking around for
 onenand corruption. But that is still being investigated and
 it does not seem to be GPMC timings related.
 
 Meanwhile, it would be good to get this fix into v4.4 to prevent
 wrong timings from corrupting onenand.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJWj+LZAAoJEBvUPslcq6VzRwMQAN9cxwbGblHuEnt22GJEQNUP
 XRgAB6j00zKugAYg5QCXihZf+SgQuvI8VeB+BeI0K0vL0zNnLlF/jiKYg1fwzDvr
 jcKx8dKbcfI7idWtNP2DL1nWe9dDjT+hBye3xH/DavXFcvFiuMLrBtbZ2WO1zPn7
 MYADo5jh+X3/Cl+9okS0q7ZblaZ+txs+8dl87bIkup96A2hYw/Zp+h4H7PcnJbFn
 4YyOVMsHwTUeCXCbcd5aDZvENN4uhXYFZXo1glrB4GePz7F7ST+vgUZkhuSqI4Z0
 vwRpYPjLtZfsvW9SWodMLt7r7qIKYbEX7ATtjYIV2QLa8QL14KUZLFk35VgXGCA5
 WciP3UeNQrzQPUSnDfthYDVDWV50EbrN0Tw3/f+xo4RDGYfMZ5A26jZsJavHaEHj
 stB0EGy72RkqUJmCqquP3X2k1W2JsFbhI/WKyHxZspOuvadFzbfW5Rz8I1ad6+68
 b485s5qPLYpufZj5+03wAnuCJBVz8A6x6qAZqi2sIaHbqa8H0b0/u85Svrfe0y45
 PxxwLbjipWy2/FCTicJL3HiboSGdJoXXO6ru65oEqG7J6BFGk/607QCSpEB3FWbW
 jx/4WbdMcsoPgqlbFoCG5TSPD7esMdhBNlZirZiAvRoPeSdmQVOy230dLn7Cek7z
 3ws+XPHWsOSgATpwvE//
 =QtBl
 -----END PGP SIGNATURE-----

Merge tag 'omap-for-v4.4/onenand-corruption' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

Pull "urgent onenand file system corruption fix for n900" from Tony Lindgren:

Last minute urgent pull request to prevent file system corruption
on Nokia N900.

Looks like we have a GPMC bus timing bug that has gone unnoticed
because of bootloader configured registers until few days ago. We
are not detecting the onenand clock rate properly unless we have
CONFIG_OMAP_GPMC_DEBUG set and this causes onenand corruption
that can be easily be reproduced.

There seems to be also an additional bug still lurking around for
onenand corruption. But that is still being investigated and
it does not seem to be GPMC timings related.

Meanwhile, it would be good to get this fix into v4.4 to prevent
wrong timings from corrupting onenand.

* tag 'omap-for-v4.4/onenand-corruption' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Fix onenand rate detection to avoid filesystem corruption

arch/arm/mach-omap2/gpmc-onenand.c

@@ -149,8 +149,8 @@ static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg,
 		freq = 104;
 		break;
 	default:
-		freq = 54;
-		break;
+		pr_err("onenand rate not detected, bad GPMC async timings?\n");
+		freq = 0;
 	}
 
 	return freq;
@@ -271,6 +271,11 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
 	struct gpmc_timings t;
 	int ret;
 
+	/*
+	 * Note that we need to keep sync_write set for the call to
+	 * omap2_onenand_set_async_mode() to work to detect the onenand
+	 * supported clock rate for the sync timings.
+	 */
 	if (gpmc_onenand_data->of_node) {
 		gpmc_read_settings_dt(gpmc_onenand_data->of_node,
 				      &onenand_async);
@@ -281,12 +286,9 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
 			else
 				gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
 			onenand_async.sync_read = false;
-			onenand_async.sync_write = false;
 		}
 	}
 
-	omap2_onenand_set_async_mode(onenand_base);
-
 	omap2_onenand_calc_async_timings(&t);
 
 	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);
@@ -310,6 +312,8 @@ static int omap2_onenand_setup_sync(void __iomem *onenand_base, int *freq_ptr)
 	if (!freq) {
 		/* Very first call freq is not known */
 		freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
+		if (!freq)
+			return -ENODEV;
 		set_onenand_cfg(onenand_base);
 	}