| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
|
Do not disable bus mastering on outgoing preserved devices during
pci_device_shutdown() for kexec.
Preserved devices must be allowed to perform memory transactions during
a Live Update to ensure continuous operation. Clearing the bus
mastering bit would prevent these devices from issuing any memory
requests while the new kernel boots.
Because bridges upstream of preserved endpoint devices are also
automatically preserved, this change also avoids clearing bus mastering
on them. This is critical because clearing bus mastering on an upstream
bridge prevents the bridge from forwarding memory requests upstream (i.e.
it would prevent the endpoint device from accessing system RAM and doing
peer-to-peer transactions with devices not downstream of the bridge).
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-12-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Freeze a device's outgoing preservation status (preserved or not
preserved) during shutdown. This enables the PCI core and drivers to
safely make decisions based on the device's preservation status during
shutdown.
Note that pci_liveupdate_freeze() is triggered by the PCI core rather
than from drivers participating in Live Update so that all devices can
have their status frozen (i.e. prevent non-preserved devices from
getting preserved late).
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-11-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Adopt the ARI Forwarding Enable bit on preserved bridges and update
pci_dev->ari_enabled accordingly during a Live Update. This ensures that
the preserved devices on the bridge's secondary bus can be identified
with the same expanded 8-bit function number after a Live Update.
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-10-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Adopt Access Control Services (ACS) controls on all incoming preserved
devices (endpoints and upstream bridges) during a Live Update.
Inheriting ACS flags avoids changing routing rules while memory
transactions are in flight from preserved devices. This is also strictly
necessary to ensure that IOMMU group assignments do not change during or
after Live Update.
Cache the inherited ACS controls established by the previous kernel in
struct pci_dev so that ACS controls do not change after a reset
(pci_restore_state() calls pci_enable_acs()).
To simplify ACS inheritance, reject preserving any devices that require
quirks to enable ACS as those quirks would also have to take Live Update
into account.
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-9-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Refactor the logic to match devices to pci_dev_acs_ops by factoring out
the device matching loop into its own routine, pci_dev_acs_ops_get().
This eliminates duplicate code between pci_dev_specific_enable_acs() and
pci_dev_specific_disable_acs_redir(), and will also be used in a
subsequent commit to check if a device requires device-specific
enable_acs() during a Live Update.
No functional change intended.
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-8-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
When a PCI device is preserved across a Live Update, all of its upstream
bridges up to the root port must also be preserved. This enables the PCI
core and any drivers bound to the bridges to manage bridges correctly
across a Live Update.
Notably, this will be used in subsequent commits to ensure that
preserved devices can continue performing memory transactions without a
disruption or change in routing.
To preserve bridges, the PCI core tracks the number of downstream
devices preserved under each bridge using a reference count in struct
pci_dev_ser. This allows a bridge to remain preserved until all its
downstream preserved devices are unpreserved or finish their
participation in the Live Update.
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-7-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
During a Live Update, preserved devices must be allowed to continue
performing memory transactions so the kernel cannot change the fabric
topology, including bus numbers, since that would require disabling and
flushing any memory transactions first.
To keep bus numbers constant, always preserve the secondary and
subordinate bus numbers assigned to bridges during scanning, instead of
assigning new ones, if any PCI devices were preserved. Note that the
kernel preserves bus numbers even on bridges without any downstream
endpoints that were preserved. This avoids accidentally assigning a
bridge a new window that overlaps with a preserved device that is
downstream of a different bridge.
If a bridge is scanned with a broken topology or has no bus numbers set
during a Live Update, refuse to assign it new bus numbers and refuse to
enumerate devices below it until the Live Update is finished. This is a
safety measure to prevent topology conflicts.
Require that CONFIG_CARDBUS is not enabled to enable
CONFIG_PCI_LIVEUPDATE since preserving bus numbers on PCI-to-CardBus
bridges requires additional work but is not a priority at the moment.
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-6-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Document how driver binding works during a Live Update and what the PCI
core expects of drivers and users. Note that this is only a description
of the current division of responsibilities. These can change in the
future if we decide.
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-5-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
During PCI enumeration, the previous kernel might have passed state about
devices that were preserved across kexec. The PCI core needs to fetch
this state to identify which devices are "incoming" and require special
handling.
Add pci_liveupdate_setup_device() which is called during device setup
to fetch the serialized state (struct pci_ser) from the Live Update
Orchestrator. The first time this happens, pci_flb_retrieve() will run
and convert the array of pci_dev_ser structs into an xarray so that it
can be looked up efficiently.
If a device is found in the xarray, the PCI core stores a pointer to its
state in dev->liveupdate_incoming until pci_liveupdate_finish() is
called by the driver. This pointer allows the PCI core and drivers to
apply Live Update-specific logic to incoming devices in subsequent
commits.
Drivers can check if a device is an incoming preserved device (e.g.
during probe) by calling pci_liveupdate_is_incoming().
CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the
domain and bdf can be guaranteed to fit in an unsigned long and be used
as the xarray key.
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-4-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Add APIs to allow drivers to notify the PCI core of which devices are
being preserved across a Live Update for the next kernel, i.e.
"outgoing" devices.
Drivers must notify the PCI core when devices are preserved so that the
PCI core can update its FLB data (struct pci_ser) and track the list of
outgoing devices. pci_liveupdate_preserve() notifies the PCI core that a
device must be preserved across Live Update. pci_liveupdate_unpreserve()
reverses this (cancels the preservation of the device).
This tracking ensures the PCI core is fully aware of which devices may
need special handling during shutdown and kexec, and so the list of
preserved devices can be handed off to the next kernel.
For now, the API only supports preserving non-VF devices on a root bus
(not behind an PCI-to-PCI bridges).
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-3-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable
it to participate in the preservation of PCI devices across Live Update.
Essentially, this commit enables the PCI core to allocate a struct
(struct pci_ser) and preserve it across a Live Update whenever at least
one device is preserved.
Preserving PCI devices across Live Update is built on top of the Live
Update Orchestrator's (LUO) support for file preservation. Drivers are
expected to expose a file to userspace to represent a single PCI device
and support preservation of that file. This is intended primarily to
support preservation of PCI devices bound to VFIO drivers.
This commit enables drivers to register their liveupdate_file_handler
with the PCI core so that the PCI core can do its own tracking and
enforcement of which devices are preserved.
pci_liveupdate_register_flb(driver_file_handler);
pci_liveupdate_unregister_flb(driver_file_handler);
When the first file (with a handler registered with the PCI core) is
preserved, the PCI core will be notified to allocate its tracking struct
(pci_ser). When the last file is unpreserved (i.e. preservation
cancelled) the PCI core will be notified to free struct pci_ser.
This struct is preserved across a Live Update using KHO and can be
fetched by the PCI core during early boot (e.g. during device
enumeration) so that it knows which devices were preserved.
Note: This commit only allocates struct pci_ser and preserves it across
Live Update. A subsequent commit will add an API for drivers to tell the
PCI core exactly which devices are being preserved.
Note: There is no reason to check for kho_is_enabled() since it can be
assumed to return true. If KHO was not enabled then Live Update would
not be enabled and these routines would never run.
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Link: https://patch.msgid.link/20260728221007.2098560-2-dmatlack@google.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
|
|
- Flush initiator posted writes before calling IRQ handler to work around a
Meteor Lake erratum, where a DMA completion MSI can arrive before the
completion queue in memory has been updated, resulting in an nvme 30
second stall before a QID timeout and possibly other similar problems
(Rickey Bartlett)
* pci/controller/vmd:
PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake
|
|
- Limit Max_Read_Request_Size to 256 to avoid hardware erratum (Marek
Vasut)
- Add a .post_deinit() callback to handle dw_pcie_ep_init() failures (Marek
Vasut)
* pci/controller/dwc-rcar-gen4:
PCI: rcar-gen4: Use .post_deinit() to handle dw_pcie_ep_init() failures
PCI: dwc: Add dw_pcie_ep_ops->post_deinit() callback
PCI: rcar-gen4: Limit Max_Read_Request_Size to 256 Bytes
|
|
- Only collect reset GPIOs from PCI bridge DT nodes to avoid stealing
resets used by downstream devices like USB controllers (Christopher
Obbard)
- Block accesses to downstream devices on link down to reduce a storm of
Completion Timeout AER interrupts (Qiang Yu)
- Skip system suspend/resume for firmware-managed PCIe, where firmware
manages clocks, regulators, resets, etc (Mrinmay Sarkar)
* pci/controller/dwc-qcom:
PCI: qcom: Skip system suspend/resume for firmware-managed PCIe
PCI: qcom: Block accesses to downstream devices on link down
PCI: qcom: Only check bridge nodes for PERST# GPIOs
|
|
- Fix pwrctrl device leak when .probe() PM runtime setup fail (hanzhijian)
- Enable clock after core reset is asserted to fix enumeration regression
on i.MX6Q Apalis platforms with ASM1061/ASM1062 SATA controllers (Richard
Zhu)
* pci/controller/dwc-imx6:
PCI: imx6: Move clock enable after core reset assertion
PCI: imx6: Fix pwrctrl device leak on PM runtime setup failure
|
|
- Fix optional clock leak when .probe() fails by using
devm_clk_get_optional_enabled() (Felix Gu)
- Fix device link leaks when PHY get or enable fails (Felix Gu)
* pci/controller/dwc-dra7xx:
PCI: dra7xx: Fix device links leak when dra7xx_pcie_enable_phy() fails
PCI: dra7xx: Fix device link leak when devm_phy_get() fails
PCI: dra7xx: Fix clock enable leak on probe failure
|
|
- Fix enum type mismatch warning in LTSSM debugfs (Hans Zhang)
* pci/controller/cadence:
PCI: cadence: Fix enum type mismatch warning in LTSSM debugfs
|
|
- Fix clk and PHY leaks in aspeed_pcie_port_init() error paths (Liu
Zhenlong)
* pci/controller/aspeed:
PCI: aspeed: Fix clk and PHY leak in aspeed_pcie_port_init() error paths
|
|
- Pass the correct physical and virtual endpoint function numbers when
setting translation of inbound memory windows (Koichiro Den)
- Make embedded doorbell IRQ non-shared, since currently only the first EPF
can allocate doorbells (Koichiro Den)
- MSI doorbells currently target the first EPF attached to an EPC; let
other EPFs try the embedded doorbell instead of failing when they can't
use the MSI doorbell (Koichiro Den)
* pci/endpoint:
PCI: endpoint: pci-ep-msi: Let non-first EPFs use embedded doorbells
PCI: endpoint: pci-ep-msi: Make embedded doorbell IRQ exclusive
PCI: endpoint: pci-epf-vntb: Pass PF/VF number when BAR programming
|
|
- Use regmap APIs for tc9563 I2C accesses instead of open-coding I2C
transfers (Lorenzo Bianconi)
- Use devm-managed tc9563 I2C dummy device allocation (Lorenzo Bianconi)
- Allow tc9563 RESX reset assertion to sleep (Abel Vesa)
* pci/pwrctrl:
PCI/pwrctrl: tc9563: Allow RESX reset assertion to sleep
PCI/pwrctrl: tc9563: Use devm-managed I2C dummy device allocation
PCI/pwrctrl: tc9563: Rely on regmap APIs
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
Zhaoxin host bridges support peer-to-peer DMA. Add their device IDs
(0x1003, 0x1005-0x1008) to the allowlist so p2pdma works on these
platforms.
The entries cover the KX-6000, KH-40000, KX-6000G, KX-7000 and KH-50000
families.
Mark the KX-6000/KH-40000/KX-6000G/KX-7000 entries REQ_SAME_HOST_BRIDGE
because P2P requests are only supported between devices below the same host
bridge. KH-50000 doesn't have this restriction.
Signed-off-by: LeoLiu-oc <leoliu-oc@zhaoxin.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260901083653.48890-1-leoliu-oc@zhaoxin.com
|
|
The RESX GPIO may be provided by a sleeping GPIO controller, such as an I2C
or SPI I/O expander. Calling gpiod_set_value() for such a GPIO triggers the
following warning:
WARNING: ... drivers/gpio/gpiolib.c:4030 at gpiod_set_value()
The TC9563 power-on and power-off callbacks already sleep while enabling or
disabling regulators and while waiting for oscillator stabilization. Use
gpiod_set_value_cansleep() for RESX so it can be driven without triggering
the warning.
Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260825-pci-pwrctl-tc9563-use-cansleep-for-resx-v1-1-0dbe7cfd8200@oss.qualcomm.com
|
|
Implement .post_deinit() callback in R-Car Gen4 'struct dw_pcie_ep_ops'
which asserts reset and stops the clock. This undoes start of clock and
deassert of reset performed in .pre_init(), in case dw_pcie_ep_init() fails
after successful call of .pre_init() callback.
The use of .post_deinit() callback correctly handles the clock and reset
unwind, unlike the call of rcar_gen4_pcie_ep_deinit() in dw_pcie_ep_init()
which could not discern at which point the dw_pcie_ep_init() failed and can
attempt to stop clock and assert reset twice.
Since dw_pcie_ep_deinit() also invokes the .post_deinit() callback, drop
calls to rcar_gen4_pcie_ep_deinit() in both rcar_gen4_add_dw_pcie_ep() and
dw_pcie_ep_init_registers() fail paths and rcar_gen4_remove_dw_pcie_ep() to
avoid duplicate stop of clock and assert of reset, and drop no longer used
rcar_gen4_pcie_ep_deinit() entirely.
Initialize PCIEDMAINTSTSEN early in rcar_gen4_pcie_ep_pre_init() to 0, to
make sure that edma_int bits will never be left set in case of failure of
dw_pcie_ep_init(), and will only be set in case dw_pcie_ep_init() succeeds.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260821122808.238248-2-marek.vasut+renesas@mailbox.org
|
|
If .pre_init() succeeds but subsequent initialization fails, it is
mandatory to correctly undo the hardware configuration which the
.pre_init() callback did. Introduce a .post_deinit() callback to do exactly
that, undo what the .pre_init() callback did. Usually, that means stop the
clock, assert reset, and possibly program some registers to quiesce the
hardware. Invoke the .post_deinit() callback in dw_pcie_ep_deinit() to
retain functional symmetry.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260821122808.238248-1-marek.vasut+renesas@mailbox.org
|
|
R-Car Gen4 PCIe controller has a hardware limitation of 256 Bytes
Max_Payload_Size (MPS). PCIe specification indicates that the MPS must not
exceed minimum MPS of any element along the packet path. The PCI core
already enforces this, but add a check to warn if MPS is ever set larger
than 256.
R-Car Gen4 Reference Manual, chapter 104.4.8 Usage notes for MRRS (Max Read
Request Size) states:
Please set "Max Read Request Size" to 128 bytes or 256 bytes.
If "Max Read Request Size" is set to anything other than the
above, the transferred data will not match the expected value.
This limitation also seems to apply to devices doing DMA reads, i.e.,
issuing MRd TLPs. This limitation can be triggered by using non-HMB NVMe
SSD with Max_Read_Request_Size 512 Bytes, for example Crucial P5 Plus. Any
write to the SSD (MRd TLP issued by the SSD controller) longer than 256
Bytes wraps around at the 256 Byte boundary, and the same data are written
to the SSD starting at offset 0 and at 256 Bytes.
Limit Max_Read_Request_Size to at most 256 Bytes for each device connected
to this PCIe controller to avoid this behavior.
A non-HMB (Host Memory Buffer) NVMe SSD can be identified using the
following command. Affected SSD reports 'hmpre' field as 0:
$ nvme id-ctrl /dev/nvme0 | grep hmpre
hmpre : 0
The symptom is a read from the SSD which wraps around at 256 Byte boundary.
The test for this symptom can be implemented by writing 512 Byte of random
data into the SSD and reading the data back. If the read back data repeat
after 256 Bytes, the device is affected.
$ dd if=/dev/urandom of=/tmp/data.bin bs=256 count=2 ; \
dd if=/tmp/data.bin of=/dev/nvme0n1 bs=256 count=2 ; \
dd if=/dev/nvme0n1 bs=256 count=2 of=/tmp/readback.bin
Expected data:
$ hexdump -vC /tmp/data.bin
00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca
00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b
...
00000100 7a ce 3c b2 e1 d5 d9 11 88 63 10 59 76 3c dc 32 <-- random
00000110 72 32 2a 7d a3 e1 aa 13 7c da 58 a1 7b 21 11 50 <-- data
Faulty readback, collected without this change in place:
$ hexdump -vC /tmp/readback.bin
00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <---.
00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-. |
... | |
00000100 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <-:-+- repeated
00000110 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-+--- data
^^^
|
'--- Repeat starts at offset 0x100 = 256 Bytes
Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260821020636.111719-1-marek.vasut+renesas@mailbox.org
|
|
For firmware-managed PCIe controllers, all resources, including clocks,
regulators, resets, PHYs and link state, are owned and managed by
firmware. The host driver must not attempt to manage these resources
during system suspend or resume. Firmware will properly transition the
devices/controller into relevant low power modes.
Skip the suspend and resume operations for firmware-managed controllers.
The associated power domain transitions are handled independently by the
genpd framework through its own system suspend/resume callbacks, so no
explicit action is required by the PCIe controller driver.
Signed-off-by: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260831-skip_suspend-v1-1-ba2d877e22b1@oss.qualcomm.com
|
|
pci_epf_alloc_doorbell() rejects every EPF that is not the first one
attached to the EPC because the MSI-backed path can populate doorbell
messages only for that EPF. This also prevents non-first EPFs from using
the embedded doorbell backend.
Keep the MSI-backed path limited to the first attached EPF. Let
non-first EPFs skip it and try the embedded doorbell directly. The
embedded IRQ is exclusive, so a second embedded user fails to request
the IRQ instead of receiving another EPF's notifications.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260728172306.2751813-4-den@valinux.co.jp
|
|
Embedded doorbells may use the same virq for several messages. This does
not mean the IRQ itself should be shared. Consumers only need to request
each distinct virq once, as vNTB and pci-epf-test already do.
IRQF_SHARED would let different EPFs register handlers for the same IRQ.
The embedded doorbell interface cannot tell which EPF a write targets,
so every handler would handle it.
Only the first EPF can allocate doorbells today, so this cannot happen
yet. Drop IRQF_SHARED before extending the embedded backend to non-first
EPFs. A second request for the same IRQ will then fail with -EBUSY
instead of attaching another handler.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260728172306.2751813-3-den@valinux.co.jp
|
|
vntb_epf_mw_set_trans() programs the memory-window BAR through
pci_epc_set_bar() with hardcoded function numbers (0, 0), so the BAR
lands on the wrong function whenever the vNTB EPF is bound to anything
but PF0. The other BAR programming sites in the vNTB driver already pass
the EPF's own numbers.
Pass the EPF's own func_no/vfunc_no here as well.
Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260728172306.2751813-2-den@valinux.co.jp
|
|
Commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators")
inadvertently moved clock enablement before core reset assertion, breaking
PCI device initialization on i.MX6Q Apalis platforms with
ASM1061/ASM1062 SATA controllers connected:
imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges:
imx6q-pcie 1ffc000.pcie: IO 0x0001f80000..0x0001f8ffff -> 0x0000000000
imx6q-pcie 1ffc000.pcie: MEM 0x0001000000..0x0001efffff -> 0x0001000000
imx6q-pcie 1ffc000.pcie: config reg[1] 0x01f00000 == cpu 0x01f00000
imx6q-pcie 1ffc000.pcie: iATU: unroll F, 4 ob, 4 ib, align 64K, limit 4G
imx6q-pcie 1ffc000.pcie: Link: Only Gen1 is enabled
imx6q-pcie 1ffc000.pcie: Link failed to come up. LTSSM: POLL_CONFIG
imx6q-pcie 1ffc000.pcie: probe with driver imx6q-pcie failed with error -110
NOTE: It is not 100% clear if the issue is specific to the ASM1061/ASM1062
device or on the specific power-up sequence (reset vs cold-power-on).
To fix this regression, restore the original sequence where clocks are
enabled after asserting core reset and configuring the controller type.
Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators")
Reported-by: Leonardo Costa <leoreis.costa@gmail.com>
Closes: https://lore.kernel.org/all/bl7i3obu2clzsgeoct2a4mtfhv6typcjdqmgneropf3hpgwve6@n2m5uhlduw57/T/#u
Reported-by: Franz Schnyder <fra.schnyder@gmail.com>
Closes: https://lore.kernel.org/all/t65y5d54axtksbfs7r4olcefqhwm6m4dz3njgnrnf7fcotj74i@o7avoznlafbj/
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Cc: stable@vger.kernel.org # 7.2+
Link: https://patch.msgid.link/20260813095003.356062-1-hongxing.zhu@oss.nxp.com
|
|
When dra7xx_pcie_enable_phy() fails, the code returned immediately and
left the already created device links behind.
Jump to the existing err_link cleanup instead so those links are
deleted on failure.
Fixes: 7a4db656a635 ("PCI: dra7xx: Create functional dependency between PCIe and PHY")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260822-dra7xx-v1-3-23e204d5548b@gmail.com
|
|
When devm_phy_get() fails, the code returned immediately and left the
already created device links behind.
Jump to the existing err_link cleanup instead so those links are
deleted on failure.
Fixes: 7a4db656a635 ("PCI: dra7xx: Create functional dependency between PCIe and PHY")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260822-dra7xx-v1-2-23e204d5548b@gmail.com
|
|
dra7xx_pcie_probe() enables the optional clock but never disables it
when probing fails afterwards.
Switch to devm_clk_get_optional_enabled(), which disables the clock
automatically on failure.
Fixes: 5af9405397bf ("PCI: dra7xx: Get an optional clock")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260822-dra7xx-v1-1-23e204d5548b@gmail.com
|
|
Lake
Meteor Lake VMD (8086:7d0b) is affected by erratum MTL016: the VMD can
signal its MSI before the posted writes carrying a child device's DMA
data have landed in memory. vmd_irq() then demuxes to the child handler
while the child's completion queue is not yet coherent, so the handler
observes no completion and returns without consuming it. The I/O is
only recovered when the block layer timeout expires and polls the queue:
nvme nvme0: I/O tag 253 (50fd) QID 1 timeout, completion polled
The practical effect is therefore not a lost I/O but a 30 second stall
of the entire storage stack, repeated under any sustained read load.
This was originally diagnosed and fixed by Kai-Heng Feng in September
2024 [1]. That patch used udelay(4); Keith Busch objected that the delay
is merely a side effect of the read, and that flushing the pending
device-to-host writes is what the erratum actually requires. Kai-Heng
agreed to respin with a dummy register read. The thread then stalled on
an open question from Manivannan Sadhasivam [2]: whether the read must
target the child device (the "MSI initiator" named by the erratum)
rather than the VMD, and whether the workaround belongs in the NVMe
driver instead. No revision followed, and the erratum has remained
unmitigated in mainline since.
This implements the flush read Keith asked for, and answers the open
question empirically: the read MUST complete at the initiating child
device. A read of the VMD's own config BAR was tried first and does not
help - it terminates at the VMD and never traverses the downstream
link, so it does not order against the child's posted writes (measured:
timeout rate unchanged). Reading the initiator's config space does
order correctly: per PCIe ordering rules the read completion cannot
pass the device's earlier posted writes, so returning from the read
guarantees the completion queue entry is visible.
The initiator's config address is captured per-IRQ at MSI allocation
time from the requesting device, so the hot path adds one config read
only on affected parts, and only for vectors owned by a child device.
The read is serialized with cfg_lock like all other VMD config access.
No NVMe driver change is needed.
Measured on a Dell Pro Max 14 MC14250 (Meteor Lake, VMD 8086:7d0b,
KIOXIA BG6 512GB, 7.0.0-30-generic). The drive is healthy (46C, 0 media
errors, 2% used) and ASPM is disabled on the link with all L1 substates
off, so neither ASPM nor APST is involved.
Dropping caches and reading 3000 shared libraries, measuring
/proc/pressure/io "full" (every task on the system blocked on I/O),
with nvme_core.io_timeout=5:
unpatched: round 1 wall 37.4s full I/O stall 32.6s timeouts 0
round 2 wall 30.6s full I/O stall 28.7s timeouts 1
round 3 wall 30.3s full I/O stall 27.4s timeouts 1
VMD-BAR read: round 1 wall 44.8s full I/O stall 38.6s timeouts 8
(insufficient) round 2 wall 234.8s full I/O stall 207.9s timeouts 37
round 3 wall 3.6s full I/O stall 0.8s timeouts 0
this patch: round 1 wall 3.6s full I/O stall 1.3s timeouts 0
round 2 wall 3.6s full I/O stall 1.3s timeouts 0
round 3 wall 3.6s full I/O stall 1.4s timeouts 0
Before any workaround, 208 seconds of total-system I/O stall
accumulated in the first 13 minutes of uptime, roughly 27% of wall
clock. Userspace experiences this as GUI applications taking 30-60+
seconds to start while throughput between stalls looks entirely normal
(1.9 GB/s QD1) - which is what makes the fault easy to misattribute to
ASPM or to the drive.
[1] https://lore.kernel.org/all/20240909082657.19660-1-kai.heng.feng@canonical.com/
[2] https://lkml.iu.edu/hypermail/linux/kernel/2409.1/08047.html
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Suggested-by: Keith Busch <kbusch@kernel.org>
Assisted-by: LLM
Signed-off-by: Rickey Bartlett <subtexel@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20240909082657.19660-1-kai.heng.feng@canonical.com/
Link: https://lkml.iu.edu/hypermail/linux/kernel/2409.1/08047.html
Link: https://patch.msgid.link/20260825043220.9047-1-subtexel@gmail.com
|
|
aspeed_pcie_port_init() calls clk_prepare_enable() to enable the port
clock, but if phy_init() or phy_set_mode_ext() fails afterwards, the
function returns without calling clk_disable_unprepare(), leaking the
clock reference on every probe failure. Additionally, when
phy_set_mode_ext() fails, phy_init() has already succeeded, so
phy_exit() is also missing, leaking the PHY reference.
Add the matching clk_disable_unprepare() to both error paths, and
phy_exit() to the phy_set_mode_ext() failure path, mirroring the
cleanup pattern in pci-aardvark.
Compile-tested with gcc on arm64 defconfig using COMPILE_TEST.
Fixes: 9aa0cb68fcc1 ("PCI: aspeed: Add ASPEED PCIe RC driver")
Signed-off-by: Liu Zhenlong <dragonliu2018@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260816171633.15025-1-dragonliu2018@gmail.com
|
|
In imx_pcie_probe(), after pci_pwrctrl_create_devices() creates the
pwrctrl devices, the error paths for imx_add_pcie_ep() and
dw_pcie_host_init() both jump to err_pwrctrl_destroy to tear them down.
However, the error path for devm_pm_runtime_set_active_enabled() returns
directly, leaking the pwrctrl devices.
Jump to err_pwrctrl_destroy instead so the pwrctrl devices are cleaned
up on this error path too.
Signed-off-by: hanzhijian <hanzhijian1991@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260822012205.2459806-1-hanzhijian1991@gmail.com
|
|
Fix Clang -Wenum-compare-conditional warning by using a single u32
variable to hold the LTSSM status value, replacing two separate enum
variables of different types.
Fixes: d70e964dc099 ("PCI: cadence: Add LGA IP debugfs for LTSSM status")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608201933.w2579mwx-lkp@intel.com/
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260820232305.80596-1-18255117159@163.com
|
|
After a PCIe link goes down, software may still access the BAR (MMIO)
space or configuration space of devices behind that link before recovery
has run. As the link is down, these accesses never complete, resulting in
a storm of Completion Timeout AERs.
Use the controller's ECAM blocker to drop these accesses to the PCIe
address space as soon as the link-down interrupt fires, so that Completion
Timeout AERs are reduced. The blocked range covers the entire address
space (base 0x0, all-ones limit), since the Root Port's own DBI/iATU
register space remains accessible regardless.
The range is programmed once in the host init path, since the range
registers are wiped by BCR reset. This leaves only the ECAM_BLOCKER_EN
bit to be flipped from the link-down IRQ handler, so the blocker can be
armed with a single fast register write for immediate effect.
The subsequent Root Port reset re-initialises the controller, which clears
the enable bit and re-programs the range for the fresh link.
Some IP revisions implement the ECAM blocker registers but do not wire
up the "global" interrupt used to deliver the link-down event that arms
the blocker, so there is no way to enable the blocker on those platforms.
Restrict blocker initialization to the post_init hooks of the IP
revisions that do have a global IRQ wired up
(qcom_pcie_post_init_2_3_3(), qcom_pcie_post_init_2_7_0() and
qcom_pcie_post_init_2_9_0()), instead of unconditionally programming it
from the common host_init path.
The link-down IRQ thread's blocker-enable write to PARF_SYS_CTRL can race
with a Root Port reset triggered independently through AER, which
reprograms PARF_SYS_CTRL as part of reinitializing the controller.
Serialize these with a per-controller mutex.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
[mani: renamed hw_lock to reset_lock and used guard(mutex)]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD + ASUS PA27AC
Link: https://patch.msgid.link/20260819-ecam_blocker-v2-1-e7a8fdc1c5cb@oss.qualcomm.com
|
|
qcom_pcie_parse_perst() walks the PCIe hierarchy described in the device
tree below its Root Port and collects the PERST# GPIOs from each bridge
node so all PERST# lines can be driven in unison during controller
bring-up, reset and power sequencing.
However, the recursive device tree walk currently visits every available
child node without checking that it is a PCI bridge. This allows the walk
to leave the PCI hierarchy and collect reset lines from children of PCI
Endpoint nodes, where those reset lines belong to other drivers.
This is reproducible on the Qualcomm RB3Gen2, where a Renesas uPD720201
USB host controller sits behind a PCIe switch downstream port. A Genesys
GL3590 USB hub connected to that controller is described as a child of
the PCI endpoint:
pcie@2,0 {
device_type = "pci";
usb-controller@0,0 {
compatible = "pci1912,0014";
hub@1 {
compatible = "usb5e3,610";
reset-gpios = <&tlmm 162 GPIO_ACTIVE_HIGH>;
};
};
};
The USB controller is a PCI Endpoint, and not a bridge, but the PERST#
walk descends through it and incorrectly claims the hub's reset GPIO:
$ gpioinfo
line 162: unnamed output consumer=PERST#
As a result, the onboard-usb-dev driver cannot acquire its reset GPIO
during probe:
onboard-usb-dev 1c08000.pcie:...:usb-controller@0,0:hub@1: \
error -EBUSY: failed to get reset GPIO
onboard-usb-dev 1c08000.pcie:...:usb-controller@0,0:hub@1: \
probe with driver onboard-usb-dev failed with error -16
The GPIO is also added to the root port's PERST# list and is asserted
and deasserted as part of PCIe reset sequencing. On the RB3Gen2 this
causes the USB hub to repeatedly re-enumerate:
[ 116.479598] hub 2-1:1.0: USB hub found
[ 116.488601] hub 2-1:1.0: USB hub found
[ 116.496971] hub 2-1:1.0: USB hub found
...
This disrupts the hub and devices connected to it.
Restrict the recursive walk to children with device_type "pci", so
PERST# GPIOs are collected only from PCI bridge nodes and the walk
does not descend through endpoints.
qocm_pcie_parse_ports() has made the same distinction since
commit 45df22935bdc ("PCI: qcom: Restrict port parsing only to PCIe
bridge child nodes"), but the PERST# walk added later did not carry over
that check.
This bug is distinct from commit 3edb3a038d42 ("PCI: qcom: Skip PERST#
GPIOs provided by downstream PCIe devices"), which filters PERST# GPIOs
based on their provider. Here the GPIO is provided by the SoC TLMM; the
bug is that reset-gpios is consumed from a non-bridge node at all.
Fixes: 2fd60a2edb83 ("PCI: qcom: Parse PERST# from all PCIe bridge nodes")
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260829-wip-obbardc-drivers-pcie-qcom-rb3gen2-usb-fix-v1-1-337821131a99@oss.qualcomm.com
|
|
Switch from i2c_new_dummy_device() to its devm variant
devm_i2c_new_dummy_device() so the I2C client is automatically
unregistered when the driver is removed or on probe failure.
This allows removing the manual i2c_unregister_device() calls from both the
probe error path and the remove function, and lets the i2c_client pointer
be a local variable in probe instead of storing it in the driver data
structure.
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260729-pci-pwrctrl-tc956x-regmap-v1-2-20ce61a3ce12@oss.qualcomm.com
|
|
Replace the custom tc9563_pwrctrl_i2c_{read,write,bulk_write} functions
with standard regmap APIs. The device uses 24-bit big-endian register
addresses and 32-bit little-endian register values over I2C, which is
directly supported by regmap.
This removes the open-coded I2C transfer handling and lets the regmap
core handle formatting, locking, and multi-register coalescing.
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260729-pci-pwrctrl-tc956x-regmap-v1-1-20ce61a3ce12@oss.qualcomm.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
Pull hyperv updates from Wei Liu:
- Decrypt netvsc buffer on contiguous direct-map addresses (Kameron
Carr)
- Drop WS2012/2012R2 & Win8/8.1 Hyper-V support (Michael Kelley)
- Use more meaningful errnos for hypercall status code (Hardik Garg)
- Fix lost interrupts on CPU hot-unplug for Hyper-V PCI/MSI (Naman
Jain)
- Reserve more MSHV vectors for Linux root partition (Wei Liu)
* tag 'hyperv-next-signed-20260826' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
clocksource: hyper-v: Remove support for stimer interrupts in message mode
scsi: storvsc: Remove support for storvsc protocol of old Hyper-V hosts
hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts
hv_sock: Remove check for old Hyper-V hosts
Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V
hv_netvsc: Allocate send/receive buffers using vmbus_alloc_buffer()
Drivers: hv: vmbus: Add vmbus_alloc_buffer()/vmbus_free_buffer() for CoCo VMs
Drivers: hv: vmbus: add vmbus_establish_gpadl_caller_decrypted()
Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition
x86/hyperv: reserve more vectors
PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip
Drivers: hv: Use meaningful errnos for hypercall status codes
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull another power sequencing update from Bartosz Golaszewski:
"A single tree-wide rename of two of the public functions to better
reflect their actual semantics:
- rename pwrseq_power_on/off() to pwrseq_enable/disable() tree-wide"
* tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()
|
|
The way power sequencing works means that a call to pwrseq_power_on()
does not necessarily result in the pwrseq target being powered-on at
that time: it may have already been powered on before. Similarly: a call
to pwrseq_power_off() does not have to result in an actual powering off
of resources: there may still be other users that requested a power-on
before.
We will also introduce the concept of "non-controllable" pwrseq targets
soon which further increases the disconnect between the naming
convention and the actual semantics.
What consumers of pwrseq descriptors actually do is: they *vote* for a
powering on of a given target or retract that vote. These operations
could be called get/put in line with runtime PM but this could become
confusing since we already provide pwrseq_get/put() for a different
purpose. pwrseq_vote_on/off() also have been rejected as unusual in
the tree.
Change the name of the two functions to pwrseq_enable/disable() which
better reflects their purpose and semantics and also mirrors other
enable-counted resources like regulators and clocks. No functional change
intended.
If at any point users need to know *when* the exact power event happens,
we can provide that information in the form of a notifier.
Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Acked-by: Alessio Belle <alessio.belle@imgtec.com> # imagination
Link: https://patch.msgid.link/20260731-pwrseq-vote-rename-v3-1-44e60b8be053@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc/IIO/etc driver updates from Greg KH:
"Here is the big set of char, misc, iio, counter, fpga, and other small
driver subsystems for 7.3-rc1.
Overall, due to some driver removals we only added a bit more code
than removed, which was a nice change. Highlights in this merge
request are:
- Loads of IIO driver updates and additions
- binder driver updates (more on that below...)
- Removal of the SGI XP and GRU drivers as they are not used anymore
and turn out to be pretty insecure overall
- Removal of the obsolete ibmasm driver as it's not being used
anymore
- Coresight driver updates and additions
- Mei driver udpates
- Counter driver updates
- FPGA driver updates
- ICC driver updates
- lots and lots of other tiny driver updates to resolve reported
issues
All of these have been in linux-next for a while"
* tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (513 commits)
iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
iio: adc: pac1921: fix wrong channel used in trigger handler read
iio: light: gp2ap002: re-enable irq if runtime suspend fails
iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes
iio: light: apds9306: fix PM reference leak in apds9306_read_data()
iio: gyro: mpu3050: fix sign of raw angular velocity readings
iio: srf04: fix pm_runtime handling on probe error path
iio: adc: ad4080: configure backend data size
iio: adc: adi-axi-adc: add data size support for AD408X backend
iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable
iio: dac: ad5446: fix OF module device table
iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask
iio: light: opt4001: Reject integration times with a non-zero seconds part
iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem()
iio: light: opt4001: Fix power down clearing bits of the wrong register
iio: light: opt4060: Fix incorrect register name in threshold read error message
iio: light: opt4060: Fix pointer type passed to div_u64_rem()
iio: light: opt4060: Reject integration times with a non-zero seconds part
iio: light: ltrf216a: fix runtime PM reference leak in error path
iio: pressure: dps310: fix NULL pointer dereference on ACPI probe
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine
Pull dmaengine updates from Vinod Koul:
"Core:
- New API to combine configuration and preparation and users
New hardware support:
- Mediatek MT8189 SoC uart dma support
Updates:
- Designware dma driver flatten desc structures and simplify code,
interrupt-path groundwork changes, first part of PCI EP DMA support
- Updates to zynqmp_dma with runtime PM and device removal
improvments
- Xilinx dma optimizations for AXIDMA and MCDMA channel management"
* tag 'dmaengine-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (73 commits)
dmaengine: dw-edma: Mark emulated IRQ as level-triggered
dmaengine: idxd: assign all engines to group 0 in IAA defaults
dmaengine: qcom_hidma: remove conditional return with no effect
dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal
dmaengine: fsl-edma: tracing: no ptr dereference during log output
dmaengine: dw-edma: Program endpoint function numbers
dmaengine: dw-edma-pcie: Add chip flags to match data
dmaengine: dw-edma-pcie: Handle optional data blocks
dmaengine: dw-edma-pcie: Factor out descriptor block address lookup
dmaengine: dw-edma-pcie: Add register offset match flag
dmaengine: dw-edma-pcie: Add platform ops to match data
dmaengine: dw-edma-pcie: Rename vsec_data to dma_data
dmaengine: dw-edma-pcie: Add capability match data
dmaengine: dw-edma-pcie: Track non-LL mode in DMA data
dmaengine: dw-edma: Add partial channel ownership mode
dmaengine: dw-edma: Initialize IRQ data before requesting IRQs
dmaengine: dw-edma: Add core quiesce operations
dmaengine: dw-edma: Add per-channel interrupt routing control
dmaengine: dw-edma: Factor out HDMA interrupt setup helper
dmaengine: dw-edma: Defer channel IRQ handling to workqueue
...
|
|
The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback.
On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to
the outgoing CPU to a new target. If an interrupt still has its pending bit
set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the
new target through the irqchip's irq_retrigger() callback. As the Hyper-V
PCI/MSI chip does not provide that callback, the pending interrupt is
silently dropped, which can result in lost interrupts, stalls and "No irq
handler for vector" messages during CPU hotplug.
Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for
the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its
new target CPU via the parent x86 vector domain.
Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Cc: stable@vger.kernel.org
Suggested-by: Long Li <longli@microsoft.com>
Suggested-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Aditya Garg <gargaditya@linux.microsoft.com>
Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
