Am 14.01.2013 12:22, schrieb Ville Syrj?l?: > On Fri, Jan 11, 2013 at 09:15:40PM +0100, Daniel Vetter wrote: >> On Fri, Jan 11, 2013 at 05:57:51PM -0200, Rodrigo Vivi wrote: >>> From: Shobhit Kumar <shobhit.kumar at intel.com> >>> >>> Signed-off-by: Sateesh Kavuri <sateesh.kavuri at intel.com> >>> >>> v2: Modified and corrected the structures to be more in line for >>> kernel coding guidelines and rebased the code on Paulo's DP patchset >>> >>> Signed-off-by: Shobhit Kumar <shobhit.kumar at intel.com> >>> >>> v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE >>> >>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at gmail.com> >> >> DP spec stuff should be put into the drm core imo, i.e. into >> include/drm/drm_dp_helper.h Since all bitfields are u8 we also have no >> problems with endianess for this. > > I don't think C guarantees anything about the order of bits inside > bitfieds. > C11 standard, section 6.7.2.1: "An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified." C doesn't guarantee that your u8 is a valid type for bit-fields. The only types a C compiler must support for bit-fields are bool, int, signed int and unsigned int (note that bit-fields are also the only place where the type int can be different from signed int). Philipp
