Re: [Xen-devel] [PATCH v6 05/11] pci: split code to size BARs from pci_add_device

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.10.17 at 15:31, <roger.pau@xxxxxxxxxx> wrote:
> On Wed, Oct 04, 2017 at 08:32:06AM +0000, Jan Beulich wrote:
>> >>> On 19.09.17 at 17:29, <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel