* [PATCH v2] media: rkvdec: fix PM runtime teardown ordering in remove
From: Francesco Saverio Pavone @ 2026-05-18 14:54 UTC (permalink / raw)
To: jonas, detlev.casanova, nicolas.dufresne, hverkuil, mchehab
Cc: ezequiel, heiko, stable, linux-media, linux-rockchip,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260518105413.42147-1-pavone.lawyer@gmail.com>
From: Jonas Karlman <jonas@kwiboo.se>
The current remove() path calls rkvdec_v4l2_cleanup() and
pm_runtime_disable() before pm_runtime_dont_use_autosuspend(), and
frees the empty IOMMU domain after that. With autosuspend still
armed when the domain goes away, the VDPU381 can be left in a dirty
state across module reload and suspend/resume cycles.
On RK3588 this surfaces as a VP9 inter-prediction bug: from the
second ALTREF frame onward, motion blocks decode with U=V=0 (BT.709
green), while intra and static blocks stay correct. Reordering the
teardown to dont_use_autosuspend() -> iommu_domain_free() ->
pm_runtime_disable() -> v4l2_cleanup() makes the symptom go away.
Tested on a Radxa Rock 5B+ (RK3588, 8 GB LPDDR5) with both the
libva-v4l2-request mpv pipeline and Chromium's V4L2 stateless
decoder. With the fix, 300 random pixel samples on VP9 Profile 0
clips at 1080p and 1440p match a libvpx software reference exactly
(worst delta 0). Without it, the same 1080p sample at frame 4,
pixel (960, 270) reads HW=(0,112,0) vs SW=(204,147,116). HEVC and
H.264 stateless decoding via mpv keep running on hardware with no
fallback.
Fixes: ff8c5622f9f7 ("media: rkvdec: Restore iommu addresses on errors")
Cc: <stable@vger.kernel.org>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
Signed-off-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
---
Changes in v2:
- Add Cc: <stable@vger.kernel.org>; media-CI flagged that the
Fixes: target (ff8c5622f9f7) is present in the 6.17, 6.18, 6.19
and 7.0 stable branches, so the fix should reach them too.
Link to v1: https://lore.kernel.org/all/20260518105413.42147-1-pavone.lawyer@gmail.com/
Media-CI report: https://linux-media.pages.freedesktop.org/-/users/patchwork/-/jobs/100124849/artifacts/report.htm
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index 6f5f0422d317..bb95b090a25b 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -2066,12 +2066,13 @@ static void rkvdec_remove(struct platform_device *pdev)
cancel_delayed_work_sync(&rkvdec->watchdog_work);
- rkvdec_v4l2_cleanup(rkvdec);
- pm_runtime_disable(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
if (rkvdec->empty_domain)
iommu_domain_free(rkvdec->empty_domain);
+
+ pm_runtime_disable(&pdev->dev);
+ rkvdec_v4l2_cleanup(rkvdec);
}
#ifdef CONFIG_PM
--
2.45.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Paul Kocialkowski @ 2026-05-18 14:56 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <bc3b786313adee30cc00c65ea98ff5258a816abb.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]
Alexander,
Le Mon 18 May 26, 16:40, Alexander Sverdlin a écrit :
> Hi Paul,
>
> On Mon, 2026-05-18 at 16:14 +0200, Paul Kocialkowski wrote:
> > I also have a U-Boot config ready for it, which I could send once the
> > device-trees are merged on the kernel side. I could send it to you if
> > you're interested.
>
> I do have one as well, I'm testing all open-source ;-) from ATF-upwards,
> just thought U-Boot would require ATF merged and kernel DT merged
> because of OF_UPSTREAM in U-Boot. But I'd be happy to sync when we get
> there.
Sure, let's keep in touch about this!
I also have the 7" LVDS LCD that goes with it, which was supported by
Parthiban's initial series (but needs rework, and it seems that he's
unlikely to do it). I also have the 5" MIPI LCD but it's less likely
that it will be supported, although I have seen dirty patches to make
some other MIPI panel work with A133.
We'll need PWM for it which should be a follow-up to the current H616
PWM series from Richard Genoud.
Other than that there is a PCF8563TS RTC on the board, audio stuff:
speaker (which I have) mic and headphones and a GPIO beeper which could
be added.
Do you have other A133 boards that you're interested in?
I also have:
- KICKPI K5C
- DshanPi-R818
- Logicom La Tab 129
- Trimui Brick
And have some WIP device-trees and u-boot for most of them.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v8 1/5] PCI: dwc: ep: Clear MSI iATU mapping in dw_pcie_ep_cleanup()
From: Manivannan Sadhasivam via B4 Relay @ 2026-05-18 14:59 UTC (permalink / raw)
To: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Niklas Cassel, Wilfred Mallawa,
Krishna Chaitanya Chundru, mani, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding, Manivannan Sadhasivam
In-Reply-To: <20260518-pci-port-reset-v8-0-eb5a7d331dfc@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
The MSI iATU mapping is currently only cleared when the endpoint is
stopped via configfs or when the host updates the MSI address/size.
This avoids redundant iATU reconfiguration every time the endpoint
raises an MSI interrupt.
However, a fundamental reset triggered by PERST# assert/deassert
resets all iATU inbound/outbound registers without going through the
configfs stop path. If the host also retains the same MSI address/size
after PERST# deassert, the driver never clears the stale MSI iATU
mapping. It then continues using this stale mapping to raise the MSI
interrupts, which can cause IOMMU faults and MSI failures on the host.
Fix this by clearing the MSI iATU mapping inside dw_pcie_ep_cleanup(),
which is already called as part of the PERST# assert/deassert sequence.
This unmaps the MSI iATU region and sets the msi_iatu_mapped flag to
false, ensuring that dw_pcie_ep_raise_msi_irq() performs a fresh iATU
mapping on its next invocation, regardless of whether the host changed
the MSI address/size.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index d4dc3b24da60..4ae0e1b55f39 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -1035,6 +1035,11 @@ void dw_pcie_ep_cleanup(struct dw_pcie_ep *ep)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ if (ep->msi_iatu_mapped) {
+ dw_pcie_ep_unmap_addr(ep->epc, 0, 0, ep->msi_mem_phys);
+ ep->msi_iatu_mapped = false;
+ }
+
dwc_pcie_debugfs_deinit(pci);
dw_pcie_edma_remove(pci);
}
--
2.48.1
^ permalink raw reply related
* [PATCH v8 4/5] PCI: qcom: Add support for resetting the Root Port due to link down event
From: Manivannan Sadhasivam via B4 Relay @ 2026-05-18 14:59 UTC (permalink / raw)
To: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Niklas Cassel, Wilfred Mallawa,
Krishna Chaitanya Chundru, mani, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding, Manivannan Sadhasivam,
Manivannan Sadhasivam
In-Reply-To: <20260518-pci-port-reset-v8-0-eb5a7d331dfc@oss.qualcomm.com>
From: Manivannan Sadhasivam <mani@kernel.org>
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 users have to restart the
machine to make PCIe link operational again. So fix it by detecting the
link down event and resetting the Root Port.
Since the Qcom PCIe controllers report the link down event through the
'global' IRQ, enable the link down event by setting PARF_INT_ALL_LINK_DOWN
bit in PARF_INT_ALL_MASK register.
In the case of the event, iterate through the available Root Ports and call
pci_host_handle_link_down() API with Root Port 'pci_dev' to let the PCI
core handle the link down condition. Since Qcom PCIe controllers only
support one Root Port per controller instance, the API will be called only
once. But the looping is necessary as there is no PCI API available to
fetch the Root Port instance without the child 'pci_dev'.
The API will internally call, 'pci_host_bridge::reset_root_port()' callback
to reset the Root Port in a platform specific way. So implement the
callback to reset the Root Port by first resetting the PCIe core, followed
by reinitializing the resources and then finally starting the link again.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
drivers/pci/controller/dwc/pcie-qcom.c | 143 ++++++++++++++++++++++++++++++++-
1 file changed, 142 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index af6bf5cce65b..feda8abf5f85 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -56,6 +56,10 @@
#define PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1a8
#define PARF_Q2A_FLUSH 0x1ac
#define PARF_LTSSM 0x1b0
+#define PARF_INT_ALL_STATUS 0x224
+#define PARF_INT_ALL_CLEAR 0x228
+#define PARF_INT_ALL_MASK 0x22c
+#define PARF_STATUS 0x230
#define PARF_SID_OFFSET 0x234
#define PARF_BDF_TRANSLATE_CFG 0x24c
#define PARF_DBI_BASE_ADDR_V2 0x350
@@ -131,6 +135,13 @@
/* PARF_LTSSM register fields */
#define LTSSM_EN BIT(8)
+#define SW_CLEAR_FLUSH_MODE BIT(10)
+#define FLUSH_MODE BIT(11)
+
+/* PARF_INT_ALL_{STATUS/CLEAR/MASK} register fields */
+#define INT_ALL_LINK_DOWN 1
+#define PARF_INT_ALL_LINK_DOWN BIT(INT_ALL_LINK_DOWN)
+#define PARF_INT_MSI_DEV_0_7 GENMASK(30, 23)
/* PARF_NO_SNOOP_OVERRIDE register fields */
#define WR_NO_SNOOP_OVERRIDE_EN BIT(1)
@@ -142,6 +153,9 @@
/* PARF_BDF_TO_SID_CFG fields */
#define BDF_TO_SID_BYPASS BIT(0)
+/* PARF_STATUS fields */
+#define FLUSH_COMPLETED BIT(8)
+
/* ELBI_SYS_CTRL register fields */
#define ELBI_SYS_CTRL_LT_ENABLE BIT(0)
@@ -166,6 +180,7 @@
PCIE_CAP_SLOT_POWER_LIMIT_SCALE)
#define PERST_DELAY_US 1000
+#define FLUSH_TIMEOUT_US 100
#define QCOM_PCIE_CRC8_POLYNOMIAL (BIT(2) | BIT(1) | BIT(0))
@@ -282,11 +297,14 @@ struct qcom_pcie {
const struct qcom_pcie_cfg *cfg;
struct dentry *debugfs;
struct list_head ports;
+ int global_irq;
bool suspended;
bool use_pm_opp;
};
#define to_qcom_pcie(x) dev_get_drvdata((x)->dev)
+static int qcom_pcie_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev);
static void __qcom_pcie_perst_assert(struct qcom_pcie *pcie, bool assert)
{
@@ -1330,6 +1348,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
goto err_assert_reset;
}
+ pp->bridge->reset_root_port = qcom_pcie_reset_root_port;
+
return 0;
err_assert_reset:
@@ -1613,6 +1633,78 @@ static void qcom_pcie_icc_opp_update(struct qcom_pcie *pcie)
}
}
+/*
+ * Qcom PCIe controllers only support one Root Port per controller instance. So
+ * this function ignores the 'pci_dev' associated with the Root Port and just
+ * resets the host bridge, which in turn resets the Root Port also.
+ */
+static int qcom_pcie_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev)
+{
+ struct pci_bus *bus = bridge->bus;
+ struct dw_pcie_rp *pp = bus->sysdata;
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct qcom_pcie *pcie = to_qcom_pcie(pci);
+ struct device *dev = pcie->pci->dev;
+ u32 val;
+ int ret;
+
+ /* Wait for the pending transactions to be completed */
+ ret = readl_relaxed_poll_timeout(pcie->parf + PARF_STATUS, val,
+ val & FLUSH_COMPLETED, 10,
+ FLUSH_TIMEOUT_US);
+ if (ret) {
+ dev_err(dev, "Flush completion failed: %d\n", ret);
+ goto err_host_deinit;
+ }
+
+ /* Clear the FLUSH_MODE to allow the core to be reset */
+ val = readl(pcie->parf + PARF_LTSSM);
+ val |= SW_CLEAR_FLUSH_MODE;
+ writel(val, pcie->parf + PARF_LTSSM);
+
+ /* Wait for the FLUSH_MODE to clear */
+ ret = readl_relaxed_poll_timeout(pcie->parf + PARF_LTSSM, val,
+ !(val & FLUSH_MODE), 10,
+ FLUSH_TIMEOUT_US);
+ if (ret) {
+ dev_err(dev, "Flush mode clear failed: %d\n", ret);
+ goto err_host_deinit;
+ }
+
+ qcom_pcie_host_deinit(pp);
+
+ ret = qcom_pcie_host_init(pp);
+ if (ret) {
+ dev_err(dev, "Host init failed\n");
+ return ret;
+ }
+
+ ret = dw_pcie_setup_rc(pp);
+ if (ret)
+ goto err_host_deinit;
+
+ /*
+ * Re-enable global IRQ events as the PARF_INT_ALL_MASK register is
+ * non-sticky.
+ */
+ if (pcie->global_irq)
+ writel_relaxed(PARF_INT_ALL_LINK_DOWN | PARF_INT_MSI_DEV_0_7,
+ pcie->parf + PARF_INT_ALL_MASK);
+
+ qcom_pcie_start_link(pci);
+ dw_pcie_wait_for_link(pci);
+
+ dev_dbg(dev, "Root Port reset completed\n");
+
+ return 0;
+
+err_host_deinit:
+ qcom_pcie_host_deinit(pp);
+
+ return ret;
+}
+
static int qcom_pcie_link_transition_count(struct seq_file *s, void *data)
{
struct qcom_pcie *pcie = (struct qcom_pcie *)dev_get_drvdata(s->private);
@@ -1650,6 +1742,27 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
qcom_pcie_link_transition_count);
}
+static irqreturn_t qcom_pcie_global_irq_thread(int irq, void *data)
+{
+ struct qcom_pcie *pcie = data;
+ struct dw_pcie_rp *pp = &pcie->pci->pp;
+ struct device *dev = pcie->pci->dev;
+ struct pci_dev *port;
+ unsigned long status = readl_relaxed(pcie->parf + PARF_INT_ALL_STATUS);
+
+ writel_relaxed(status, pcie->parf + PARF_INT_ALL_CLEAR);
+
+ if (test_and_clear_bit(INT_ALL_LINK_DOWN, &status)) {
+ dev_dbg(dev, "Received Link down event\n");
+ for_each_pci_bridge(port, pp->bridge->bus) {
+ if (pci_pcie_type(port) == PCI_EXP_TYPE_ROOT_PORT)
+ pci_host_handle_link_down(port);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
static void qcom_pci_free_msi(void *ptr)
{
struct dw_pcie_rp *pp = (struct dw_pcie_rp *)ptr;
@@ -1852,7 +1965,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
struct dw_pcie_rp *pp;
struct resource *res;
struct dw_pcie *pci;
- int ret;
+ int ret, irq;
pcie_cfg = of_device_get_match_data(dev);
if (!pcie_cfg) {
@@ -2009,6 +2122,32 @@ static int qcom_pcie_probe(struct platform_device *pdev)
goto err_phy_exit;
}
+ irq = platform_get_irq_byname_optional(pdev, "global");
+ if (irq > 0) {
+ const char *name;
+
+ name = devm_kasprintf(dev, GFP_KERNEL, "qcom_pcie_global_irq%d",
+ pci_domain_nr(pp->bridge->bus));
+ if (!name) {
+ ret = -ENOMEM;
+ goto err_host_deinit;
+ }
+
+ ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+ qcom_pcie_global_irq_thread,
+ IRQF_ONESHOT, name, pcie);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret,
+ "Failed to request Global IRQ\n");
+ goto err_host_deinit;
+ }
+
+ writel_relaxed(PARF_INT_ALL_LINK_DOWN | PARF_INT_MSI_DEV_0_7,
+ pcie->parf + PARF_INT_ALL_MASK);
+
+ pcie->global_irq = irq;
+ }
+
qcom_pcie_icc_opp_update(pcie);
if (pcie->mhi)
@@ -2016,6 +2155,8 @@ static int qcom_pcie_probe(struct platform_device *pdev)
return 0;
+err_host_deinit:
+ dw_pcie_host_deinit(pp);
err_phy_exit:
list_for_each_entry_safe(port, tmp_port, &pcie->ports, list) {
list_for_each_entry_safe(perst, tmp_perst, &port->perst, list)
--
2.48.1
^ permalink raw reply related
* [PATCH v8 0/5] PCI: Add support for resetting the Root Ports in a platform specific way
From: Manivannan Sadhasivam via B4 Relay @ 2026-05-18 14:59 UTC (permalink / raw)
To: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Niklas Cassel, Wilfred Mallawa,
Krishna Chaitanya Chundru, mani, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding, Manivannan Sadhasivam, Frank Li,
Manivannan Sadhasivam
Hi,
Currently, in the event of AER/DPC, PCI core will try to reset the slot (Root
Port) and its subordinate devices by invoking bridge control reset and FLR. But
in some cases like AER Fatal error, it might be necessary to reset the Root
Ports using the PCI host bridge drivers in a platform specific way (as indicated
by the TODO in the pcie_do_recovery() function in drivers/pci/pcie/err.c).
Otherwise, the PCI link won't be recovered successfully.
So this series adds a new callback 'pci_host_bridge::reset_root_port' for the
host bridge drivers to reset the Root Port when a fatal error happens.
Also, this series allows the host bridge drivers to handle PCI link down event
by resetting the Root Ports and recovering the bus. This is accomplished by the
help of the new 'pci_host_handle_link_down()' API. Host bridge drivers are
expected to call this API (preferrably from a threaded IRQ handler) with
relevant Root Port 'pci_dev' when a link down event is detected for the port.
The API will reuse the pcie_do_recovery() function to recover the link if AER
support is enabled, otherwise it will directly call the reset_root_port()
callback of the host bridge driver (if exists).
For reference, I've modified the pcie-qcom driver to call
pci_host_handle_link_down() API with Root Port 'pci_dev' after receiving the
LDn global_irq event and populated 'pci_host_bridge::reset_root_port()'
callback to reset the Root Ports.
Testing
-------
Tested on Qcom Lemans AU Ride platform with Host and EP SoCs connected over PCIe
link. Simulated the LDn by disabling LTSSM_EN on the EP and I could verify that
the link was getting recovered successfully.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Changes in v8:
- Removed pci_save_state() for the Root Port during recovery as the PCI core now
saves the config space during enumeration
- Added save/restore in pci_endpoint_test.c driver to save the config space
after enabling BME and restoring it after reset
- Added a patch to unmap MSI address post LDn
- Rebased on top of v7.1-rc1
- Link to v7: https://lore.kernel.org/r/20260310-pci-port-reset-v7-0-9dd00ccc25ab@oss.qualcomm.com
Changes in v7:
- Dropped Rockchip Root port reset patch due to reported issues. But the series
works on other platforms as tested by others.
- Added pci_{lock/unlock}_rescan_remove() to guard pci_bus_error_reset() as the
device could be removed in-between due to Native hotplug interrupt.
- Rebased on top of v7.0-rc1
- Link to v6: https://lore.kernel.org/r/20250715-pci-port-reset-v6-0-6f9cce94e7bb@oss.qualcomm.com
Changes in v6:
- Incorporated the patch: https://lore.kernel.org/all/20250524185304.26698-2-manivannan.sadhasivam@linaro.org/
- Link to v5: https://lore.kernel.org/r/20250715-pci-port-reset-v5-0-26a5d278db40@oss.qualcomm.com
Changes in v5:
* Reworked the pci_host_handle_link_down() to accept Root Port instead of
resetting all Root Ports in the event of link down.
* Renamed 'reset_slot' to 'reset_root_port' to avoid confusion as both terms
were used interchangibly and the series is intended to reset Root Port only.
* Added the Rockchip driver change to this series.
* Dropped the applied patches and review/tested tags due to rework.
* Rebased on top of v6.16-rc1.
Changes in v4:
- Handled link down first in the irq handler
- Updated ICC & OPP bandwidth after link up in reset_slot() callback
- Link to v3: https://lore.kernel.org/r/20250417-pcie-reset-slot-v3-0-59a10811c962@linaro.org
Changes in v3:
- Made the pci-host-common driver as a common library for host controller
drivers
- Moved the reset slot code to pci-host-common library
- Link to v2: https://lore.kernel.org/r/20250416-pcie-reset-slot-v2-0-efe76b278c10@linaro.org
Changes in v2:
- Moved calling reset_slot() callback from pcie_do_recovery() to pcibios_reset_secondary_bus()
- Link to v1: https://lore.kernel.org/r/20250404-pcie-reset-slot-v1-0-98952918bf90@linaro.org
---
Manivannan Sadhasivam (5):
PCI: dwc: ep: Clear MSI iATU mapping in dw_pcie_ep_cleanup()
PCI/ERR: Add support for resetting the Root Ports in a platform specific way
PCI: host-common: Add link down handling for Root Ports
PCI: qcom: Add support for resetting the Root Port due to link down event
misc: pci_endpoint_test: Add AER error handlers
drivers/misc/pci_endpoint_test.c | 23 ++++
drivers/pci/controller/dwc/pcie-designware-ep.c | 5 +
drivers/pci/controller/dwc/pcie-qcom.c | 143 +++++++++++++++++++++++-
drivers/pci/controller/pci-host-common.c | 35 ++++++
drivers/pci/controller/pci-host-common.h | 1 +
drivers/pci/pci.c | 14 +++
drivers/pci/pcie/err.c | 6 +-
include/linux/pci.h | 1 +
8 files changed, 222 insertions(+), 6 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20250715-pci-port-reset-4d9519570123
Best regards,
--
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v8 5/5] misc: pci_endpoint_test: Add AER error handlers
From: Manivannan Sadhasivam via B4 Relay @ 2026-05-18 14:59 UTC (permalink / raw)
To: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Niklas Cassel, Wilfred Mallawa,
Krishna Chaitanya Chundru, mani, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding, Manivannan Sadhasivam
In-Reply-To: <20260518-pci-port-reset-v8-0-eb5a7d331dfc@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
This Endpoint test driver doesn't need to do anything fancy in its error
handlers, but just restore the config space that was saved during probe and
report the correct result. This helps in making sure that the AER recovery
succeeds.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/misc/pci_endpoint_test.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index dbd017cabbb9..3e89bd48c196 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -1327,6 +1327,8 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
goto err_kfree_name;
}
+ pci_save_state(pdev);
+
return 0;
err_kfree_name:
@@ -1448,12 +1450,33 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
+static pci_ers_result_t pci_endpoint_test_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
+{
+ if (state == pci_channel_io_perm_failure)
+ return PCI_ERS_RESULT_DISCONNECT;
+
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+static pci_ers_result_t pci_endpoint_test_slot_reset(struct pci_dev *pdev)
+{
+ pci_restore_state(pdev);
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+static const struct pci_error_handlers pci_endpoint_test_err_handler = {
+ .error_detected = pci_endpoint_test_error_detected,
+ .slot_reset = pci_endpoint_test_slot_reset,
+};
+
static struct pci_driver pci_endpoint_test_driver = {
.name = DRV_MODULE_NAME,
.id_table = pci_endpoint_test_tbl,
.probe = pci_endpoint_test_probe,
.remove = pci_endpoint_test_remove,
.sriov_configure = pci_sriov_configure_simple,
+ .err_handler = &pci_endpoint_test_err_handler,
};
module_pci_driver(pci_endpoint_test_driver);
--
2.48.1
^ permalink raw reply related
* [PATCH v8 3/5] PCI: host-common: Add link down handling for Root Ports
From: Manivannan Sadhasivam via B4 Relay @ 2026-05-18 14:59 UTC (permalink / raw)
To: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Niklas Cassel, Wilfred Mallawa,
Krishna Chaitanya Chundru, mani, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding, Manivannan Sadhasivam, Frank Li,
Manivannan Sadhasivam
In-Reply-To: <20260518-pci-port-reset-v8-0-eb5a7d331dfc@oss.qualcomm.com>
From: Manivannan Sadhasivam <mani@kernel.org>
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
for a specific Root Port when the link goes down.
The API accepts the 'pci_dev' corresponding to the Root Port which observed
the link down event. If CONFIG_PCIEAER is enabled, the API calls
pcie_do_recovery() function with 'pci_channel_io_frozen' as the state. This
will result in the execution of the AER Fatal error handling code. Since
the link down recovery is pretty much the same as AER Fatal error handling,
pcie_do_recovery() helper is reused here. First, the AER error_detected()
callback will be triggered for the bridge and then for the downstream
devices. Finally, pci_host_reset_root_port() will be called for the Root
Port, which will reset the Root Port using 'reset_root_port' callback to
recover the link. Once that's done, resume message will be broadcasted to
the bridge and the downstream devices, indicating successful link recovery.
But if CONFIG_PCIEAER is not enabled in the kernel, only
pci_host_reset_root_port() API will be called, which will in turn call
pci_bus_error_reset() to just reset the Root Port as there is no way we
could inform the drivers about link recovery.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Tested-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/pci/controller/pci-host-common.c | 35 ++++++++++++++++++++++++++++++++
drivers/pci/controller/pci-host-common.h | 1 +
drivers/pci/pci.c | 1 +
drivers/pci/pcie/err.c | 1 +
4 files changed, 38 insertions(+)
diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
index d6258c1cffe5..15ebff8a542a 100644
--- a/drivers/pci/controller/pci-host-common.c
+++ b/drivers/pci/controller/pci-host-common.c
@@ -12,9 +12,11 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
+#include <linux/pci.h>
#include <linux/pci-ecam.h>
#include <linux/platform_device.h>
+#include "../pci.h"
#include "pci-host-common.h"
static void gen_pci_unmap_cfg(void *ptr)
@@ -106,5 +108,38 @@ void pci_host_common_remove(struct platform_device *pdev)
}
EXPORT_SYMBOL_GPL(pci_host_common_remove);
+static pci_ers_result_t pci_host_reset_root_port(struct pci_dev *dev)
+{
+ int ret;
+
+ pci_lock_rescan_remove();
+ ret = pci_bus_error_reset(dev);
+ pci_unlock_rescan_remove();
+ if (ret) {
+ pci_err(dev, "Failed to reset Root Port: %d\n", ret);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_info(dev, "Root Port has been reset\n");
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+static void pci_host_recover_root_port(struct pci_dev *port)
+{
+#if IS_ENABLED(CONFIG_PCIEAER)
+ pcie_do_recovery(port, pci_channel_io_frozen, pci_host_reset_root_port);
+#else
+ pci_host_reset_root_port(port);
+#endif
+}
+
+void pci_host_handle_link_down(struct pci_dev *port)
+{
+ pci_info(port, "Recovering Root Port due to Link Down\n");
+ pci_host_recover_root_port(port);
+}
+EXPORT_SYMBOL_GPL(pci_host_handle_link_down);
+
MODULE_DESCRIPTION("Common library for PCI host controller drivers");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/pci/controller/pci-host-common.h b/drivers/pci/controller/pci-host-common.h
index b5075d4bd7eb..dd12dd1a1b23 100644
--- a/drivers/pci/controller/pci-host-common.h
+++ b/drivers/pci/controller/pci-host-common.h
@@ -17,6 +17,7 @@ int pci_host_common_init(struct platform_device *pdev,
struct pci_host_bridge *bridge,
const struct pci_ecam_ops *ops);
void pci_host_common_remove(struct platform_device *pdev);
+void pci_host_handle_link_down(struct pci_dev *port);
struct pci_config_window *pci_host_common_ecam_create(struct device *dev,
struct pci_host_bridge *bridge, const struct pci_ecam_ops *ops);
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 651505b3bd60..35dc9f54a8ef 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5669,6 +5669,7 @@ int pci_bus_error_reset(struct pci_dev *bridge)
{
return pci_reset_bridge(bridge, PCI_RESET_NO_RESTORE);
}
+EXPORT_SYMBOL_GPL(pci_bus_error_reset);
int pci_try_reset_bridge(struct pci_dev *bridge)
{
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 13b9d9eb714f..d77403d8855b 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -292,3 +292,4 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
return status;
}
+EXPORT_SYMBOL_GPL(pcie_do_recovery);
--
2.48.1
^ permalink raw reply related
* [PATCH v8 2/5] PCI/ERR: Add support for resetting the Root Ports in a platform specific way
From: Manivannan Sadhasivam via B4 Relay @ 2026-05-18 14:59 UTC (permalink / raw)
To: Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel
Cc: linux-pci, linux-kernel, linuxppc-dev, linux-arm-kernel,
linux-arm-msm, linux-rockchip, Niklas Cassel, Wilfred Mallawa,
Krishna Chaitanya Chundru, mani, Lukas Wunner, Richard Zhu,
Brian Norris, Wilson Ding, Manivannan Sadhasivam, Frank Li,
Manivannan Sadhasivam
In-Reply-To: <20260518-pci-port-reset-v8-0-eb5a7d331dfc@oss.qualcomm.com>
From: Manivannan Sadhasivam <mani@kernel.org>
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() if available. Also,
save the Root Port config space before reset and restore it afterwards.
The 'reset_root_port' callback is responsible for resetting the given Root
Port referenced by the 'pci_dev' pointer in a platform specific way and
bring it back to the working state if possible. If any error occurs during
the reset operation, relevant errno should be returned.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Tested-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/pci/pci.c | 13 +++++++++++++
drivers/pci/pcie/err.c | 5 -----
include/linux/pci.h | 1 +
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8f7cfcc00090..651505b3bd60 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4809,6 +4809,19 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
{
+ struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+ int ret;
+
+ if (pci_is_root_bus(dev->bus) && host->reset_root_port) {
+ ret = host->reset_root_port(host, dev);
+ if (ret)
+ pci_err(dev, "Failed to reset Root Port: %d\n", ret);
+ else
+ pci_restore_state(dev);
+
+ return;
+ }
+
pci_reset_secondary_bus(dev);
}
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index bebe4bc111d7..13b9d9eb714f 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -256,11 +256,6 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
}
if (status == PCI_ERS_RESULT_NEED_RESET) {
- /*
- * TODO: Should call platform-specific
- * functions to reset slot before calling
- * drivers' slot_reset callbacks?
- */
status = PCI_ERS_RESULT_RECOVERED;
pci_dbg(bridge, "broadcast slot_reset message\n");
pci_walk_bridge(bridge, report_slot_reset, &status);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..439dbd0d9184 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -646,6 +646,7 @@ struct pci_host_bridge {
void (*release_fn)(struct pci_host_bridge *);
int (*enable_device)(struct pci_host_bridge *bridge, struct pci_dev *dev);
void (*disable_device)(struct pci_host_bridge *bridge, struct pci_dev *dev);
+ int (*reset_root_port)(struct pci_host_bridge *bridge, struct pci_dev *dev);
void *release_data;
unsigned int ignore_reset_delay:1; /* For entire hierarchy */
unsigned int no_ext_tags:1; /* No Extended Tags */
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-18 15:01 UTC (permalink / raw)
To: Shenwei Wang, Mathieu Poirier
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Andrew Lunn,
Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <PAXPR04MB918587A8812B51BBB2A46A2C89032@PAXPR04MB9185.eurprd04.prod.outlook.com>
On 5/18/2026 9:24 AM, Shenwei Wang wrote:
>
>
>
>>
>> On Thu, May 07, 2026 at 07:43:33PM +0000, Shenwei Wang wrote:
>>>
>>>
>>>> That was my initial approach. We don't even need an additional
>>>> "rpmsg-io-*" in rpmsg_gpio_channel_id_table[]. All we need is:
>>>>
>>>> /* rpmsg devices and drivers are matched using the service name */
>>>> static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
>>>> const struct rpmsg_device_id *id) {
>>>> + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
>>>>
>>>> - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
>>>> + return strncmp(id->name, rpdev->id.name, len) == 0;
>>>> }
>>>>
>>>
>>> If we encode the port index directly into ept->src, for example:
>>>
>>> ept->src = (baseaddr << 8) | port_index;
>>>
>>
>> There is no rpmsg_endpoint::src. You likely meant ept->addr. This would work
>> but not optimal on two front:
>>
>> (1) rpms_endpoint::addr is a u32 and idr_alloc() returns an 'int'. As such there is a
>> possibility of conflict. I concede the possibility is marginal, but it still exists.
>>
>
> I think there may be a misunderstanding in the implementation. In this case, we do not
> need the return value from idr_alloc.
>
> When the driver calls rpmsg_create_ept, it can pass an rpmsg_channel_info structure as an
> input parameter. This allows you to specify the source address you want to bind.
> Please refer to the definitions below:
>
> struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
> rpmsg_rx_cb_t cb, void *priv,
> struct rpmsg_channel_info chinfo)
>
> struct rpmsg_channel_info {
> char name[RPMSG_NAME_SIZE];
> u32 src;
> u32 dst;
> };
>
>> (2) By proceeding this way, the kernel exposes the GPIO controller it knows
>> about. It is preferrable to have the remote processor tell the kernel about the
>> GPIO controller it wants.
>>
>
> If everyone agrees with this namespace announcement approach, I will prepare the
> next revision based on it, even though it is not as clean as the source address encoding solution.
>
I have ack on the namespace announcement approach. To me it is very
simple contract between the firmware and the Linux which allows dynamic
endpoint allocation without giving up security concerns. Also this
approach can be easily extended for any other rpmsg devices like i2c,
spi etc.. With the fix in the rpmsg_core.c, this will work. I will have
to see the actual implementation in the next rev to provide further
feedback.
Thanks,
Tanmay
> Shenwei
>
>> I am done reviewing this revision. Given the amount of refactoring needed, I will
>> not look at the code. Please refer to this reply [1] for what I am expecting in the
>> next revision.
>>
>
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Alexander Sverdlin @ 2026-05-18 15:04 UTC (permalink / raw)
To: Paul Kocialkowski; +Cc: linux-sunxi, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <agsohFpjuGqRRDO-@collins>
Paul,
On Mon, 2026-05-18 at 16:56 +0200, Paul Kocialkowski wrote:
> I also have the 7" LVDS LCD that goes with it, which was supported by
> Parthiban's initial series (but needs rework, and it seems that he's
> unlikely to do it). I also have the 5" MIPI LCD but it's less likely
> that it will be supported, although I have seen dirty patches to make
> some other MIPI panel work with A133.
>
> We'll need PWM for it which should be a follow-up to the current H616
> PWM series from Richard Genoud.
I didn't have video in my mind, but...
> Other than that there is a PCF8563TS RTC on the board, audio stuff:
> speaker (which I have) mic and headphones and a GPIO beeper which could
> be added.
... would be happy to work on higher quality audio I/O support after
we get the base merged...
> Do you have other A133 boards that you're interested in?
> I also have:
> - KICKPI K5C
> - DshanPi-R818
> - Logicom La Tab 129
> - Trimui Brick
thanks! I'll try to concentrate on the SzBaijie Core/Helper boards
I have for now.
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v14 0/8] arm64: add ARCH_HAS_COPY_MC support
From: Kefeng Wang @ 2026-05-18 15:05 UTC (permalink / raw)
To: Ruidong Tian, catalin.marinas, will, rafael, tony.luck, guohanjun,
mchehab, xueshuai, tongtiangen, james.morse, robin.murphy,
andreyknvl, dvyukov, vincenzo.frascino, mpe, npiggin,
ryabinin.a.a, glider, christophe.leroy, aneesh.kumar,
naveen.n.rao, tglx, mingo
Cc: linux-arm-kernel, linux-mm, linuxppc-dev, linux-kernel, kasan-dev
In-Reply-To: <20260518084956.2538442-1-tianruidong@linux.alibaba.com>
On 5/18/2026 4:49 PM, Ruidong Tian wrote:
> This series continues Tong Tiangen's work on arm64 ARCH_HAS_COPY_MC
> support. We encounter the same problem, and from a forward-looking
> perspective, large-memory ARM machines such as Grace and Vera will suffer
> more from this class of issues, which motivates us to push this feature
> upstream.
>
> Problem
> =========
> With the increase of memory capacity and density, the probability of memory
> error also increases. The increasing size and density of server RAM in data
> centers and clouds have shown increased uncorrectable memory errors.
>
> Currently, more and more scenarios that can tolerate memory errors, such as
> COW[1,2], KSM copy[3], coredump copy[4], khugepaged[5,6], uaccess copy[7],
> etc.
We have encountered more scenarios and have made more enhancements, eg,
658be46520ce mm: support poison recovery from copy_present_page()
aa549f923f5e mm: support poison recovery from do_cow_fault()
f00b295b9b61 fs: hugetlbfs: support poisoned recover from
hugetlbfs_migrate_folio()
060913999d7a mm: migrate: support poisoned recover from migrate folio
Hope that the architecture-related sections can receive relevant reviews
and responses.
Thanks.
> Solution
> =========
>
> This patchset introduces a new processing framework on ARM64, which enables
> ARM64 to support error recovery in the above scenarios, and more scenarios
> can be expanded based on this in the future.
>
> In arm64, memory error handling in do_sea(), which is divided into two cases:
> 1. If the user state consumed the memory errors, the solution is to kill
> the user process and isolate the error page.
> 2. If the kernel state consumed the memory errors, the solution is to
> panic.
>
> For case 2, Undifferentiated panic may not be the optimal choice, as it can
> be handled better. In some scenarios, we can avoid panic, such as uaccess,
> if the uaccess fails due to memory error, only the user process will be
> affected, returning an error to the caller and isolating the user page with
> hardware memory errors is a better choice.
>
> [1] commit d302c2398ba2 ("mm, hwpoison: when copy-on-write hits poison, take page offline")
> [2] commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults")
> [3] commit 6b970599e807 ("mm: hwpoison: support recovery from ksm_might_need_to_copy()")
> [4] commit 245f09226893 ("mm: hwpoison: coredump: support recovery from dump_user_range()")
> [5] commit 98c76c9f1ef7 ("mm/khugepaged: recover from poisoned anonymous memory")
> [6] commit 12904d953364 ("mm/khugepaged: recover from poisoned file-backed memory")
> [7] commit 278b917f8cb9 ("x86/mce: Add _ASM_EXTABLE_CPY for copy user access")
>
> ------------------
> Test result:
>
> Tested on Kunpeng 920.
>
> 1. copy_page(), copy_mc_page() basic function test pass, and the disassembly
> contents remains the same before and after refactor.
>
> 2. copy_to/from_user() access kernel NULL pointer raise translation fault
> and dump error message then die(), test pass.
>
> 3. Test following scenarios: copy_from_user(), get_user(), COW.
>
> Before patched: trigger a hardware memory error then panic.
> After patched: trigger a hardware memory error without panic.
>
> Testing step:
> step1. start an user-process.
> step2. poison(einj) the user-process's page.
> step3: user-process access the poison page in kernel mode, then trigger SEA.
> step4: the kernel will not panic, only the user process is killed, the poison
> page is isolated. (before patched, the kernel will panic in do_sea())
>
> The above tests can also be reproduced using ras-tools, which provides
> einj-based injection and validation for uaccess and COW scenarios.
> Example usage:
>
> einj_mem_uc futex # get_user
> einj_mem_uc copyin # copy_to_user
> einj_mem_uc copy-on-write # COW
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/aegl/ras-tools.git
>
> ------------------
>
> Benefits
> =========
> According to Huawei's statistics from their storage products, memory errors
> triggered in kernel-mode by COW and page cache read (uaccess) scenarios
> account for more than 50%. With this patchset deployed, all kernel panics
> caused by COW and page cache memory errors are eliminated.
> Alibaba Cloud has also observed memory errors occurring in uaccess contexts.
>
> Since V13:
> 1. Changed MC-safe functions to return an error rather than kill the user
> process. When a user program invokes a syscall and the kernel encounters
> a memory error during uaccess, killing the process is unexpected; the
> syscall should return an error.
> 2. Added FEAT_MOPS support for the copy_page_mc paths.
> 3. Refactored copy_page() and memcpy() on top of the shared memcpy_template,
> reducing duplicated assembly code.
>
> Since v12:
> Thanks to the suggestions of Jonathan, Mark, and Mauro, the following modifications
> are made:
> 1. Rebase to latest kernel version.
> 2. Patch1, add Jonathan's and Mauro's review-by.
> 3. Patch2, modified do_apei_claim_sea() according to Mark's and Jonathan's suggestions,
> and optimized the commit message according to Mark's suggestions(Added description of
> the impact on regular copy_to_user()).
> 4. Patch3, optimized the commit message according to Mauro's suggestions and add Jonathan's
> review-by.
> 5. Patch4, modified copy_mc_user_highpage() and Optimized the commit message according to
> Jonathan's suggestions(no functional changes).
> 6. Patch5, optimized the commit message according to Mauro's suggestions.
> 7. Patch4/5, FEAT_MOPS is added to the code logic. Currently, the fixup is not performed
> on the MOPS instruction.
> 8. Remove patch6 in v12 according to Jonathan's suggestions.
>
> Since v11:
> 1. Rebase to latest kernel version 6.9-rc1.
> 2. Add patch 5, Since the problem described in "Since V10 Besides 3" has
> been solved in a50026bdb867 ('iov_iter: get rid of 'copy_mc' flag').
> 3. Add the benefit of applying the patch set to our company to the description of patch0.
>
> Since V10:
> Accroding Mark's suggestion:
> 1. Merge V10's patch2 and patch3 to V11's patch2.
> 2. Patch2(V11): use new fixup_type for ld* in copy_to_user(), fix fatal
> issues (NULL kernel pointeraccess) been fixup incorrectly.
> 3. Patch2(V11): refactoring the logic of do_sea().
> 4. Patch4(V11): Remove duplicate assembly logic and remove do_mte().
>
> Besides:
> 1. Patch2(V11): remove st* insn's fixup, st* generally not trigger memory error.
> 2. Split a part of the logic of patch2(V11) to patch5(V11), for detail,
> see patch5(V11)'s commit msg.
> 3. Remove patch6(v10) “arm64: introduce copy_mc_to_kernel() implementation”.
> During modification, some problems that cannot be solved in a short
> period are found. The patch will be released after the problems are
> solved.
> 4. Add test result in this patch.
> 5. Modify patchset title, do not use machine check and remove "-next".
>
> Since V9:
> 1. Rebase to latest kernel version 6.8-rc2.
> 2. Add patch 6/6 to support copy_mc_to_kernel().
>
> Since V8:
> 1. Rebase to latest kernel version and fix topo in some of the patches.
> 2. According to the suggestion of Catalin, I attempted to modify the
> return value of function copy_mc_[user]_highpage() to bytes not copied.
> During the modification process, I found that it would be more
> reasonable to return -EFAULT when copy error occurs (referring to the
> newly added patch 4).
>
> For ARM64, the implementation of copy_mc_[user]_highpage() needs to
> consider MTE. Considering the scenario where data copying is successful
> but the MTE tag copying fails, it is also not reasonable to return
> bytes not copied.
> 3. Considering the recent addition of machine check safe support for
> multiple scenarios, modify commit message for patch 5 (patch 4 for V8).
>
> Since V7:
> Currently, there are patches supporting recover from poison
> consumption for the cow scenario[1]. Therefore, Supporting cow
> scenario under the arm64 architecture only needs to modify the relevant
> code under the arch/.
> [1]https://lore.kernel.org/lkml/20221031201029.102123-1-tony.luck@intel.com/
>
> Since V6:
> Resend patches that are not merged into the mainline in V6.
>
> Since V5:
> 1. Add patch2/3 to add uaccess assembly helpers.
> 2. Optimize the implementation logic of arm64_do_kernel_sea() in patch8.
> 3. Remove kernel access fixup in patch9.
> All suggestion are from Mark.
>
> Since V4:
> 1. According Michael's suggestion, add patch5.
> 2. According Mark's suggestiog, do some restructuring to arm64
> extable, then a new adaptation of machine check safe support is made based
> on this.
> 3. According Mark's suggestion, support machine check safe in do_mte() in
> cow scene.
> 4. In V4, two patches have been merged into -next, so V5 not send these
> two patches.
>
> Since V3:
> 1. According to Robin's suggestion, direct modify user_ldst and
> user_ldp in asm-uaccess.h and modify mte.S.
> 2. Add new macro USER_MC in asm-uaccess.h, used in copy_from_user.S
> and copy_to_user.S.
> 3. According to Robin's suggestion, using micro in copy_page_mc.S to
> simplify code.
> 4. According to KeFeng's suggestion, modify powerpc code in patch1.
> 5. According to KeFeng's suggestion, modify mm/extable.c and some code
> optimization.
>
> Since V2:
> 1. According to Mark's suggestion, all uaccess can be recovered due to
> memory error.
> 2. Scenario pagecache reading is also supported as part of uaccess
> (copy_to_user()) and duplication code problem is also solved.
> Thanks for Robin's suggestion.
> 3. According Mark's suggestion, update commit message of patch 2/5.
> 4. According Borisllav's suggestion, update commit message of patch 1/5.
>
> Since V1:
> 1.Consistent with PPC/x86, Using CONFIG_ARCH_HAS_COPY_MC instead of
> ARM64_UCE_KERNEL_RECOVERY.
> 2.Add two new scenes, cow and pagecache reading.
> 3.Fix two small bug(the first two patch).
>
> V1 in here:
> https://lore.kernel.org/lkml/20220323033705.3966643-1-tongtiangen@huawei.com/
>
> Ruidong Tian (3):
> ACPI: APEI: GHES: use exception context to gate SIGBUS on poison
> consumption
> lib/test: memcpy_kunit: add copy_page() and copy_mc_page() tests
> lib/tests: memcpy_kunit: add memcpy_mc() and memcpy_mc_large() test
>
> Tong Tiangen (5):
> uaccess: add generic fallback version of copy_mc_to_user()
> arm64: add support for ARCH_HAS_COPY_MC
> mm/hwpoison: return -EFAULT when copy fail in
> copy_mc_[user]_highpage()
> arm64: support copy_mc_[user]_highpage()
> arm64: introduce copy_mc_to_kernel() implementation
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/asm-extable.h | 22 ++-
> arch/arm64/include/asm/asm-uaccess.h | 4 +
> arch/arm64/include/asm/extable.h | 1 +
> arch/arm64/include/asm/mte.h | 9 +
> arch/arm64/include/asm/page.h | 10 ++
> arch/arm64/include/asm/string.h | 5 +
> arch/arm64/include/asm/uaccess.h | 17 ++
> arch/arm64/kernel/acpi.c | 2 +-
> arch/arm64/lib/Makefile | 2 +
> arch/arm64/lib/copy_mc_page.S | 44 +++++
> arch/arm64/lib/copy_page.S | 62 +------
> arch/arm64/lib/copy_page_template.S | 71 ++++++++
> arch/arm64/lib/copy_to_user.S | 10 +-
> arch/arm64/lib/memcpy.S | 253 ++-------------------------
> arch/arm64/lib/memcpy_mc.S | 56 ++++++
> arch/arm64/lib/memcpy_template.S | 249 ++++++++++++++++++++++++++
> arch/arm64/lib/mte.S | 29 +++
> arch/arm64/mm/copypage.c | 75 ++++++++
> arch/arm64/mm/extable.c | 21 +++
> arch/arm64/mm/fault.c | 30 +++-
> arch/powerpc/include/asm/uaccess.h | 1 +
> arch/x86/include/asm/uaccess.h | 1 +
> drivers/acpi/apei/ghes.c | 36 ++--
> include/acpi/ghes.h | 6 +-
> include/linux/highmem.h | 16 +-
> include/linux/uaccess.h | 8 +
> lib/tests/memcpy_kunit.c | 178 ++++++++++++++++++-
> mm/kasan/shadow.c | 12 ++
> mm/khugepaged.c | 4 +-
> 30 files changed, 904 insertions(+), 331 deletions(-)
> create mode 100644 arch/arm64/lib/copy_mc_page.S
> create mode 100644 arch/arm64/lib/copy_page_template.S
> create mode 100644 arch/arm64/lib/memcpy_mc.S
> create mode 100644 arch/arm64/lib/memcpy_template.S
>
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding
From: Will Deacon @ 2026-05-18 15:06 UTC (permalink / raw)
To: Fredrik Markstrom
Cc: Catalin Marinas, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Santosh Shilimkar, Olof Johansson, Tony Lindgren,
linux-arm-kernel, linux-kernel, linux-kselftest, linux-perf-users,
Nicolas Pitre, Ivar Holmqvist, Malin Jonsson
In-Reply-To: <20260430-master-with-pfix-v3-v2-0-bd526ec04a75@est.tech>
On Thu, Apr 30, 2026 at 12:55:12PM +0200, Fredrik Markstrom wrote:
> Perf callchain unwinding follows userspace frame pointers via
> copy_from_user. A corrupted or malicious frame pointer can point
> into device I/O memory mapped into the process (e.g. via UIO or
> /dev/mem), causing the kernel to read from MMIO regions in PMU
> interrupt context. Such reads can have side effects on hardware
> (clearing status registers, advancing FIFOs, triggering DMA) and
> on arm64 can produce a synchronous external abort that panics the
> kernel.
Hmm, but why is unwinding special in this case? If userspace has access
to sensitive MMIO/device mappings, it can presumably pass them to
syscalls and trigger crashes all over the place?
Will
^ permalink raw reply
* [PATCH v2 0/2] arm64: Implement support for 2025 dpISA extensions
From: Mark Brown @ 2026-05-18 15:07 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, linux-doc, linux-kselftest,
Mark Brown
The 2025 dpISA extensions introduce a number of architecture features
all of which are fairly straightforward from a kernel point of view
since they only introduce new instructions, not any architecture state.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Changes in v2:
- Rename HWCAP3_LUT6 to HWCAP3_SVE_LUT6 and make it depend on SVE.
- Rebase onto v7.1-rc3.
- Link to v1: https://patch.msgid.link/20260302-arm64-dpisa-2025-v1-0-0855e7f41689@kernel.org
---
Mark Brown (2):
arm64/cpufeature: Define hwcaps for 2025 dpISA features
kselftest/arm64: Add 2025 dpISA coverage to hwcaps
Documentation/arch/arm64/elf_hwcaps.rst | 24 +++++++
arch/arm64/include/uapi/asm/hwcap.h | 8 +++
arch/arm64/kernel/cpufeature.c | 11 +++
arch/arm64/kernel/cpuinfo.c | 8 +++
tools/testing/selftests/arm64/abi/hwcap.c | 116 ++++++++++++++++++++++++++++++
5 files changed, 167 insertions(+)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260106-arm64-dpisa-2025-d6673ae6acee
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply
* [PATCH v2 1/2] arm64/cpufeature: Define hwcaps for 2025 dpISA features
From: Mark Brown @ 2026-05-18 15:07 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, linux-doc, linux-kselftest,
Mark Brown
In-Reply-To: <20260518-arm64-dpisa-2025-v2-0-b3367b73bd00@kernel.org>
The features added by the 2025 dpISA are all straightforward instruction
only features so there is no state to manage, we can just expose hwcaps to
let userspace know they are available.
F16MM is slightly odd in that the feature is FEAT_F16MM but it is discovered
via ID_AA64FPFR0_EL1.F16MM2. We follow the feature name.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/arch/arm64/elf_hwcaps.rst | 24 ++++++++++++++++++++++++
arch/arm64/include/uapi/asm/hwcap.h | 8 ++++++++
arch/arm64/kernel/cpufeature.c | 11 +++++++++++
arch/arm64/kernel/cpuinfo.c | 8 ++++++++
4 files changed, 51 insertions(+)
diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
index 97315ae6c0da..07ff9ea1d605 100644
--- a/Documentation/arch/arm64/elf_hwcaps.rst
+++ b/Documentation/arch/arm64/elf_hwcaps.rst
@@ -451,6 +451,30 @@ HWCAP3_LS64
of CPU. User should only use ld64b/st64b on supported target (device)
memory location, otherwise fallback to the non-atomic alternatives.
+HWCAP3_SVE_B16MM
+ Functionality implied by ID_AA64ZFR0_EL1.B16B16 == 0b0011
+
+HWCAP3_SVE2P3
+ Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0100
+
+HWCAP3_SME_LUT6
+ Functionality implied by ID_AA64SMFR0_EL1.LUT6 == 0b1
+
+HWCAP3_SME2P3
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0100
+
+HWCAP3_F16MM
+ Functionality implied by ID_AA64FPFR0_EL1.F16MM2 == 0b1
+
+HWCAP3_F16F32DOT
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0010
+
+HWCAP3_F16F32MM
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0011
+
+HWCAP3_SVE_LUT6
+ Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0010 and
+ ID_AA64PFR0_EL1.SVE == 0b0001.
4. Unused AT_HWCAP bits
-----------------------
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 06f83ca8de56..10272ddb4d6f 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -147,5 +147,13 @@
#define HWCAP3_MTE_STORE_ONLY (1UL << 1)
#define HWCAP3_LSFE (1UL << 2)
#define HWCAP3_LS64 (1UL << 3)
+#define HWCAP3_SVE_B16MM (1UL << 4)
+#define HWCAP3_SVE2P3 (1UL << 5)
+#define HWCAP3_SME_LUT6 (1UL << 6)
+#define HWCAP3_SME2P3 (1UL << 7)
+#define HWCAP3_F16MM (1UL << 8)
+#define HWCAP3_F16F32DOT (1UL << 9)
+#define HWCAP3_F16F32MM (1UL << 10)
+#define HWCAP3_SVE_LUT6 (1UL << 11)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6d53bb15cf7b..96de16582fca 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -365,6 +365,8 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
static const struct arm64_ftr_bits ftr_id_aa64smfr0[] = {
ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_FA64_SHIFT, 1, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
+ FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_LUT6_SHIFT, 1, 0),
ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
FTR_STRICT, FTR_EXACT, ID_AA64SMFR0_EL1_LUTv2_SHIFT, 1, 0),
ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
@@ -419,6 +421,7 @@ static const struct arm64_ftr_bits ftr_id_aa64fpfr0[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8DP2_SHIFT, 1, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8MM8_SHIFT, 1, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8MM4_SHIFT, 1, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F16MM2_SHIFT, 1, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8E4M3_SHIFT, 1, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64FPFR0_EL1_F8E5M2_SHIFT, 1, 0),
ARM64_FTR_END,
@@ -3284,6 +3287,8 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(ID_AA64ISAR0_EL1, SM4, IMP, CAP_HWCAP, KERNEL_HWCAP_SM4),
HWCAP_CAP(ID_AA64ISAR0_EL1, DP, IMP, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
HWCAP_CAP(ID_AA64ISAR0_EL1, FHM, IMP, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
+ HWCAP_CAP(ID_AA64ISAR0_EL1, FHM, F16F32DOT, CAP_HWCAP, KERNEL_HWCAP_F16F32DOT),
+ HWCAP_CAP(ID_AA64ISAR0_EL1, FHM, F16F32MM, CAP_HWCAP, KERNEL_HWCAP_F16F32MM),
HWCAP_CAP(ID_AA64ISAR0_EL1, TS, FLAGM, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
HWCAP_CAP(ID_AA64ISAR0_EL1, TS, FLAGM2, CAP_HWCAP, KERNEL_HWCAP_FLAGM2),
HWCAP_CAP(ID_AA64ISAR0_EL1, RNDR, IMP, CAP_HWCAP, KERNEL_HWCAP_RNG),
@@ -3313,7 +3318,9 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(ID_AA64ISAR3_EL1, LSFE, IMP, CAP_HWCAP, KERNEL_HWCAP_LSFE),
HWCAP_CAP(ID_AA64MMFR2_EL1, AT, IMP, CAP_HWCAP, KERNEL_HWCAP_USCAT),
#ifdef CONFIG_ARM64_SVE
+ HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ISAR2_EL1, LUT, LUT6, CAP_HWCAP, KERNEL_HWCAP_SVE_LUT6),
HWCAP_CAP(ID_AA64PFR0_EL1, SVE, IMP, CAP_HWCAP, KERNEL_HWCAP_SVE),
+ HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, SVEver, SVE2p3, CAP_HWCAP, KERNEL_HWCAP_SVE2P3),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, SVEver, SVE2p2, CAP_HWCAP, KERNEL_HWCAP_SVE2P2),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, SVEver, SVE2p1, CAP_HWCAP, KERNEL_HWCAP_SVE2P1),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, SVEver, SVE2, CAP_HWCAP, KERNEL_HWCAP_SVE2),
@@ -3323,6 +3330,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, BitPerm, IMP, CAP_HWCAP, KERNEL_HWCAP_SVEBITPERM),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, B16B16, IMP, CAP_HWCAP, KERNEL_HWCAP_SVE_B16B16),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, B16B16, BFSCALE, CAP_HWCAP, KERNEL_HWCAP_SVE_BFSCALE),
+ HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, B16B16, B16MM, CAP_HWCAP, KERNEL_HWCAP_SVE_B16MM),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, BF16, IMP, CAP_HWCAP, KERNEL_HWCAP_SVEBF16),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, BF16, EBF16, CAP_HWCAP, KERNEL_HWCAP_SVE_EBF16),
HWCAP_CAP_MATCH_ID(has_sve_feature, ID_AA64ZFR0_EL1, SHA3, IMP, CAP_HWCAP, KERNEL_HWCAP_SVESHA3),
@@ -3362,7 +3370,9 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
#ifdef CONFIG_ARM64_SME
HWCAP_CAP(ID_AA64PFR1_EL1, SME, IMP, CAP_HWCAP, KERNEL_HWCAP_SME),
HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, FA64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_FA64),
+ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, LUT6, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUT6),
HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, LUTv2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUTV2),
+ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p3, CAP_HWCAP, KERNEL_HWCAP_SME2P3),
HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p2, CAP_HWCAP, KERNEL_HWCAP_SME2P2),
HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p1, CAP_HWCAP, KERNEL_HWCAP_SME2P1),
HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2, CAP_HWCAP, KERNEL_HWCAP_SME2),
@@ -3393,6 +3403,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(ID_AA64FPFR0_EL1, F8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_F8DP2),
HWCAP_CAP(ID_AA64FPFR0_EL1, F8MM8, IMP, CAP_HWCAP, KERNEL_HWCAP_F8MM8),
HWCAP_CAP(ID_AA64FPFR0_EL1, F8MM4, IMP, CAP_HWCAP, KERNEL_HWCAP_F8MM4),
+ HWCAP_CAP(ID_AA64FPFR0_EL1, F16MM2, IMP, CAP_HWCAP, KERNEL_HWCAP_F16MM),
HWCAP_CAP(ID_AA64FPFR0_EL1, F8E4M3, IMP, CAP_HWCAP, KERNEL_HWCAP_F8E4M3),
HWCAP_CAP(ID_AA64FPFR0_EL1, F8E5M2, IMP, CAP_HWCAP, KERNEL_HWCAP_F8E5M2),
#ifdef CONFIG_ARM64_POE
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 6149bc91251d..d50e2a9b066b 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -164,6 +164,14 @@ static const char *const hwcap_str[] = {
[KERNEL_HWCAP_MTE_FAR] = "mtefar",
[KERNEL_HWCAP_MTE_STORE_ONLY] = "mtestoreonly",
[KERNEL_HWCAP_LSFE] = "lsfe",
+ [KERNEL_HWCAP_SVE_B16MM] = "sveb16mm",
+ [KERNEL_HWCAP_SVE2P3] = "sve2p3",
+ [KERNEL_HWCAP_SME_LUT6] = "smelut6",
+ [KERNEL_HWCAP_SME2P3] = "sme2p3",
+ [KERNEL_HWCAP_F16MM] = "f16mm",
+ [KERNEL_HWCAP_F16F32DOT] = "f16f32dot",
+ [KERNEL_HWCAP_F16F32MM] = "f16f32mm",
+ [KERNEL_HWCAP_SVE_LUT6] = "svelut6",
};
#ifdef CONFIG_COMPAT
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/2] kselftest/arm64: Add 2025 dpISA coverage to hwcaps
From: Mark Brown @ 2026-05-18 15:07 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, linux-doc, linux-kselftest,
Mark Brown
In-Reply-To: <20260518-arm64-dpisa-2025-v2-0-b3367b73bd00@kernel.org>
Add coverage of the new hwcaps to the test program, encodings cross checked
against LLVM 22.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/arm64/abi/hwcap.c | 116 ++++++++++++++++++++++++++++++
1 file changed, 116 insertions(+)
diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
index e22703d6b97c..19fca95f7c22 100644
--- a/tools/testing/selftests/arm64/abi/hwcap.c
+++ b/tools/testing/selftests/arm64/abi/hwcap.c
@@ -108,6 +108,24 @@ static void f8mm8_sigill(void)
asm volatile(".inst 0x6e80ec00");
}
+static void f16f32dot_sigill(void)
+{
+ /* FDOT V0.2S, V0.4H, V0.2H[0] */
+ asm volatile(".inst 0xf409000");
+}
+
+static void f16f32mm_sigill(void)
+{
+ /* FMMLA V0.4S, V0.8H, V0.8H */
+ asm volatile(".inst 0x4e40ec00");
+}
+
+static void f16mm_sigill(void)
+{
+ /* FMMLA V0.8H, V0.8H, V0.8H */
+ asm volatile(".inst 0x4ec0ec00");
+}
+
static void faminmax_sigill(void)
{
/* FAMIN V0.4H, V0.4H, V0.4H */
@@ -191,6 +209,12 @@ static void lut_sigill(void)
asm volatile(".inst 0x4e801000");
}
+static void sve_lut6_sigill(void)
+{
+ /* LUTI6 Z0.H, { Z0.H, Z1.H }, Z0[0] */
+ asm volatile(".inst 0x4560ac00");
+}
+
static void mops_sigill(void)
{
char dst[1], src[1];
@@ -282,6 +306,18 @@ static void sme2p2_sigill(void)
asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
}
+static void sme2p3_sigill(void)
+{
+ /* SMSTART SM */
+ asm volatile("msr S0_3_C4_C3_3, xzr" : : : );
+
+ /* ADDQP Z0.B, Z0.B, Z0.B */
+ asm volatile(".inst 0x4207800" : : : "z0");
+
+ /* SMSTOP */
+ asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
static void sme_aes_sigill(void)
{
/* SMSTART SM */
@@ -378,6 +414,18 @@ static void smef8f32_sigill(void)
asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
}
+static void smelut6_sigill(void)
+{
+ /* SMSTART */
+ asm volatile("msr S0_3_C4_C7_3, xzr" : : : );
+
+ /* LUTI6 { Z0.B-Z3.B }, ZT0, { Z0-Z2 } */
+ asm volatile(".inst 0xc08a0000" : : : );
+
+ /* SMSTOP */
+ asm volatile("msr S0_3_C4_C6_3, xzr" : : : );
+}
+
static void smelutv2_sigill(void)
{
/* SMSTART */
@@ -486,6 +534,12 @@ static void sve2p2_sigill(void)
asm volatile(".inst 0x4cea000" : : : "z0");
}
+static void sve2p3_sigill(void)
+{
+ /* ADDQP Z0.B, Z0.B, Z0.B */
+ asm volatile(".inst 0x4207800" : : : "z0");
+}
+
static void sveaes_sigill(void)
{
/* AESD z0.b, z0.b, z0.b */
@@ -504,6 +558,12 @@ static void sveb16b16_sigill(void)
asm volatile(".inst 0x65000000" : : : );
}
+static void sveb16mm_sigill(void)
+{
+ /* BFMMLA Z0.H, Z0.H, Z0.H */
+ asm volatile(".inst 0x64e0e000" : : : );
+}
+
static void svebfscale_sigill(void)
{
/* BFSCALE Z0.H, P0/M, Z0.H, Z0.H */
@@ -729,6 +789,27 @@ static const struct hwcap_data {
.cpuinfo = "f8mm4",
.sigill_fn = f8mm4_sigill,
},
+ {
+ .name = "F16MM",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_F16MM,
+ .cpuinfo = "f16mm",
+ .sigill_fn = f16mm_sigill,
+ },
+ {
+ .name = "F16F32DOT",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_F16F32DOT,
+ .cpuinfo = "f16f32dot",
+ .sigill_fn = f16f32dot_sigill,
+ },
+ {
+ .name = "F16F32MM",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_F16F32MM,
+ .cpuinfo = "f16f32mm",
+ .sigill_fn = f16f32mm_sigill,
+ },
{
.name = "FAMINMAX",
.at_hwcap = AT_HWCAP2,
@@ -918,6 +999,13 @@ static const struct hwcap_data {
.cpuinfo = "sme2p2",
.sigill_fn = sme2p2_sigill,
},
+ {
+ .name = "SME 2.3",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_SME2P3,
+ .cpuinfo = "sme2p3",
+ .sigill_fn = sme2p3_sigill,
+ },
{
.name = "SME AES",
.at_hwcap = AT_HWCAP,
@@ -967,6 +1055,13 @@ static const struct hwcap_data {
.cpuinfo = "smef8f32",
.sigill_fn = smef8f32_sigill,
},
+ {
+ .name = "SME LUT6",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_SME_LUT6,
+ .cpuinfo = "smelut6",
+ .sigill_fn = smelut6_sigill,
+ },
{
.name = "SME LUTV2",
.at_hwcap = AT_HWCAP2,
@@ -1052,6 +1147,13 @@ static const struct hwcap_data {
.cpuinfo = "sve2p2",
.sigill_fn = sve2p2_sigill,
},
+ {
+ .name = "SVE 2.3",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_SVE2P3,
+ .cpuinfo = "sve2p3",
+ .sigill_fn = sve2p3_sigill,
+ },
{
.name = "SVE AES",
.at_hwcap = AT_HWCAP2,
@@ -1066,6 +1168,13 @@ static const struct hwcap_data {
.cpuinfo = "sveaes2",
.sigill_fn = sveaes2_sigill,
},
+ {
+ .name = "SVE B16MM",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_SVE_B16MM,
+ .cpuinfo = "sveb16mm",
+ .sigill_fn = sveb16mm_sigill,
+ },
{
.name = "SVE BFSCALE",
.at_hwcap = AT_HWCAP,
@@ -1087,6 +1196,13 @@ static const struct hwcap_data {
.cpuinfo = "svef16mm",
.sigill_fn = svef16mm_sigill,
},
+ {
+ .name = "SVE_LUT6",
+ .at_hwcap = AT_HWCAP3,
+ .hwcap_bit = HWCAP3_SVE_LUT6,
+ .cpuinfo = "svelut6",
+ .sigill_fn = sve_lut6_sigill,
+ },
{
.name = "SVE2 B16B16",
.at_hwcap = AT_HWCAP2,
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v14 00/28] CoreSight: Refactor power management for CoreSight path
From: Suzuki K Poulose @ 2026-05-18 15:23 UTC (permalink / raw)
To: Mike Leach, James Clark, Yeoreum Yun, Mark Rutland, Will Deacon,
Yabin Cui, Keita Morisaki, Jie Gan, Yuanfang Zhang,
Greg Kroah-Hartman, Alexander Shishkin, Tamas Petz,
Thomas Gleixner, Peter Zijlstra, Leo Yan
Cc: Suzuki K Poulose, coresight, linux-arm-kernel
In-Reply-To: <20260515-arm_coresight_path_power_management_improvement-v14-0-f88c4a3ecfe9@arm.com>
On Fri, 15 May 2026 21:08:07 +0100, Leo Yan wrote:
> This series focuses on CoreSight path power management. The changes can
> be divided into four parts for review:
>
> Patches 01 - 10: Preparison for CPU PM:
> Fix source disabling on idr_alloc failure.
> Fix helper enable failure handling.
> Refactor CPU ID stored in csdev.
> Move CPU lock to sysfs layer.
> Move per-CPU source pointer from etm-perf to core layer.
> Refactor etm-perf to retrieve source via per-CPU's event
> data for lockless and get source reference during AUX
> setup.
> Patches 11 - 13: Refactor CPU idle flow managed in the CoreSight core
> layer.
> Patches 14 - 23: Refactor path enable / disable with range, control path
> during CPU idle.
> Patches 24 - 25: Support the sink (TRBE) control during CPU idle.
> Patches 26 - 28: Move CPU hotplug into the core layer, and fix sysfs
> mode for hotplug.
>
> [...]
Applied, thanks!
[01/28] coresight: Fix source not disabled on idr_alloc_u32 failure
https://git.kernel.org/coresight/c/ea2c2b9e2a66
[02/28] coresight: Handle helper enable failure properly
https://git.kernel.org/coresight/c/864754d0a084
[03/28] coresight: Extract device init into coresight_init_device()
https://git.kernel.org/coresight/c/10be00dd7375
[04/28] coresight: Populate CPU ID into coresight_device
https://git.kernel.org/coresight/c/da2bfe3377b5
[05/28] coresight: Remove .cpu_id() callback from source ops
https://git.kernel.org/coresight/c/9d5eb760e304
[06/28] coresight: Take hotplug lock in enable_source_store() for Sysfs mode
https://git.kernel.org/coresight/c/2c7f786928c4
[07/28] coresight: perf: Retrieve path and source from event data
https://git.kernel.org/coresight/c/f37bc31447c0
[08/28] coresight: Take a reference on csdev
https://git.kernel.org/coresight/c/6317302ae252
[09/28] coresight: Move per-CPU source pointer to core layer
https://git.kernel.org/coresight/c/3a4a1c4dd977
[10/28] coresight: Take per-CPU source reference during AUX setup
https://git.kernel.org/coresight/c/d79125cc3622
[11/28] coresight: Register CPU PM notifier in core layer
https://git.kernel.org/coresight/c/4d8dd98ee5bf
[12/28] coresight: etm4x: Hook CPU PM callbacks
https://git.kernel.org/coresight/c/0f5e588c70a8
[13/28] coresight: etm4x: Remove redundant checks in PM save and restore
https://git.kernel.org/coresight/c/81bf1c33f6a7
[14/28] coresight: syscfg: Use IRQ-safe spinlock to protect active variables
https://git.kernel.org/coresight/c/3b6e3e04659a
[15/28] coresight: Disable source helpers in coresight_disable_path()
https://git.kernel.org/coresight/c/5cae71994339
[16/28] coresight: Control path with range
https://git.kernel.org/coresight/c/3d3289c0d850
[17/28] coresight: Use helpers to fetch first and last nodes
https://git.kernel.org/coresight/c/0724585ace19
[18/28] coresight: Introduce coresight_enable_source() helper
https://git.kernel.org/coresight/c/a18e877b0491
[19/28] coresight: Save active path for system tracers
https://git.kernel.org/coresight/c/ac8eac9062ee
[20/28] coresight: etm4x: Set active path on target CPU
https://git.kernel.org/coresight/c/b6d54a94dcf4
[21/28] coresight: etm3x: Set active path on target CPU
https://git.kernel.org/coresight/c/bc9907750718
[22/28] coresight: sysfs: Use source's path pointer for path control
https://git.kernel.org/coresight/c/a2e91258e864
[23/28] coresight: Control path during CPU idle
https://git.kernel.org/coresight/c/39c40892f1a4
[24/28] coresight: Add PM callbacks for sink device
https://git.kernel.org/coresight/c/7bbe5a172376
[25/28] coresight: trbe: Save and restore state across CPU low power state
https://git.kernel.org/coresight/c/da06d6eb523b
[26/28] coresight: sysfs: Increment refcount only for software source
https://git.kernel.org/coresight/c/bf64b06ede93
[27/28] coresight: Move CPU hotplug callbacks to core layer
https://git.kernel.org/coresight/c/7105d2aa76d8
[28/28] coresight: sysfs: Validate CPU online status for per-CPU sources
https://git.kernel.org/coresight/c/a5dd853fb777
Best regards,
--
Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* Re: [PATCH v2 0/6] fsl-mc: Move over to device MSI infrastructure
From: Arnd Bergmann @ 2026-05-18 15:24 UTC (permalink / raw)
To: Marc Zyngier, Christophe Leroy
Cc: Ioana Ciornei, Thomas Gleixner, Sascha Bischoff, linux-kernel,
linux-arm-kernel, linuxppc-dev
In-Reply-To: <86zf1wx0b4.wl-maz@kernel.org>
On Mon, May 18, 2026, at 16:24, Marc Zyngier wrote:
> On Mon, 18 May 2026 14:51:48 +0100,
> "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
>>
>> > > Do I need to respin it?
>>
>> No, I'd like to avoid having to rebase again. If you have changes to
>> the series please send followup patches.
Sorry this got held up even longer now. I meant to reply
earlier but dropped the ball on that while sending the merge
window contents.
This was indeed bad timing as the original pull request reached
me only after 7.0 was already out.
> No follow-up patches for that particular series, I just wanted to find
> out whether I could start posting additional changes that do not
> directly involve fsl-mc, but that are prevented by the current state
> of the code (such as trying to move the ITS initialisation much later
> in the boot process).
>
> I'll postpone my changes to 7.3, and keep my fingers crossed for this
> to hit 7.2.
I've merged the soc_fsl-7.1-2 tag into the soc/drivers branch
for 7.2 now. You should be able to base your other changes on top
of f0a2eac6a597 ("platform-msi: Remove stale comment") as a shared
branch.
Arnd
^ permalink raw reply
* Re: [PATCH v8 2/4] firmware: ti_sci: add support for restoring IRQs during resume
From: Thomas Richard @ 2026-05-18 15:31 UTC (permalink / raw)
To: Kumar, Udit, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Michael Turquette, Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Abhash Kumar, Thomas Petazzoni,
linux-arm-kernel, linux-kernel, linux-clk, Dhruva Gole,
Kendall Willis
In-Reply-To: <495082a3-1a08-45d9-90f0-4723837ec4be@ti.com>
Hello Udit,
On 5/18/26 3:22 PM, Kumar, Udit wrote:
>
>
> On 5/13/2026 6:16 PM, Thomas Richard (TI) wrote:
>> Some DM-Firmware are not able to restore the IRQ context after a
>> suspend-resume. The IRQ_CONTEXT_LOST firmware capability has been
>> introduced to identify this characteristic. In this case the
>> responsibility is delegated to the ti_sci driver, which maintains an
>> internal list of all requested IRQs. This list is updated on each
>> set()/free() operation, and all IRQs are restored during the resume_noirq()
>> phase.
>>
>> Reviewed-by: Dhruva Gole <d-gole@ti.com>
>> Reviewed-by: Kendall Willis <k-willis@ti.com>
>> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
>> ---
>> drivers/firmware/ti_sci.c | 201 +++++++++++++++++++++++++++++++++++++++++++---
>> drivers/firmware/ti_sci.h | 3 +
>> 2 files changed, 192 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
>> index eaeaaae94142..35ee8cc830c8 100644
>> --- a/drivers/firmware/ti_sci.c
>> +++ b/drivers/firmware/ti_sci.c
>> @@ -12,11 +12,13 @@
>> #include <linux/cpu.h>
>> #include <linux/debugfs.h>
>> #include <linux/export.h>
>> +#include <linux/hashtable.h>
>> #include <linux/io.h>
>> #include <linux/iopoll.h>
>> #include <linux/kernel.h>
>> #include <linux/mailbox_client.h>
>> #include <linux/module.h>
>> +#include <linux/mutex.h>
>> #include <linux/of.h>
>> #include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>
> Could you check, recursive header inclusion header warning
> In file included from linux/printk.h,
> from linux/srcu.h:85
> from linux/notifier.h:16
> from linux/reboot.h:6
> -drivers/firmware/ti_sci.c:31: warning: recursive header inclusion
> +drivers/firmware/ti_sci.c:33: warning: recursive header inclusion
This warning was already present. It just means the line changed because
I added some new headers. But this patch did not introduce the recursive
header inclusion.
>
>> @@ -87,6 +89,16 @@ struct ti_sci_desc {
>> int max_msg_size;
>> };
>>
>> +/**
>> + * struct ti_sci_irq - Description of allocated irqs
>> + * @node: Link to hash table
>> + * @desc: Description of the irq
>> + */
>> +struct ti_sci_irq {
>> + struct hlist_node node;
>> + struct ti_sci_msg_req_manage_irq desc;
>> +};
>> +
>> /**
>> * struct ti_sci_info - Structure representing a TI SCI instance
>> * @dev: Device pointer
>> @@ -101,6 +113,8 @@ struct ti_sci_desc {
>> * @chan_rx: Receive mailbox channel
>> * @minfo: Message info
>> * @node: list head
>> + * @irqs: List of allocated irqs
>> + * @irq_lock: Protection for irq hash list
>> * @host_id: Host ID
>> * @fw_caps: FW/SoC low power capabilities
>> * @users: Number of users of this instance
>> @@ -118,6 +132,8 @@ struct ti_sci_info {
>> struct mbox_chan *chan_rx;
>> struct ti_sci_xfers_info minfo;
>> struct list_head node;
>> + DECLARE_HASHTABLE(irqs, 8);
>> + struct mutex irq_lock;
>
> One of script report errors, you might need to document hashtabke.
> However warning is unrelated
> CHECK: struct mutex definition without commen
mutex and hashtable are documented.
checkpatch returns there is no comment for struct mutex which not true.
It's a false positive.
Best Regards,
Thomas
^ permalink raw reply
* [PATCH v2] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Will Deacon @ 2026-05-18 15:31 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Oliver Upton, Marc Zyngier,
Catalin Marinas, Mark Rutland
Currently, it is not necessary for __finalise_el2() to configure
TPIDR_EL2:
* The hyp stub code does not consume the value of TPIDR_EL2.
* On the boot cpu, TPIDR_EL1 is used for the percpu offset until the
ARM64_HAS_VIRT_HOST_EXTN cpucap is detected and boot alternatives
are patched. Before boot alternatives are patched,
cpu_copy_el2regs() will copy TPIDR_EL1 into TPIDR_EL2. It is not
necessary for __finalise_el2() to initialise TPIDR_EL2 before this.
* Secondary CPUs are brought up after boot alternatives have been
patched, and __secondary_switched() will initialize TPIDR_EL2 in
'init_cpu_task', after finalise_el2() calls __finalise_el2()
* KVM hyp code which may consume TPIDR_EL2 is brought up after all
secondaries have been booted, once TPIDR_El2 has been configured on
all CPUs.
Remove the redundant initialisation from __finalise_el2().
Cc: Oliver Upton <oupton@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
v2: Use Mark's commit message, add his R-b tag, rebase onto -rc4.
Link to v1: https://lore.kernel.org/r/20260330152927.26300-1-will@kernel.org
arch/arm64/kernel/hyp-stub.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 634ddc904244..37c6976e44a4 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -104,11 +104,9 @@ SYM_CODE_START_LOCAL(__finalise_el2)
mov_q x0, HCR_HOST_VHE_FLAGS
msr_hcr_el2 x0
- // Use the EL1 allocated stack, per-cpu offset
+ // Use the EL1 allocated stack
mrs x0, sp_el1
mov sp, x0
- mrs x0, tpidr_el1
- msr tpidr_el2, x0
// FP configuration, vectors
mrs_s x0, SYS_CPACR_EL12
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v9 0/9] Allwinner A31/A83T MIPI CSI-2 and A31 ISP / Platform Support
From: Paul Kocialkowski @ 2026-05-18 15:33 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
This series adds platform support for the V3s/V3/S3 MIPI CSI-2 and ISP units
as well the as A83T MIPI CSI-2 unit in the respective device-trees.
Overlays for the BananaPi M3 cameras are also provided as actual users of the
camera pipeline on A83T.
The corresponding drivers and dt bindings were merged a long time ago but this
series was never actually picked up. It seems more than ready to be merged!
Changes since v8:
- Added collected review tags;
- Added the overlays to be built as full dtbs.
- Removed trailing whitespace.
Changes since v7:
- Added collected review tags;
- Added interconnect properties to bindings;
- Added compatible for device-tree overlays;
- Moved mclk pin to sensor node in bpi-m3 overlays;
- Removed duplicated assigned-clocks in bpi-m3 overlays.
Changes since v6:
- Rebased on top of the latest media tree, renamed dts to dtso for overlays.
Changes since v5:
- Added BananaPi M3 camera sensor support as device-tree overlays;
- Cleaned-up OV8865 regulator definitions;
- Always declared the internal links between CSI and MIPI CSI-2 on A83T
in device-tree.
Changes since v4:
- Removed mbus bindings patch: an equivalent change was merged;
- Added collected tags;
- Rebased on latest media tree.
Changes since v3:
- Reordered v3s mbus compatible in binding;
- Added collected tag;
- Removed rejected interconnects fix.
Changes since all-in-one v2:
- Corrected mbus index used for the interconnects;
- Used extended mbus binding and exported the DRAM clock for that;
- Reworked the description of the core openfirmware change to give
more insight about the situation.
*** BLURB HERE ***
Paul Kocialkowski (9):
dt-bindings: media: sun6i-a31-csi: Add optional interconnect
properties
dt-bindings: media: sun6i-a31-isp: Add optional interconnect
properties
clk: sunxi-ng: v3s: Export MBUS and DRAM clocks to the public header
ARM: dts: sun8i: v3s: Add mbus node to represent the interconnect
ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
ARM: dts: sun8i: v3s: Add support for the ISP
ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node
ARM: dts: sun8i-a83t: Add BananaPi M3 OV5640 camera overlay
ARM: dts: sun8i-a83t: Add BananaPi M3 OV8865 camera overlay
.../media/allwinner,sun6i-a31-csi.yaml | 6 +
.../media/allwinner,sun6i-a31-isp.yaml | 6 +
arch/arm/boot/dts/allwinner/Makefile | 6 +
.../sun8i-a83t-bananapi-m3-camera-ov5640.dtso | 115 +++++++++++++++++
.../sun8i-a83t-bananapi-m3-camera-ov8865.dtso | 101 +++++++++++++++
arch/arm/boot/dts/allwinner/sun8i-a83t.dtsi | 43 +++++++
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 121 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 4 -
include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 +-
9 files changed, 400 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov8865.dtso
--
2.54.0
^ permalink raw reply
* [PATCH v9 1/9] dt-bindings: media: sun6i-a31-csi: Add optional interconnect properties
From: Paul Kocialkowski @ 2026-05-18 15:33 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
An interconnect can be attached to the sun6i-a31-csi device, which is
useful to attach the dma memory offset. Add related properties.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1aa5775ba2bc..978ef2dc0ae7 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -40,6 +40,12 @@ properties:
resets:
maxItems: 1
+ interconnects:
+ maxItems: 1
+
+ interconnect-names:
+ const: dma-mem
+
port:
$ref: /schemas/graph.yaml#/$defs/port-base
description: Parallel input port, connect to a parallel sensor
--
2.54.0
^ permalink raw reply related
* [PATCH v9 2/9] dt-bindings: media: sun6i-a31-isp: Add optional interconnect properties
From: Paul Kocialkowski @ 2026-05-18 15:33 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
An interconnect can be attached to the sun6i-a31-csi device, which is
useful to attach the dma memory offset. Add related properties.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
.../devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml
index 3ea4a4290f23..c0d7accc7bbe 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml
@@ -36,6 +36,12 @@ properties:
resets:
maxItems: 1
+ interconnects:
+ maxItems: 1
+
+ interconnect-names:
+ const: dma-mem
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
--
2.54.0
^ permalink raw reply related
* [PATCH v9 3/9] clk: sunxi-ng: v3s: Export MBUS and DRAM clocks to the public header
From: Paul Kocialkowski @ 2026-05-18 15:33 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard, Paul Kocialkowski
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
In order to declare a mbus node for the v3s, expose its associated
clocks to the public header.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 4 ----
include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 ++--
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
index 345cdbbab362..c933ef016570 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
@@ -39,14 +39,10 @@
/* The first bunch of module clocks are exported */
-#define CLK_DRAM 58
-
/* All the DRAM gates are exported */
/* Some more module clocks are exported */
-#define CLK_MBUS 72
-
/* And the GPU module clock is exported */
#define CLK_PLL_DDR1 74
diff --git a/include/dt-bindings/clock/sun8i-v3s-ccu.h b/include/dt-bindings/clock/sun8i-v3s-ccu.h
index c4055629c9f9..d635bffd6914 100644
--- a/include/dt-bindings/clock/sun8i-v3s-ccu.h
+++ b/include/dt-bindings/clock/sun8i-v3s-ccu.h
@@ -87,7 +87,7 @@
#define CLK_SPI0 55
#define CLK_USB_PHY0 56
#define CLK_USB_OHCI0 57
-
+#define CLK_DRAM 58
#define CLK_DRAM_VE 59
#define CLK_DRAM_CSI 60
#define CLK_DRAM_EHCI 61
@@ -101,7 +101,7 @@
#define CLK_VE 69
#define CLK_AC_DIG 70
#define CLK_AVS 71
-
+#define CLK_MBUS 72
#define CLK_MIPI_CSI 73
/* Clocks not available on V3s */
--
2.54.0
^ permalink raw reply related
* [PATCH v9 4/9] ARM: dts: sun8i: v3s: Add mbus node to represent the interconnect
From: Paul Kocialkowski @ 2026-05-18 15:33 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard, Paul Kocialkowski
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
The V3s uses the mbus interconnect to provide DRAM access for a
number of blocks. The SoC can only map 2 GiB of DRAM, which is
reflected in the dma-ranges property.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
---
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
index fa54510319ac..02d6c62b3874 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
@@ -629,6 +629,21 @@ int_mii_phy: ethernet-phy@1 {
};
};
+ mbus: dram-controller@1c62000 {
+ compatible = "allwinner,sun8i-v3s-mbus";
+ reg = <0x01c62000 0x1000>,
+ <0x01c63000 0x1000>;
+ reg-names = "mbus", "dram";
+ clocks = <&ccu CLK_MBUS>,
+ <&ccu CLK_DRAM>,
+ <&ccu CLK_BUS_DRAM>;
+ clock-names = "mbus", "dram", "bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x00000000 0x40000000 0x80000000>;
+ #interconnect-cells = <1>;
+ };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v9 5/9] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
From: Paul Kocialkowski @ 2026-05-18 15:33 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard, Paul Kocialkowski
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.
On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.
Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.
Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.
The interconnects property is used to inherit the proper DMA offset.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 71 ++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
index 02d6c62b3874..bfe02295f45d 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
@@ -671,6 +671,77 @@ gic: interrupt-controller@1c81000 {
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ csi0: camera@1cb0000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb0000 0x1000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ interconnects = <&mbus 5>;
+ interconnect-names = "dma-mem";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csi0_in_mipi_csi2: endpoint {
+ remote-endpoint = <&mipi_csi2_out_csi0>;
+ };
+ };
+ };
+ };
+
+ mipi_csi2: csi@1cb1000 {
+ compatible = "allwinner,sun8i-v3s-mipi-csi2",
+ "allwinner,sun6i-a31-mipi-csi2";
+ reg = <0x01cb1000 0x1000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_CSI>;
+ status = "disabled";
+
+ phys = <&dphy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ mipi_csi2_out: port@1 {
+ reg = <1>;
+
+ mipi_csi2_out_csi0: endpoint {
+ remote-endpoint = <&csi0_in_mipi_csi2>;
+ };
+ };
+ };
+ };
+
+ dphy: d-phy@1cb2000 {
+ compatible = "allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01cb2000 0x1000>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_MIPI_CSI>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_CSI>;
+ allwinner,direction = "rx";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox