On 09/14/2017 11:44 AM, Srinath Mannam wrote: > Hi Jens Axboe, > > On Thu, Sep 14, 2017 at 11:05 PM, Jens Axboe <ax...@kernel.dk> wrote: >> On 09/14/2017 11:28 AM, Srinath Mannam wrote: >>> Hi Bjorn, >>> >>> On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe <ax...@kernel.dk> wrote: >>>> >>>> On 09/14/2017 11:11 AM, Bjorn Helgaas wrote: >>>>> [+cc linux-pci] >>>>> >>>>> On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe <ax...@kernel.dk> wrote: >>>>>> On 09/12/2017 02:04 PM, Johannes Berg wrote: >>>>>>> On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote: >>>>>>> >>>>>>>> CC'ing the guilty part and Bjorn. I'm assuming it's the >>>>>>>> pci_is_enabled() check, since the rest of the patch shouldn't have >>>>>>>> functional changes. >>>>>>> >>>>>>> and pci_enable_bridge() already checks if it's already enabled, but >>>>>>> still enables mastering in that case if it isn't: >>>>>>> >>>>>>> static void pci_enable_bridge(struct pci_dev *dev) >>>>>>> { >>>>>>> [...] >>>>>>> if (pci_is_enabled(dev)) { >>>>>>> if (!dev->is_busmaster) >>>>>>> pci_set_master(dev); >>>>>>> return; >>>>>>> } >>>>>>> >>>>>>> so I guess due to the new check we end up with mastering disabled, and >>>>>>> thus the firmware can't load since that's a DMA thing? >>>>>> >>>>>> Bjorn/Srinath, any input here? This is a regression that prevents wifi >>>>>> from working on a pretty standard laptop. It'd suck to have this be in >>>>>> -rc1. Seems like the trivial fix would be: >>>>>> >>>>>> >>>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c >>>>>> index b0002daa50f3..ffbe11dbdd61 100644 >>>>>> --- a/drivers/pci/pci.c >>>>>> +++ b/drivers/pci/pci.c >>>>>> @@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct pci_dev >>>>>> *dev, unsigned long flags) >>>>>> return 0; /* already enabled */ >>>>>> >>>>>> bridge = pci_upstream_bridge(dev); >>>>>> - if (bridge && !pci_is_enabled(bridge)) >>>>>> + if (bridge) >>> With this change and keeping "mutex_lock(&pci_bridge_mutex);" in >>> pci_enable_bridge functoin will causes a nexted lock. >> >> Took a look, and looks like you are right. That code looks like a mess, >> fwiw. >> >> I'd strongly suggest that the bad commit is reverted until a proper >> solution is found, since the simple one-liner could potentially >> introduce a deadlock with your patch applied. > atomic_inc_return(&dev->enable_cnt) in function > pci_enable_device_flags enables passed pcie device. > !pci_is_enabled(bridge) check in "if (bridge && > !pci_is_enabled(bridge))" checks for bridge device of previous pcie > device. > So it will not stop bus_master of bridge device. > In your case how many bridges in between endpoint and host bridge? > Please provide the details about your use case.
It's a bog standard Lenovo X1 Carbon, gen4. # lspci 00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev 08) 00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 07) 00:08.0 System peripheral: Intel Corporation Sky Lake Gaussian Mixture Model 00:13.0 Non-VGA unclassified device: Intel Corporation Device 9d35 (rev 21) 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI (rev 21) 00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1) 00:1c.2 PCI bridge: Intel Corporation Device 9d12 (rev f1) 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port (rev f1) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 21) 04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a) 05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01) # lspci -t -[0000:00]-+-00.0 +-02.0 +-08.0 +-13.0 +-14.0 +-14.2 +-16.0 +-1c.0-[02]-- +-1c.2-[04]----00.0 +-1c.4-[05]----00.0 +-1f.0 +-1f.2 +-1f.3 +-1f.4 \-1f.6 -- Jens Axboe