All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.