From: poza@codeaurora.org
To: Lukas Wunner <lukas@wunner.de>
Cc: Sinan Kaya <okaya@codeaurora.org>,
linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Bjorn Helgaas <bhelgaas@google.com>,
Keith Busch <keith.busch@intel.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset
Date: Tue, 03 Jul 2018 19:40:46 +0530 [thread overview]
Message-ID: <1658f1759864e22fed4273a22d501a8e@codeaurora.org> (raw)
In-Reply-To: <20180703135956.GA18639@wunner.de>
On 2018-07-03 19:29, Lukas Wunner wrote:
> On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote:
>> Issue is observing hotplug link down event in the middle of AER
>> recovery
>> as in my previous reply.
>>
>> If we mask hotplug interrupts before secondary bus reset via my patch,
>> then hotplug driver will not observe both link up and link down
>> interrupts.
>>
>> If we don't mask hotplug interrupts, we have a race condition.
>
> I assume that a bus reset not only causes a link and presence event but
> also clears the Presence Detect State bit in the Slot Status register
> and the Data Link Layer Link Active bit in the Link Status register
> momentarily.
>
> pciehp may access those two bits concurrently to the AER driver
> performing a slot reset. So it may not be sufficient to mask
> the interrupt.
Was just wondering that you are protecting Presence Detect State bit
with reset_lock, mainly in pciehp_ist
but with hotplug interrupt disabled, is there another way that it
hotplug code gets activated ?
>
> I've posted this patch to address the issue:
> https://patchwork.ozlabs.org/patch/930391/
>
> Thanks,
>
> Lukas
WARNING: multiple messages have this Message-ID (diff)
From: poza@codeaurora.org
To: Lukas Wunner <lukas@wunner.de>
Cc: Keith Busch <keith.busch@intel.com>,
linux-pci@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
Sinan Kaya <okaya@codeaurora.org>,
linux-arm-msm@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset
Date: Tue, 03 Jul 2018 19:40:46 +0530 [thread overview]
Message-ID: <1658f1759864e22fed4273a22d501a8e@codeaurora.org> (raw)
In-Reply-To: <20180703135956.GA18639@wunner.de>
On 2018-07-03 19:29, Lukas Wunner wrote:
> On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote:
>> Issue is observing hotplug link down event in the middle of AER
>> recovery
>> as in my previous reply.
>>
>> If we mask hotplug interrupts before secondary bus reset via my patch,
>> then hotplug driver will not observe both link up and link down
>> interrupts.
>>
>> If we don't mask hotplug interrupts, we have a race condition.
>
> I assume that a bus reset not only causes a link and presence event but
> also clears the Presence Detect State bit in the Slot Status register
> and the Data Link Layer Link Active bit in the Link Status register
> momentarily.
>
> pciehp may access those two bits concurrently to the AER driver
> performing a slot reset. So it may not be sufficient to mask
> the interrupt.
Was just wondering that you are protecting Presence Detect State bit
with reset_lock, mainly in pciehp_ist
but with hotplug interrupt disabled, is there another way that it
hotplug code gets activated ?
>
> I've posted this patch to address the issue:
> https://patchwork.ozlabs.org/patch/930391/
>
> Thanks,
>
> Lukas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: poza@codeaurora.org (poza at codeaurora.org)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset
Date: Tue, 03 Jul 2018 19:40:46 +0530 [thread overview]
Message-ID: <1658f1759864e22fed4273a22d501a8e@codeaurora.org> (raw)
In-Reply-To: <20180703135956.GA18639@wunner.de>
On 2018-07-03 19:29, Lukas Wunner wrote:
> On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote:
>> Issue is observing hotplug link down event in the middle of AER
>> recovery
>> as in my previous reply.
>>
>> If we mask hotplug interrupts before secondary bus reset via my patch,
>> then hotplug driver will not observe both link up and link down
>> interrupts.
>>
>> If we don't mask hotplug interrupts, we have a race condition.
>
> I assume that a bus reset not only causes a link and presence event but
> also clears the Presence Detect State bit in the Slot Status register
> and the Data Link Layer Link Active bit in the Link Status register
> momentarily.
>
> pciehp may access those two bits concurrently to the AER driver
> performing a slot reset. So it may not be sufficient to mask
> the interrupt.
Was just wondering that you are protecting Presence Detect State bit
with reset_lock, mainly in pciehp_ist
but with hotplug interrupt disabled, is there another way that it
hotplug code gets activated ?
>
> I've posted this patch to address the issue:
> https://patchwork.ozlabs.org/patch/930391/
>
> Thanks,
>
> Lukas
next prev parent reply other threads:[~2018-07-03 14:10 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-02 22:52 [PATCH V5 0/3] PCI: separate hotplug handling from fatal error handling Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` [PATCH V5 1/3] PCI: pciehp: implement mask and unmask interrupt functions Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` [PATCH V5 2/3] PCI: pciehp: reuse pciehp_mask/unmask_irq() in reset_slot() Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-02 22:52 ` Sinan Kaya
2018-07-03 8:34 ` Lukas Wunner
2018-07-03 10:52 ` poza
2018-07-03 10:52 ` poza at codeaurora.org
2018-07-03 10:52 ` poza
2018-07-03 12:04 ` okaya
2018-07-03 12:04 ` okaya at codeaurora.org
2018-07-03 12:04 ` okaya
2018-07-03 11:30 ` okaya
2018-07-03 11:30 ` okaya
2018-07-03 11:30 ` okaya at codeaurora.org
2018-07-03 11:30 ` okaya
2018-07-03 13:11 ` poza
2018-07-03 13:11 ` poza at codeaurora.org
2018-07-03 13:11 ` poza
2018-07-03 13:25 ` Sinan Kaya
2018-07-03 13:25 ` Sinan Kaya
2018-07-03 13:25 ` Sinan Kaya
2018-07-03 13:31 ` Sinan Kaya
2018-07-03 13:31 ` Sinan Kaya
2018-07-03 13:31 ` Sinan Kaya
2018-07-03 13:59 ` Lukas Wunner
2018-07-03 14:10 ` poza [this message]
2018-07-03 14:10 ` poza at codeaurora.org
2018-07-03 14:10 ` poza
2018-07-03 14:17 ` Lukas Wunner
2018-07-03 15:34 ` Sinan Kaya
2018-07-03 15:34 ` Sinan Kaya
2018-07-03 15:34 ` Sinan Kaya
2018-07-29 12:32 ` Lukas Wunner
2018-07-03 14:12 ` Lukas Wunner
2018-07-03 14:29 ` poza
2018-07-03 14:29 ` poza at codeaurora.org
2018-07-03 14:29 ` poza
2018-07-29 12:19 ` Lukas Wunner
2018-07-03 14:34 ` Lukas Wunner
2018-07-03 15:12 ` poza
2018-07-03 15:12 ` poza at codeaurora.org
2018-07-03 15:12 ` poza
2018-07-03 15:49 ` Sinan Kaya
2018-07-03 15:49 ` Sinan Kaya
2018-07-03 15:49 ` Sinan Kaya
2018-07-03 15:43 ` Sinan Kaya
2018-07-03 15:43 ` Sinan Kaya
2018-07-08 17:14 ` Lukas Wunner
2018-07-09 14:48 ` Sinan Kaya
2018-07-09 14:48 ` Sinan Kaya
2018-07-09 14:48 ` Sinan Kaya
2018-07-09 16:00 ` Lukas Wunner
2018-07-10 18:30 ` Sinan Kaya
2018-07-10 18:30 ` Sinan Kaya
2018-07-10 18:30 ` Sinan Kaya
2018-07-10 18:30 ` Sinan Kaya
2018-07-20 20:01 ` Bjorn Helgaas
2018-07-20 20:01 ` Bjorn Helgaas
2018-07-20 20:01 ` Bjorn Helgaas
2018-07-21 2:58 ` Sinan Kaya
2018-07-21 2:58 ` Sinan Kaya
2018-07-21 2:58 ` Sinan Kaya
2018-07-21 6:07 ` Sinan Kaya
2018-07-21 6:07 ` Sinan Kaya
2018-07-21 6:07 ` Sinan Kaya
2018-07-25 8:29 ` poza
2018-07-25 8:29 ` poza at codeaurora.org
2018-07-29 18:02 ` Lukas Wunner
2018-07-31 18:44 ` [PATCH V5 0/3] PCI: separate hotplug handling from fatal error handling Bjorn Helgaas
2018-07-31 18:44 ` Bjorn Helgaas
2018-07-31 18:44 ` Bjorn Helgaas
2018-07-31 18:54 ` Sinan Kaya
2018-07-31 18:54 ` Sinan Kaya
2018-07-31 18:54 ` Sinan Kaya
2018-07-31 20:16 ` Bjorn Helgaas
2018-07-31 20:16 ` Bjorn Helgaas
2018-07-31 20:16 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1658f1759864e22fed4273a22d501a8e@codeaurora.org \
--to=poza@codeaurora.org \
--cc=bhelgaas@google.com \
--cc=keith.busch@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=okaya@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.