On Thu, 27 Sep 2018, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > On Thu, 27 Sep 2018, Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx> wrote: >> On Thu, 27 Sep 2018 11:40:19 +0200, Jani Nikula <jani.nikula@xxxxxxxxx> >> wrote: >> >>> This is an RFC to get input on how people feel about moving towards >>> using <linux/bits.h> and <linux/bitfield.h> macros for register field >>> definitions and manipulation: >>> >>> * BIT() >>> * GENMASK() >> >> BIT/GENMASK macros assumes 'unsigned long' type (64b) while our registers >> (and some of our temporary variables) are 'unsigned int' (32b). > > I don't see a problem with that as long as we stick to unsigned types. Okay, there's a problem with mixing (1 << n) with GENMASK, as the former is signed. Using BIT() and GENMASK() together works better. Another slight annoyance is printf formats, which are currently written for unsigned ints, and passing GENMASK or BIT to prints will make them require unsigned longs. I don't think we use that a whole lot, but it's a consideration. If all else fails, we can write our own wrappers for u32, though it's a bit meh. BR, Jani. > >> It was reported [1] that use of plain BIT(0) may cause compilation issues. > > That mixes signed and unsigned types. > > > BR, > Jani. > >> >> Michal >> >> [1] >> https://lists.freedesktop.org/archives/intel-gfx/2018-September/176704.html >> >>> * FIELD_GET() >>> * FIELD_PREP() >> >> -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
