Re: iwlwifi firmware load broken in current -git

[Jens Axboe <axboe@kernel.dk>]

On 09/14/2017 11:28 AM, Srinath Mannam wrote:
> Hi Bjorn,
> 
> On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe <axboe@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 <axboe@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.

-- 
Jens Axboe