public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@kernel.org>
To: "Kuppuswamy,
	Sathyanarayanan"  <sathyanarayanan.kuppuswamy@linux.intel.com>,
	Bjorn Helgaas <helgaas@kernel.org>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, ashok.raj@intel.com,
	Jay Vosburgh <jay.vosburgh@canonical.com>
Subject: Re: [PATCH v3 1/1] PCI/ERR: Fix reset logic in pcie_do_recovery() call
Date: Fri, 25 Sep 2020 13:47:41 -0400	[thread overview]
Message-ID: <f360165e-5f73-057c-efd1-557b5e5027eb@kernel.org> (raw)
In-Reply-To: <4ae86061-2182-bcf1-ebd7-485acf2d47b9@linux.intel.com>

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 the state
and DPC driver is not; let's fix the DPC driver rather than causing
two resets and hope for the best.

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.

DPC driver should be self-sufficient by itself.

> Also for non-fatal errors, if reset is requested then we still need
> some kind of bus reset call here.

DPC should handle both fatal and non-fatal cases and cause a bus reset
in hardware already before triggering an interrupt.

I disagree that you need an additional reset on top of DPC reset.
Isn't one reset enough?

What will the second reset provide that first reset won't provide?

I see that you are trying to do the second reset only because second
reset restores state.

That looks like a short-term fix only to explode on the next iteration.

  reply	other threads:[~2020-09-25 17:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3cad1a07-509b-ef51-f635-71def2ff8293@linux.intel.com>
2020-09-22 23:33 ` [PATCH v3 1/1] PCI/ERR: Fix reset logic in pcie_do_recovery() call Bjorn Helgaas
2020-09-22 23:44   ` Kuppuswamy, Sathyanarayanan
2020-09-24  1:15     ` Sinan Kaya
2020-09-24  2:04       ` Kuppuswamy, Sathyanarayanan
2020-09-24  2:16         ` Sinan Kaya
2020-09-24  2:51           ` Kuppuswamy, Sathyanarayanan
2020-09-24  3:13             ` Sinan Kaya
2020-09-24  4:06               ` Kuppuswamy, Sathyanarayanan
2020-09-24 20:52                 ` Sinan Kaya
2020-09-25  5:11                   ` Kuppuswamy, Sathyanarayanan
2020-09-25 16:55                     ` Sinan Kaya
2020-09-25 17:11                       ` Kuppuswamy, Sathyanarayanan
2020-09-25 17:47                         ` Sinan Kaya [this message]
2020-09-25 18:16                           ` Kuppuswamy, Sathyanarayanan
2020-09-25 18:30                             ` Sinan Kaya
2020-09-28  2:43                               ` Kuppuswamy, Sathyanarayanan
2020-09-28  8:41                                 ` Ethan Zhao
2020-09-28 11:17                                 ` Sinan Kaya
2020-09-28 12:16                                   ` Sinan Kaya
2020-09-28 17:15                                   ` Kuppuswamy, Sathyanarayanan
2020-09-28 18:02                                     ` Sinan Kaya
2020-09-28 18:25                                       ` Sinan Kaya
2020-09-28 18:32                                         ` Kuppuswamy, Sathyanarayanan
2020-10-12  5:13                                           ` Kuppuswamy, Sathyanarayanan
2020-10-12 14:51                                             ` Sinan Kaya
2020-09-28 12:11                                 ` Sinan Kaya
2020-09-25 23:50                             ` Sinan Kaya
2020-07-24 19:07 sathyanarayanan.kuppuswamy
2020-09-01  5:41 ` Kuppuswamy, Sathyanarayanan
2020-09-22 18:52 ` 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=f360165e-5f73-057c-efd1-557b5e5027eb@kernel.org \
    --to=okaya@kernel.org \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=jay.vosburgh@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox