summaryrefslogtreecommitdiff
path: root/drivers/i2c
diff options
context:
space:
mode:
authorNikita Kiryanov <nikita@compulab.co.il>2013-12-16 19:19:01 +0200
committerScott Wood <scottwood@freescale.com>2013-12-17 17:46:53 -0600
commiteb237a15bd793a785feb0c77c459c9f97c6fbe4c (patch)
treeba4253248338d3e2a14350db4df34ae9fec7c44d /drivers/i2c
parent3ef1eadb4466a68a32cb56e6be98a98061c07673 (diff)
downloadu-boot-imx-eb237a15bd793a785feb0c77c459c9f97c6fbe4c.zip
u-boot-imx-eb237a15bd793a785feb0c77c459c9f97c6fbe4c.tar.gz
u-boot-imx-eb237a15bd793a785feb0c77c459c9f97c6fbe4c.tar.bz2
mtd: nand: omap: fix sw->hw->sw ecc switch
When switching ecc mode, omap_select_ecc_scheme() assigns the appropriate values into the current nand chip's ecc.layout struct. This is done under the assumption that the struct exists only to store values, so it is OK to overwrite it, but there is at least one situation where this assumption is incorrect: When switching to 1 bit hamming code sw ecc, the job of assigning layout data is outsourced to nand_scan_tail(), which simply assigns into ecc.layout a pointer to an existing struct prefilled with the appropriate values. This struct doubles as both data and layout definition, and therefore shouldn't be overwritten, but on the next switch to hardware ecc, this is exactly what's going to happen. The next time the user switches to software ecc, they're going to get a messed up ecc layout. Prevent this and possible similar bugs by explicitly using the private-to-omap_gpmc.c omap_ecclayout struct when switching ecc mode. Cc: Scott Wood <scottwood@freescale.com> Cc: Pekon Gupta <pekon@ti.com> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Diffstat (limited to 'drivers/i2c')
0 files changed, 0 insertions, 0 deletions