> On 20 Jun 2023, at 13:39, Jan Beulich <jbeul...@suse.com> wrote: > > On 20.06.2023 12:34, Simone Ballarin wrote: >> --- a/xen/drivers/passthrough/amd/iommu-defs.h >> +++ b/xen/drivers/passthrough/amd/iommu-defs.h >> @@ -38,49 +38,49 @@ >> ((uint64_t)(offset) << (12 + (PTE_PER_TABLE_SHIFT * ((level) - 1)))) >> >> /* IOMMU Capability */ >> -#define PCI_CAP_ID_MASK 0x000000FF >> +#define PCI_CAP_ID_MASK 0x000000FFU > > Seeing this and similar uses further down, I think there's a purely > stylistic question to be resolved first (and hence I'm widening the To: > list here): Do we want to allow either case of U to be used > interchangeably, leaving the choice up to the patch author?
Because you ask to the list, my personal opinion is that we might want to have only capital U, so that it’s consistent across the codebase and we don’t need to create too many rules for the developer, it stands out anyway as it can’t be an hex digit, also maybe every hex constant is nicer to have with all capital, but this is another subject. Said that, clearly it’s up to the maintainers to choose. > > Personally at least for hex numbers I'd prefer the suffix to stand out: If > the digits use upper case, have the suffix be lower case and vice versa. > (If there are only numbers, then surrounding context would need > consulting.) I realize though that this will not fit well with the desire > of avoiding lower-case l in number suffixes; it would be fine for e.g. > 0xFFul. Not sure in how many cases this would matter though, as I expect > most constants want to be unsigned. > > Jan >
