Il 12/10/22 16:12, Justin Green ha scritto:
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?
Yes I mean something like that (except, use u16, u32 short form)... and that should be safe really. As for the endianness, a lot more would break already, so I don't see that as a concern right now.
