From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Sat, 28 Dec 2013 00:07:42 +0100
Subject: [U-Boot] [PATCH 1/3] mtd: onenand: Fix unaligned access
In-Reply-To: <1388016086-20293-1-git-send-email-marex@denx.de>
References: <1388016086-20293-1-git-send-email-marex@denx.de>
Message-ID: <201312280007.42883.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thursday, December 26, 2013 at 01:01:24 AM, Marek Vasut wrote:
> Fix unaligned access in OneNAND core. The problem is that the ffchars[]
> array is an array of "unsigned char", but in onenand_write_ops_nolock()
> can be passed to the memcpy_16() function. The memcpy_16() function will
> treat the buffer as an array of "unsigned short", thus triggering
> unaligned access if the compiler decided ffchars[] to be not aligned.
> 
> I managed to trigger the problem with regular ELDK 5.4 GCC compiler.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Tom Rini <trini@ti.com>
> ---
>  drivers/mtd/onenand/onenand_base.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c index 979e4af..e33e8d3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -91,7 +91,13 @@ static struct nand_ecclayout onenand_oob_32 = {
>  	.oobfree	= { {2, 3}, {14, 2}, {18, 3}, {30, 2} }
>  };
> 
> -static const unsigned char ffchars[] = {
> +/*
> + * Warning! This array is used with the memcpy_16() function, thus
> + * it must be aligned to 2 bytes. GCC can make this array unaligned
> + * as the array is made of unsigned char, which memcpy16() doesn't
> + * like and will cause unaligned access.
> + */
> +static const unsigned char __aligned(2) ffchars[] = {
>  	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>  	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,	/* 16 */
>  	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,

Lukasz, can you please review this one?

Best regards,
Marek Vasut