[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/5] pci: switch pci_conf_{read/write} to use pci_sbdf_t



On Tue, May 28, 2019 at 02:51:22AM -0600, Jan Beulich wrote:
> >>> On 27.05.19 at 18:44, <roger.pau@xxxxxxxxxx> wrote:
> > On Fri, May 24, 2019 at 04:01:23AM -0600, Jan Beulich wrote:
> >> >>> On 10.05.19 at 18:10, <roger.pau@xxxxxxxxxx> wrote:
> >> > --- a/xen/include/xen/pci.h
> >> > +++ b/xen/include/xen/pci.h
> >> > @@ -58,6 +58,11 @@ typedef union {
> >> >      };
> >> >  } pci_sbdf_t;
> >> >  
> >> > +#define PCI_SBDF_T(s, b, d, f) \
> >> > +    ((pci_sbdf_t) { .seg = (s), .bus = (b), .dev = (d), .func = (f) })
> >> 
> >> I'd prefer if the _T suffix could be omitted. Afaics there's no use of the
> >> existing PCI_SBDF() anywhere in the tree, so this should be fine. For
> >> the 2nd macro below I can't easily tell whether the few existing used
> >> have all disappeared by now, but it seems likely.
> > 
> > I can see about dropping the _T suffix, but I think there's likely
> > some overlap between the introduction of PCI_SBDF_T and the last user
> > of the current PCI_SBDF helpers, so maybe it's fine to use the _T
> > suffix at first and have one final patch that removes it?
> 
> That would be an option if it can't be done in one go, sure.
> 
> >> Also I'm afraid initializers of this kind will break the build with old 
> >> gcc.
> > 
> > I thought we dropped support for such old versions of gcc, is that not
> > the case?
> 
> No yet, as per ./README.

Right, so then I guess the only solution would be to use something
like:

#define PCI_SBDF_T(s, b, d, f) \
    ((pci_sbdf_t) { .sbdf = PCI_SBDF(s,b,d,f) })

And similarly for the other initializers. I guess then you would be
fine with using the _T suffix for those helpers and keeping the
current ones as-is?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.