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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.05.19 at 12:05, <roger.pau@xxxxxxxxxx> wrote:
> 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) })

I think so, yes.

> 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?

Not really, no - I would hope for this to be the only use of
PCI_SBDF(), and hence I'd still like the _T to be dropped and the
current macro to be expanded explicitly.

Jan



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