All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Sinan Kaya <okaya@kernel.org>, Thomas Tai <thomas.tai@oracle.com>,
	poza@codeaurora.org
Subject: Re: [PATCH 12/16] PCI/pciehp: Fix powerfault detection order
Date: Tue, 4 Sep 2018 08:27:54 -0600	[thread overview]
Message-ID: <20180904142753.GI9677@localhost.localdomain> (raw)
In-Reply-To: <20180901151836.oceptz267wy33bes@wunner.de>

On Sat, Sep 01, 2018 at 05:18:36PM +0200, Lukas Wunner wrote:
> * In pcie_enable_notification() there's a code comment:
>   "TBD: Power fault detected software notification support"
>   Is there really anything left to be done or can this code comment be
>   deleted?  AFAICS, a power fault *is* detected and acted upon, then
>   has to be cleared by the user, either through enablement via sysfs
>   or by physically replacing the card.
> 
> * In pciehp_ist(), the if-condition to check for a power fault also
>   checks for "&& !ctrl->power_fault_detected".  The check seems
>   superfluous to me because pciehp_isr() clears the PCI_EXP_SLTSTA_PFD
>   bit in the pending events if ctrl->power_fault_detected is true.
>   Can the additional check be removed from the if-condition in
>   pciehp_ist()?

The slot is supposed to have PFD set while the controller detects a
power fault. The host acknowledging the event doesn't actually make the
power fault stop exisiting, so we have to make the observation sticky
until it goes away.
 
> * In pciehp_ist(), we call pciehp_green_led_off() if a power fault is
>   detected.  However my (limited) understanding is that a power fault
>   always results in a Link Down, and when bringing down the slot in
>   response to that, we already call pciehp_green_led_off() in
>   remove_board().  Can the call to pciehp_green_led_off() be removed
>   from pciehp_ist()?  Or does the link not necessarily go down on a
>   power fault and we should rather bring the slot down when a power
>   fault is detected?  Is that the "TBD" mentioned in the code comment?
>   Or is this just an intentional cosmetic behavior that we turn off
>   the green LED as early as possible once we detect the slot is off?

  reply	other threads:[~2018-09-04 18:51 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 21:26 [PATCH 00/16] PCI, error handling and hot plug Keith Busch
2018-08-31 21:26 ` [PATCH 01/16] PCI: Simplify disconnected marking Keith Busch
2018-08-31 21:26 ` [PATCH 02/16] PCI: Fix pci_reset_bus Keith Busch
2018-08-31 21:52   ` Sinan Kaya
2018-08-31 22:08     ` Keith Busch
2018-08-31 21:26 ` [PATCH 03/16] PCI/AER: Remove dead code Keith Busch
2018-08-31 21:26 ` [PATCH 04/16] PCI/ERR: Use slot reset if available Keith Busch
2018-09-01 17:20   ` Lukas Wunner
2018-09-04 14:53     ` Keith Busch
2018-08-31 21:26 ` [PATCH 05/16] PCI/ERR: Handle fatal error recovery Keith Busch
2018-09-01  8:31   ` Christoph Hellwig
2018-09-05  5:56   ` poza
2018-08-31 21:26 ` [PATCH 06/16] PCI/ERR: Remove devices on recovery failure Keith Busch
2018-08-31 22:26   ` Sinan Kaya
2018-08-31 21:26 ` [PATCH 07/16] PCI/ERR: Always use the first downstream port Keith Busch
2018-08-31 21:26 ` [PATCH 08/16] PCI/ERR: Simplify broadcast callouts Keith Busch
2018-09-01  8:33   ` Christoph Hellwig
2018-08-31 21:26 ` [PATCH 09/16] PCI/ERR: Report current recovery status for udev Keith Busch
2018-09-01  8:36   ` Christoph Hellwig
2018-08-31 21:26 ` [PATCH 10/16] PCI/portdrv: Provide pci error callbacks Keith Busch
2018-09-02 10:16   ` Lukas Wunner
2018-09-04 21:38     ` Keith Busch
2018-08-31 21:26 ` [PATCH 11/16] PCI/portdrv: Restore pci state on slot reset Keith Busch
2018-09-02  9:34   ` Lukas Wunner
2018-09-04 14:36     ` Keith Busch
2018-08-31 21:26 ` [PATCH 12/16] PCI/pciehp: Fix powerfault detection order Keith Busch
2018-09-01 15:18   ` Lukas Wunner
2018-09-04 14:27     ` Keith Busch [this message]
2018-08-31 21:26 ` [PATCH 13/16] PCI/pciehp: Implement error handling callbacks Keith Busch
2018-09-02 10:39   ` Lukas Wunner
2018-09-04 14:19     ` Keith Busch
2018-08-31 21:26 ` [PATCH 14/16] pciehp: Ignore link events during DPC event Keith Busch
2018-08-31 22:18   ` Sinan Kaya
2018-08-31 22:33     ` Keith Busch
2018-08-31 22:55       ` Sinan Kaya
2018-08-31 22:59         ` Keith Busch
2018-08-31 23:07           ` Sinan Kaya
2018-09-02 14:27   ` Lukas Wunner
2018-09-04 14:16     ` Keith Busch
2018-09-04 14:40       ` Lukas Wunner
2018-09-04 15:31         ` Keith Busch
2018-08-31 21:26 ` [PATCH 15/16] PCI/DPC: Wait for reset complete Keith Busch
2018-08-31 22:15   ` Sinan Kaya
2018-08-31 21:26 ` [PATCH 16/16] PCI: Unify device inaccessible Keith Busch
2018-09-02 14:39   ` Lukas Wunner
2018-09-03  0:38     ` Benjamin Herrenschmidt

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=20180904142753.GI9677@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=okaya@kernel.org \
    --cc=poza@codeaurora.org \
    --cc=thomas.tai@oracle.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 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.