>>> On 04.10.17 at 15:31, <roger....@citrix.com> wrote: > On Wed, Oct 04, 2017 at 08:32:06AM +0000, Jan Beulich wrote: >> >>> On 19.09.17 at 17:29, <roger....@citrix.com> wrote: >> > --- a/xen/include/xen/pci.h >> > +++ b/xen/include/xen/pci.h >> > @@ -189,6 +189,10 @@ const char *parse_pci(const char *, unsigned int >> > *seg, unsigned int *bus, >> > const char *parse_pci_seg(const char *, unsigned int *seg, unsigned int >> > *bus, >> > unsigned int *dev, unsigned int *func, bool >> > *def_seg); >> > >> > +#define _PCI_BAR_VF 0 >> > +#define PCI_BAR_VF (1u << _PCI_BAR_VF) >> >> Do you really need both? I know we have quite a few cases where flags >> are being defined this way, but that's usually when bit operations >> (test_bit() and alike) are intended on the flags fields. > > Ack, would you then rather prefer to have 1, or (1u << 0)? (to keep it > in line with the other flag that will be added later).
1u please, as that's going to be mandatory once someone adds a definition for the 32nd flag bit. The other option would be to use a plain hex constant without involving the shift operator. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel