On Sat, Feb 25, 2017 at 08:40:03AM +0100, Lukas Wunner wrote:
> On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote:
> > On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > > --- a/include/linux/pci.h
> > > +++ b/include/linux/pci.h
> > > @@ -358,6 +358,7 @@ struct pci_dev {
> > > unsigned int is_virtfn:1;
> > > unsigned int reset_fn:1;
> > > unsigned int is_hotplug_bridge:1;
> > > + unsigned int is_thunderbolt:1; /* Thunderbolt controller */
> >
> > I'm not really keen on having this in the PCI core because the core
> > doesn't need this or even know what it means.
> >
> > pci_find_next_ext_capability() is available to drivers, and if
> > Thunderbolt-connectedness is useful information to apple-gmux or GPU
> > drivers, it's fine with me if you want to use it there. I just don't
> > see the benefit to having it in the core.
>
> The above contradicts your statement 3 days earlier:
>
> "Assuming we need it, having it in struct pci_dev is fine.
> There's no point in looking up the VSEC capability more than once."
> (http://www.spinics.net/lists/linux-pci/msg58532.html)
It's clear that none of the proposed uses is related to Thunderbolt as
a technology, which is why I would suggest we don't need the flag.
But in the interest of moving on, if you remove the changelog part
about whitelisting Thunderbolt for runtime PM (since that's not part
of this series), you can add my:
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
