[U-Boot] [PATCH] usb: do explicit unaligned accesses

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Marek,

On Fri, 31 Aug 2012 01:29:05 +0200, Marek Vasut <marex@denx.de> wrote:

> Dear Lucas Stach,
> 
> > usb_hub_descriptor has to be packed as it's used for
> > communication with the device. Member wHubCharacteristics
> > violates the natural alignment rules.
> > 
> > Use explicit unaligned access functions for this member.
> > Fixes ARMv7 traping while using USB.
> 
> Shouldn't a properly configured compiler prevent such behavior?

This has been discussed before. As a summary:

1. A properly configured compiler can pad a structure so that the
fields always start at an aligned address (assuming the structure base
address is itself aligned). But that alters the structure, and here
there must be no alterations to the structure.

2. A properly (and differently) configured compiler can automatically
generate native unaligned accesses to unaligned fields. This is
acceptable on armv6+ architectures, has a performance penalty on earlier
architectures, and does not necessarily work depending on the hardware
configuration.
 
3. A properly (and differently yet) configured compiler can
automatically generate non-native unaligned accesses to unaligned
fields. This is acceptable on all architectures, has a performance
penalty on pre-armV6 architectures for all misaligned accesses, whether
voluntary or not. 

The conclusion of the discussion is as follows -- or to be more exact,
following this discussion, this is my stance as the U-Boot custodian:

i) All the code intended to run 'close to' U-Boot (i.e., U-Boot code
itself and application code) is controlled enough that we should be
able to know and limit which code requires misaligned access (such as
here for this USB structure field);

ii) On some ARM architectures, and possibly some non-ARM architectures
as well, native misaligned access incur a performance hit, and may
even simply be impossible or forbidden by a hardware or system design
decision.

iii) Thus, U-Boot should follow a strict policy of using native aligned
accesses only, possibly enforcing misaligned native access prevention in
hardware, and of explicitly emulating misaligned accesses when they
cannot be avoided. 

Hope this clarifies.

Amicalement,
-- 
Albert.