On Fri, 2015-10-09 at 00:26 +0000, Rustad, Mark D wrote:
> Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
>
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -176,6 +176,8 @@ enum pci_dev_flags {
> > > > PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> > > > /* Provide indication device is assigned by a Virtual Machine Manager */
> > > > PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > +> > > > /* Get VPD from function 0 VPD */
> > +> > > > PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
> > };
> >
> > enum pci_irq_reroute_variant {
>
> In this hunk I happened to notice the change in how these values are
> assigned. Should the new value remain (1 << 8) or should it fall in
> line with the older implementation and simply be 8? Or should it be
> 256? It depends on which kind of consistency you prefer for the
> backport.
They're bit masks, not bit numbers, both in 3.2 and upstream. In
mainline, bits 3-7 have already been assigned to other flags. I don't
see the need to renumber or write the value differently when
backporting.
Ben.
--
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.Attachment:
signature.asc
Description: This is a digitally signed message part