From: Shivaprasad G Bhat <sbhat@linux.ibm.com>
To: Harsh Prateek Bora <harshpb@linux.ibm.com>,
maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org
Cc: mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/rtas_pci: No hotplug on permanently removed device on pSeries
Date: Fri, 26 Jun 2026 14:44:33 +0530 [thread overview]
Message-ID: <96850460-f3a2-447c-bcdb-1ed2aec9d8eb@linux.ibm.com> (raw)
In-Reply-To: <b896e3b9-6e0a-490b-820c-54c1608b5424@linux.ibm.com>
Hi Harsh,
On 5/12/26 11:14 PM, Harsh Prateek Bora wrote:
>
>
> On 12/05/26 10:47 pm, Harsh Prateek Bora wrote:
>>
>>
>> On 27/04/26 8:25 am, 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
>
> Also, not sure if this commit description is correct as the patch only
> changes behaviour of RTAS config-space accesses and not making changes
> for omission semantics.
This is for the pci core rescan attempts to be skipped, when rescan is
attempted
with write to rescan sysfs file.
pci_bus_generic_read_dev_vendor_id+0x48/0x220
pci_scan_single_device+0xa8/0x130
pci_scan_slot+0x9c/0x2e0
pci_scan_child_bus_extend+0x70/0x410
pci_rescan_bus+0x2c/0x70
rescan_store+0xa4/0xe0
bus_attr_store+0x3c/0x60
sysfs_kf_write+0xb0/0xe0
> The existing code in arch/powerpc/kernel/pci_of_scan.c already
> suppresses discovery of removed device:
>
> #ifdef CONFIG_EEH
> if (edev && (edev->mode & EEH_DEV_REMOVED))
> return NULL;
> #endif
>
This is boot time only scan from the pcibios_init() path.
>>> 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 | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/
>>> rtas_pci.c
>>> index fccf96e897f6..ce24b18712ca 100644
>>> --- a/arch/powerpc/kernel/rtas_pci.c
>>> +++ b/arch/powerpc/kernel/rtas_pci.c
>>> @@ -57,6 +57,9 @@ int rtas_pci_dn_read_config(struct pci_dn *pdn,
>>> int where, int size, u32 *val)
>>> if (pdn->edev && pdn->edev->pe &&
>>> (pdn->edev->pe->state & EEH_PE_CFG_BLOCKED))
>>> return PCIBIOS_SET_FAILED;
>>> +
>>> + if (pdn->edev && pdn->edev->mode & EEH_DEV_REMOVED)
>>
>> Consider using paranthesis for (pdn->edev->mode & EEH_DEV_REMOVED)
>> and moving to next line for readability (similar to prev one).
Sure.
>>
>>> + return PCIBIOS_SET_FAILED;
>>
>> Why not return PCIBIOS_DEVICE_NOT_FOUND ? Returning SET_FAILED for a
>> removed device could be misleading.
>>
>
Sure.
> Also we should check for EEH_DEV_REMOVED before checking for
> EEH_PE_CFG_BLOCKED to avoid returning early when the latter is still set
> for a removed device.
>
Sure.
v2 posted here -
https://lore.kernel.org/all/178246517230.1267.12206176311111155505.stgit@linux.ibm.com/
Thanks,
Shivaprasad
<snip/>
prev parent reply other threads:[~2026-06-26 9:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 2:55 [PATCH] powerpc/rtas_pci: No hotplug on permanently removed device on pSeries Shivaprasad G Bhat
2026-05-12 17:17 ` Harsh Prateek Bora
2026-05-12 17:44 ` Harsh Prateek Bora
2026-06-26 9:14 ` Shivaprasad G Bhat [this message]
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=96850460-f3a2-447c-bcdb-1ed2aec9d8eb@linux.ibm.com \
--to=sbhat@linux.ibm.com \
--cc=chleroy@kernel.org \
--cc=harshpb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.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