Re: [PATCH v3] ACPI, APEI: Cleanup alignment related codes for APEI

["Chen, Gong" <gong.chen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

On Mon, Dec 16, 2013 at 03:19:06PM +0100, Borislav Petkov wrote:
> Date: Mon, 16 Dec 2013 15:19:06 +0100
> From: Borislav Petkov <bp@alien8.de>
> To: "Chen, Gong" <gong.chen@linux.intel.com>
> Cc: tony.luck@intel.com, linux-acpi@vger.kernel.org
> Subject: Re: [PATCH v3] ACPI, APEI: Cleanup alignment related codes for APEI
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> On Fri, Nov 15, 2013 at 12:45:56AM -0500, Chen, Gong wrote:
> > diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
> > index 26311f2..bf30a12 100644
> > --- a/drivers/acpi/apei/erst.c
> > +++ b/drivers/acpi/apei/erst.c
> > @@ -611,7 +611,7 @@ static void __erst_record_id_cache_compact(void)
> >  		if (entries[i] == APEI_ERST_INVALID_RECORD_ID)
> >  			continue;
> >  		if (wpos != i)
> > -			memcpy(&entries[wpos], &entries[i], sizeof(entries[i]));
> > +			entries[wpos] = entries[i];
> 
> Why is it ok to drop the memcpy here and do a normal access?
> 
> __erst_record_id_cache_add_one still has a memcpy-like access.
> 
> What is the difference with all those accesses to erst_record_id_cache
> and why doesn't it need the unaligned helpers?
> 
> This all needs to be explained in detail in the commit message.
> 
> Thanks.
> 
erst record id cache is implemented in the memory to increase the access
speed via caching ERST content, so it doesn't matter with firmware access.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]