* [PATCH v2 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
Add binding documentation for the new power-domains-child-ids property,
which works in conjunction with the existing power-domains property to
establish parent-child relationships between a multi-domain power domain
provider and external parent domains.
Each element in the uint32 array identifies the child domain
ID (index) within the provider that should be made a child domain of
the corresponding phandle entry in power-domains. The two arrays must
have the same number of elements.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index b1147dbf2e73..163b0af158fd 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -68,6 +68,21 @@ properties:
by the given provider should be subdomains of the domain specified
by this binding.
+ power-domains-child-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ An array of child domain IDs that correspond to the power-domains
+ property. This property is only applicable to power domain providers
+ with "#power-domain-cells" > 0 (i.e., providers that supply multiple
+ power domains). It specifies which of the provider's child domains
+ should be associated with each parent domain listed in the power-domains
+ property. The number of elements in this array must match the number of
+ phandles in the power-domains property. Each element specifies the child
+ domain ID (index) that should be made a child domain of the corresponding
+ parent domain. This enables hierarchical power domain structures where
+ different child domains from the same provider can have different
+ parent domains.
+
required:
- "#power-domain-cells"
@@ -133,3 +148,22 @@ examples:
min-residency-us = <7000>;
};
};
+
+ - |
+ // Example: SCMI domain 15 -> MAIN_PD, SCMI domain 19 -> WKUP_PD
+ MAIN_PD: power-controller-main {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <0>;
+ };
+
+ WKUP_PD: power-controller-wkup {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <0>;
+ };
+
+ scmi_pds: power-controller-scmi {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <1>;
+ power-domains = <&MAIN_PD>, <&WKUP_PD>;
+ power-domains-child-ids = <15>, <19>;
+ };
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Jason Gunthorpe @ 2026-04-10 23:25 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <adl0aEfBAKmBsMs6@Asurada-Nvidia>
On Fri, Apr 10, 2026 at 03:06:32PM -0700, Nicolin Chen wrote:
> On Thu, Apr 09, 2026 at 09:27:34PM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > index 846a278fa5469..0e48264ccd01b 100644
> > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> > > */
> > > arm_smmu_domain_inv(smmu_domain);
> > >
> > > - /*
> > > - * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> > > - * still be called/running at this point. We allow the ASID to be
> > > - * reused, and if there is a race then it just suffers harmless
> > > - * unnecessary invalidation.
> > > - */
> > > - xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> > > -
> >
> > I don't think this artifact has disappeared so the comment should
> > probably remain too. It has become slightly different because it is
> > now running under RCU protections so it will clear alot faster.
>
> By taking a closer look, I think either the arm_smmu_domain_inv call
> above or any concurrent arm_smmu_mm_arch_invalidate_secondary_tlbs
> call is a NOP now?
That sounds right, with all the changes there should be no cache
flushing on the free path since it is now always flushed on detach, so
the arm_smmu_domain_inv() should be deleted here too.
> We reworked the ASID lifecycle, which now ends when the last device
> detaches. So, ASID was free-ed in arm_smmu_iotlb_tag_free() that did
> a per-ASID flush also.
Yes, so the comment is:
Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs() op can
still be called/running at this point. Like the normal detach flow
the RCU protected ASID may still experiance harmless invalidation.
However unlike normal domains the SVA invalidation will continue
into free until the mmu_notifier_put().
> So, when freeing the SVA domain here, the domain should have an empty
> invalidation array and the HW cache is flushed as well, right?
Yes, but the parallel thread is still possible even in free which is
unusual compared to normal domains where it is illegal to call
map/unmap concurrently with free.
Jason
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
From: patchwork-bot+netdevbpf @ 2026-04-10 23:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev, xuegang.lu
In-Reply-To: <20260408-airoha-reg_fe_pse_buf_set-v1-1-0c4fa8f4d1d9@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 12:20:09 +0200 you wrote:
> airoha_fe_set routine is used to set specified bits to 1 in the selected
> register. In the FE_PSE_BUF_SET case this can due to a overestimation of
> the required buffers for I/O queues since we can miss to set some bits
> of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw
> routine instead.
>
> Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()")
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
https://git.kernel.org/netdev/net/c/02f729643959
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Nicolin Chen @ 2026-04-10 23:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410214115.GC2588311@nvidia.com>
On Fri, Apr 10, 2026 at 06:41:15PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2026 at 02:23:48PM -0700, Nicolin Chen wrote:
>
> > Reworking the SVA code, I found arm_smmu_update_s1_domain_cd_entry
> > is marked as __maybe_unused and not getting called anywhere(?). Do
> > you recall why we kept it?
>
> I intended to send the vBTM support that uses it, and now that this is
> done it can work properly without races. So lets hang on, I was
> meaning to look at that soon
OK. I assume its caller would hold arm_smmu_asid_mutex, because
it's calling arm_smmu_find_iotlb_tag() now.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS suspend skip
From: Bjorn Helgaas @ 2026-04-10 22:53 UTC (permalink / raw)
To: Hongxing Zhu
Cc: mani@kernel.org, Frank Li, jingoohan1@gmail.com,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <AS8PR04MB883374CBFD3C97CE54DFB4C48C5BA@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 02:38:35AM +0000, Hongxing Zhu wrote:
> ...
> One additional note regarding NVMe: ASPM (Active State Power Management) is
> disabled locally on i.MX platforms for NVMe devices. This decision was made
> after encountering a system hang issue similar to the one reported by Hans a
> few months ago in his patch listed below.
> https://lore.kernel.org/linux-nvme/20250502032051.920990-1-hans.zhang@cixtech.com/
Where is ASPM disabled for i.MX? I don't see anything in pci-imx6.c.
It doesn't sound architecturally clean to me to disable ASPM based on
whether an NVMe device is involved.
^ permalink raw reply
* [GIT PULL] Qualcomm clock updates for v7.1
From: Bjorn Andersson @ 2026-04-10 22:38 UTC (permalink / raw)
To: Stephen Boyd, linux-clk
Cc: linux-arm-msm, linux-arm-kernel, Taniya Das, Val Packett,
Krzysztof Kozlowski, Konrad Dybcio, John Crispin, Abel Vesa,
Kathiravan Thirumoorthy, Pengyu Luo, Dmitry Baryshkov,
Jagadeesh Kona, Prasanna Tolety, Vladimir Zapolskiy, White Lewis
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-clk-for-7.1
for you to fetch changes up to a4f780cd5c7aa8c0d2d044ffd153f7a3a13ca81e:
clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC (2026-04-08 21:00:09 -0500)
----------------------------------------------------------------
Qualcomm clock updates for v7.1
Add global TCSR, RPMh, and display clock controller support for the
Eliza platform.
Add TCSR, the multiple global, and the RPMh clock controller support
for the Nord platform.
Add GPU clock controller support for SM8750.
Introduce video and GPU clock controller support for Glymur.
Add global clock controller for IPQ5210.
Introduce various smaller display-related fixes across Kaanapali, Milos,
SC8280XP, SM4450, SM8250, and SA8775P.
Add missing GDSCs and fix retention flags for PCIe and USB power domains
on SC8180X. Also enable runtime PM support to ensure performance votes
are propagated to CX.
Mark the USB QTB clock as always-on on Hamoa, in order to ensure the
SMMU can work even when USB controller device is sleeping.
Add IPQ6018 and IPQ8074 support to the IPQ CMN PLL driver.
Add MDSS resets for SC7180, SM6115, and SM6125, to allow display
subsystem driver to reset the hardware from the state left by the
bootloader.
Introduce various cleanups across drivers.
----------------------------------------------------------------
Abel Vesa (3):
clk: qcom: Add TCSR clock driver for Eliza
clk: qcom: gcc-eliza: Enable FORCE_MEM_CORE_ON for UFS AXI PHY clock
dt-bindings: clock: qcom: Add missing power-domains property
Bjorn Andersson (5):
Merge branch '20260311-eliza-clocks-v6-1-453c4cf657a2@oss.qualcomm.com' into clk-for-7.1
Merge branch '20260303034847.13870-2-val@packett.cool' into clk-for-7.1
Merge branch '20260318-ipq5210_boot_to_shell-v2-1-a87e27c37070@oss.qualcomm.com' into clk-for-7.1
Merge branch '20260319-clk-qcom-dispcc-eliza-v3-1-d1f2b19a6e6b@oss.qualcomm.com' into clk-for-7.1
Merge branch '20260120-topic-7180_dispcc_bcr-v1-1-0b1b442156c3@oss.qualcomm.com' into clk-for-7.1
Dmitry Baryshkov (1):
clk: qcom: dispcc-glymur: use RCG2 ops for DPTX1 AUX clock source
Jagadeesh Kona (1):
clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON
John Crispin (5):
clk: qcom: gcc-ipq6018: mark gcc_xo_clk_src as critical
dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
clk: qcom: ipq-cmn-pll: Add IPQ6018 SoC support
dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
clk: qcom: ipq-cmn-pll: Add IPQ8074 SoC support
Kathiravan Thirumoorthy (2):
dt-bindings: clock: add Qualcomm IPQ5210 GCC
clk: qcom: add Global Clock controller (GCC) driver for IPQ5210 SoC
Konrad Dybcio (9):
clk: qcom: dispcc-glymur: Fix DSI byte clock rate setting
clk: qcom: dispcc-kaanapali: Fix DSI byte clock rate setting
clk: qcom: dispcc-milos: Fix DSI byte clock rate setting
clk: qcom: dispcc-sm4450: Fix DSI byte clock rate setting
clk: qcom: dispcc[01]-sa8775p: Fix DSI byte clock rate setting
dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets
clk: qcom: dispcc-sc7180: Add missing MDSS resets
dt-bindings: clock: qcom: Add SM8750 GPU clocks
clk: qcom: Add a driver for SM8750 GPU clocks
Krzysztof Kozlowski (12):
dt-bindings: clock: qcom,glymur-dispcc: De-acronymize SoC name
clk: qcom: De-acronymize Glymur SoC name
clk: qcom: kaanapali: Cleanup redundant header includes
clk: qcom: glymur: Cleanup redundant header includes
clk: qcom: sm8750: Cleanup redundant header includes
clk: qcom: milos: Cleanup redundant header includes
clk: qcom: eliza: Cleanup redundant header includes
dt-bindings: clock: qcom,eliza-dispcc: Add Eliza SoC display CC
clk: qcom: dispcc-eliza: Add Eliza display clock controller support
clk: qcom: videocc-glymur: Constify qcom_cc_desc
clk: qcom: Constify qcom_cc_driver_data
clk: qcom: Constify list of critical CBCR registers
Pengyu Luo (2):
clk: qcom: videocc-sm8350: use depend on instead of select
clk: qcom: rcg2: expand frac table for mdss_pixel_clk_src
Prasanna Tolety (1):
clk: qcom: rpmh: Add support for Nord rpmh clocks
Taniya Das (16):
dt-bindings: clock: qcom: document the Glymur GPU Clock Controller
clk: qcom: Add support for GPUCC and GXCLK for Glymur
dt-bindings: clock: qcom: Add GCC video axi reset clock for Glymur
dt-bindings: clock: qcom: Add video clock controller on Glymur SoC
clk: qcom: gcc-glymur: Add video axi clock resets for glymur
clk: qcom: videocc-glymur: Add video clock controller driver for Glymur
dt-bindings: clock: qcom: document the Eliza Global Clock Controller
dt-bindings: clock: qcom: Document the Eliza TCSR Clock Controller
dt-bindings: clock: qcom-rpmhcc: Add RPMHCC for Eliza
clk: qcom: rpmh: Add support for Eliza rpmh clocks
clk: qcom: Add support for Global clock controller on Eliza
dt-bindings: clock: qcom: Document the Nord SoC TCSR Clock Controller
dt-bindings: clock: qcom-rpmhcc: Add support for Nord SoCs
dt-bindings: clock: qcom: Add Nord Global Clock Controller
clk: qcom: Add TCSR clock driver for Nord SoC
clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC
Val Packett (13):
dt-bindings: clock: qcom,sm6115-dispcc: Define MDSS resets
dt-bindings: clock: qcom,dispcc-sm6125: Define MDSS resets
clk: qcom: dispcc-sm6115: Add missing MDSS resets
clk: qcom: dispcc-sm6125: Add missing MDSS resets
dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs
clk: qcom: gcc-sc8180x: Add missing GDSCs
clk: qcom: gcc-sc8180x: Use retention for USB power domains
clk: qcom: gcc-sc8180x: Use retention for PCIe power domains
clk: qcom: gcc-sc8180x: Enable runtime PM support
clk: qcom: gcc-sc8180x: Refactor to use qcom_cc_driver_data
clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk
clk: qcom: dispcc-sm8250: Enable parents for pixel clocks
clk: qcom: camcc-sc8180x: Refactor to use qcom_cc_driver_data
Vladimir Zapolskiy (1):
clk: qcom: gdsc: Fix error path on registration of multiple pm subdomains
White Lewis (1):
clk: qcom: dispcc-sc8280xp: remove CLK_SET_RATE_PARENT from byte_div_clk_src dividers
.../bindings/clock/qcom,eliza-dispcc.yaml | 96 +
.../bindings/clock/qcom,glymur-dispcc.yaml | 4 +-
.../bindings/clock/qcom,ipq5210-gcc.yaml | 62 +
.../bindings/clock/qcom,ipq9574-cmn-pll.yaml | 2 +
.../bindings/clock/qcom,kaanapali-gxclkctl.yaml | 2 +
.../devicetree/bindings/clock/qcom,milos-gcc.yaml | 16 +-
.../devicetree/bindings/clock/qcom,nord-gcc.yaml | 58 +
.../devicetree/bindings/clock/qcom,nord-negcc.yaml | 60 +
.../devicetree/bindings/clock/qcom,nord-nwgcc.yaml | 55 +
.../devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 +
.../bindings/clock/qcom,sm8450-gpucc.yaml | 27 +-
.../bindings/clock/qcom,sm8450-videocc.yaml | 3 +
.../bindings/clock/qcom,sm8550-tcsr.yaml | 4 +
drivers/clk/qcom/Kconfig | 94 +-
drivers/clk/qcom/Makefile | 9 +
drivers/clk/qcom/apss-ipq5424.c | 2 +-
drivers/clk/qcom/cambistmclkcc-kaanapali.c | 6 +-
drivers/clk/qcom/cambistmclkcc-sm8750.c | 4 +-
drivers/clk/qcom/camcc-kaanapali.c | 6 +-
drivers/clk/qcom/camcc-milos.c | 4 +-
drivers/clk/qcom/camcc-qcs615.c | 2 +-
drivers/clk/qcom/camcc-sc8180x.c | 67 +-
drivers/clk/qcom/camcc-sm8450.c | 4 +-
drivers/clk/qcom/camcc-sm8550.c | 4 +-
drivers/clk/qcom/camcc-sm8650.c | 4 +-
drivers/clk/qcom/camcc-sm8750.c | 4 +-
drivers/clk/qcom/camcc-x1e80100.c | 4 +-
drivers/clk/qcom/clk-rcg2.c | 2 +
drivers/clk/qcom/clk-rpmh.c | 46 +
drivers/clk/qcom/common.h | 4 +-
drivers/clk/qcom/dispcc-eliza.c | 2121 +++++++++++++
drivers/clk/qcom/dispcc-glymur.c | 12 +-
drivers/clk/qcom/dispcc-kaanapali.c | 8 +-
drivers/clk/qcom/dispcc-milos.c | 9 +-
drivers/clk/qcom/dispcc-qcs615.c | 4 +-
drivers/clk/qcom/dispcc-sc7180.c | 8 +
drivers/clk/qcom/dispcc-sc8280xp.c | 4 -
drivers/clk/qcom/dispcc-sm4450.c | 1 -
drivers/clk/qcom/dispcc-sm6115.c | 7 +
drivers/clk/qcom/dispcc-sm6125.c | 7 +
drivers/clk/qcom/dispcc-sm8250.c | 6 +-
drivers/clk/qcom/dispcc0-sa8775p.c | 2 -
drivers/clk/qcom/dispcc1-sa8775p.c | 2 -
drivers/clk/qcom/gcc-eliza.c | 3105 ++++++++++++++++++++
drivers/clk/qcom/gcc-glymur.c | 8 +-
drivers/clk/qcom/gcc-ipq5210.c | 2661 +++++++++++++++++
drivers/clk/qcom/gcc-ipq6018.c | 2 +-
drivers/clk/qcom/gcc-kaanapali.c | 5 +-
drivers/clk/qcom/gcc-milos.c | 4 +-
drivers/clk/qcom/gcc-nord.c | 1902 ++++++++++++
drivers/clk/qcom/gcc-sc8180x.c | 126 +-
drivers/clk/qcom/gcc-x1e80100.c | 1 +
drivers/clk/qcom/gdsc.c | 12 +-
drivers/clk/qcom/gpucc-glymur.c | 618 ++++
drivers/clk/qcom/gpucc-kaanapali.c | 5 +-
drivers/clk/qcom/gpucc-milos.c | 4 +-
drivers/clk/qcom/gpucc-qcs615.c | 4 +-
drivers/clk/qcom/gpucc-sm8750.c | 473 +++
drivers/clk/qcom/gxclkctl-kaanapali.c | 3 +-
drivers/clk/qcom/ipq-cmn-pll.c | 16 +
drivers/clk/qcom/negcc-nord.c | 1987 +++++++++++++
drivers/clk/qcom/nwgcc-nord.c | 688 +++++
drivers/clk/qcom/segcc-nord.c | 1609 ++++++++++
drivers/clk/qcom/tcsrcc-eliza.c | 179 ++
drivers/clk/qcom/tcsrcc-glymur.c | 3 +-
drivers/clk/qcom/tcsrcc-kaanapali.c | 1 -
drivers/clk/qcom/tcsrcc-nord.c | 337 +++
drivers/clk/qcom/tcsrcc-sm8750.c | 2 +-
drivers/clk/qcom/videocc-glymur.c | 532 ++++
drivers/clk/qcom/videocc-kaanapali.c | 4 +-
drivers/clk/qcom/videocc-milos.c | 4 +-
drivers/clk/qcom/videocc-qcs615.c | 4 +-
drivers/clk/qcom/videocc-sm8450.c | 4 +-
drivers/clk/qcom/videocc-sm8550.c | 4 +-
drivers/clk/qcom/videocc-sm8750.c | 5 +-
include/dt-bindings/clock/qcom,dispcc-sc7180.h | 7 +-
include/dt-bindings/clock/qcom,dispcc-sm6125.h | 6 +-
include/dt-bindings/clock/qcom,eliza-dispcc.h | 118 +
include/dt-bindings/clock/qcom,eliza-gcc.h | 210 ++
include/dt-bindings/clock/qcom,eliza-tcsr.h | 17 +
include/dt-bindings/clock/qcom,gcc-sc8180x.h | 5 +
include/dt-bindings/clock/qcom,glymur-gcc.h | 1 +
include/dt-bindings/clock/qcom,glymur-gpucc.h | 51 +
include/dt-bindings/clock/qcom,glymur-videocc.h | 45 +
include/dt-bindings/clock/qcom,ipq5210-gcc.h | 126 +
include/dt-bindings/clock/qcom,ipq6018-cmn-pll.h | 15 +
include/dt-bindings/clock/qcom,ipq8074-cmn-pll.h | 15 +
include/dt-bindings/clock/qcom,nord-gcc.h | 147 +
include/dt-bindings/clock/qcom,nord-negcc.h | 124 +
include/dt-bindings/clock/qcom,nord-nwgcc.h | 69 +
include/dt-bindings/clock/qcom,nord-segcc.h | 98 +
include/dt-bindings/clock/qcom,nord-tcsrcc.h | 26 +
include/dt-bindings/clock/qcom,sm6115-dispcc.h | 7 +-
include/dt-bindings/clock/qcom,sm8750-gpucc.h | 50 +
include/dt-bindings/reset/qcom,ipq5210-gcc.h | 127 +
95 files changed, 18239 insertions(+), 185 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,eliza-dispcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,ipq5210-gcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml
create mode 100644 drivers/clk/qcom/dispcc-eliza.c
create mode 100644 drivers/clk/qcom/gcc-eliza.c
create mode 100644 drivers/clk/qcom/gcc-ipq5210.c
create mode 100644 drivers/clk/qcom/gcc-nord.c
create mode 100644 drivers/clk/qcom/gpucc-glymur.c
create mode 100644 drivers/clk/qcom/gpucc-sm8750.c
create mode 100644 drivers/clk/qcom/negcc-nord.c
create mode 100644 drivers/clk/qcom/nwgcc-nord.c
create mode 100644 drivers/clk/qcom/segcc-nord.c
create mode 100644 drivers/clk/qcom/tcsrcc-eliza.c
create mode 100644 drivers/clk/qcom/tcsrcc-nord.c
create mode 100644 drivers/clk/qcom/videocc-glymur.c
create mode 100644 include/dt-bindings/clock/qcom,eliza-dispcc.h
create mode 100644 include/dt-bindings/clock/qcom,eliza-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,eliza-tcsr.h
create mode 100644 include/dt-bindings/clock/qcom,glymur-gpucc.h
create mode 100644 include/dt-bindings/clock/qcom,glymur-videocc.h
create mode 100644 include/dt-bindings/clock/qcom,ipq5210-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,ipq6018-cmn-pll.h
create mode 100644 include/dt-bindings/clock/qcom,ipq8074-cmn-pll.h
create mode 100644 include/dt-bindings/clock/qcom,nord-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-negcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-nwgcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-segcc.h
create mode 100644 include/dt-bindings/clock/qcom,nord-tcsrcc.h
create mode 100644 include/dt-bindings/clock/qcom,sm8750-gpucc.h
create mode 100644 include/dt-bindings/reset/qcom,ipq5210-gcc.h
^ permalink raw reply
* Re: [PATCH v4 06/10] iommu/arm-smmu-v3: Introduce INV_TYPE_S2_VMID_VSMMU
From: Nicolin Chen @ 2026-04-10 22:32 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260409235913.GZ3357077@nvidia.com>
On Thu, Apr 09, 2026 at 08:59:13PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:52PM -0700, Nicolin Chen wrote:
> > @@ -3246,7 +3248,10 @@ int arm_smmu_find_iotlb_tag(struct iommu_domain *domain,
> > tag->type = INV_TYPE_S1_ASID;
> > break;
> > case ARM_SMMU_DOMAIN_S2:
> > - tag->type = INV_TYPE_S2_VMID;
> > + if (to_vsmmu(domain))
> > + tag->type = INV_TYPE_S2_VMID_VSMMU;
> > + else
> > + tag->type = INV_TYPE_S2_VMID;
> > break;
>
> This shouldn't search, the vmid always comes from the vsmmu struct.
>
> arm_smmu_alloc_iotlb_tag() fixes it after, but the call in
> arm_smmu_attach_prepare_invs() should also only be using the
> vsmmu->vmid so this is a bug.
>
> Just set tag->id here and return. Move the tag->smmu up so that is
> safe.
Yea, I am changing it to this:
case ARM_SMMU_DOMAIN_S2:
- if (to_vsmmu(domain))
+ if (to_vsmmu(domain)) {
+ /*
+ * The VMID for a VSMMU must be pre-allocated during
+ * arm_vsmmu_init(). Return that directly.
+ */
+ WARN_ON(to_vsmmu(domain)->vmid == 0);
tag->type = INV_TYPE_S2_VMID_VSMMU;
- else
- tag->type = INV_TYPE_S2_VMID;
+ tag->id = to_vsmmu(domain)->vmid;
+ tag->smmu = smmu;
+ return 0;
+ }
+ tag->type = INV_TYPE_S2_VMID;
> > @@ -3357,7 +3369,7 @@ arm_smmu_master_build_invs(struct arm_smmu_master *master, bool ats_enabled,
> > return NULL;
> >
> > /* All the nested S1 ASIDs have to be flushed when S2 parent changes */
> > - if (nesting) {
> > + if (tag->type == INV_TYPE_S2_VMID_VSMMU) {
> > if (!arm_smmu_master_build_inv(master,
> > INV_TYPE_S2_VMID_S1_CLEAR,
> > tag->id, IOMMU_NO_PASID, 0))
>
> I think this function should not mix nesting and type at the same
> time..
>
> If INV_TYPE_S2_VMID_VSMMU means the tag is used as a nesting child
> then that should also drive the atc decision:
>
> if (!arm_smmu_master_build_inv(
> master, nesting ? INV_TYPE_ATS_FULL : INV_TYPE_ATS,
> master->streams[i].id, ssid, 0))
I am dropping the nest_parent and changing the 'nesting' here:
- const bool nesting = smmu_domain->nest_parent;
+ const bool nesting = tag->type == INV_TYPE_S2_VMID_VSMMU;
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Kevin Hilman @ 2026-04-10 22:25 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <CAPDyKFrR2zyMFXTAkKs1XRgB-u5jSP256g730s=7SLuOZKsKVg@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
>> >>
>> >> Currently, PM domains can only support hierarchy for simple
>> >> providers (e.g. ones with #power-domain-cells = 0).
>> >>
>> >> Add support for oncell providers as well by adding a new property
>> >> `power-domains-child-ids` to describe the parent/child relationship.
>> >>
>> >> For example, an SCMI PM domain provider has multiple domains, each of
>> >> which might be a child of diffeent parent domains. In this example,
>> >> the parent domains are MAIN_PD and WKUP_PD:
>> >>
>> >> scmi_pds: protocol@11 {
>> >> reg = <0x11>;
>> >> #power-domain-cells = <1>;
>> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
>> >> power-domains-child-ids = <15>, <19>;
>> >> };
>> >>
>> >> With this example using the new property, SCMI PM domain 15 becomes a
>> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
>> >> WKUP_PD.
>> >>
>> >> To support this feature, add two new core functions
>> >>
>> >> - of_genpd_add_child_ids()
>> >> - of_genpd_remove_child_ids()
>> >>
>> >> which can be called by pmdomain providers to add/remove child domains
>> >> if they support the new property power-domains-child-ids.
>> >>
>> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
>> >
>> > Thanks for working on this! It certainly is a missing feature!
>>
>> You're welcome, thanks for the detailed review.
>>
>> >> ---
>> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> include/linux/pm_domain.h | 16 ++++++++++++++++
>> >> 2 files changed, 185 insertions(+)
>> >>
>> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
>> >> index 61c2277c9ce3..acb45dd540b7 100644
>> >> --- a/drivers/pmdomain/core.c
>> >> +++ b/drivers/pmdomain/core.c
>> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
>> >> return genpd;
>> >> }
>> >>
>> >> +/**
>> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
>> >> + * @np: Device node pointer associated with the PM domain provider.
>> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
>> >> + *
>> >> + * Parse the power-domains and power-domains-child-ids properties to establish
>> >> + * parent-child relationships for PM domains. The power-domains property lists
>> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
>> >> + * should be associated with each parent.
>> >> + *
>> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
>> >
>> > I think we should avoid returning specific error codes for specific
>> > errors, simply because it usually becomes messy.
>> >
>> > If I understand correctly the intent here is to allow the caller to
>> > check for -ENOENT and potentially avoid bailing out as it may not
>> > really be an error, right?
>>
>> Right, -ENOENT is not an error of parsing, it's to indicate that there
>> are no child-ids to be parsed.
>>
>> > Perhaps a better option is to return the number of children for whom
>> > we successfully assigned parents. Hence 0 or a positive value allows
>> > the caller to understand what happened. More importantly, a negative
>> > error code then really becomes an error for the caller to consider.
>>
>> I explored this a bit, but it gets messy quick. It means we have to
>> track cases where only some of the children were added as well as when
>> all children were added. Personally, I think this should be an "all or
>> nothing" thing. If all the children cannot be parsed/added, then none
>> of them should be added.
>>
>> This also allows the remove to not have to care about how many were
>> added, and just remove them all, with the additional benefit of not
>> having to track the state of how many children were successfully added.
>>
>
> I fully agree, it should be all or nothing. Failing with one
> child/parent should end up with an error code being returned.
>
> That said, it still seems to make perfect sense to return the number
> of children for whom we assigned parents for, no?
No, because what will the caller use that number for? If we are
assuming "all or nothing", what would we use it for (other than a debug print?)
It also makes it a bit confusing what a zero return value means. Does
that mean success? Or that zero children were added (which would be
fail.)
I prefer to keep it as is.
Kevin
^ permalink raw reply
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Nicolin Chen @ 2026-04-10 22:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410002734.GC3357077@nvidia.com>
On Thu, Apr 09, 2026 at 09:27:34PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > index 846a278fa5469..0e48264ccd01b 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> > */
> > arm_smmu_domain_inv(smmu_domain);
> >
> > - /*
> > - * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> > - * still be called/running at this point. We allow the ASID to be
> > - * reused, and if there is a race then it just suffers harmless
> > - * unnecessary invalidation.
> > - */
> > - xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> > -
>
> I don't think this artifact has disappeared so the comment should
> probably remain too. It has become slightly different because it is
> now running under RCU protections so it will clear alot faster.
By taking a closer look, I think either the arm_smmu_domain_inv call
above or any concurrent arm_smmu_mm_arch_invalidate_secondary_tlbs
call is a NOP now?
We reworked the ASID lifecycle, which now ends when the last device
detaches. So, ASID was free-ed in arm_smmu_iotlb_tag_free() that did
a per-ASID flush also.
So, when freeing the SVA domain here, the domain should have an empty
invalidation array and the HW cache is flushed as well, right?
Nicolin
^ permalink raw reply
* [PATCH net-next] net: airoha: Wait for TX to complete in airoha_dev_stop()
From: Lorenzo Bianconi @ 2026-04-10 22:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Wait for TX to complete in airoha_dev_stop routine before stopping the
TX DMA and run airoha_qdma_cleanup_tx_queue routine. Moreover,
start/stop TX/RX NAPIs in ndo_open()/ndo_stop() callbacks in order to be
sure the TX NAPIs have completed before stopping the TX DMA engine in
airoha_dev_stop routine.
Please note this patch on the commit 'b1c803d5c816 ("net: airoha: Rework
the code flow in airoha_remove() and in airoha_probe() error path")'
that is available only in net-next tree at the moment.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 44 +++++++++++++++++---------------
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 8e4b043af4bc..9e40c8f375c1 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1662,10 +1662,12 @@ static int airoha_dev_open(struct net_device *dev)
FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
FIELD_PREP(GDM_LONG_LEN_MASK, len));
- airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
- GLOBAL_CFG_TX_DMA_EN_MASK |
- GLOBAL_CFG_RX_DMA_EN_MASK);
- atomic_inc(&qdma->users);
+ if (!atomic_fetch_inc(&qdma->users)) {
+ airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
+ GLOBAL_CFG_TX_DMA_EN_MASK |
+ GLOBAL_CFG_RX_DMA_EN_MASK);
+ airoha_qdma_start_napi(qdma);
+ }
if (port->id == AIROHA_GDM2_IDX &&
airoha_ppe_is_enabled(qdma->eth, 1)) {
@@ -1684,18 +1686,26 @@ static int airoha_dev_stop(struct net_device *dev)
struct airoha_qdma *qdma = port->qdma;
int i, err;
- netif_tx_disable(dev);
err = airoha_set_vip_for_gdm_port(port, false);
if (err)
return err;
- for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
- netdev_tx_reset_subqueue(dev, i);
-
airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
+ netif_tx_disable(dev);
if (atomic_dec_and_test(&qdma->users)) {
+ u32 val;
+
+ /* Wait for TX to complete */
+ err = read_poll_timeout(airoha_qdma_rr, val,
+ !(val & GLOBAL_CFG_TX_DMA_BUSY_MASK),
+ USEC_PER_MSEC, 100 * USEC_PER_MSEC,
+ false, qdma, REG_QDMA_GLOBAL_CFG);
+ if (err)
+ return err;
+
+ airoha_qdma_stop_napi(qdma);
airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
@@ -1708,6 +1718,9 @@ static int airoha_dev_stop(struct net_device *dev)
}
}
+ for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
+ netdev_tx_reset_subqueue(dev, i);
+
return 0;
}
@@ -3048,9 +3061,6 @@ static int airoha_probe(struct platform_device *pdev)
if (err)
goto error_netdev_free;
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_start_napi(ð->qdma[i]);
-
for_each_child_of_node(pdev->dev.of_node, np) {
if (!of_device_is_compatible(np, "airoha,eth-mac"))
continue;
@@ -3061,20 +3071,17 @@ static int airoha_probe(struct platform_device *pdev)
err = airoha_alloc_gdm_port(eth, np);
if (err) {
of_node_put(np);
- goto error_napi_stop;
+ goto error_netdev_unregister;
}
}
err = airoha_register_gdm_devices(eth);
if (err)
- goto error_napi_stop;
+ goto error_netdev_unregister;
return 0;
-error_napi_stop:
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_stop_napi(ð->qdma[i]);
-
+error_netdev_unregister:
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
@@ -3098,9 +3105,6 @@ static void airoha_remove(struct platform_device *pdev)
struct airoha_eth *eth = platform_get_drvdata(pdev);
int i;
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_stop_napi(ð->qdma[i]);
-
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
---
base-commit: 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7
change-id: 20260410-airoha-fix-ndo_stop-ebbf3c724ae0
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 0/6] perf arm_spe: Dump IMPDEF events
From: Arnaldo Carvalho de Melo @ 2026-04-10 22:05 UTC (permalink / raw)
To: Namhyung Kim
Cc: James Clark, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, linux-arm-kernel,
linux-perf-users, linux-kernel, Leo Yan
In-Reply-To: <adkqSLNceF2OQuBo@google.com>
On Fri, Apr 10, 2026 at 09:50:16AM -0700, Namhyung Kim wrote:
> Hi James,
>
> On Tue, Apr 07, 2026 at 03:05:14PM +0100, James Clark wrote:
> > In the Arm SPE raw data dump, IMPDEF events aren't printed. Add the
> > ability to add names for some known events or print the raw event number
> > for unknown events.
> >
> > For example:
> >
> > $ perf report -D
> >
> > ... ARM SPE data: size 0xd000 bytes
> > 00000000: b0 18 c6 32 80 00 80 ff a0 PC 0xff80008032c618 el1 ns=1
> > 00000009: 64 e7 42 00 00 CONTEXT 0x42e7 el1
> > 0000000e: 00 00 00 00 00 PAD
> > 00000013: 49 00 LD GP-REG
> > 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS
> >
> > On N1 the event line becomes:
> >
> > 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS LATE-PREFETCH
> >
> > Or on other cores it becomes:
> >
> > 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS IMPDEF:12
> >
> > Signed-off-by: James Clark <james.clark@linaro.org>
> > ---
> > Changes in v2:
> > - Put MIDR in arm_spe_pkt (Leo)
> > - Use for_each_set_bit() (Leo)
> > - Use BIT_ULL() to fix 32bit builds (Ian)
> > - Don't call strtol() with NULL (Ian)
> > - Link to v1: https://lore.kernel.org/r/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org
>
> I'm getting this on 32-bit build.
>
> In file included from /linux/tools/include/linux/bitmap.h:8,
> from util/arm-spe-decoder/arm-spe-pkt-decoder.c:11:
> util/arm-spe-decoder/arm-spe-pkt-decoder.c: In function 'arm_spe_pkt_desc_event':
> util/arm-spe-decoder/arm-spe-pkt-decoder.c:377:37: error: passing argument 1 of 'find_first_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 377 | for_each_set_bit(i, &payload, 64) {
> /linux/tools/include/linux/bitops.h:55:38: note: in definition of macro 'for_each_set_bit'
> 55 | for ((bit) = find_first_bit((addr), (size)); \
> | ^~~~
> In file included from /linux/tools/include/linux/bitmap.h:9:
> /linux/tools/include/linux/find.h:118:51: note: expected 'const long unsigned int *' but argument is of type 'u64 *' {aka 'long long unsigned int *'}
> 118 | unsigned long find_first_bit(const unsigned long *addr, unsigned long size)
> | ~~~~~~~~~~~~~~~~~~~~~^~~~
I saw this as well.
- Arnaldo
^ permalink raw reply
* [PATCH net] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-10 21:49 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in
airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to
TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 31 ++++++++++++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 9285a68f435f..963ab7b8d166 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1044,13 +1044,17 @@ static int airoha_qdma_init_tx(struct airoha_qdma *qdma)
static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
- int i;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int i, qid = q - &qdma->q_tx[0];
+ struct airoha_queue_entry *e;
+ u16 index;
spin_lock_bh(&q->lock);
for (i = 0; i < q->ndesc; i++) {
- struct airoha_queue_entry *e = &q->entry[i];
+ struct airoha_qdma_desc *desc = &q->desc[i];
+ e = &q->entry[i];
if (!e->dma_addr)
continue;
@@ -1060,8 +1064,29 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
e->dma_addr = 0;
e->skb = NULL;
list_add_tail(&e->list, &q->tx_list);
+
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+
q->queued--;
}
+
+ e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
+ list);
+ index = e - q->entry;
+ /* Set TX_DMA_IDX to TX_CPU_IDX to notify the hw the QDMA TX ring is
+ * empty.
+ */
+ airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
+ FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
+ airoha_qdma_rmw(qdma, REG_TX_DMA_IDX(qid), TX_RING_DMA_IDX_MASK,
+ FIELD_PREP(TX_RING_DMA_IDX_MASK, index));
+
spin_unlock_bh(&q->lock);
}
---
base-commit: 12ff2a4aee6c86746623d5aed24389dbf6dffded
change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Jason Gunthorpe @ 2026-04-10 21:41 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <adlqZLZMr9VfnKse@Asurada-Nvidia>
On Fri, Apr 10, 2026 at 02:23:48PM -0700, Nicolin Chen wrote:
> Reworking the SVA code, I found arm_smmu_update_s1_domain_cd_entry
> is marked as __maybe_unused and not getting called anywhere(?). Do
> you recall why we kept it?
I intended to send the vBTM support that uses it, and now that this is
done it can work properly without races. So lets hang on, I was
meaning to look at that soon
Jason
^ permalink raw reply
* RE: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses
From: Kameron Carr @ 2026-04-10 21:36 UTC (permalink / raw)
To: 'Catalin Marinas'
Cc: will, suzuki.poulose, steven.price, ryan.roberts, dev.jain, yang,
shijie, kevin.brodsky, linux-arm-kernel, linux-kernel
In-Reply-To: <adjZpFIgXQYOvyTq@arm.com>
On Friday, April 10, 2026 4:06 AM, Catalin Marinas wrote:
> Could you give more details about the user of set_memory_decrypted() on
> vmalloc()'ed addresses? I think this came up in the past and I wondered
> whether something like GFP_DECRYPTED would be simpler to implement (even
> posted a hack but without vmalloc() support). If it is known upfront
> that the memory will be decrypted, it's easier/cheaper to do this on the
> page allocation time to change the linear map and just use
> pgprot_decrypted() for vmap(). No need to rewrite the page table after
> mapping the pages.
Thank you for the review. I understand that my approach is not ideal in
terms of speed / cost. For my use case it was not an issue since the
memory is typically only initialized once during device initialization,
but I understand there could be a larger performance impact in other
uses.
The use case I am interested in is Hyper-V netvsc
(drivers/net/hyperv/netvsc.c). The network driver allocates large send
and receive buffers (typically 16MB+) with vzalloc(), then registers them
as Guest Physical Address Descriptor Lists (GPADLs) via
vmbus_establish_gpadl(). Inside __vmbus_establish_gpadl()
(drivers/hv/channel.c), set_memory_decrypted() is called on the buffer so
the hypervisor can access the shared memory.
In this use case, whether to decrypt the memory can always be known at
time of allocation, so a solution like GFP_DECRYPTED is an option.
I think I found the hack you mentioned
(https://lore.kernel.org/linux-arm-kernel/ZmNJdSxSz-sYpVgI@arm.com/). The
feedback in Michael Kelley's reply covers the key considerations well. He
likely had netvsc's use of vmalloc in mind when he made the point
"GFP_DECRYPTED should work for the three memory allocation interfaces and
their variants: alloc_pages(), kmalloc(), and vmalloc()." His other
points already cover the concerns I had in mind around handling errors
from set_memory_decrypted()/encrypted(), etc.
What is the current status of your proposed GFP_DECRYPTED implementation?
Is this something you are actively working on?
I'd be happy to work on an RFC following the GFP_DECRYPTED approach if
you think that's the right direction.
Regards,
Kameron Carr
^ permalink raw reply
* [PATCH 2/3] drm/exynos: remove bridge when component_add fails
From: Osama Abdelkader @ 2026-04-10 21:27 UTC (permalink / raw)
To: luca.ceresoli, Inki Dae, Seung-Woo Kim, Kyungmin Park,
David Airlie, Simona Vetter, Krzysztof Kozlowski, Alim Akhtar,
dri-devel, linux-arm-kernel, linux-samsung-soc, linux-kernel
Cc: Osama Abdelkader
In-Reply-To: <20260410212801.413827-2-osama.abdelkader@gmail.com>
when component_add fails in exynos_mic_probe remove drm
bridge before return
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 29a8366513fa..5e771b236bf0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -437,6 +437,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
err_pm:
pm_runtime_disable(dev);
+ drm_bridge_remove(&mic->bridge);
err:
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Nicolin Chen @ 2026-04-10 21:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410204709.GB2588311@nvidia.com>
On Fri, Apr 10, 2026 at 05:47:09PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2026 at 11:52:01AM -0700, Nicolin Chen wrote:
> > > Only readers *with the possibility of concurrent access* should be
> > > marked with READ_ONCE. IIRC this is just the invalidation walker.
> >
> > I added a cleanup patch to the beginning of the series and corrected
> > all the new reads/writes too.
> >
> > > Places like this have to be protected by a lock or the whole thing is
> > > wrong, so it should have a lockdep annoation.
> >
> > Hmm, is the lockdep_is_held() in rcu_dereference_protected() enough?
>
> Yes.. but I didn't notice it there, not where I usually look for
> lockdeps :)
I added two new asserts in the find/get() and put notes in kdocs.
> But also that should have failed in your testing in the SVA case, so
> make sure you test with lockdep on, and segfault some app using SVA to
> trigger the error clean up flow.
Ack. I recall I tried SVA case with CONFIG_LOCKDEP=y. But it did
not cover the error clean up flow..
Reworking the SVA code, I found arm_smmu_update_s1_domain_cd_entry
is marked as __maybe_unused and not getting called anywhere(?). Do
you recall why we kept it?
> > > But why does arm_smmu_mm_release() need a tag in the first place? ASID
> > > isn't going to be used when EPD0|EPD1 is set, so the tag can just be
> > > 0. Probably make a patch with that change early on..
> >
> > I see. I added a cleanup patch.
>
> Also double check it still generates a hitless update, I think it
> should but worth confirming.
Both EDP0 and ASID are in the word0 of a CD:
CTXDESC_CD_0_ASID
CTXDESC_CD_0_TCR_EPD0
So, used_qword_diff is 0x1. I think we are good.
> Also is ASID 0 used at all?
Setting EPD0/1 disables any PT walk. HW could still use an ASID to
match the cache lines. But, in this release pathway, the cache will
be flushed also. And completely aborting any ASID usage makes sense
to me. So, passing ASID=0 to guarantee a TLB miss should work.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH 3/4] pinctrl: vt8500: Enable compile testing
From: Sander Vanheule @ 2026-04-10 21:22 UTC (permalink / raw)
To: Krzysztof Kozlowski, Linus Walleij, Andreas Färber
Cc: linux-gpio, linux-kernel, Andrew Jeffery, linux-aspeed, openbmc,
linux-arm-kernel, Joel Stanley, linux-realtek-soc, James Tai,
Yu-Chun Lin
In-Reply-To: <20260410-pinctrl-testing-v1-3-6f708c855867@oss.qualcomm.com>
Hi Krzysztof,
On Fri, 2026-04-10 at 15:04 +0200, Krzysztof Kozlowski wrote:
> Enable compile testing for Realtek pin controller drivers for increased
Small nit, but this looks like a copy-paste error from the other patch.
Realtek -> VIA/Wondermedia (or vt8500, whatever you prefer)
Best,
Sander
^ permalink raw reply
* Re: [PATCH RFC net-next 02/10] net: stmmac: rename dev_id to userver
From: Jitendra Vegiraju @ 2026-04-10 21:04 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adi3Vks-N0a83ylE@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
On Fri, Apr 10, 2026 at 1:39 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Apr 09, 2026 at 04:07:42PM -0700, Jitendra Vegiraju wrote:
> > Hi Russell,
> >
> > On Wed, Apr 8, 2026 at 2:27 AM Russell King (Oracle)
> > <rmk+kernel@armlinux.org.uk> wrote:
> > >
> > > The Synopsys Databook and several implementation TRMs identify bits
> > > 15:8 of the version register in dwmac v3.xx and v4.xx as "userver".
> > > We even print its value with "User ID". Rather than using "dev_id",
> > > use "userver" instead.
> > >
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > ---
> > > drivers/net/ethernet/stmicro/stmmac/hwif.c | 18 +++++++++---------
> > > 1 file changed, 9 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > index 3774af66db48..830ff816ab4f 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> > > @@ -15,7 +15,7 @@
> > >
> > > struct stmmac_version {
> > > u8 snpsver;
> > > - u8 dev_id;
> > > + u8 userver;
> > > };
> > From the XGMAC databook that I have access to bits(15:8) identify the
> > DEVID field of MAC_version register.
> > The userver field is from bits(23:16) of the same register. This is a
> > customer defined field (configured with coreConsultant).
> > Currently stmmac doesn't care about bits(23:16).
>
> Thanks for the additional information.
>
> I don't have any XGMAC documentation, but this indicates that it differs
> between XGMAC and previous cores - GMAC and GMAC4 cores, 15:8 are
> documented as userver, and 31:16 are marked as reserved.
>
> Note that the dev_info() also prints 15:8 as "User ID" not "Device ID".
>
> To confirm, is the XGMAC version register at offset 0x20 ? Later GMAC
> cores moved it to 0x110.
The XGMAC version register is at offset 0x110.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5435 bytes --]
^ permalink raw reply
* [patch V1.1 11/38] misc: sgi-gru: Remove get_cycles() [ab]use
From: Thomas Gleixner @ 2026-04-10 20:56 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120318.320727701@kernel.org>
Calculating a timeout from get_cycles() is a historical leftover without
any functional requirement.
Use ktime_get() instead.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
---
V2: Fix typo
---
drivers/misc/sgi-gru/gruhandles.c | 20 ++++++++------------
drivers/misc/sgi-gru/grukservices.c | 3 ++-
drivers/misc/sgi-gru/grutlbpurge.c | 5 ++---
3 files changed, 12 insertions(+), 16 deletions(-)
--- a/drivers/misc/sgi-gru/gruhandles.c
+++ b/drivers/misc/sgi-gru/gruhandles.c
@@ -6,26 +6,22 @@
*/
#include <linux/kernel.h>
+#include <linux/timekeeping.h>
#include "gru.h"
#include "grulib.h"
#include "grutables.h"
-/* 10 sec */
#include <linux/sync_core.h>
-#include <asm/tsc.h>
-#define GRU_OPERATION_TIMEOUT ((cycles_t) tsc_khz*10*1000)
-#define CLKS2NSEC(c) ((c) * 1000000 / tsc_khz)
+
+#define GRU_OPERATION_TIMEOUT_NSEC (((ktime_t)10 * NSEC_PER_SEC))
/* Extract the status field from a kernel handle */
#define GET_MSEG_HANDLE_STATUS(h) (((*(unsigned long *)(h)) >> 16) & 3)
struct mcs_op_statistic mcs_op_statistics[mcsop_last];
-static void update_mcs_stats(enum mcs_op op, unsigned long clks)
+static void update_mcs_stats(enum mcs_op op, unsigned long nsec)
{
- unsigned long nsec;
-
- nsec = CLKS2NSEC(clks);
atomic_long_inc(&mcs_op_statistics[op].count);
atomic_long_add(nsec, &mcs_op_statistics[op].total);
if (mcs_op_statistics[op].max < nsec)
@@ -58,21 +54,21 @@ static void report_instruction_timeout(v
static int wait_instruction_complete(void *h, enum mcs_op opc)
{
+ ktime_t start_time = ktime_get();
int status;
- unsigned long start_time = get_cycles();
while (1) {
cpu_relax();
status = GET_MSEG_HANDLE_STATUS(h);
if (status != CCHSTATUS_ACTIVE)
break;
- if (GRU_OPERATION_TIMEOUT < (get_cycles() - start_time)) {
+ if (GRU_OPERATION_TIMEOUT_NSEC < (ktime_get() - start_time)) {
report_instruction_timeout(h);
- start_time = get_cycles();
+ start_time = ktime_get();
}
}
if (gru_options & OPT_STATS)
- update_mcs_stats(opc, get_cycles() - start_time);
+ update_mcs_stats(opc, (unsigned long)(ktime_get() - start_time));
return status;
}
--- a/drivers/misc/sgi-gru/grukservices.c
+++ b/drivers/misc/sgi-gru/grukservices.c
@@ -20,6 +20,7 @@
#include <linux/uaccess.h>
#include <linux/delay.h>
#include <linux/export.h>
+#include <linux/random.h>
#include <asm/io_apic.h>
#include "gru.h"
#include "grulib.h"
@@ -1106,7 +1107,7 @@ static int quicktest3(unsigned long arg)
int ret = 0;
memset(buf2, 0, sizeof(buf2));
- memset(buf1, get_cycles() & 255, sizeof(buf1));
+ memset(buf1, get_random_u32() & 255, sizeof(buf1));
gru_copy_gpa(uv_gpa(buf2), uv_gpa(buf1), BUFSIZE);
if (memcmp(buf1, buf2, BUFSIZE)) {
printk(KERN_DEBUG "GRU:%d quicktest3 error\n", smp_processor_id());
--- a/drivers/misc/sgi-gru/grutlbpurge.c
+++ b/drivers/misc/sgi-gru/grutlbpurge.c
@@ -22,13 +22,12 @@
#include <linux/delay.h>
#include <linux/timex.h>
#include <linux/srcu.h>
+#include <linux/random.h>
#include <asm/processor.h>
#include "gru.h"
#include "grutables.h"
#include <asm/uv/uv_hub.h>
-#define gru_random() get_cycles()
-
/* ---------------------------------- TLB Invalidation functions --------
* get_tgh_handle
*
@@ -49,7 +48,7 @@ static inline int get_off_blade_tgh(stru
int n;
n = GRU_NUM_TGH - gru->gs_tgh_first_remote;
- n = gru_random() % n;
+ n = get_random_u32() % n;
n += gru->gs_tgh_first_remote;
return n;
}
^ permalink raw reply
* [patch V1.1 02/38] x86: Cleanup include recursion hell
From: Thomas Gleixner @ 2026-04-10 20:55 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120317.709923681@kernel.org>
Including a random architecture specific header which requires global
headers just to avoid including that header at the two usage sites is
really beyond lazy and tasteless. Including global headers just to get the
__percpu macro from linux/compiler_types.h falls into the same category.
Remove the linux/percpu.h and asm/cpumask.h includes from msr.h and smp.h
and fix the resulting fallout by a simple forward struct declaration and by
including the x86 specific asm/cpumask.h header where it is actually
required.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
---
V1.1: Fix PARAVIRT_XXL fallout....
---
arch/x86/include/asm/cache.h | 1 +
arch/x86/include/asm/msr.h | 5 +++--
arch/x86/include/asm/paravirt.h | 3 ++-
arch/x86/include/asm/pvclock.h | 1 +
arch/x86/include/asm/smp.h | 2 --
arch/x86/include/asm/vdso/gettimeofday.h | 5 ++---
arch/x86/kernel/cpu/mce/core.c | 1 +
arch/x86/kernel/nmi.c | 1 +
arch/x86/kernel/smpboot.c | 1 +
9 files changed, 12 insertions(+), 8 deletions(-)
--- a/arch/x86/include/asm/cache.h
+++ b/arch/x86/include/asm/cache.h
@@ -2,6 +2,7 @@
#ifndef _ASM_X86_CACHE_H
#define _ASM_X86_CACHE_H
+#include <vdso/page.h>
#include <linux/linkage.h>
/* L1 cache line size */
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -8,12 +8,11 @@
#include <asm/asm.h>
#include <asm/errno.h>
-#include <asm/cpumask.h>
#include <uapi/asm/msr.h>
#include <asm/shared/msr.h>
+#include <linux/compiler_types.h>
#include <linux/types.h>
-#include <linux/percpu.h>
struct msr_info {
u32 msr_no;
@@ -256,6 +255,8 @@ int msr_set_bit(u32 msr, u8 bit);
int msr_clear_bit(u32 msr, u8 bit);
#ifdef CONFIG_SMP
+struct cpumask;
+
int rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
int wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
int rdmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 *q);
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -16,9 +16,10 @@
#ifndef __ASSEMBLER__
#include <linux/types.h>
-#include <linux/cpumask.h>
#include <asm/frame.h>
+struct cpumask;
+
/* The paravirtualized I/O functions */
static inline void slow_down_io(void)
{
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -2,6 +2,7 @@
#ifndef _ASM_X86_PVCLOCK_H
#define _ASM_X86_PVCLOCK_H
+#include <asm/barrier.h>
#include <asm/clocksource.h>
#include <asm/pvclock-abi.h>
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -5,8 +5,6 @@
#include <linux/cpumask.h>
#include <linux/thread_info.h>
-#include <asm/cpumask.h>
-
DECLARE_PER_CPU_CACHE_HOT(int, cpu_number);
DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map);
--- a/arch/x86/include/asm/vdso/gettimeofday.h
+++ b/arch/x86/include/asm/vdso/gettimeofday.h
@@ -11,13 +11,12 @@
#define __ASM_VDSO_GETTIMEOFDAY_H
#ifndef __ASSEMBLER__
-
+#include <clocksource/hyperv_timer.h>
#include <uapi/linux/time.h>
+
#include <asm/vgtod.h>
#include <asm/unistd.h>
-#include <asm/msr.h>
#include <asm/pvclock.h>
-#include <clocksource/hyperv_timer.h>
#include <asm/vdso/sys_call.h>
#define VDSO_HAS_TIME 1
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -48,6 +48,7 @@
#include <linux/vmcore_info.h>
#include <asm/fred.h>
+#include <asm/cpumask.h>
#include <asm/cpu_device_id.h>
#include <asm/processor.h>
#include <asm/traps.h>
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -26,6 +26,7 @@
#include <linux/sched/clock.h>
#include <linux/kvm_types.h>
+#include <asm/cpumask.h>
#include <asm/cpu_entry_area.h>
#include <asm/traps.h>
#include <asm/mach_traps.h>
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -70,6 +70,7 @@
#include <asm/irq.h>
#include <asm/realmode.h>
#include <asm/cpu.h>
+#include <asm/cpumask.h>
#include <asm/numa.h>
#include <asm/tlbflush.h>
#include <asm/mtrr.h>
^ permalink raw reply
* Re: [PATCH 1/1] virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
From: Gavin Shan @ 2026-04-10 20:50 UTC (permalink / raw)
To: Sami Mujawar, linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, steven.price, suzuki.poulose, YeoReum.Yun,
Jagdish Gediya
In-Reply-To: <20260410163636.259443-1-sami.mujawar@arm.com>
On 4/11/26 2:36 AM, Sami Mujawar wrote:
> The RSI interface can return RSI_INCOMPLETE when a report spans
> multiple granules. This is an expected condition and should not be
> treated as a fatal error.
>
> Currently, arm_cca_report_new() checks for `info.result != RSI_SUCCESS`
> and bails out, which incorrectly flags RSI_INCOMPLETE as a failure.
> Fix the check to only break out on results other than RSI_SUCCESS or
> RSI_INCOMPLETE.
>
> This ensures partial reports are handled correctly and avoids spurious
> -ENXIO errors when generating attestation reports.
>
> Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms")
> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
> Reported-by: Jagdish Gediya <Jagdish.Gediya@arm.com>
> ---
> drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-04-10 20:49 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <adiop-9Mo4ADfvfw@lore-desk>
On Fri, 10 Apr 2026 09:37:11 +0200 Lorenzo Bianconi wrote:
> > On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> > > EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> > > Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> > > manages the traffic in a TDM manner. As a result multiple net_devices can
> > > connect to the same GDM{3,4} port and there is a theoretical "1:n"
> > > relation between GDM ports and net_devices.
> >
> > Looks like this driver uses page pool.
> > If you're sharing the same page pool across multiple netdevs
> > it must not be linked to a netdev.
>
> are you referring to slow.netdev pointer? If so, this is not set in airoha_eth
> driver.
Yes. Alright, thanks for checking. Pretty sure I saw it set somewhere
in a file called airoha* but must be another component :)
^ permalink raw reply
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Jason Gunthorpe @ 2026-04-10 20:47 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <adlG0QTAzdh9vA4M@Asurada-Nvidia>
On Fri, Apr 10, 2026 at 11:52:01AM -0700, Nicolin Chen wrote:
> > Only readers *with the possibility of concurrent access* should be
> > marked with READ_ONCE. IIRC this is just the invalidation walker.
>
> I added a cleanup patch to the beginning of the series and corrected
> all the new reads/writes too.
>
> > Places like this have to be protected by a lock or the whole thing is
> > wrong, so it should have a lockdep annoation.
>
> Hmm, is the lockdep_is_held() in rcu_dereference_protected() enough?
Yes.. but I didn't notice it there, not where I usually look for
lockdeps :)
But also that should have failed in your testing in the SVA case, so
make sure you test with lockdep on, and segfault some app using SVA to
trigger the error clean up flow.
> > But why does arm_smmu_mm_release() need a tag in the first place? ASID
> > isn't going to be used when EPD0|EPD1 is set, so the tag can just be
> > 0. Probably make a patch with that change early on..
>
> I see. I added a cleanup patch.
Also double check it still generates a hitless update, I think it
should but worth confirming.
Also is ASID 0 used at all?
Jason
^ permalink raw reply
* Re: [PATCH V3 7/7] arm64/hw_breakpoint: Enable FEAT_Debugv8p9
From: Rob Herring @ 2026-04-10 19:55 UTC (permalink / raw)
To: Mark Rutland
Cc: Anshuman Khandual, linux-arm-kernel, linux-kernel,
Jonathan Corbet, Marc Zyngier, Oliver Upton, James Morse,
Suzuki K Poulose, Catalin Marinas, Will Deacon, Mark Brown,
kvmarm
In-Reply-To: <adeE4MD0RgapI8aL@J2N7QTR9R3>
On Thu, Apr 9, 2026 at 5:52 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Thu, Apr 02, 2026 at 12:46:56PM -0500, Rob Herring wrote:
> > On Thu, Apr 2, 2026 at 5:37 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > On Tue, Mar 31, 2026 at 05:58:00PM -0500, Rob Herring wrote:
> > > > On Mon, Dec 16, 2024 at 10:58:29AM +0000, Mark Rutland wrote:
> > > > > On Mon, Dec 16, 2024 at 09:38:31AM +0530, Anshuman Khandual wrote:
> > > That said, the use of 'bp_per_reg' looks suspect given their
> > > arch_install_hw_breakpoint() and arch_uninstall_hw_breakpoint() modify
> > > that non-atomically.
> >
> > You don't believe the comment saying counter->ctx->lock is held?
>
> Sorry, my concern here was that hw_breakpoint_handler() (which cannot
> hold the lock) consumes bp_per_reg[], and could race with the non-atomic
> modification in arch_install_hw_breakpoint() or
> arch_uninstall_hw_breakpoint().
>
> I've sent a more elaborate mail to x86 folk, with that and another issue
> caused by taking a breakpoint under arch_uninstall_hw_breakpoint():
>
> https://lore.kernel.org/lkml/adZWmPW8S9Y2pwkv@J2N7QTR9R3.cambridge.arm.com/
>
> I think we have a similar latent issue where we can take an breakpoint
> or watchpoint ad infinitum, described in more detail at the end of this
> mail.
>
> [...]
>
> > > > > | What prevents a race with an exception handler? e.g.
> > > > > |
> > > > > | * Does the structure of the code prevent that somehow?
> > > >
> > > > If you can't set a breakpoint/watchpoint in NOKPROBE_SYMBOL() annotated
> > > > code, you can't race.
> > >
> > > As above, I agree (with caveats), but I couldn't spot where this is
> > > enforced.
> > >
> > > > However, there's no such annotation for data. It looks like the kernel
> > > > policy is "don't do that" or disable all breakpoints/watchpoints.
> > >
> > > If we have to transiently disable watchpoints/breakpoints when
> > > manipulating the relevant HW registers, that sounds fine to me.
> >
> > For wp/bp_on_reg, the ordering is 'data access, h/w accesses'. I think
> > we just need a barrier to enforce that ordering so the data access
> > (and then watchpoint) don't trigger in the middle of the h/w accesses.
>
> I assume that by 'h/w accesses' you mean MSRs to the system registers
> controlling breakpoints/watchpoints. Ordering-wise, I don't believe
> memory barriers are necessary here (explain in more detail below).
> However, I also think there's a latent issue here that might bite us
> with the new banking, described at the end of this mail.
>
> Both breakpoint and watchpoint exceptions are synchronous, meanning that
> they can only be taken from the specific instruction that triggered
> them. However, updates to the watchpoint control registers *do* need a
> context synchronization event before they're guarnateed to take effect.
>
> For a sequence:
>
> // Initially:
> // - MDSCR, MDCR, DAIF.D permit debug exceptions at CurrentEL
> // - No watchpoints enabled
>
> 0x000: LDR <val>, [<addr>]
> 0x004: MSR DBGWVR<n>_EL1, <addr>
> 0x008: MSR DBGWCR<n>_EL1, <configure_and_enable>
> 0x010: LDR <val>, [<addr>]
> 0x014: ISB
> 0x018: LDR <val>, [<addr>]
>
> ... we know:
>
> (a) The LDR at 0x000 *cannot* trigger the watchpoint.
Why not? Can't the LDR complete after the MSR? Is ordering ensured
between those? Surely the watchpoint triggers on completion of the
load and that wouldn't stall the PE from doing the MSR(s)?
> (b) The LDR at 0x010 *might* trigger the matchpoint.
> (c) The LDR at 0x018 *must* trigger the watchpoint.
>
> For C code, we can enforce this order with barrier(), e.g.
>
> val = *addr;
> barrier();
> write_sysreg(addr, DBGWVR<n>_EL1);
> write_sysreg(configure_and_enable, DBGWCR<n>_EL1);
> isb();
>
> ... where the compiler cannot re-order the memory access (or
> write_sysreg(), or isb()) across the barrier(), and as isb() has a
> memory clobber, the same is true for isb().
>
> Likewise, for the inverse sequence:
>
> // Initially:
> // - MDSCR, MDCR, DAIF.D permit debug exceptions at CurrentEL
> // - Watchpoint configured and enabled for <addr>
>
> 0x100: LDR <val>, [<addr>]
> 0x104: MSR DBGWCR<n>_EL1, <disable>
> 0x108: LDR <val>, [<addr>]
> 0x110: ISB
> 0x114: LDR <val>, [<addr>]
>
> ... we know:
>
> (a) The LDR at 0x100 *must* trigger the watchpoint.
> (b) The LDR at 0x108 *might* trigger the watchpoint.
> (c) The LDR at 0x114 *cannot* trigger the watchpoint.
>
> > Any guidance on the flavor of dsb here? (And is there any guarantee
> > that the access is visible to the watchpoint h/w after a dsb
> > completes?)
>
> Hopefully the above was sufficient?
>
> As mentioned above, I think we have a latent issue where we can take a
> breakpoint or watchpoint under arch_uninstall_hw_breakpoint(), where we
> have:
>
> arch_uninstall_hw_breakpoint(bp) {
> ...
> hw_breakpoint_control(bp, HW_BREAKPOINT_UNINSTALL) {
> ...
> hw_breakpoint_slot_setup(slots, max_slots, bp, HW_BREAKPOINT_UNINSTALL) {
> ...
> *slot = NULL;
> ...
> }
> ...
> write_wb_reg(ctrl_reg, i, 0) {
> ...
> write_sysreg(0, ...);
> isb();
> ...
> }
> }
> }
>
> The HW breakpoint/watchpoint associated with 'bp' could be triggered
> between setting '*slot' to NULL and the ISB. If that happens, then
> do_breakpoint() won't find 'bp', and will return *without* disabling the
> HW breakpoint or attempting to step.
>
> If that first exception was taken *before* the MSR in write_sysreg(),
> then nothing has changed, and the breakpoint/watchpoint will then be
> taken again ad infinitum.
>
> If that first exception was taken *after* the MSR in write_sysreg(), the
> context synchronization provided by exception entry/return will prevent
> it from being taken again.
>
> Building v6.19 and testing (with pseudo-NMI enabled):
>
> | # grep write_wb_reg /proc/kallsyms
> | ffff80008004b980 t write_wb_reg
> | # ./perf-6.19 stat -a -C 1 -e 'mem:0xffff80008004b980/4:xk' true
I'll give it a try with v4, but that should be prevented with my
changes to exclude kprobe regions.
Rob
^ permalink raw reply
* Re: [PATCH v2 3/4] perf/arm64: Add BRBE support for bpf_get_branch_snapshot()
From: Rob Herring @ 2026-04-10 19:23 UTC (permalink / raw)
To: Puranjay Mohan
Cc: bpf, Puranjay Mohan, Alexei Starovoitov, Andrii Nakryiko,
Daniel Borkmann, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Will Deacon, Mark Rutland,
Catalin Marinas, Leo Yan, Breno Leitao, linux-arm-kernel,
linux-perf-users, kernel-team
In-Reply-To: <20260318171706.2840512-4-puranjay@kernel.org>
On Wed, Mar 18, 2026 at 10:16:57AM -0700, Puranjay Mohan wrote:
> Enable the bpf_get_branch_snapshot() BPF helper on ARM64 by implementing
> the perf_snapshot_branch_stack static call for ARM's Branch Record Buffer
> Extension (BRBE).
>
> The BPF helper bpf_get_branch_snapshot() allows BPF programs to capture
> hardware branch records on-demand. This was previously only available on
> x86 (Intel LBR) but not on ARM64 despite BRBE being available since
> ARMv9.
>
> BRBE is paused before disabling interrupts because local_irq_save() can
> trigger trace_hardirqs_off() which performs stack walking and pollutes
> the branch buffer. The sysreg read/write and ISB used to pause BRBE are
> branchless, so pausing first avoids this pollution.
>
> All exceptions are masked after pausing BRBE using local_daif_save() to
> prevent pseudo-NMI from PMU counter overflow from interfering with the
> snapshot read. A PMU overflow arriving between the pause and
> local_daif_save() can re-enable BRBE via the interrupt handler; the
> snapshot detects this by re-checking BRBFCR_EL1.PAUSED and bailing out.
>
> Branch records are read using the existing perf_entry_from_brbe_regset()
> helper with a NULL event pointer, which bypasses event-specific filtering
> and captures all recorded branches. The BPF program is responsible for
> filtering entries based on its own criteria. The BRBE buffer is
> invalidated after reading to maintain contiguity for other consumers.
>
> On heterogeneous big.LITTLE systems, only some CPUs may implement
> FEAT_BRBE. The perf_snapshot_branch_stack static call is system-wide, so
> a per-CPU brbe_active flag is used to prevent BRBE sysreg access on CPUs
> that do not implement FEAT_BRBE, where such access would be UNDEFINED.
Is this something you've seen? IIRC, the existing assumption is all CPUs
have FEAT_BRBE or that perf has been limited to those CPUs. It is
allowed that the number of records can vary.
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
> drivers/perf/arm_brbe.c | 79 +++++++++++++++++++++++++++++++++++++++-
> drivers/perf/arm_brbe.h | 9 +++++
> drivers/perf/arm_pmuv3.c | 5 ++-
> 3 files changed, 90 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/arm_brbe.c b/drivers/perf/arm_brbe.c
> index ba554e0c846c..527c2d5ebba6 100644
> --- a/drivers/perf/arm_brbe.c
> +++ b/drivers/perf/arm_brbe.c
> @@ -8,9 +8,13 @@
> */
> #include <linux/types.h>
> #include <linux/bitmap.h>
> +#include <linux/percpu.h>
> #include <linux/perf/arm_pmu.h>
> +#include <asm/daifflags.h>
> #include "arm_brbe.h"
>
> +static DEFINE_PER_CPU(bool, brbe_active);
> +
> #define BRBFCR_EL1_BRANCH_FILTERS (BRBFCR_EL1_DIRECT | \
> BRBFCR_EL1_INDIRECT | \
> BRBFCR_EL1_RTN | \
> @@ -533,6 +537,8 @@ void brbe_enable(const struct arm_pmu *arm_pmu)
> /* Finally write SYS_BRBFCR_EL to unpause BRBE */
> write_sysreg_s(brbfcr, SYS_BRBFCR_EL1);
> /* Synchronization in PMCR write ensures ordering WRT PMU enabling */
> +
> + this_cpu_write(brbe_active, true);
> }
>
> void brbe_disable(void)
> @@ -544,6 +550,7 @@ void brbe_disable(void)
> */
> write_sysreg_s(BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> write_sysreg_s(0, SYS_BRBCR_EL1);
> + this_cpu_write(brbe_active, false);
> }
>
> static const int brbe_type_to_perf_type_map[BRBINFx_EL1_TYPE_DEBUG_EXIT + 1][2] = {
> @@ -618,10 +625,10 @@ static bool perf_entry_from_brbe_regset(int index, struct perf_branch_entry *ent
>
> brbe_set_perf_entry_type(entry, brbinf);
>
> - if (!branch_sample_no_cycles(event))
> + if (!event || !branch_sample_no_cycles(event))
> entry->cycles = brbinf_get_cycles(brbinf);
>
> - if (!branch_sample_no_flags(event)) {
> + if (!event || !branch_sample_no_flags(event)) {
> /* Mispredict info is available for source only and complete branch records. */
> if (!brbe_record_is_target_only(brbinf)) {
> entry->mispred = brbinf_get_mispredict(brbinf);
> @@ -803,3 +810,71 @@ void brbe_read_filtered_entries(struct perf_branch_stack *branch_stack,
> done:
> branch_stack->nr = nr_filtered;
> }
> +
> +/*
> + * Best-effort BRBE snapshot for BPF tracing. Pause BRBE to avoid
> + * self-recording and return 0 if the snapshot state appears disturbed.
> + */
> +int arm_brbe_snapshot_branch_stack(struct perf_branch_entry *entries, unsigned int cnt)
> +{
> + unsigned long flags;
> + int nr_hw, nr_banks, nr_copied = 0;
> + u64 brbidr, brbfcr, brbcr;
> +
> + if (!cnt || !__this_cpu_read(brbe_active))
> + return 0;
> +
> + /* Pause BRBE first to avoid recording our own branches. */
> + brbfcr = read_sysreg_s(SYS_BRBFCR_EL1);
> + brbcr = read_sysreg_s(SYS_BRBCR_EL1);
> + write_sysreg_s(brbfcr | BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> + isb();
Is there something that guarantees BRBE is enabled when you enter this
function and that it is not disabled in this window? A context switch
could disable it unless it's a global event for example.
> +
> + /* Block local exception delivery while reading the buffer. */
> + flags = local_daif_save();
> +
> + /*
> + * A PMU overflow before local_daif_save() could have re-enabled
> + * BRBE, clearing the PAUSED bit. The overflow handler already
> + * restored BRBE to its correct state, so just bail out.
> + */
> + if (!(read_sysreg_s(SYS_BRBFCR_EL1) & BRBFCR_EL1_PAUSED)) {
> + local_daif_restore(flags);
> + return 0;
> + }
> +
> + brbidr = read_sysreg_s(SYS_BRBIDR0_EL1);
> + if (!valid_brbidr(brbidr))
This is not possibly true if brbe_active is true. If BRBIDR is not
valid, then we would have rejected any event requesting branch stack.
> + goto out;
> +
> + nr_hw = FIELD_GET(BRBIDR0_EL1_NUMREC_MASK, brbidr);
> + nr_banks = DIV_ROUND_UP(nr_hw, BRBE_BANK_MAX_ENTRIES);
> +
> + for (int bank = 0; bank < nr_banks; bank++) {
> + int nr_remaining = nr_hw - (bank * BRBE_BANK_MAX_ENTRIES);
> + int nr_this_bank = min(nr_remaining, BRBE_BANK_MAX_ENTRIES);
> +
> + select_brbe_bank(bank);
> +
> + for (int i = 0; i < nr_this_bank; i++) {
I don't love all this being duplicated. Perhaps an iterator would help
here (and the other copy):
static void next_slot(int *bank, int *bank_idx, int nr_hw)
{
*bank_idx++;
if (*bank_idx + (*bank * BRBE_BANK_MAX_ENTRIES) == nr_hw)
bank = BRBE_MAX_BANKS;
else if ((*bank_idx % BRBE_BANK_MAX_ENTRIES) == 0) {
*bank_idx = 0;
select_brbe_bank(++(*bank));
}
}
#define for_each_bank_slot(i, nr_hw) \
for (int bank = 0, int i = 0; bank < BRBE_MAX_BANKS; next_slot(&bank,
&i))
Then here you just have:
for_each_bank_slot(i, FIELD_GET(BRBIDR0_EL1_NUMREC_MASK, brbidr)) {
...
}
Feel free to come up with better naming. :)
> + if (nr_copied >= cnt)
> + goto done;
> +
> + if (!perf_entry_from_brbe_regset(i, &entries[nr_copied], NULL))
> + goto done;
> +
> + nr_copied++;
> + }
> + }
> +
> +done:
> + brbe_invalidate();
> +out:
> + /* Restore BRBCR before unpausing via BRBFCR, matching brbe_enable(). */
> + write_sysreg_s(brbcr, SYS_BRBCR_EL1);
> + isb();
> + write_sysreg_s(brbfcr, SYS_BRBFCR_EL1);
> + local_daif_restore(flags);
> +
> + return nr_copied;
> +}
^ permalink raw reply
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