linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Tyrel Datwyler <tyreld@linux.ibm.com>,
	Oliver O'Halloran <oohall@gmail.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: linux-pci@vger.kernel.org,
	Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
Subject: Re: [PATCH] powerpc/powernv: Disable native PCIe port management
Date: Fri, 15 Nov 2019 15:28:35 +1100	[thread overview]
Message-ID: <87a78xepak.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <5a12d199-fa1f-5a60-05d8-df9edffbc227@linux.ibm.com>

Tyrel Datwyler <tyreld@linux.ibm.com> writes:
> Nothing but pedantic spelling and grammar nits of the commit log follow.

Thanks, they were annoying me :)

cheers

> On 11/13/19 1:40 AM, Oliver O'Halloran wrote:
>> On PowerNV the PCIe topology is (currently) managed the powernv platform
>
> s/the powernv/by the powernv
>
>> code in cooperation with firmware. The PCIe-native service drivers bypass
>> both and this can cause problems.
>> 
>> Historically this hasn't been a big deal since the only port service
>> driver that saw much use was the AER driver. The AER driver relies
>> a kernel service to report when errors occur rather than acting autonmously
>
> s/a kernel/on a kernel
> autonomously
>
>> so it's fairly easy to ignore. On PowerNV (and pseries) AER events are
>> handled through EEH, which ignores the AER service, so it's never been
>> an issue.
>> 
>> Unfortunately, the hotplug port service driver (pciehp) does act
>> autonomously and conflicts with the platform specific hotplug
>> driver (pnv_php). The main issue is that pciehp claims the interrupt
>> associated with the PCIe capability which in turn prevents pnv_php from
>> claiming it.
>> 
>> This results in hotplug events being handled by pciehp which does not
>> notify firmware when the PCIe topology changes, and does not setup/teardown
>> the arch specific PCI device structures (pci_dn) when the topology changes.
>> The end result is that hot-added devices cannot be enabled and hot-removed
>> devices may not be fully torn-down on removal.
>> 
>> We can fix these problems by setting the "pcie_ports_disabled" flag during
>> platform initialisation. The flag indicates the platform owns the PCIe
>> ports which stops the portbus driver being registered.
>
> s/being/from being
>
>> 
>> Cc: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> Fixes: 66725152fb9f ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver")
>> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
>> ---
>> Sergey, just FYI. I'll try sort out the rest of the hotplug
>> trainwreck in 5.6.
>> 
>> The Fixes: here is for the patch that added pnv_php in 4.8. It's been
>> a problem since then, but wasn't noticed until people started testing
>> it after the EEH fixes in commit 799abe283e51 ("powerpc/eeh: Clean up
>> EEH PEs after recovery finishes") went in earlier in the 5.4 cycle.
>> ---
>>  arch/powerpc/platforms/powernv/pci.c | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>> 
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index 2825d00..ae62583 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -941,6 +941,23 @@ void __init pnv_pci_init(void)
>> 
>>  	pci_add_flags(PCI_CAN_SKIP_ISA_ALIGN);
>> 
>> +#ifdef CONFIG_PCIEPORTBUS
>> +	/*
>> +	 * On PowerNV PCIe devices are (currently) managed in cooperation
>> +	 * with firmware. This isn't *strictly* required, but there's enough
>> +	 * assumptions baked into both firmware and the platform code that
>> +	 * it's unwise to allow the portbus services to be used.
>> +	 *
>> +	 * We need to fix this eventually, but for now set this flag to disable
>> +	 * the portbus driver. The AER service isn't required since that AER
>> +	 * events are handled via EEH. The pciehp hotplug driver can't work
>> +	 * without kernel changes (and portbus binding breaks pnv_php). The
>> +	 * other services also require some thinking about how we're going
>> +	 * to integrate them.
>> +	 */
>> +	pcie_ports_disabled = true;
>> +#endif
>> +
>>  	/* If we don't have OPAL, eg. in sim, just skip PCI probe */
>>  	if (!firmware_has_feature(FW_FEATURE_OPAL))
>>  		return;
>> 

      parent reply	other threads:[~2019-11-15  4:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13  9:40 [PATCH] powerpc/powernv: Disable native PCIe port management Oliver O'Halloran
2019-11-13 14:31 ` Bjorn Helgaas
2019-11-14 13:34   ` Oliver O'Halloran
2019-11-14 13:54     ` Bjorn Helgaas
2019-11-13 20:39 ` Tyrel Datwyler
2019-11-14 13:37   ` Oliver O'Halloran
2019-11-15  4:28   ` Michael Ellerman [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=87a78xepak.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oohall@gmail.com \
    --cc=s.miroshnichenko@yadro.com \
    --cc=tyreld@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;
as well as URLs for NNTP newsgroup(s).