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
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
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 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 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 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
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
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,
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,
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 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 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
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
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 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
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
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 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,
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,
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
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
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,
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,
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 =
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 =
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
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
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
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
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 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-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
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
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 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
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
>
> 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
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
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
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
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
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
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
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
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
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
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
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
for the link to come up.
3. Hotplug driver observes a link down
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
for the link to come up.
3. Hotplug driver observes a link down
58 matches
Mail list logo
