> These would be different from the macros that are available in bitfield.h, but > not *fundamentally* different, so these would look a little redundant... > > I think that you refer to that `pitch` variable that's coming from the DRM(/fb) > API... and bitfield macros are for register access... so I guess that one clean > way of avoiding the magic shifting (that is purely used to split the 32-bits > number in two 16-bits 'chunks') would be to perhaps use a union, so that you > will have something like u.pitch_lsb, u.pitch_msb (with lsb/msb being two u16). Do you mean something like this? union pitch_val { struct split_pitch_val { uint16_t lsb; uint16_t msb; } split; uint32_t val; }; I think my concern with that approach would be it assumes the compiler packs structs tightly and it also assumes the endianness of the machine, whereas a bitshift is maybe more portable. Is this an issue worth considering since we know this driver will only run on specific MTK SoCs?