The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: Shivaprasad G Bhat <sbhat@linux.ibm.com>,
	maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
	Sourabh Jain <sourabhjain@linux.ibm.com>,
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
	Narayana Murty N <nnmlinux@linux.ibm.com>
Cc: mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] powerpc/rtas_pci: No hotplug on permanently removed device on pSeries
Date: Mon, 3 Aug 2026 11:42:55 +0530	[thread overview]
Message-ID: <4774b148-7cee-4273-9c24-1e86d4603dad@linux.ibm.com> (raw)
In-Reply-To: <178246517230.1267.12206176311111155505.stgit@linux.ibm.com>

+ Sourabh, Mahesh, Narayana - FYI/R

Hi Shiva,

On 26/06/26 2:43 pm, Shivaprasad G Bhat wrote:
> The eeh_driver disables and offlines the PE permanently when it
> exceeds the freeze count beyond eeh_max_freeze within the last hour.
> The PE is only offline, so the device tree entries, eeh device
> references are all intact till the real unplug of the device from
> the guest/host takes place.
> 
> On pSeries, with a new hotplug of any PCI device, the drmgr initiates
> a system-wide PCI rescan, which finds devices offlined by the eeh_driver
> and there will be attempts to bring them online. This leads to
> recurring EEHs either at the config read time itself or a bit
> later depending on the type of the problem.
> 
> For PowerNV, the commit d2b0f6f77ee5 ("powerpc/eeh: No hotplug on
> permanently removed dev") introduced the EEH_DEV_REMOVED flag to
> prevent such inadvertent rescans on hierarchical toplogies relavent in
> Baremetal setups. For pSeries, such topologies don't really make sense
> as the devices are either part of the same PE OR exposed as independent
> devices on multiple virtual PHBs. However, the inadvertent rescans are
> still a possibility with either hotplug of a new device or otherwise
> with manual system-wide pci bus rescan attempts.
> 
> So the patch checks for EEH_DEV_REMOVED before allowing config space
> access just like PowerNV, making the PCI core omit the PE, and thus
> preventing subsequent EEH recurances. The patch is tested on PowerVM
> and KVM machines with single and multi-function devices, and on the
> devices behind a switch. The unplug of the affected devices post EEH
> removal is also working fine as expected.
> 
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> References: d2b0f6f77ee5 ("powerpc/eeh: No hotplug on permanently removed dev")
> ---
>   arch/powerpc/kernel/rtas_pci.c |    8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
> index fccf96e897f6..206c825225c2 100644
> --- a/arch/powerpc/kernel/rtas_pci.c
> +++ b/arch/powerpc/kernel/rtas_pci.c
> @@ -54,6 +54,10 @@ int rtas_pci_dn_read_config(struct pci_dn *pdn, int where, int size, u32 *val)
>   	if (!config_access_valid(pdn, where))
>   		return PCIBIOS_BAD_REGISTER_NUMBER;
>   #ifdef CONFIG_EEH
> +	if (pdn->edev &&
> +	    (pdn->edev->mode & EEH_DEV_REMOVED))
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
>   	if (pdn->edev && pdn->edev->pe &&
>   	    (pdn->edev->pe->state & EEH_PE_CFG_BLOCKED))
>   		return PCIBIOS_SET_FAILED;
> @@ -105,6 +109,10 @@ int rtas_pci_dn_write_config(struct pci_dn *pdn, int where, int size, u32 val)
>   	if (!config_access_valid(pdn, where))
>   		return PCIBIOS_BAD_REGISTER_NUMBER;
>   #ifdef CONFIG_EEH
> +	if (pdn->edev &&
> +	    (pdn->edev->mode & EEH_DEV_REMOVED))
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +

Thanks for addressing review comments. Feel free to add:
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>

>   	if (pdn->edev && pdn->edev->pe &&
>   	    (pdn->edev->pe->state & EEH_PE_CFG_BLOCKED))
>   		return PCIBIOS_SET_FAILED;
> 
> 


  reply	other threads:[~2026-08-03  6:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  9:13 [PATCH v2] powerpc/rtas_pci: No hotplug on permanently removed device on pSeries Shivaprasad G Bhat
2026-08-03  6:12 ` Harsh Prateek Bora [this message]
2026-08-26 11:14 ` tasmiya

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=4774b148-7cee-4273-9c24-1e86d4603dad@linux.ibm.com \
    --to=harshpb@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mahesh@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=nnmlinux@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=sbhat@linux.ibm.com \
    --cc=sourabhjain@linux.ibm.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