Tyrel Datwyler 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
On Fri, Nov 15, 2019 at 12:34:50AM +1100, Oliver O'Halloran wrote:
> On Thu, Nov 14, 2019 at 1:31 AM Bjorn Helgaas wrote:
> >
> > This is fine, but it feels like sort of a blunt instrument. Is there
> > any practical way to clear pci_host_bridge.native_pcie_hotplug (and
> > native_aer if appropri
On Thu, Nov 14, 2019 at 7:39 AM Tyrel Datwyler wrote:
>
> Nothing but pedantic spelling and grammar nits of the commit log follow.
>
> -Tyrel
Thanks. My speeling is bad even on a good day and it was not a good day.
On Thu, Nov 14, 2019 at 1:31 AM Bjorn Helgaas wrote:
>
> This is fine, but it feels like sort of a blunt instrument. Is there
> any practical way to clear pci_host_bridge.native_pcie_hotplug (and
> native_aer if appropriate) for the PHBs in question? That would also
> prevent pciehp from binding.
Nothing but pedantic spelling and grammar nits of the commit log follow.
-Tyrel
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 driv
On Wed, Nov 13, 2019 at 08:40:35PM +1100, Oliver O'Halloran wrote:
> On PowerNV the PCIe topology is (currently) managed the powernv platform
> 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
On PowerNV the PCIe topology is (currently) managed the powernv platform
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
