On 10/12/2020 1:13 AM, Kuppuswamy, Sathyanarayanan wrote:
> Hi Sinan,
>
> On 9/28/20 11:32 AM, Kuppuswamy, Sathyanarayanan wrote:
>>
>>
>> On 9/28/20 11:25 AM, Sinan Kaya wrote:
>>> On 9/28/2020 2:02 PM, Sinan Kaya wrote:
Since there is no state restoration for FATAL errors, I am wondering
>>
Hi Sinan,
On 9/28/20 11:32 AM, Kuppuswamy, Sathyanarayanan wrote:
On 9/28/20 11:25 AM, Sinan Kaya wrote:
On 9/28/2020 2:02 PM, Sinan Kaya wrote:
Since there is no state restoration for FATAL errors, I am wondering
whether
calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
r
On 9/28/20 11:25 AM, Sinan Kaya wrote:
On 9/28/2020 2:02 PM, Sinan Kaya wrote:
Since there is no state restoration for FATAL errors, I am wondering
whether
calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
required?
I also would like to ask someone closer to the spec lang
On 9/28/2020 2:02 PM, Sinan Kaya wrote:
> Since there is no state restoration for FATAL errors, I am wondering
> whether
> calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
> required?
I also would like to ask someone closer to the spec language double
check this.
When we recov
On 9/28/2020 1:15 PM, Kuppuswamy, Sathyanarayanan wrote:
> Since there is no state restoration for FATAL errors, I am wondering
> whether
> calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
> required?
Good question,
Initially when we started, we were trying to handle both NON_
On 9/28/20 4:17 AM, Sinan Kaya wrote:
On 9/27/2020 10:43 PM, Kuppuswamy, Sathyanarayanan wrote:
FATAL + no-hotplug - In this case, link will still be reseted. But
currently driver state is not properly restored. So I attempted
to restore it using pci_reset_bus().
status = reset_lin
On 9/28/2020 7:17 AM, Sinan Kaya wrote:
> This should remove/rescan logic should be inside DPC's slot_reset()
> function BTW. Not here.
Correct function name is dpc_handler().
I hope I did not create confusion with slot_reset() that gets called for
each driver post recovery.
On 9/27/2020 10:43 PM, Kuppuswamy, Sathyanarayanan wrote:
>> 2. no bus reset on NON_FATAL error through AER driver path.
>> This already tells me that you need to split your change into
>> multiple patches.
>>
>> Let's talk about this too. bus reset should be triggered via
>> AER driver before info
On 9/27/2020 10:43 PM, Kuppuswamy, Sathyanarayanan wrote:
> FATAL + no-hotplug - In this case, link will still be reseted. But
> currently driver state is not properly restored. So I attempted
> to restore it using pci_reset_bus().
>
> status = reset_link(dev);
> - if (status != PC
Sathyanarayanan,
On Mon, Sep 28, 2020 at 10:44 AM Kuppuswamy, Sathyanarayanan
wrote:
>
> Hi,
>
> On 9/25/20 11:30 AM, Sinan Kaya wrote:
> > On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
> >>>
> >>> If this is a too involved change, DPC driver should restore state
> >>> when hotplug is
Hi,
On 9/25/20 11:30 AM, Sinan Kaya wrote:
On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
If this is a too involved change, DPC driver should restore state
when hotplug is not supported.
Yes. we can add a condition for hotplug capability check.
DPC driver should be self-sufficient
On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
>> One approach is to share the restore code between hotplug driver and
>> DPC driver.
>>
>> If this is a too involved change, DPC driver should restore state
>> when hotplug is not supported.
> Yes. we can add a condition for hotplug capabil
On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
>>
>> If this is a too involved change, DPC driver should restore state
>> when hotplug is not supported.
> Yes. we can add a condition for hotplug capability check.
>>
>> DPC driver should be self-sufficient by itself.
>>
Sounds good.
>>>
On 9/25/20 10:47 AM, Sinan Kaya wrote:
On 9/25/2020 1:11 PM, Kuppuswamy, Sathyanarayanan wrote:
Why? Isn't DPC slot reset enough?
It will do the reset at hardware level. But driver state is not
cleaned up. So doing bus reset will restore both driver and
hardware states.
I really don't like
On 9/25/2020 1:11 PM, Kuppuswamy, Sathyanarayanan wrote:
>> Why? Isn't DPC slot reset enough?
> It will do the reset at hardware level. But driver state is not
> cleaned up. So doing bus reset will restore both driver and
> hardware states.
I really don't like this. If hotplug driver is restoring
On 9/25/20 9:55 AM, Sinan Kaya wrote:
On 9/25/2020 1:11 AM, Kuppuswamy, Sathyanarayanan wrote:
On 9/24/20 1:52 PM, Sinan Kaya wrote:
On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote:
So, this is a matter of moving the save/restore logic from the hotplug
driver into common code
On 9/25/2020 1:11 AM, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 9/24/20 1:52 PM, Sinan Kaya wrote:
>> On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote:
>>
>> So, this is a matter of moving the save/restore logic from the hotplug
>> driver into common code so that DPC slot reset takes a
On 9/24/20 1:52 PM, Sinan Kaya wrote:
On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote:
For problem description, please check the following details
Current pcie_do_recovery() implementation has following two issues:
1. Fatal (DPC) error recovery is currently broken for non-hotplug
c
On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote:
> For problem description, please check the following details
>
> Current pcie_do_recovery() implementation has following two issues:
>
> 1. Fatal (DPC) error recovery is currently broken for non-hotplug
> capable devices. Current fatal er
On 9/23/20 8:13 PM, Sinan Kaya wrote:
On 9/23/2020 10:51 PM, Kuppuswamy, Sathyanarayanan wrote:
I see. Can I assume that your system supports DPC?
DPC is supposed to recover the link via dpc_reset_link().
Yes. But the affected device/drivers cleanup during error recovery
is handled by hotpl
On 9/23/2020 10:51 PM, Kuppuswamy, Sathyanarayanan wrote:
>>
>> I see. Can I assume that your system supports DPC?
>> DPC is supposed to recover the link via dpc_reset_link().
> Yes. But the affected device/drivers cleanup during error recovery
> is handled by hotplug handler. So we are facing issu
On 9/23/20 7:16 PM, Sinan Kaya wrote:
On 9/23/2020 10:04 PM, Kuppuswamy, Sathyanarayanan wrote:
AFAIK, DLLSC is a requirement not optional. Why is this not supported by
non-hotplug ports?
Its required for hotplug capable ports. Please check PCIe spec v5.0 sec
6.7.3.3.
The Data Link Layer St
On 9/23/2020 10:04 PM, Kuppuswamy, Sathyanarayanan wrote:
>> AFAIK, DLLSC is a requirement not optional. Why is this not supported by
>> non-hotplug ports?
> Its required for hotplug capable ports. Please check PCIe spec v5.0 sec
> 6.7.3.3.
>
> The Data Link Layer State Changed event provides an i
On 9/23/20 6:15 PM, Sinan Kaya wrote:
On 9/22/2020 7:44 PM, Kuppuswamy, Sathyanarayanan wrote:
here does the restore happen here? I.e., what function does this?
DLLSC link down event will remove affected devices/drivers. And link up
event
will re-create all devices.
on DLLSC link down eve
On 9/22/2020 7:44 PM, Kuppuswamy, Sathyanarayanan wrote:
>> here does the restore happen here? I.e., what function does this?
>
> DLLSC link down event will remove affected devices/drivers. And link up
> event
> will re-create all devices.
>
> on DLLSC link down event
> ->pciehp_ist()
> ->pcie
On 9/22/20 4:33 PM, Bjorn Helgaas wrote:
On Tue, Sep 22, 2020 at 02:44:51PM -0700, Kuppuswamy, Sathyanarayanan wrote:
On 9/22/20 11:52 AM, Bjorn Helgaas wrote:
On Fri, Jul 24, 2020 at 12:07:55PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
C
On Tue, Sep 22, 2020 at 02:44:51PM -0700, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 9/22/20 11:52 AM, Bjorn Helgaas wrote:
> > On Fri, Jul 24, 2020 at 12:07:55PM -0700,
> > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > From: Kuppuswamy Sathyanarayanan
> > >
> > >
> > > Current pci
On Fri, Jul 24, 2020 at 12:07:55PM -0700,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Current pcie_do_recovery() implementation has following two issues:
>
I'm having trouble parsing this out, probably just lack of my
understanding...
> 1. Fatal (D
Hi Bjorn,
On 7/24/20 12:07 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
Current pcie_do_recovery() implementation has following two issues:
1. Fatal (DPC) error recovery is currently broken for non-hotplug
capable devices. Current fatal error recovery
From: Kuppuswamy Sathyanarayanan
Current pcie_do_recovery() implementation has following two issues:
1. Fatal (DPC) error recovery is currently broken for non-hotplug
capable devices. Current fatal error recovery implementation relies
on PCIe hotplug (pciehp) handler for detaching and re-enumera
30 matches
Mail list logo
