On Fri, Jul 20, 2018 at 07:58:20PM -0700, Sinan Kaya wrote:
> My patch solves the problem if AER interrupt happens before the hotplug
> interrupt. We are masking the data link layer active interrupt. So,
> AER/DPC can perform their link operations without hotplug driver race.
>
> We need to figure
On Tue, Jul 03, 2018 at 06:41:33PM +0530, p...@codeaurora.org wrote:
> pciehp_unconfigure_device doing little more than enumeration to quiescence
> the bus.
>
> /*
>* Ensure that no new Requests will be generated from
>* the device.
>*/
On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote:
> On 2018-07-03 04:34, Lukas Wunner wrote:
> > On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> > > If a bridge supports hotplug and observes a PCIe fatal error, the
> > > following events happen:
> > >
> > > 1. AER
On 2018-07-21 11:37, Sinan Kaya wrote:
On 7/20/2018 7:58 PM, Sinan Kaya wrote:
We need to figure out how to gracefully return inside hotplug driver
if link down happened and there is an error pending.
How about adding the following into the hotplug ISR?
1. check if firmware first is disabled
On 7/20/2018 7:58 PM, Sinan Kaya wrote:
We need to figure out how to gracefully return inside hotplug driver
if link down happened and there is an error pending.
How about adding the following into the hotplug ISR?
1. check if firmware first is disabled
2. check if there is a fatal error pendi
On 7/20/2018 1:01 PM, Bjorn Helgaas wrote:
On Tue, Jul 10, 2018 at 02:30:11PM -0400, Sinan Kaya wrote:
On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner wrote:
On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
On 7/8/18, Lukas Wunner wrote:
On Tue, Jul 03, 2018 at 11:43:26AM -0400, Si
On Tue, Jul 10, 2018 at 02:30:11PM -0400, Sinan Kaya wrote:
> On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner wrote:
> > On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
> > > On 7/8/18, Lukas Wunner wrote:
> > > > On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
> > > > > My
On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner wrote:
>
> On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
> > On 7/8/18, Lukas Wunner wrote:
> > > On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
> > > > My solution doesn't help if link down interrupt is observed before the
On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
> On 7/8/18, Lukas Wunner wrote:
> > On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
> > > My solution doesn't help if link down interrupt is observed before the
> > > AER
> > > or DPC services.
> >
> > If pciehp gets an inter
On 7/8/18, Lukas Wunner wrote:
> On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
>> On 7/3/2018 10:34 AM, Lukas Wunner wrote:
>> > We've already got the ->reset_slot callback in struct hotplug_slot_ops,
>> > I'm wondering if we really need additional ones for this use case.
>>
>> As I
On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:
> On 7/3/2018 10:34 AM, Lukas Wunner wrote:
> > We've already got the ->reset_slot callback in struct hotplug_slot_ops,
> > I'm wondering if we really need additional ones for this use case.
>
> As I have informed you before on my previou
On 7/3/2018 11:12 AM, p...@codeaurora.org wrote:
> if (!pci_probe_reset_slot(dev->slot))
> {
> pci_reset_slot(dev->slot)
> result = reset_link(udev, service); >> in this case aer_root_reset must
> not call pci_reset_bridge_secondary_bus()
> } else
> result = reset_link(udev, service);
On 7/3/2018 10:34 AM, Lukas Wunner wrote:
> On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
>> @@ -308,8 +310,17 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32
>> service)
>> pci_dev_put(pdev);
>> }
>>
>> +hpsvc = pcie_port_find_service(udev, PCIE_PORT_
On 7/3/2018 9:59 AM, 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
On 2018-07-03 20:04, Lukas Wunner wrote:
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
@@ -308,8 +310,17 @@ void pcie_do_fatal_recovery(struct pci_dev *dev,
u32 service)
pci_dev_put(pdev);
}
+ hpsvc = pcie_port_find_service(udev, PCIE_PORT_SERVICE_HP
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> @@ -308,8 +310,17 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32
> service)
> pci_dev_put(pdev);
> }
>
> + hpsvc = pcie_port_find_service(udev, PCIE_PORT_SERVICE_HP);
> + hpdev = pcie_port_find_dev
On 2018-07-03 19:42, Lukas Wunner wrote:
On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote:
On 2018-07-03 04:34, Lukas Wunner wrote:
>On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
>>If a bridge supports hotplug and observes a PCIe fatal error, the
>>following
>>e
On Tue, Jul 03, 2018 at 07:40:46PM +0530, p...@codeaurora.org wrote:
> 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 mas
On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote:
> On 2018-07-03 04:34, Lukas Wunner wrote:
> >On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> >>If a bridge supports hotplug and observes a PCIe fatal error, the
> >>following
> >>events happen:
> >>
> >>1. AER driv
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
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
On 7/3/2018 9:25 AM, Sinan Kaya wrote:
>> what if we only have conditional enumeration ? (leaving removing devices
>> followed by SBR as is) ?
>>
Sorry, I think I didn't quite get your question.
Are you asking about the enumeration following link up while keeping the
current code as is?
Issue
>
> what if we only have conditional enumeration ? (leaving removing devices
> followed by SBR as is) ?
>
If we leave it as is, hotplug driver observes a link down interrupt as soon
as secondary bus reset is issued. Hotplug driver will try device removal while
AER driver is working on the curr
On 2018-07-03 17:00, ok...@codeaurora.org wrote:
On 2018-07-03 04:34, Lukas Wunner wrote:
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
If a bridge supports hotplug and observes a PCIe fatal error, the
following
events happen:
1. AER driver removes the devices from PCI tree on f
On 2018-07-03 06:52, p...@codeaurora.org wrote:
On 2018-07-03 14:04, Lukas Wunner wrote:
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
If a bridge supports hotplug and observes a PCIe fatal error, the
following
events happen:
1. AER driver removes the devices from PCI tree on fa
On 2018-07-03 04:34, Lukas Wunner wrote:
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
If a bridge supports hotplug and observes a PCIe fatal error, the
following
events happen:
1. AER driver removes the devices from PCI tree on fatal error
2. AER driver brings down the link by i
On 2018-07-03 14:04, Lukas Wunner wrote:
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
If a bridge supports hotplug and observes a PCIe fatal error, the
following
events happen:
1. AER driver removes the devices from PCI tree on fatal error
2. AER driver brings down the link by i
On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote:
> If a bridge supports hotplug and observes a PCIe fatal error, the following
> events happen:
>
> 1. AER driver removes the devices from PCI tree on fatal error
> 2. AER driver brings down the link by issuing a secondary bus reset waits
28 matches
Mail list logo
