* Re: [PATCH v2 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: Jie Gan @ 2026-04-11 1:08 UTC (permalink / raw)
To: James Clark, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260407-james-spe-impdef-decode-v2-6-55d3ef997c48@linaro.org>
Hi James,
On 4/7/2026 10:05 PM, James Clark wrote:
> Any IMPDEF events not printed out from a known core's IMPDEF list or for
> a completely unknown core will still not be shown to the user. Fix this
> by printing the remaining bits as comma separated raw numbers, e.g.
> "IMPDEF:1,2,3,4".
>
> Suggested-by: Al Grant <al.grant@arm.com>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index b74f887a48f2..c65b22a2179c 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -8,6 +8,7 @@
> #include <string.h>
> #include <endian.h>
> #include <byteswap.h>
> +#include <linux/bitmap.h>
> #include <linux/bitops.h>
> #include <stdarg.h>
> #include <linux/kernel.h>
> @@ -365,6 +366,23 @@ static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> payload);
> }
>
> + /*
> + * Print remaining IMPDEF bits that weren't printed above as raw
> + * "IMPDEF:1,2,3,4" etc.
> + */
> + if (payload) {
> + int i;
> +
> + arm_spe_pkt_out_string(&err, &buf, &buf_len, " IMPDEF:");
> + for_each_set_bit(i, &payload, 64) {
for_each_set_bit(i, &payload, 64) passes &payload where payload is u64.
The macro expands to find_next_bit(const unsigned long *addr, ...). On a
32-bit host unsigned long is 32 bits wide, so only the low 32 bits of
payload would be scanned; bits 32–63 would be silently ignored. While
perf is almost always built on a 64-bit host today, the tools/ tree is
explicitly portable and the compiler will emit a -Wpointer-arith /
-Wincompatible-pointer-types warning on a 32-bit build.
Thanks,
Jie
> + const char *sep = payload & (payload - 1) ? "," : "";
> +
> + arm_spe_pkt_out_string(&err, &buf, &buf_len, "%d%s", i,
> + sep);
> + payload &= ~BIT_ULL(i);
> + }
> + }
> +
> return err;
> }
>
>
^ permalink raw reply
* Re: [PATCH v3 0/8] perf libunwind multiple remote support
From: Ian Rogers @ 2026-04-11 1:04 UTC (permalink / raw)
To: acme
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260404054032.1538095-1-irogers@google.com>
On Fri, Apr 3, 2026 at 10:40 PM Ian Rogers <irogers@google.com> wrote:
>
> Fix the libunwind build for when libdw and libunwind are feature
> detected, currently failing with a duplicate symbol.
>
> Refactor the libunwind support so that whenever a remote target is
> available, perf functions using the ELF machine can use that remote
> target regardless of what the host/local machine is. Migrate existing
> libunwind supported architectures like powerpc, arm64 and loongarch so
> that they can work in a cross-architecture way. Add support for
> RISC-V. Make the code more regular in function names, etc. and avoid
> including a C-file. This increases the lines of code. It is similar in
> style to the unwind-libdw implementation. It is hoped that the more
> uniform nature of the code with help with refactoring the perf
> registers for SIMD/APX support.
>
> Aside from local host testing these patches are under tested, in part
> as I'm failing to see how to build libunwind with support for multiple
> remote targets. Please could I get help in testing.
>
> v3: Minor whitespace clean up and warn when a dynamic choice of libdw
> or libunwind is selected for unwinding and support is missing (Arnaldo).
Hi Arnaldo,
anything else outstanding from this series?
Thanks,
Ian
> v2: Move two fixes patches to position 1 and 2 in the series. Fix
> struct naming inconsistency, Andrew Jones
> <andrew.jones@oss.qualcomm.com>. Fix other inconsistencies and
> potential non-x86 build issues.
> https://lore.kernel.org/lkml/20260305221927.3237145-1-irogers@google.com/
>
> v1: https://lore.kernel.org/lkml/20260224142938.26088-1-irogers@google.com/
>
> Ian Rogers (8):
> perf unwind: Refactor get_entries to allow dynamic libdw/libunwind
> selection
> perf build loongarch: Remove reference to missing file
> tools build: Deduplicate test-libunwind for different architectures
> perf build: Be more programmatic when setting up libunwind variables
> perf unwind-libunwind: Make libunwind register reading cross platform
> perf unwind-libunwind: Move flush/finish access out of local
> perf unwind-libunwind: Remove libunwind-local
> perf unwind-libunwind: Add RISC-V libunwind support
>
> tools/build/feature/Makefile | 38 +-
> tools/build/feature/test-libunwind-aarch64.c | 27 -
> tools/build/feature/test-libunwind-arm.c | 28 -
> .../test-libunwind-debug-frame-aarch64.c | 17 -
> .../feature/test-libunwind-debug-frame-arm.c | 17 -
> .../feature/test-libunwind-debug-frame.c | 1 -
> tools/build/feature/test-libunwind-x86.c | 28 -
> tools/build/feature/test-libunwind-x86_64.c | 28 -
> tools/build/feature/test-libunwind.c | 1 -
> tools/perf/Makefile.config | 215 ++---
> tools/perf/arch/arm/util/Build | 2 -
> tools/perf/arch/arm/util/unwind-libunwind.c | 50 --
> tools/perf/arch/arm64/util/Build | 1 -
> tools/perf/arch/arm64/util/unwind-libunwind.c | 17 -
> tools/perf/arch/loongarch/util/Build | 3 -
> .../arch/loongarch/util/unwind-libunwind.c | 82 --
> tools/perf/arch/mips/Build | 1 -
> tools/perf/arch/mips/util/Build | 1 -
> tools/perf/arch/mips/util/unwind-libunwind.c | 22 -
> tools/perf/arch/powerpc/util/Build | 1 -
> .../perf/arch/powerpc/util/unwind-libunwind.c | 92 --
> tools/perf/arch/x86/util/Build | 3 -
> tools/perf/arch/x86/util/unwind-libunwind.c | 115 ---
> tools/perf/builtin-inject.c | 4 +
> tools/perf/builtin-report.c | 4 +
> tools/perf/builtin-script.c | 4 +
> tools/perf/util/Build | 5 +-
> tools/perf/util/libunwind-arch/Build | 11 +
> .../perf/util/libunwind-arch/libunwind-arch.c | 319 +++++++
> .../perf/util/libunwind-arch/libunwind-arch.h | 296 +++++++
> .../perf/util/libunwind-arch/libunwind-arm.c | 290 ++++++
> .../util/libunwind-arch/libunwind-arm64.c | 289 ++++++
> .../perf/util/libunwind-arch/libunwind-i386.c | 312 +++++++
> .../util/libunwind-arch/libunwind-loongarch.c | 297 +++++++
> .../perf/util/libunwind-arch/libunwind-mips.c | 299 +++++++
> .../util/libunwind-arch/libunwind-ppc32.c | 301 +++++++
> .../util/libunwind-arch/libunwind-ppc64.c | 303 +++++++
> .../util/libunwind-arch/libunwind-riscv.c | 297 +++++++
> .../perf/util/libunwind-arch/libunwind-s390.c | 299 +++++++
> .../util/libunwind-arch/libunwind-x86_64.c | 320 +++++++
> tools/perf/util/libunwind/arm64.c | 40 -
> tools/perf/util/libunwind/x86_32.c | 41 -
> tools/perf/util/maps.c | 29 +-
> tools/perf/util/maps.h | 4 +-
> tools/perf/util/symbol_conf.h | 10 +
> tools/perf/util/thread.c | 29 +-
> tools/perf/util/unwind-libdw.c | 2 +-
> tools/perf/util/unwind-libunwind-local.c | 832 ------------------
> tools/perf/util/unwind-libunwind.c | 679 ++++++++++++--
> tools/perf/util/unwind.c | 98 +++
> tools/perf/util/unwind.h | 77 +-
> 51 files changed, 4549 insertions(+), 1732 deletions(-)
> delete mode 100644 tools/build/feature/test-libunwind-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-x86.c
> delete mode 100644 tools/build/feature/test-libunwind-x86_64.c
> delete mode 100644 tools/perf/arch/arm/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/arm64/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/loongarch/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/mips/Build
> delete mode 100644 tools/perf/arch/mips/util/Build
> delete mode 100644 tools/perf/arch/mips/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/powerpc/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/x86/util/unwind-libunwind.c
> create mode 100644 tools/perf/util/libunwind-arch/Build
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arch.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arch.h
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arm.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arm64.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-i386.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-loongarch.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-mips.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-ppc32.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-ppc64.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-riscv.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-s390.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-x86_64.c
> delete mode 100644 tools/perf/util/libunwind/arm64.c
> delete mode 100644 tools/perf/util/libunwind/x86_32.c
> delete mode 100644 tools/perf/util/unwind-libunwind-local.c
> create mode 100644 tools/perf/util/unwind.c
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
^ permalink raw reply
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Nicolin Chen @ 2026-04-11 0: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: <20260410232500.GD2588311@nvidia.com>
On Fri, Apr 10, 2026 at 08:25:00PM -0300, Jason Gunthorpe wrote:
> 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:
> > 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.
Yea, I did that.
> > 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().
I updated that in my words but this reads more accurate. I will
use this (fixing the typo experiance).
Thanks
Nicolin
^ permalink raw reply
* [PATCH v2 0/3] pmdomain: core: add support for domain hierarchies in DT
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
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.
Also adds the first user of the new API: the Arm SCMI PM domain driver.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
This idea was previously discussed on the arm-scmi mailing list[1]
where this approach was proposed by Ulf, and then an initial RFC[2]
implementation was made. From there, it was suggested by Rob[3] to
use a nexus node map instead, which led to several more versions
attempting to implement that, culminating in v5[4], where Rob and
Geert then had second thoughts about the power-domain-map approach.
Therefore, I've gone back to the approach in the initial RFC[2] to use
the child-ids approach.
Changes compared to initial RFC[2]
- dropped RFC
- rewrote the parse/add function to use iterators/helpers from of.h
- add a remove function for cleanup
- use child domain language instead of subdomain
[1] https://lore.kernel.org/arm-scmi/CAPDyKFo_P129sVirHHYjOQT+QUmpymcRJme9obzKJeRgO7B-1A@mail.gmail.com/
[2] https://lore.kernel.org/all/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com/
[3] https://lore.kernel.org/all/20250528203532.GA704342-robh@kernel.org/
[4] https://lore.kernel.org/r/20260122-pmdomain-hierarchy-onecell-v5-0-76855ec856bd@baylibre.com
Changes in v2:
- dt-bindings: fix warinings from make dt_binding_check
- scmi_pm_domain: switch to dev_err()
- pmdomain: core: fix locking around add/remove domains
- pmdomain: error unwind if any children fail to be added
- pmdomain: fix node reference leak
- pmdomain: ensure power-domains and child-ids properties are same
length before iterating
- Link to v1: https://patch.msgid.link/20260310-topic-lpm-pmdomain-child-ids-v1-0-5361687a18ff@baylibre.com
---
Kevin Hilman (TI) (3):
dt-bindings: power: Add power-domains-child-ids property
pmdomain: core: add support for power-domains-child-ids
pmdomain: arm_scmi: add support for domain hierarchies
Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
drivers/pmdomain/core.c | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 16 ++++++++++++++++
4 files changed, 229 insertions(+), 1 deletion(-)
---
base-commit: f7b88edb52c8dd01b7e576390d658ae6eef0e134
change-id: 20260310-topic-lpm-pmdomain-child-ids-e3d57ae57040
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 3/3] pmdomain: arm_scmi: add support for domain hierarchies
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>
After primary SCMI pmdomain is created, use new of_genpd helper which
checks for child domain mappings defined in power-domains-child-ids.
Also remove any child domain mappings when SCMI domain is removed.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index b5e2ffd5ea64..6d33b3d62ef3 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -114,6 +114,14 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
dev_set_drvdata(dev, scmi_pd_data);
+ /*
+ * Parse (optional) power-domains-child-ids property to
+ * establish parent-child relationships
+ */
+ ret = of_genpd_add_child_ids(np, scmi_pd_data);
+ if (ret < 0 && ret != -ENOENT)
+ dev_err(dev, "Failed to add child domain hierarchy: %d\n", ret);
+
return 0;
err_rm_genpds:
for (i = num_domains - 1; i >= 0; i--)
@@ -129,9 +137,13 @@ static void scmi_pm_domain_remove(struct scmi_device *sdev)
struct device *dev = &sdev->dev;
struct device_node *np = dev->of_node;
+ scmi_pd_data = dev_get_drvdata(dev);
+
+ /* Remove any parent-child relationships established at probe time */
+ of_genpd_remove_child_ids(np, scmi_pd_data);
+
of_genpd_del_provider(np);
- scmi_pd_data = dev_get_drvdata(dev);
for (i = 0; i < scmi_pd_data->num_domains; i++) {
if (!scmi_pd_data->domains[i])
continue;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] pmdomain: core: add support for power-domains-child-ids
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>
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.
The add function is "all or nothing". If it cannot add all of the
child domains in the list, it will unwind any additions already made
and report a failure.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/core.c | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 16 ++++++++++++++++
2 files changed, 182 insertions(+)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 61c2277c9ce3..f978477dd546 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2909,6 +2909,172 @@ 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.
+ *
+ * Uses "all or nothing" semantics: either all relationships are established
+ * successfully, or none are (any partially-added relationships are unwound
+ * on error).
+ *
+ * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
+ */
+int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ struct of_phandle_args parent_args;
+ struct generic_pm_domain *parent_genpd, *child_genpd;
+ struct generic_pm_domain **pairs; /* pairs[2*i]=parent, pairs[2*i+1]=child */
+ u32 child_id;
+ int i, ret, count, child_count, added = 0;
+
+ /* Check if both properties exist */
+ count = of_count_phandle_with_args(np, "power-domains", "#power-domain-cells");
+ if (count <= 0)
+ return -ENOENT;
+
+ child_count = of_property_count_u32_elems(np, "power-domains-child-ids");
+ if (child_count < 0)
+ return -ENOENT;
+ if (child_count != count)
+ return -EINVAL;
+
+ /* Allocate tracking array for error unwind (parent/child pairs) */
+ pairs = kmalloc_array(count * 2, sizeof(*pairs), GFP_KERNEL);
+ if (!pairs)
+ return -ENOMEM;
+
+ for (i = 0; i < count; i++) {
+ ret = of_property_read_u32_index(np, "power-domains-child-ids",
+ i, &child_id);
+ if (ret)
+ goto err_unwind;
+
+ /* Validate child ID is within bounds */
+ if (child_id >= data->num_domains) {
+ pr_err("Child ID %u out of bounds (max %u) for %pOF\n",
+ child_id, data->num_domains - 1, np);
+ ret = -EINVAL;
+ goto err_unwind;
+ }
+
+ /* Get the child domain */
+ child_genpd = data->domains[child_id];
+ if (!child_genpd) {
+ pr_err("Child domain %u is NULL for %pOF\n", child_id, np);
+ ret = -EINVAL;
+ goto err_unwind;
+ }
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", i,
+ &parent_args);
+ if (ret)
+ goto err_unwind;
+
+ /* Get the parent domain */
+ parent_genpd = genpd_get_from_provider(&parent_args);
+ of_node_put(parent_args.np);
+ if (IS_ERR(parent_genpd)) {
+ pr_err("Failed to get parent domain for %pOF: %ld\n",
+ np, PTR_ERR(parent_genpd));
+ ret = PTR_ERR(parent_genpd);
+ goto err_unwind;
+ }
+
+ /* Establish parent-child relationship */
+ ret = pm_genpd_add_subdomain(parent_genpd, child_genpd);
+ if (ret) {
+ pr_err("Failed to add child domain %u to parent in %pOF: %d\n",
+ child_id, np, ret);
+ goto err_unwind;
+ }
+
+ /* Track for potential unwind */
+ pairs[2 * added] = parent_genpd;
+ pairs[2 * added + 1] = child_genpd;
+ added++;
+
+ pr_debug("Added child domain %u (%s) to parent %s for %pOF\n",
+ child_id, child_genpd->name, parent_genpd->name, np);
+ }
+
+ kfree(pairs);
+ return 0;
+
+err_unwind:
+ /* Reverse all previously established relationships */
+ while (added-- > 0)
+ pm_genpd_remove_subdomain(pairs[2 * added], pairs[2 * added + 1]);
+ kfree(pairs);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_genpd_add_child_ids);
+
+/**
+ * of_genpd_remove_child_ids() - Remove parent-child PM domain relationships
+ * @np: Device node pointer associated with the PM domain provider.
+ * @data: Pointer to the onecell data associated with the PM domain provider.
+ *
+ * Reverses the effect of of_genpd_add_child_ids() by parsing the same
+ * power-domains and power-domains-child-ids properties and calling
+ * pm_genpd_remove_subdomain() for each established relationship.
+ *
+ * Returns 0 on success, -ENOENT if properties don't exist, or negative error
+ * code on failure.
+ */
+int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ struct of_phandle_args parent_args;
+ struct generic_pm_domain *parent_genpd, *child_genpd;
+ u32 child_id;
+ int i, ret, count, child_count;
+
+ /* Check if both properties exist */
+ count = of_count_phandle_with_args(np, "power-domains", "#power-domain-cells");
+ if (count <= 0)
+ return -ENOENT;
+
+ child_count = of_property_count_u32_elems(np, "power-domains-child-ids");
+ if (child_count < 0)
+ return -ENOENT;
+ if (child_count != count)
+ return -EINVAL;
+
+ for (i = 0; i < count; i++) {
+ if (of_property_read_u32_index(np, "power-domains-child-ids",
+ i, &child_id))
+ continue;
+
+ if (child_id >= data->num_domains || !data->domains[child_id])
+ continue;
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", i,
+ &parent_args);
+ if (ret)
+ continue;
+
+ parent_genpd = genpd_get_from_provider(&parent_args);
+ of_node_put(parent_args.np);
+ if (IS_ERR(parent_genpd))
+ continue;
+
+ child_genpd = data->domains[child_id];
+ pm_genpd_remove_subdomain(parent_genpd, child_genpd);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_genpd_remove_child_ids);
+
/**
* of_genpd_add_device() - Add a device to an I/O PM domain
* @genpdspec: OF phandle args to use for look-up PM domain
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index f67a2cb7d781..b44615d79af6 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -465,6 +465,10 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
int of_genpd_parse_idle_states(struct device_node *dn,
struct genpd_power_state **states, int *n);
void of_genpd_sync_state(struct device_node *np);
+int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data);
+int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data);
int genpd_dev_pm_attach(struct device *dev);
struct device *genpd_dev_pm_attach_by_id(struct device *dev,
@@ -534,6 +538,18 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
{
return ERR_PTR(-EOPNOTSUPP);
}
+
+static inline int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
#ifdef CONFIG_PM
--
2.51.0
^ permalink raw reply related
* [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
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