Messages in this thread | | | Subject | Re: [PATCH v8 1/5] PCI: Conditionally initialize host bridge native_* members | From | "Kuppuswamy, Sathyanarayanan" <> | Date | Tue, 15 Sep 2020 19:30:31 -0700 |
| |
On 9/15/20 3:17 PM, Bjorn Helgaas wrote: > On Sun, Sep 13, 2020 at 01:49:26PM -0700, Kuppuswamy, Sathyanarayanan wrote: >> On 9/10/20 2:00 PM, Kuppuswamy, Sathyanarayanan wrote: >>> On 9/10/20 12:49 PM, Bjorn Helgaas wrote: >>>> On Fri, Jul 24, 2020 at 08:58:52PM -0700, sathyanarayanan.kuppuswamy@linux.intel.com wrote: >>>>> From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> >>>>>
>> >> But I am wondering whether its correct to move LTR code under >> CONFIG_PCIEPORTBUS?. As per PCIe spec v5.0 sec 7.8.2, LTR is a >> optional PCIe extended capability. So why is not moved under >> drivers/pci/pcie/*. What is the criteria for code to be placed under >> drivers/pci/pcie/* > > Some folks think drivers/pci/pcie/ should not exist, and I tend to > agree, but it's a fair bit of churn to remove it. We do have quite a > bit of PCIe extended capability support in drivers/pci -- ats.c, > iov.c, vc.c. > > There's no need to move LTR under CONFIG_PCIEPORTBUS because > CONFIG_PCIEPORTBUS enables portdrv, and AFAIK there's nothing > LTR-related that relies on portdrv. > > The stuff currently in drivers/pci/pcie is mostly just portdrv and > services that depend on it. aspm.c and ptm.c are exceptions and > really should be in drivers/pci. Thanks for the clarification. I will remove the CONFIG_PCIEPORTBUS dependency. >
>>>>> -- >>>>> 2.17.1 >>>>> >>> >> >> -- >> Sathyanarayanan Kuppuswamy >> Linux Kernel Developer
-- Sathyanarayanan Kuppuswamy Linux Kernel Developer
| |