From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Thu, 23 Feb 2012 21:12:16 +0530 Subject: [U-Boot] [PATCH v3 5/6] omap4+: Avoid using __attribute__ ((__packed__)) In-Reply-To: <201202231003.03101.vapier@gentoo.org> References: <1328528248-20872-1-git-send-email-aneesh@ti.com> <1330005966-1444-5-git-send-email-aneesh@ti.com> <201202231003.03101.vapier@gentoo.org> Message-ID: <4F465E58.4070303@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thursday 23 February 2012 08:33 PM, Mike Frysinger wrote: > On Thursday 23 February 2012 09:21:00 Tom Rini wrote: >> On Thu, Feb 23, 2012 at 7:06 AM, Aneesh V wrote: >>> Avoid using __attribute__ ((__packed__)) unless it's >>> absolutely necessary. "packed" will remove alignment >>> requirements for the respective objects and may cause >>> alignment issues unless alignment is also enforced >>> using a pragma. >>> >>> Here, these packed attributes were causing alignment >>> faults in Thumb build. >> >> Why did we pack these to start with? Otherwise seems fine (and I see >> the rest of the TI parts don't have this particular packing). > > because these represent hardware register blocks which get used with writew() > and typically those blocks get marked packed. No. That's not the case. This is just a table that has the mux data for the board. It's not directly mapped to hardware. The hardware register offset is part of this table. > > if the arch won't introduce padding with the members, then this change should > be ok, and looking at the structs which are just 2 16bit members, that should > be the case here. > > if you really want to be pedantic, i think the alternative would be: > struct pad_conf_entry {} __packed __aligned(2); I had tried that and it had solved the problem too, but the "packed" is not needed at all. That's purely a software table. regards, Aneesh