Bagas Sanjaya writes:
> Hi,
>
> This is the cleanup series following up from 03c9d1a5a30d93 ("Documentation:
> Fix description format for powerpc RTAS ioctls"). It is based on docs-next
> tree. The end result should be the same as my previous fixup patch [1].
>
> Enjoy!
>
> Changes since v1 (RESE
From: Wilfred Mallawa
The PCIe link may go down in cases like firmware crashes or unstable
connections. When this occurs, the PCIe Root Port must be reset to restore
the functionality. However, the current driver lacks link down handling,
forcing users to reboot the system to recover.
This patch
mmon.c | 33 +++
drivers/pci/controller/pci-host-common.h | 1 +
drivers/pci/pci.c | 13 +++
drivers/pci/pcie/err.c| 6 +-
include/linux/pci.h | 1 +
8 files changed, 252 insertions(+), 15 deletions(-)
---
ba
From: Manivannan Sadhasivam
Some host bridge devices require resetting the Root Ports in a platform
specific way to recover them from error conditions such as Fatal AER
errors, Link Down etc... So introduce pci_host_bridge::reset_root_port
callback and call it from pcibios_reset_secondary_bus() i
On Tue, Jul 15, 2025 at 10:16:27AM GMT, Lukas Wunner wrote:
> On Tue, Jul 15, 2025 at 01:29:18PM +0530, Manivannan Sadhasivam wrote:
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -4964,7 +4964,19 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
> >
> > void __weak pcibios_re
From: Manivannan Sadhasivam
The PCI link, when down, needs to be recovered to bring it back. But on
some platforms, that cannot be done in a generic way as link recovery
procedure is platform specific. So add a new API
pci_host_handle_link_down() that could be called by the host bridge drivers
fo
On Mon, Jul 14, 2025 at 10:37:11PM -0700, Kees Cook wrote:
> On Tue, 01 Jul 2025 14:55:53 +0100, Dave Martin wrote:
> > This series aims to clean up an aspect of coredump generation:
> >
> > ELF coredumps contain a set of notes describing the state of machine
> > registers and other information ab
Apologies for that, I had meant to send v3 in and apparently it got dropped. I
believe I have addressed the comments in the v3 I just sent in.
Thank you!
- Original Message -
> From: "Bjorn Helgaas"
> To: "Timothy Pearson"
> Cc: "Krishna Kumar" , "linuxppc-dev"
> , "linux-kernel"
> ,
From: Manivannan Sadhasivam
The PCIe link can go down under circumstances such as the device firmware
crash, link instability, etc... When that happens, the PCIe Root Port needs
to be reset to make it operational again. Currently, the driver is not
handling the link down event, due to which the u
From: Wilfred Mallawa
The PCIe link may go down in cases like firmware crashes or unstable
connections. When this occurs, the PCIe Root Port must be reset to restore
the functionality. However, the current driver lacks link down handling,
forcing users to reboot the system to recover.
This patch
From: Manivannan Sadhasivam
The PCI link, when down, needs to be recovered to bring it back. But on
some platforms, that cannot be done in a generic way as link recovery
procedure is platform specific. So add a new API
pci_host_handle_link_down() that could be called by the host bridge drivers
fo
nly.
Changes in v6:
- Incorporated the patch:
https://lore.kernel.org/all/20250524185304.26698-2-manivannan.sadhasi...@linaro.org/
- Link to v5:
https://lore.kernel.org/r/20250715-pci-port-reset-v5-0-26a5d278d...@oss.qualcomm.com
Changes in v5:
* Reworked the pci_host_handle_link_down() to accep
From: Manivannan Sadhasivam
Some host bridge devices require resetting the Root Ports in a platform
specific way to recover them from error conditions such as Fatal AER
errors, Link Down etc... So introduce pci_host_bridge::reset_root_port()
callback and call it from pcibios_reset_secondary_bus()
/20250715-160430
base: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
patch link:
https://lore.kernel.org/r/20250715-pci-port-reset-v5-2-26a5d278db40%40oss.qualcomm.com
patch subject: [PATCH v5 2/4] PCI: host-common: Add link down handling for Root
Ports
config: i386-buildonly-randconfig-003
Hello all,
This series includes several fixes for bugs in the PowerNV PCIe hotplug
driver that were discovered in testing with a Microsemi Switchtec PM8533
PFX 48xG3 PCIe switch on a PowerNV system, as well as one workaround for
PCIe switches that don't correctly implement slot presence detection
In cases where the root of a nested PCIe bridge configuration is
unplugged, the pnv_php driver would leak the allocated IRQ resources for
the child bridges' hotplug event notifications, resulting in a panic.
Fix this by walking all child buses and deallocating all it's IRQ
resources before calling
The Microsemi Switchtec PM8533 PFX 48xG3 [11f8:8533] PCIe switch system
was observed to incorrectly assert the Presence Detect Set bit in its
capabilities when tested on a Raptor Computing Systems Blackbird system,
resulting in the hot insert path never attempting a rescan of the bus
and any downst
Multiple race conditions existed between the PCIe hotplug driver and
the EEH driver, leading to a variety of kernel oopses of the same
general nature:
A second class of oops is also seen when the underling bus disappears
during device recovery.
Refactor the EEH module to be PCI rescan and
The PowerNV hotplug driver needs to be able to clear any frozen PE(s)
on the PHB after suprise removal of a downstream device.
Export the eeh_unfreeze_pe() symbol to allow implementation of this
functionality in the php_nv module.
Signed-off-by: Timothy Pearson
---
arch/powerpc/kernel/eeh.c | 1
The existing PowerNV hotplug code did not handle surprise plug events
correctly, leading to a complete failure of the hotplug system after
device removal and a required reboot to detect new devices.
This comes down to two issues:
1.) When a device is surprise removed, oftentimes the bridge upstrea
The PCIe specification allows three attention indicator states,
on, off, and blink. Enable all three states instead of basic
on / off control.
This changes the userspace API to match the behavior of pcihp.
Signed-off-by: Timothy Pearson
---
drivers/pci/hotplug/pnv_php.c | 15 ++-
1
Hi Leon,
On Wed, Jun 25, 2025 at 04:19:05PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Convert HMM DMA operations from the legacy page-based API to the new
> physical address-based dma_map_phys() and dma_unmap_phys() functions.
> This demonstrates the preferred approach for new co
On Tue, Jul 15, 2025 at 02:24:38PM +0100, Will Deacon wrote:
> Hi Leon,
>
> On Wed, Jun 25, 2025 at 04:19:05PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > Convert HMM DMA operations from the legacy page-based API to the new
> > physical address-based dma_map_phys() and dma_un
On Tue, Jul 15, 2025 at 01:29:18PM +0530, Manivannan Sadhasivam wrote:
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4964,7 +4964,19 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
>
> void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
> {
> + struct pci_host_brid
On Mon, Jul 14, 2025 at 03:19:51PM -0500, Rob Herring (Arm) wrote:
> Many simple GPIO controllers without interrupt capability have the same
> schema other than their compatible value. Combine all these bindings
> into a single schema. The criteria to be included here is must use 2
> cells, have no
25 matches
Mail list logo
