On Fri, Nov 12, 2010 at 04:14:51PM +0100, Arnd Bergmann wrote:
> Some people prefer to express all this in C instead of macros:
>
> struct mcde_registers {
> enum {
> mcde_cr_dsicmd2_en = 0x00000001,
> mcde_cr_dsicmd1_en = 0x00000002,
> ...
> } cr;
> enum {
> mcde_conf0_syncmux0 = 0x00000001,
> ...
> } conf0;
> ...
> };
>
> This gives you better type safety, but which one you choose is your decision.
It is a bad idea to describe device registers using C structures, and
especially enums.
The only thing C guarantees about structure layout is that the elements
are arranged in the same order which you specify them in your definition.
It doesn't make any guarantees about placement of those elements within
the structure.
As far as enums go, which type they correspond with is not really
predictable in portable code:
6.7.2.2 Enumeration specifiers
Constraints
4 Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is implementation-
defined,108) but shall be capable of representing the values of all
the members of the enumeration. The enumerated type is incomplete
until after the } that terminates the list of enumerator declarations.
108) An implementation may delay the choice of which integer type
until all enumeration constants have been seen.
So, given your example above, an implementation (or architecture) may
decide that 'cr' is a 'char' represented by 8 bits, while another
implementation may decide that it is an 'int' of 32 bits.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
