* [PATCH 2/3] soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node
From: Alexey Klimov @ 2026-06-05 20:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Peter Griffin
Cc: Sam Protsenko, linux-samsung-soc, linux-arm-kernel, linux-kernel,
stable, Sashiko
In-Reply-To: <20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org>
The setup_cpuhp_and_cpuidle() parses the device tree node for the
interrupt generation block via of_parse_phandle() and decrements its
reference count using of_node_put() immediately after fetching the resource
address. However, later the intr_gen_node pointer is passed into
of_syscon_register_regmap().
Fix this by moving the of_node_put() invocation to after the
of_syscon_register_regmap() call, and adding it to correct error paths.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3
Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101")
Cc: stable@vger.kernel.org
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/exynos-pmu.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 6e635872247a..9636287f6794 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -428,23 +428,30 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
* syscon provided regmap.
*/
ret = of_address_to_resource(intr_gen_node, 0, &intrgen_res);
- of_node_put(intr_gen_node);
+ if (ret) {
+ of_node_put(intr_gen_node);
+ return ret;
+ }
virt_addr = devm_ioremap(dev, intrgen_res.start,
resource_size(&intrgen_res));
- if (!virt_addr)
+ if (!virt_addr) {
+ of_node_put(intr_gen_node);
return -ENOMEM;
+ }
pmu_context->pmuintrgen = devm_regmap_init_mmio(dev, virt_addr,
®map_pmu_intr);
if (IS_ERR(pmu_context->pmuintrgen)) {
dev_err(dev, "failed to initialize pmu-intr-gen regmap\n");
+ of_node_put(intr_gen_node);
return PTR_ERR(pmu_context->pmuintrgen);
}
/* register custom mmio regmap with syscon */
ret = of_syscon_register_regmap(intr_gen_node,
pmu_context->pmuintrgen);
+ of_node_put(intr_gen_node);
if (ret)
return ret;
--
2.51.0
^ permalink raw reply related
* [PATCH 3/3] soc: samsung: exynos-pmu: fix error paths in cpuhotplug/idle states setup
From: Alexey Klimov @ 2026-06-05 20:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Peter Griffin
Cc: Sam Protsenko, linux-samsung-soc, linux-arm-kernel, linux-kernel,
stable, Sashiko
In-Reply-To: <20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org>
The setup_cpuhp_and_cpuidle() initialisation sequence currently ignores
the return values of cpuhp_setup_state(), cpu_pm_register_notifier(), and
register_reboot_notifier(). If any of these registrations fail during
probe() routine, the driver returns 0, leaving the driver partially
configured.
Furthermore, if anything after setup_cpuhp_and_cpuidle() fails in probe()
routine, for instance devm_mfd_add_devices(), the probe() lacks an error
path and leaves notifiers and cpu hotplug states registered.
Introduce variables for the cpu hotplug state IDs in exynos_pmu_context
struct, that should be initialised to CPUHP_INVALID by default. Check all
return codes in setup_cpuhp_and_cpuidle(), and add an error path to remove
registered states on failure. Finally, add destroy_cpuhp_and_cpuidle()
helper to safely tear down notifiers and cpu hotplug states.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3
Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101")
Cc: stable@vger.kernel.org
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/exynos-pmu.c | 57 ++++++++++++++++++++++++++++++++++------
1 file changed, 49 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 9636287f6794..846313a28e9a 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -38,6 +38,8 @@ struct exynos_pmu_context {
unsigned long *in_cpuhp;
bool sys_insuspend;
bool sys_inreboot;
+ int cpuhp_prepare_state;
+ int cpuhp_online_state;
};
void __iomem *pmu_base_addr;
@@ -404,6 +406,17 @@ static struct notifier_block exynos_cpupm_reboot_nb = {
.notifier_call = exynos_cpupm_reboot_notifier,
};
+static void destroy_cpuhp_and_cpuidle(void)
+{
+ cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ unregister_reboot_notifier(&exynos_cpupm_reboot_nb);
+
+ if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
+ cpuhp_remove_state(pmu_context->cpuhp_prepare_state);
+ if (pmu_context->cpuhp_online_state != CPUHP_INVALID)
+ cpuhp_remove_state(pmu_context->cpuhp_online_state);
+}
+
static int setup_cpuhp_and_cpuidle(struct device *dev)
{
struct device_node *intr_gen_node;
@@ -465,16 +478,42 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
gs101_cpuhp_pmu_online(cpu);
/* register CPU hotplug callbacks */
- cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "soc/exynos-pmu:prepare",
- gs101_cpuhp_pmu_online, NULL);
+ pmu_context->cpuhp_prepare_state = CPUHP_INVALID;
+ pmu_context->cpuhp_online_state = CPUHP_INVALID;
- cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "soc/exynos-pmu:online",
- NULL, gs101_cpuhp_pmu_offline);
+ ret = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "soc/exynos-pmu:prepare",
+ gs101_cpuhp_pmu_online, NULL);
+ if (ret < 0)
+ return ret;
+
+ pmu_context->cpuhp_prepare_state = ret;
+
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "soc/exynos-pmu:online",
+ NULL, gs101_cpuhp_pmu_offline);
+ if (ret < 0)
+ goto clean_cpuhp_states;
+
+ pmu_context->cpuhp_online_state = ret;
/* register CPU PM notifiers for cpuidle */
- cpu_pm_register_notifier(&gs101_cpu_pm_notifier);
- register_reboot_notifier(&exynos_cpupm_reboot_nb);
- return 0;
+ ret = cpu_pm_register_notifier(&gs101_cpu_pm_notifier);
+ if (ret)
+ goto clean_cpuhp_states;
+
+ ret = register_reboot_notifier(&exynos_cpupm_reboot_nb);
+ if (!ret)
+ /* Success */
+ return ret;
+
+ cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+
+clean_cpuhp_states:
+ if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
+ cpuhp_remove_state(pmu_context->cpuhp_prepare_state);
+ if (pmu_context->cpuhp_online_state != CPUHP_INVALID)
+ cpuhp_remove_state(pmu_context->cpuhp_online_state);
+
+ return ret;
}
static int exynos_pmu_probe(struct platform_device *pdev)
@@ -548,8 +587,10 @@ static int exynos_pmu_probe(struct platform_device *pdev)
ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, exynos_pmu_devs,
ARRAY_SIZE(exynos_pmu_devs), NULL, 0, NULL);
- if (ret)
+ if (ret) {
+ destroy_cpuhp_and_cpuidle();
return ret;
+ }
if (devm_of_platform_populate(dev))
dev_err(dev, "Error populating children, reboot and poweroff might not work properly\n");
--
2.51.0
^ permalink raw reply related
* [PATCH 0/3] Exynos PMU fixes for cpu hotplug and cpuidle routines
From: Alexey Klimov @ 2026-06-05 20:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Peter Griffin
Cc: Sam Protsenko, linux-samsung-soc, linux-arm-kernel, linux-kernel,
stable, Sashiko
This was reported by Sashiko here:
https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3
and was mainly introduced by enabling cpu hotplug
support and cpuidle for gs101-based SoCs.
One patch removes strange usage of smp_processor_id() and
other patches deal with a few missing error paths issues
here and there in setup_cpuhp_and_cpuidle() and around.
Tested on gs101-raven device, I don't see any regressions
but testing from others will be appreciated.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Alexey Klimov (3):
soc: samsung: exynos-pmu: use target cpu ID in hotplug callbacks
soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node
soc: samsung: exynos-pmu: fix error paths in cpuhotplug/idle states setup
drivers/soc/samsung/exynos-pmu.c | 75 ++++++++++++++++++++++++++++++++--------
1 file changed, 60 insertions(+), 15 deletions(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260605-exynos-pmu-cpuhp-idle-fixes-32f5ed7c969f
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply
* [PATCH 1/3] soc: samsung: exynos-pmu: use target cpu ID in hotplug callbacks
From: Alexey Klimov @ 2026-06-05 20:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Peter Griffin
Cc: Sam Protsenko, linux-samsung-soc, linux-arm-kernel, linux-kernel,
stable, Sashiko
In-Reply-To: <20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org>
The CPU hotplug state callbacks __gs101_cpu_pmu_online() and
__gs101_cpu_pmu_offline() currently partially use smp_processor_id() to
determine the target register offset for the CPU inform hints. This may
be fine for cpuidle flow but broken for cpu hotplug where the target
cpu is passed as an argument and could be different from cpu where
that is executing (e.g. CPU 0 offlining CPU 1), meaning that
smp_processor_id() returns the id of local CPU but hotplug flow
deals with another CPU core undergoing the transition.
This causes the pmu driver to write power down and power on configuration
hints to the wrong hardware registers, messing up the power state of active
cores and failing to configure the target core. Fix this by removing the
cpuhint variable entirely and utilizing the target 'cpu' argument passed
to the callbacks by the hotplug core infrastructure.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3
Fixes: 598995027b91 ("soc: samsung: exynos-pmu: enable CPU hotplug support for gs101")
Cc: stable@vger.kernel.org
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/exynos-pmu.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index d58376c38179..6e635872247a 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -235,11 +235,10 @@ EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle);
static int __gs101_cpu_pmu_online(unsigned int cpu)
__must_hold(&pmu_context->cpupm_lock)
{
- unsigned int cpuhint = smp_processor_id();
u32 reg, mask;
/* clear cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpuhint),
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu),
CPU_INFORM_CLEAR);
mask = BIT(cpu);
@@ -296,12 +295,10 @@ static int gs101_cpuhp_pmu_online(unsigned int cpu)
static int __gs101_cpu_pmu_offline(unsigned int cpu)
__must_hold(&pmu_context->cpupm_lock)
{
- unsigned int cpuhint = smp_processor_id();
u32 reg, mask;
/* set cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpuhint),
- CPU_INFORM_C2);
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
mask = BIT(cpu);
regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 3/4] arm64: wire SDEI NMI into the hardlockup watchdog
From: Doug Anderson @ 2026-06-05 20:03 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Catalin Marinas, Will Deacon, James Morse, Mark Rutland,
Marc Zyngier, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <6172eafcb9de6e626c0f1c36426d67e1e562ed32.1780496779.git.kas@kernel.org>
Hi,
On Wed, Jun 3, 2026 at 7:36 AM Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Select HAVE_HARDLOCKUP_DETECTOR_ARCH so the framework takes its backend
> from this driver. A per-CPU hrtimer checks its buddy's heartbeat and
> signals event 0 at a stalled CPU, which runs watchdog_hardlockup_check()
> NMI-like.
>
> The source is chosen at boot: SDEI if firmware provides it, otherwise a
> perf-NMI counter (pseudo-NMI) fallback -- one image covers both.
>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> ---
> arch/arm64/Kconfig | 1 +
> drivers/firmware/Kconfig | 3 +
> drivers/firmware/sdei_nmi.c | 247 +++++++++++++++++++++++++++++++++++-
> 3 files changed, 248 insertions(+), 3 deletions(-)
I'm a little confused about this patch. We already have a buddy
hardlockup detector using the hrtimer, and it's even been improved
recently to trigger in a smaller time bound. It looks as if you're
duplicating bits of the perf and buddy detector here?
I don't think you need this patch at all. The existing buddy detector
+ patches #1 and #2 in your series should be sufficient.
Did I misunderstand?
-Doug
^ permalink raw reply
* Re: [PATCH v4 18/24] iommu/arm-smmu-v3: Introduce master->ats_broken flag
From: Jason Gunthorpe @ 2026-06-05 19:42 UTC (permalink / raw)
To: Nicolin Chen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <ah5txKCvspL8zMeG@Asurada-Nvidia>
On Mon, Jun 01, 2026 at 10:44:36PM -0700, Nicolin Chen wrote:
> On Mon, Jun 01, 2026 at 09:15:47PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 01, 2026 at 01:41:26PM -0700, Nicolin Chen wrote:
> > > On Mon, Jun 01, 2026 at 09:32:31AM -0300, Jason Gunthorpe wrote:
> > > > On Fri, May 29, 2026 at 06:27:40PM -0700, Nicolin Chen wrote:
> > > > > On Tue, May 19, 2026 at 09:06:58AM -0300, Jason Gunthorpe wrote:
> > > > > > On Mon, May 18, 2026 at 08:39:01PM -0700, Nicolin Chen wrote:
> > > > > So I've tried INV_TYPE_ATS_BROKEN: during per-domain invalidation,
> > > > > each batch is built from domain->invs so it can carry the "invs";
> > > > > if the batch times out, we can immediately mutate its ATS entries.
> > > > >
> > > > > But I realized a limitation. E.g., if a device attaches to two SVA
> > > > > domains on two SSIDs. An invalidation timing out on one of the SVA
> > > > > domains could mark INV_TYPE_ATS_BROKEN in its own invs, but not in
> > > > > the other SVA domain's invs?
> > > >
> > > > You'd have to mark all the S1's sharing the STE.
> > >
> > > That would be a bit convoluted as we would have to go through all
> > > other domains' invs arrays.
> >
> > Ok, that is certainly an annoying problem.
> >
> > I don't have a better idea than storing the master unfortunately
> >
> > But I think the locking for that is going to be tricky, I'm not sure it does
> > actually fully work..
>
> Yes, there can be a race that sets STE.EATS back while per-master
> flag is set, which would skip the ATC_INV in commit(), so no more
> ATC_INV timeout that resets STE.EATS=0. To close it, we can force
> STE.EATS=0 at the end of commit() when state->ats_enabled and the
> per-master flag are both set, which is only possible in a race.
I don't see any of these options as appealing. We have to maintain a
few key invariants, and I think it cannot be done without a way to
find all the domains that are using the STE.
One way or another you have to be using the invs list rw locks to
synchronize the EATS state changes.
It is okayish to be sloppy when turning EATS off, but when turning it
back on we do need to cycle through every invs list and toggle its
lock to ensure that the invalidations are synchronized before
EATS=enable happens.
Given you must have a way to go from STE -> master -> all invs lists
I'm not sure either option really makes such a large difference.
If so then adjusting the invs to disable the ATS is pretty simple, run
over the xarray and set them all off. Yes you could find the master
through a SID lookup with some locking adjustment.
>
> (1) Per-invs marker: INV_TYPE_ATS_BROKEN + master_domains
> disable_ats() in the timeout path walks master->master_domains
> and flips matching ATS invs entries to the BROKEN type.
>
> + invs walker is free (one case label in the existing type switch).
> + No lock or pointer deref in the invs walker.
> + No master pointer stored in invs; no lifetime concern.
>
> - disable_ats() walks every (master, domain) and marks each invs
> set; the list needs locking usable from atomic.
This doesn't seem so bad
> (2) Per-master flag + streams_lock
> invs walker resolves SID -> master via streams_lock and reads
> master->ats_broken.
>
> + Single source of truth on the master.
> + disable_ats() is one WRITE_ONCE.
> + atc_inv_master early-skips via one READ_ONCE.
> + attach gates ats_enabled on the flag; a concurrent quarantine
> race can be closed by a short post-attach re-check in commit()
> + No master pointer in invs; no lifetime concern.
>
> - invs walker pays streams_lock + rb_find(SID) per ATS entry on
> every invalidation. Measurable on ATS-heavy workloads.
Doesn't consider how to enable
> (3) Per-master flag + inv->master pointer (v4)
> invs entry carries a master pointer; the invs walker reads
> cur->master->ats_broken directly.
>
> + invs walker is one READ_ONCE through a cached pointer.
> + disable_ats is one WRITE_ONCE.
> + atc_inv_master early-skip via one READ_ONCE.
> + attach gate + post-attach re-check, same as (2).
>
> - invs holds a master ptr, so release_device must synchronize_rcu()
> before freeing the master to drain walkers under rcu_read_lock().
> We dropped this from v4 for that reason.
synchronize_rcu is not right because you have to have gone through the
rwlock so there can be no readers.
Jason
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: arm: sunxi: Add NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-05 19:13 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260605191322.1920944-1-lukas.schmid@netcube.li>
The OpenNMC is an open replacement for APC SmartSlot management cards
based on the Nagami System-on-Module.
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index e6443c266fa1..077b65507645 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -598,6 +598,7 @@ properties:
- description: NetCube Systems Nagami SoM based boards
items:
- enum:
+ - netcube,dobermann
- netcube,nagami-basic-carrier
- netcube,nagami-keypad-carrier
- const: netcube,nagami
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-05 19:13 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260605191322.1920944-1-lukas.schmid@netcube.li>
NetCube Systems OpenNMC is an open replacement for APC SmartSlot Management
Cards. It is based on the Nagami System-on-Module. It breaks out the
following interfaces:
- 10/100 Mbps Ethernet
- USB Type-C OTG using a TUSB320 (usb0)
- USB Type-C Console Port using a CH340 (uart3)
- USB Type-A Host with internal CH334 USB-Hub (usb1)
- MicroSD Slot with Card-Detect (mmc0)
- WiFi/Bluetooth using the modules built-in ESP32
- SmartSlot serial interface (uart4)
- DS3232 RTC with CR1220 Battery Backup
- Extension connector providing SPI,I2C,USB,CAN,UART for future use.
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
.../sun8i-t113s-netcube-dobermann.dts | 149 ++++++++++++++++++
1 file changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts b/arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
new file mode 100644
index 000000000000..d7765caffe2a
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 Lukas Schmid <lukas.schmid@netcube.li>
+ */
+
+/dts-v1/;
+#include "sun8i-t113s-netcube-nagami.dtsi"
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "NetCube Systems OpenNMC (dobermann)";
+ compatible = "netcube,dobermann", "netcube,nagami",
+ "allwinner,sun8i-t113s";
+
+ aliases {
+ serial2 = &uart4; // UART on SmartSlot
+ rtc0 = &ds3232;
+ rtc1 = &rtc; // not battery backed
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_heartbeat_green: led-heartbeat-green {
+ gpios = <&pio 6 14 GPIO_ACTIVE_HIGH>; /* PG14 */
+ linux,default-trigger = "heartbeat";
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_HEARTBEAT;
+ };
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+
+ tusb320: typec@60 {
+ compatible = "ti,tusb320";
+ reg = <0x60>;
+ interrupts-extended = <&pio 3 22 IRQ_TYPE_LEVEL_LOW>; /* PD22 */
+ };
+
+ ds3232: rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+};
+
+/* microSD Card Slot on the board */
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ disable-wp;
+ bus-width = <4>;
+ cd-gpios = <&pio 6 15 GPIO_ACTIVE_LOW>; /* PG15 */
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ gpio-line-names = "", "", "", "", // PA
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "SMART_TX", "SMART_RX", // PB
+ "EXT_IO3", "EXT_IO2", "CONSOLE_TX", "CONSOLE_RX",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "eMMC_CLK", "eMMC_CMD", // PC
+ "eMMC_D2", "eMMC_D1", "eMMC_D0", "eMMC_D3",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "", // PD
+ "", "", "", "",
+ "", "USB_SEC_EN", "EXT_SPI_nCS", "EXT_SPI_SCK",
+ "EXT_SPI_MOSI", "EXT_SPI_MISO", "EXT_IO5", "EXT_IO4",
+ "SMART_SEL", "", "", "",
+ "I2C2_SCL", "I2C2_SDA", "TUSB320_nINT", "",
+ "", "", "", "",
+ "", "", "", "",
+ "ETH_CRSDV", "ETH_RXD0", "ETH_RXD1", "ETH_TXCK", // PE
+ "ETH_TXD0", "ETH_TXD1", "ETH_TXEN", "",
+ "ETH_MDC", "ETH_MDIO", "I2C3_nINT", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "uSD_D1", "uSD_D0", "uSD_CLK", "uSD_CMD", // PF
+ "uSD_D3", "uSD_D2", "TUSB320_ID", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "ESP_CLK", "ESP_CMD", "ESP_D0", "ESP_D1", // PG
+ "ESP_D2", "ESP_D3", "ESP_TXD", "ESP_RXD",
+ "ESP_nBOOT", "ESP_nRST", "I2C3_SCL", "I2C3_SDA",
+ "EXT_IO1", "EXT_IO0", "LED_HEARTBEAT", "SD_DETECT",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+};
+
+/* SmartSlot serial */
+&uart4 {
+ pinctrl-0 = <&uart4_pb_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_otg {
+ extcon = <&tusb320 0>;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/3] riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube Systems OpenNMC
From: Lukas Schmid @ 2026-06-05 19:13 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260605191322.1920944-1-lukas.schmid@netcube.li>
Added the "uart4_pb_pins" pinctrl used by the OpenNMC
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
index 82cc85acccb1..00fddedfa36f 100644
--- a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
@@ -191,6 +191,12 @@ uart3_pb_pins: uart3-pb-pins {
pins = "PB6", "PB7";
function = "uart3";
};
+
+ /omit-if-no-ref/
+ uart4_pb_pins: uart4-pb-pins {
+ pins = "PB2", "PB3";
+ function = "uart4";
+ };
};
ccu: clock-controller@2001000 {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/3] Add support for NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-05 19:13 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
This series adds support for the NetCube Systems OpenNMC
Changes in v2:
- fixed ordering of compatible enum
- fixed gpio line names
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
Lukas Schmid (3):
dt-bindings: arm: sunxi: Add NetCube Systems OpenNMC (dobermann)
riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube
Systems OpenNMC
ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
.../devicetree/bindings/arm/sunxi.yaml | 1 +
.../sun8i-t113s-netcube-dobermann.dts | 149 ++++++++++++++++++
.../boot/dts/allwinner/sunxi-d1s-t113.dtsi | 6 +
3 files changed, 156 insertions(+)
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
--
2.47.3
^ permalink raw reply
* [PATCH] KVM: arm64: Fix block mapping validity check in stage-1 walker
From: Wei-Lin Chang @ 2026-06-05 18:52 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Wei-Lin Chang
For the 64K granule size, FEAT_LPA determines whether a level 1 mapping
is allowed. Using the result of has_52bit_pa() is too restrictive, as it
also checks the selected output addressi size in TCR.(I)PS. Fix it by
only checking FEAT_LPA.
Fixes: 5da3a3b27a01 ("KVM: arm64: Expand valid block mappings to FEAT_LPA/LPA2 support")
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/at.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 2ddb5b5a055e..30e6fa8ac07c 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -564,15 +564,18 @@ static int walk_s1(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
/* Block mapping, check the validity of the level */
if (!(desc & BIT(1))) {
bool valid_block = false;
+ bool lpa = kvm_has_feat_enum(vcpu->kvm, ID_AA64MMFR0_EL1, PARANGE, 52);
switch (BIT(wi->pgshift)) {
case SZ_4K:
valid_block = level == 1 || level == 2 || (wi->pa52bit && level == 0);
break;
case SZ_16K:
- case SZ_64K:
valid_block = level == 2 || (wi->pa52bit && level == 1);
break;
+ case SZ_64K:
+ valid_block = level == 2 || (lpa && level == 1);
+ break;
}
if (!valid_block)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 5/5] watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
From: Thomas Perrot @ 2026-06-05 18:42 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: thomas.perrot@bootlin.com, devicetree, linux-kernel, linux-gpio,
imx, linux-arm-kernel, linux-watchdog, Thomas Petazzoni,
Miquel Raynal
In-Reply-To: <bcc88b28-fa45-4a75-8a09-98d25a9377c9@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Hello Guenter,
On Fri, 2026-04-10 at 08:49 -0700, Guenter Roeck wrote:
> On 4/8/26 10:21, Thomas Perrot (Schneider Electric) wrote:
> > Add watchdog driver for the Aaeon SRG-IMX8P embedded controller.
> > This driver provides system monitoring and recovery capabilities
> > through the MCU's watchdog timer.
> >
> > The watchdog supports start, stop, and ping operations with a
> > maximum
> > hardware heartbeat of 25 seconds and a default timeout of 240
> > seconds.
> >
> > snip
> >
>
> Odd, unusual, unnecessary, I would argue that most people would
> consider a fixed
> timeout of 240s as anything but reasonable, and as the comment says
> arbitrary.
> Since I am sure that I pointed this out before, you still insist, and
> I am
> tired of arguing: Your funeral, so
>
I apologize for not addressing this in previous iterations.
This will be addressed in v6 to make the software timeout configurable.
The 240s value remains as the default fallback.
Kind regards,
Thomas
> Acked-by: Guenter Roeck <linux@roeck-us.net>
>
> Guenter
>
> >
> >
--
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] fs/resctrl: Factor MBA parse-time conversion to be per-arch
From: Reinette Chatre @ 2026-06-05 18:43 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-4-ben.horgan@arm.com>
Hi Ben,
On 5/15/26 7:06 AM, Ben Horgan wrote:
> From: Dave Martin <Dave.Martin@arm.com>
>
> The control value parser for the MB resource currently coerces the
> memory bandwidth percentage value from userspace to be an exact
> multiple of the rdt_resource::resctrl_membw::bw_gran parameter.
>
> On MPAM systems, this results in somewhat worse-than-worst-case
> rounding, since the bandwidth granularity advertised to resctrl by the
> MPAM driver is in general only an approximation to the actual hardware
> granularity on these systems, and the hardware bandwidth allocation
> control value is not natively a percentage -- necessitating a further
> conversion in the resctrl_arch_update_domains() path, regardless of the
> conversion done at parse time.
>
> For MPAM and x86 use their custom pre-prepared parse-time conversion,
> resctrl_arch_preconvert_bw(). This will avoid accumulated error
> from rounding the value twice on MPAM systems. For x86 systems there
> is no functional change.
>
> Clarify the documentation, but avoid overly exact promises.
>
> Clamping to bw_min and bw_max still feels generic: leave it in the core
> code, for now.
Same comment as v2: please use max line length available. Some more context here:
When resctrl patches are formatted as above the x86 maintainers end up reformatting
them if they can afford to spend the time doing so. Having changelog formatted
correctly from beginning avoids this extra churn.
You can find related comment from Boris at
https://lore.kernel.org/lkml/20250916105447.GCaMlB976WLxHHeNMD@fat_crate.local/
...
> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
> index 9a7dfc48cb2e..934e12f5d145 100644
> --- a/fs/resctrl/ctrlmondata.c
> +++ b/fs/resctrl/ctrlmondata.c
> @@ -37,8 +37,8 @@ typedef int (ctrlval_parser_t)(struct rdt_parse_data *data,
> /*
> * Check whether MBA bandwidth percentage value is correct. The value is
> * checked against the minimum and max bandwidth values specified by the
> - * hardware. The allocated bandwidth percentage is rounded to the next
> - * control step available on the hardware.
> + * hardware. The allocated bandwidth percentage is converted as
> + * appropriate for consumption by the specific hardware driver.
Same comment as v2: Adjusting right margin mid-paragraph looks awkward.
> */
> static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
> {
> @@ -71,7 +71,7 @@ static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
> return false;
> }
>
> - *data = roundup(bw, (unsigned long)r->membw.bw_gran);
> + *data = resctrl_arch_preconvert_bw(bw, r);
> return true;
> }
>
With line lengths adjusted (and rebased on patch #1 proposed changes):
| Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH v3 2/3] arm_mpam: resctrl: Add pass-through resctrl_arch_preconvert_bw()
From: Reinette Chatre @ 2026-06-05 18:43 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-3-ben.horgan@arm.com>
Hi Ben,
On 5/15/26 7:06 AM, Ben Horgan wrote:
> resctrl rounds up the percentage value of the MBA based on the bw_gran. As
> MPAM uses a binary fixed point fraction format for MBA rather than a
> decimal percentage, this introduces rounding errors.
>
> Without this additional rounding, if the user reads the value in an MB
> schema and then writes it back to the schema, the value in hardware won't
> change. However, with this additional rounding, this guarantee is broken
> for systems with mbw_wd < 7.
>
> resctrl is introducing resctrl_arch_preconvert_bw() to allow the arch code
> to specify the conversion resctrl does to the user-provided bandwidth
> value. Add the MPAM version of resctrl_arch_preconvert_bw(). This does no
> conversion.
>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
If rebased on patch #1 proposed changes:
| Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH v3 1/3] x86/resctrl: Add resctrl_arch_preconvert_bw()
From: Reinette Chatre @ 2026-06-05 18:42 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-2-ben.horgan@arm.com>
Hi Ben,
Since this patch also impacts resctrl fs API in include/linux/resctrl.h the
subject prefix would more accurate as "x86,fs/resctrl: Add ..."
On 5/15/26 7:06 AM, Ben Horgan wrote:
...
> @@ -500,6 +500,25 @@ bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r);
> */
> int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable);
>
> +/**
> + * resctrl_arch_preconvert_bw() - Prepare bandwidth control value for arch use.
> + * @val: Bandwidth control value written to the schemata file by userspace.
> + * @r: Resource whose schema was written.
> + *
> + * Convert the user provided bandwidth control value to an appropriate form for
> + * consumption by the hardware driver for resource @r. Converted value is stored
> + * in rdt_ctrl_domain::staged_config[] for later consumption by
> + * resctrl_arch_update_domains(). Is not called when MBA software controller is
> + * enabled.
> + *
> + * Architectures for which this pre-conversion hook is not useful should supply
> + * an implementation of this function that just returns val unmodified.
nit: "val" -> "@val"
> + *
> + * Return:
> + * The converted value.
> + */
> +u32 resctrl_arch_preconvert_bw(u32 val, const struct rdt_resource *r);
Could you please switch the resource to be the first parameter? When comparing
this to other similar arch helpers in include/linux/resctrl.h it is custom for the resource
to be the first parameter.
> +
> /*
> * Update the ctrl_val and apply this config right now.
> * Must be called on one of the domain's CPUs.
| Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH v3 0/3] x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch
From: Reinette Chatre @ 2026-06-05 18:41 UTC (permalink / raw)
To: Ben Horgan
Cc: james.morse, fenghuay, linux-kernel, linux-arm-kernel, tglx,
mingo, bp, dave.hansen, hpa, corbet, x86, linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-1-ben.horgan@arm.com>
Hi Ben,
On 5/15/26 7:06 AM, Ben Horgan wrote:
> This is a new version of Dave Martin's patch [1] to delegate rounding of
> bandwidth control user values to the arch code. As there is now more than one
> architecture using resctrl, I split the original patch into two, a core resctrl
> patch and an x86 patch, and added an MPAM patch. Please let me know if the patch
> break down and ordering is sensible and whether the pattern should be followed
> for any future similar changes.
This ordering is sensible to me. I find the patch breakdown a bit fragmented since
the logical resctrl fs change is split yet I also find that you did what was best
to ensure bisectability. I find small changes that are local to subsystems easier to
consider and believe it would be ideal to only have patches touching multiple
subsystems when it cannot be avoided, for example when doing otherwise would break
bisect. Even so, we may learn of better ways to do this when this series is considered
for x86 inclusion.
Reinette
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-05 18:26 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-2-345dd5f6608a@axiado.com>
On Thu, May 28, 2026 at 01:10:24AM -0700, Petar Stepanovic wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
>
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.
(I'll try to not duplicate what Joshua noticed already.)
...
> +config AXIADO_SARADC
> + tristate "Axiado SARADC driver"
> + depends on ARCH_AXIADO || COMPILE_TEST
> + depends on OF
No, in IIO we want a good justification on non-agnostic requirements.
Why can't this device driver be agnostic?
...
> +#include <linux/bitfield.h>
+ bits.h
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/iio/iio.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
No driver should have this header to be included.
Rare and well justified exceptions are possible
(and no, not in this case).
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
...
> +struct axiado_saradc {
> + void __iomem *regs;
> + struct clk *clk;
> + unsigned long clk_rate;
> + int vref_uv;
_uV (yes, capital letter as per SI).
> + struct mutex lock; /* Serializes ADC conversions. */
> +};
...
> +static int axiado_saradc_conversion(struct axiado_saradc *info,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + unsigned long usecs;
Missing blank line here.
> + /* Select the channel to be used and trigger conversion */
> + iowrite32(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
> + info->regs + AX_SARADC_MANUAL_CTRL);
Why not writel()?
> +
> + /* Hardware requires 13 conversion cycles at clk_rate */
> + usecs = DIV_ROUND_UP(AX_SARADC_CONV_CYCLES * 1000000, info->clk_rate);
USe USEC_PER_SEC from time.h.
> + usleep_range(usecs, usecs + 10);
> +
> + *val = ioread32(info->regs + AX_SARADC_DOUT) &
> + GENMASK(AX_RESOLUTION_BITS - 1, 0);
> +
> + /* Stop manual conversion */
> + iowrite32(0, info->regs + AX_SARADC_MANUAL_CTRL);
> + return 0;
> +}
...
> +static int axiado_saradc_probe(struct platform_device *pdev)
> +{
> + struct axiado_saradc *info;
> + const struct axiado_saradc_soc_data *soc_data;
> + struct iio_dev *indio_dev;
> + int ret;
> + u32 reg;
> +
> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> +
> + info->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(info->regs))
> + return PTR_ERR(info->regs);
> +
> + info->clk = devm_clk_get_enabled(&pdev->dev, NULL);
Why no name? It will make harder for the next generations of HW in case they
want more than one clock to be used.
> + if (IS_ERR(info->clk))
> + return PTR_ERR(info->clk);
> +
> + info->clk_rate = clk_get_rate(info->clk);
> + if (!info->clk_rate)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "invalid clock rate\n");
> + info->vref_uv = devm_regulator_get_enable_read_voltage(&pdev->dev,
> + "vref");
Having
struct device *dev = &pdev->dev;
will make the code shorter and easier to read.
> + if (info->vref_uv < 0)
> + return dev_err_probe(&pdev->dev, info->vref_uv,
> + "failed to get vref voltage\n");
> +
> + soc_data = device_get_match_data(&pdev->dev);
> + if (!soc_data)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "failed to get match data\n");
> +
> + mutex_init(&info->lock);
> + reg = FIELD_PREP(AX_SARADC_CH_EN_MASK,
> + GENMASK(soc_data->num_channels - 1, 0)) |
> + AX_SARADC_SAMPLE_16 | AX_SARADC_MODE | AX_SARADC_ENABLE;
FIELD_PREP_CONST() ?
> + iowrite32(AX_SARADC_PD, info->regs + AX_SARADC_GLOBAL_CTRL);
> + iowrite32(reg, info->regs + AX_SARADC_GLOBAL_CTRL);
> +
> + indio_dev->name = dev_name(&pdev->dev);
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->info = &axiado_saradc_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = axiado_saradc_iio_channels;
> + indio_dev->num_channels = soc_data->num_channels;
> +
> + ret = devm_iio_device_register(&pdev->dev, indio_dev);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to register IIO device\n");
> +
> + return 0;
> +}
...
> +static const struct of_device_id axiado_saradc_match[] = {
> + {
> + .compatible = "axiado,ax3000-saradc",
> + .data = &ax3000_saradc_data,
> + },
> + {
> + .compatible = "axiado,ax3005-saradc",
> + .data = &ax3005_saradc_data,
> + },
> + {},
No comma for the terminator entry.
> +};
...
> +static struct platform_driver axiado_saradc_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
We want to have these kind of strings to be fixed.
> + .of_match_table = axiado_saradc_match,
> + },
> + .probe = axiado_saradc_probe,
> +};
> +
Unnecessary blank line.
> +module_platform_driver(axiado_saradc_driver);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-05 18:16 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-0-345dd5f6608a@axiado.com>
On Thu, May 28, 2026 at 01:10:22AM -0700, Petar Stepanovic wrote:
> This series adds support for the SAR ADC controller found on Axiado
> AX3000 and AX3005 SoCs.
>
> The controller is a 10-bit ADC. AX3000 has sixteen input channels and
> AX3005 has eight input channels. The driver uses SoC match data to
> select the number of available channels for each compatible.
>
> The driver supports single-shot voltage reads through the IIO subsystem
> and uses the reference voltage regulator for scale calculation.
When submit a new driver always answer these two questions:
- why do we even need a new brand driver? (No existing that can be extended?)
- where can we get a datasheet? (URL? Other means?)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Frank Li @ 2026-06-05 18:06 UTC (permalink / raw)
To: Stefan Wahren
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <a9304534-2d7d-4316-bcd1-36ff0931bcf0@gmx.net>
On Fri, Jun 05, 2026 at 07:11:30PM +0200, Stefan Wahren wrote:
> Hi Frank,
>
> Am 05.06.26 um 18:35 schrieb Frank Li:
> > On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
> > > Hi Frank,
> > >
> > > Am 27.05.26 um 17:14 schrieb Stefan Wahren:
> > > > Enable DP83822 PHY driver as a module to support the Ethernet PHY,
> > > > which is placed on phyCORE-i.MX93 SOM.
> > > >
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > > Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> > > could you please take care of this patch?
> > which is base commit, I can't apply clearly.
> I rebased against torvalds/v7.1-rc1
pick to imx/defconfig
Frank
> >
> > Frank
> >
> > > > ---
> > > >
> > > > Changes in V2:
> > > > - rebase patch
> > > > - add Krzysztof's Reviewed-by
> > > >
> > > > arch/arm64/configs/defconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > > > index d905a0777f93..20bbbd310d2f 100644
> > > > --- a/arch/arm64/configs/defconfig
> > > > +++ b/arch/arm64/configs/defconfig
> > > > @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
> > > > CONFIG_QCA808X_PHY=m
> > > > CONFIG_REALTEK_PHY=y
> > > > CONFIG_ROCKCHIP_PHY=y
> > > > +CONFIG_DP83822_PHY=m
> > > > CONFIG_DP83867_PHY=y
> > > > CONFIG_DP83869_PHY=m
> > > > CONFIG_DP83TG720_PHY=m
> > >
>
>
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: Adam Young @ 2026-06-05 17:19 UTC (permalink / raw)
To: Sudeep Holla, Adam Young
Cc: Jassi Brar, linux-kernel, linux-hwmon, Rafael J . Wysocki,
Len Brown, linux-acpi, Andi Shyti, Guenter Roeck, Huisong Li,
MyungJoo Ham, Kyungmin Park, Chanwoo Choi, linux-arm-kernel
In-Reply-To: <c61fa285-01a6-4ac3-82ec-2a6357a9e76f@amperemail.onmicrosoft.com>
On 6/3/26 11:15, Adam Young wrote:
>
> On 5/19/26 09:23, Sudeep Holla wrote:
>> On Mon, May 18, 2026 at 03:30:06PM -0400, Adam Young wrote:
>>> The tx_done callback function has a return code (rc) parameter
>>> that the tx_done callback can use to determine how to handle an error.
>>> However the IRQ handler was not setting that value if there is an
>>> error.
>>>
>>> The following clients are affected:
>>>
>>> drivers/acpi/cppc_acpi.c
>>> drivers/i2c/busses/i2c-xgene-slimpro.c
>>> drivers/hwmon/xgene-hwmon.c
>>> drivers/soc/hisilicon/kunpeng_hccs.c
>>> drivers/devfreq/hisi_uncore_freq.c
>>>
>>> All of these only use the error code to report, so they
>>> are expecting an error code to come thorugh, but they
>>> do not modify behavior based on this code.
>>>
>>> In the case of an error code in the IRQ, the handler was returning
>>> IRQ_NONE which is not correct: the IRQ handler was matched
>>> to the IRQ. This mean that multiple error codes returned from
>>> a PCC triggered interrupt would end up disabling the device.
>>>
>>> In addition, if the error code IRQ was coming from a Type4 Device
>>> that was
>>> expecting an IRQ response, that device would then be hung.
>>>
>>> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended
>>> PCC subspaces(type 3/4)")
>>> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>>>
>>> ---
>>> ---
>>> drivers/mailbox/pcc.c | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>>> index 636879ae1db7..16b9ce087b9e 100644
>>> --- a/drivers/mailbox/pcc.c
>>> +++ b/drivers/mailbox/pcc.c
>>> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> {
>>> struct pcc_chan_info *pchan;
>>> struct mbox_chan *chan = p;
>>> + int rc;
>>> pchan = chan->con_priv;
>>> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> if (!pcc_mbox_cmd_complete_check(pchan))
>>> return IRQ_NONE;
>>> - if (pcc_mbox_error_check_and_clear(pchan))
>>> - return IRQ_NONE;
>>> + rc = pcc_mbox_error_check_and_clear(pchan);
>> I think we may have to skip the check inside
>> pcc_mbox_error_check_and_clear()
>> for Type 4 channel as the spec expects OSPM to ignore it. It is a
>> separate
>> fix, just noting that here.
>
> I think that should be in this patch, for correctness. It is a small
> enough change. I'll update.
>
Actually, it is a fix in its own right, and can be merged regardless of
this patch, so:
https://lore.kernel.org/lkml/20260604163306.160017-1-admiyo@os.amperecomputing.com/
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 17:11 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <aiL638OLrfntKmSC@lizhi-Precision-Tower-5810>
Hi Frank,
Am 05.06.26 um 18:35 schrieb Frank Li:
> On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
>> Hi Frank,
>>
>> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
>>> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
>>> which is placed on phyCORE-i.MX93 SOM.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> could you please take care of this patch?
> which is base commit, I can't apply clearly.
I rebased against torvalds/v7.1-rc1
>
> Frank
>
>>> ---
>>>
>>> Changes in V2:
>>> - rebase patch
>>> - add Krzysztof's Reviewed-by
>>>
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index d905a0777f93..20bbbd310d2f 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
>>> CONFIG_QCA808X_PHY=m
>>> CONFIG_REALTEK_PHY=y
>>> CONFIG_ROCKCHIP_PHY=y
>>> +CONFIG_DP83822_PHY=m
>>> CONFIG_DP83867_PHY=y
>>> CONFIG_DP83869_PHY=m
>>> CONFIG_DP83TG720_PHY=m
>>
^ permalink raw reply
* Re: [PATCH RFC v2] drm/rockchip: vop2: Add clock rate mode check
From: Alexey Charkov @ 2026-06-05 16:57 UTC (permalink / raw)
To: Alexey Charkov
Cc: Sebastian Reichel, Sandy Huang, Heiko Stübner, Andy Yan,
Daniel Stone, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, dri-devel, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel
In-Reply-To: <CABjd4Yw_HYpjhrgmonB9FmWV00q=r3yvqnFE4TXEHpM1ZgWOhA@mail.gmail.com>
On Fri, Jun 5, 2026 at 7:58 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Fri, Apr 10, 2026 at 2:37 AM Sebastian Reichel
> <sebastian.reichel@collabora.com> wrote:
> >
> > The display might offer modes, which exceed the maximum clock rate of a
> > video output. This usually happens for displays that offer refresh rates
> > above 60 Hz. This results in no picture (or a broken one) being displayed
> > without manual intervention. Fix this by teaching the driver about the
> > maximum achievable clock rates for each video port.
> >
> > The information about the maximum clock rates for each video channel and
> > the tip about multiple pixels being processed per clock were provided by
> > Andy Yan and roughly checked against the information available in the
> > datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
> > instead of a specific pixel rate).
> >
> > For the video ports supporting a 600 MHz input clock, there is some
> > logic to handle up to 4 pixels in parallel when needed resulting in
> > the extra multiplier.
> >
> > Suggested-by: Andy Yan <andy.yan@rock-chips.com>
> > Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> > I've kept the RFC tag, as I'm not sure about the 4x parallel pixel
> > processing. IIUIC all of the video ports with a maximum of 600 MHz
> > input clock support it, considering they can go to 4K @ 120Hz,
> > which is above 1.2GHz while Andy mentioned a max. support clock rate
> > of 600 MHz.
> > ---
> > Changes in v2:
> > - Link to v1: https://lore.kernel.org/r/20260217-vop2-clk-rate-check-v1-1-989b569119ba@collabora.com
> > - based on v7.0-rc7
> > - rename max_clock_rate into max_pixel_clock_rate to distinguish from
> > input clock
> > - update max clock rates to the numbers provided by Andy Yan with
> > extra 4x multiplier for 4K 120Hz VPs
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
> > drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 10 ++++++++++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index a195f5c819a2..35a0edda5375 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -1434,6 +1434,9 @@ static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc,
> > if (mode->hdisplay > vp->data->max_output.width)
> > return MODE_BAD_HVALUE;
> >
> > + if (mode->clock > vp->data->max_pixel_clock_rate / 1000)
> > + return MODE_CLOCK_HIGH;
> > +
> > return MODE_OK;
> > }
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > index 9124191899ba..fd46913f3346 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > @@ -225,6 +225,7 @@ struct vop2_video_port_data {
> > u16 gamma_lut_len;
> > u16 cubic_lut_len;
> > struct vop_rect max_output;
> > + u32 max_pixel_clock_rate;
> > const u8 pre_scan_max_dly[4];
> > unsigned int offset;
> > /**
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > index f3950e8476a7..6ae3d506c476 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> > @@ -559,18 +559,21 @@ static const struct vop2_video_port_data rk3568_vop_video_ports[] = {
> > .gamma_lut_len = 1024,
> > .cubic_lut_len = 9 * 9 * 9,
> > .max_output = { 4096, 2304 },
> > + .max_pixel_clock_rate = 600000000U,
> > .pre_scan_max_dly = { 69, 53, 53, 42 },
> > .offset = 0xc00,
> > }, {
> > .id = 1,
> > .gamma_lut_len = 1024,
> > .max_output = { 2048, 1536 },
> > + .max_pixel_clock_rate = 200000000U,
> > .pre_scan_max_dly = { 40, 40, 40, 40 },
> > .offset = 0xd00,
> > }, {
> > .id = 2,
> > .gamma_lut_len = 1024,
> > .max_output = { 1920, 1080 },
> > + .max_pixel_clock_rate = 150000000U,
> > .pre_scan_max_dly = { 40, 40, 40, 40 },
> > .offset = 0xe00,
> > },
> > @@ -775,6 +778,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
> > .gamma_lut_len = 1024,
> > .cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
> > .max_output = { 4096, 2304 },
> > + .max_pixel_clock_rate = 600000000U * 4,
>
> Hi Sebastian,
>
> I've tested it on a bunch of different displays with RK3576 while also
> giving VP0 an unlimited PLL to work with (and also expanding its rates
> table for each of the displays' EDID preferred pixel clocks), and I'm
> pretty sure this should be * 2 here, rather than * 4. That would also
> align with ".pixel_rate = 2" just below.
>
> In its current form, some of the advanced displays with 240 Hz modes
> by default choose modes leading to visual artifacts indicative of
> overclocking strain of the graphics pipeline.
>
> The rest look plausible, so with that change please feel free to include:
>
> Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Sorry, wrong mailbox.
Tested-by: Alexey Charkov <alchark@flipper.net> # RK3576
Best regards,
Alexey
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 fixes for 7.1, take #5
From: Paolo Bonzini @ 2026-06-05 16:57 UTC (permalink / raw)
To: Marc Zyngier
Cc: Hyunwoo Kim, Joey Gouly, Oliver Upton, Wei-Lin Chang,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
In-Reply-To: <20260605164516.2214533-1-maz@kernel.org>
On Fri, Jun 5, 2026 at 6:45 PM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Yes, I said that last week's pull request was the last. I really meant
> it, honest. But people (and their AI best mate) keep finding ugly
> stuff in dark corners, and I can't sit on this stuff much longer.
>
> So here we have an assorted mess of bad races, broken userspace, and
> architectural bugs. What's not to like? As usual, details in the tag
> below.
x86 isn't doing any better, so who am I to judge.
Pulled, thanks.
Paolo
>
> Please pull,
>
> M.
>
> The following changes since commit 83726330748981372bde86ed5411d7b306612991:
>
> KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor (2026-05-29 10:04:00 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-5
>
> for you to fetch changes up to 17f073f78fc43280891ecde8f8ec3f84f98bb37c:
>
> KVM: arm64: Correctly identify executable PTEs at stage-2 (2026-06-05 14:07:57 +0100)
>
> ----------------------------------------------------------------
> KVM/arm64 fixes for 7.1, take #5
>
> - Correctly drop the ITS translation cache reference when it actually
> gets invalidated
>
> - Take the SRCU lock for SW page table walks
>
> - Restore POR_EL0 access to host EL0, avoiding POR_EL0 becoming
> inaccessible from EL0 after running a guest
>
> - Reassign nested_mmus array behind mmu_lock, ensuring that vcpu init
> and MMU notifiers are mutually exclusive
>
> - Correctly handle FEAT_XNX at stage-2
>
> ----------------------------------------------------------------
> Hyunwoo Kim (3):
> KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry
> KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
> KVM: arm64: Reassign nested_mmus array behind mmu_lock
>
> Joey Gouly (1):
> KVM: arm64: Restore POR_EL0 access to host EL0
>
> Oliver Upton (2):
> KVM: arm64: nv: Fix handling of XN[0] when !FEAT_XNX
> KVM: arm64: Correctly identify executable PTEs at stage-2
>
> arch/arm64/include/asm/kvm_nested.h | 4 ++--
> arch/arm64/kvm/at.c | 6 ++++--
> arch/arm64/kvm/hyp/include/hyp/switch.h | 2 ++
> arch/arm64/kvm/hyp/pgtable.c | 4 +++-
> arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
> arch/arm64/kvm/vgic/vgic-its.c | 6 ++++--
> 6 files changed, 35 insertions(+), 20 deletions(-)
>
^ permalink raw reply
* Re: [PATCH V2] arm64: defconfig: Enable DP83822 PHY driver
From: Stefan Wahren @ 2026-06-05 16:51 UTC (permalink / raw)
To: Frank Li
Cc: Christoph Stoidner, Primoz Fiser, linux-arm-kernel,
Krzysztof Kozlowski, Arnd Bergmann, Catalin Marinas, Will Deacon,
Alexandre Belloni, Linus Walleij
In-Reply-To: <aiL5Yy7hiL30FENV@lizhi-Precision-Tower-5810>
Am 05.06.26 um 18:29 schrieb Frank Li:
> On Fri, Jun 05, 2026 at 06:22:14PM +0200, Stefan Wahren wrote:
>> Hi Frank,
>>
>> Am 27.05.26 um 17:14 schrieb Stefan Wahren:
>>> Enable DP83822 PHY driver as a module to support the Ethernet PHY,
>>> which is placed on phyCORE-i.MX93 SOM.
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> could you please take care of this patch?
> I will pick it, next time please cc imx@lists.linux.dev, otherwise, my imx
> patchwork can't see your patch
Sorry for this and thanks for picking
Regards
>
> Frank
>
>>> ---
>>>
>>> Changes in V2:
>>> - rebase patch
>>> - add Krzysztof's Reviewed-by
>>>
>>> arch/arm64/configs/defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index d905a0777f93..20bbbd310d2f 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -421,6 +421,7 @@ CONFIG_AT803X_PHY=y
>>> CONFIG_QCA808X_PHY=m
>>> CONFIG_REALTEK_PHY=y
>>> CONFIG_ROCKCHIP_PHY=y
>>> +CONFIG_DP83822_PHY=m
>>> CONFIG_DP83867_PHY=y
>>> CONFIG_DP83869_PHY=m
>>> CONFIG_DP83TG720_PHY=m
>>
^ permalink raw reply
* Re: [PATCH v4 2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: Frank Li @ 2026-06-05 16:49 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, Paul Gerber, devicetree, linux-kernel,
imx, linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <20260603093621.2504490-2-alexander.stein@ew.tq-group.com>
On Wed, Jun 03, 2026 at 11:36:07AM +0200, Alexander Stein wrote:
> From: Paul Gerber <paul.gerber@tq-group.com>
>
> This adds support for TQMa8MPQS module on MB-SMARC-2 board.
>
> Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> Changes in v4:
> * Fix audio codec clock config (similar to commit 6d36cebfb466a
> ("arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio
> codec as well")
> * Fix GPIO line names on gpio4, found by Sashiko bot
> * Move compatible and reg property to top for tmp1075
> * Remove interrupts for tmp1075
> No support in bindings and driver, although HW has ALET pin connected
>
...
> + pcieclk: clock-generator@6a {
> + compatible = "renesas,9fgv0241";
> + reg = <0x6a>;
> + clocks = <&clk_xtal25>;
> + #clock-cells = <1>;
> + };
> +
> + imu@6b {
Please generial node name: inertial-sensor@6b
Frank
^ 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