* Re: [PATCH v6 00/40] arm_mpam: Add KVM/arm64 and resctrl glue code
From: Fenghua Yu @ 2026-04-01 23:56 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, gshan, james.morse, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc
In-Reply-To: <20260313144617.3420416-1-ben.horgan@arm.com>
On 3/13/26 07:45, Ben Horgan wrote:
> This version of the mpam missing pieces series sees a couple of things
> dropped or hidden. Memory bandwith utilization with free-running counters
> is dropped in preference of just always using 'mbm_event' mode (ABMC
> emulation) which simplifies the code and allows for, in the future,
> filtering by read/write traffic. So, for the interim, there is no memory
> bandwidth utilization support. CDP is hidden behind config expert as
> remount of resctrl fs could potentially lead to out of range PARTIDs being
> used and the fix requires a change in fs/resctrl. The setting of MPAM2_EL2
> (for pkvm/nvhe) is dropped as too expensive a write for not much value.
>
> There are a couple of 'fixes' at the start of the series which address
> problems in the base driver but are only user visible due to this series.
Tested-by: Fenghua Yu <fenghuay@nvidia.com>
Thanks.
-Fenghua
^ permalink raw reply
* [PATCH] clk: mvebu: use kzalloc_flex
From: Rosen Penev @ 2026-04-02 0:20 UTC (permalink / raw)
To: linux-clk
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member to combine kzalloc and kcalloc in one
allocation so they can be freed together.
Add __counted_by for extra runtime analysis. Move counting variable
assignment right after allocation as done by kzalloc_flex with GCC >=
15.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/mvebu/common.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
index 28f2e1b2a932..4129690fcae0 100644
--- a/drivers/clk/mvebu/common.c
+++ b/drivers/clk/mvebu/common.c
@@ -189,10 +189,10 @@ DEFINE_SPINLOCK(ctrl_gating_lock);
struct clk_gating_ctrl {
spinlock_t *lock;
- struct clk **gates;
int num_gates;
void __iomem *base;
u32 saved_reg;
+ struct clk *gates[] __counted_by(num_gates);
};
static struct clk_gating_ctrl *ctrl;
@@ -257,24 +257,21 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
clk_put(clk);
}
- ctrl = kzalloc_obj(*ctrl);
+ /* Count, allocate, and register clock gates */
+ for (n = 0; desc[n].name;)
+ n++;
+
+ ctrl = kzalloc_flex(*ctrl, gates, n);
if (WARN_ON(!ctrl))
goto ctrl_out;
+ ctrl->num_gates = n;
+
/* lock must already be initialized */
ctrl->lock = &ctrl_gating_lock;
ctrl->base = base;
- /* Count, allocate, and register clock gates */
- for (n = 0; desc[n].name;)
- n++;
-
- ctrl->num_gates = n;
- ctrl->gates = kzalloc_objs(*ctrl->gates, ctrl->num_gates);
- if (WARN_ON(!ctrl->gates))
- goto gates_out;
-
for (n = 0; n < ctrl->num_gates; n++) {
const char *parent =
(desc[n].parent) ? desc[n].parent : default_parent;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-02 0:37 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Add compatible strings for MediaTek SoCs where the hardware random number
generator is accessed via a vendor-defined Secure Monitor Call (SMC)
rather than direct MMIO register access:
- mediatek,mt7981-rng
- mediatek,mt7987-rng
- mediatek,mt7988-rng
These variants require no reg, clocks, or clock-names properties since
the RNG hardware is managed by ARM Trusted Firmware-A.
Relax the $nodename pattern to also allow 'rng' in addition to the
existing 'rng@...' pattern.
Add a second example showing the minimal SMC variant binding.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2: express compatibilities with fallback
.../devicetree/bindings/rng/mtk-rng.yaml | 28 ++++++++++++++++---
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
index 7e8dc62e5d3a6..34648b53d14c6 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
@@ -11,12 +11,13 @@ maintainers:
properties:
$nodename:
- pattern: "^rng@[0-9a-f]+$"
+ pattern: "^rng(@[0-9a-f]+)?$"
compatible:
oneOf:
- enum:
- mediatek,mt7623-rng
+ - mediatek,mt7981-rng
- items:
- enum:
- mediatek,mt7622-rng
@@ -25,6 +26,11 @@ properties:
- mediatek,mt8365-rng
- mediatek,mt8516-rng
- const: mediatek,mt7623-rng
+ - items:
+ - enum:
+ - mediatek,mt7987-rng
+ - mediatek,mt7988-rng
+ - const: mediatek,mt7981-rng
reg:
maxItems: 1
@@ -38,9 +44,19 @@ properties:
required:
- compatible
- - reg
- - clocks
- - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: mediatek,mt7981-rng
+ then:
+ required:
+ - reg
+ - clocks
+ - clock-names
additionalProperties: false
@@ -53,3 +69,7 @@ examples:
clocks = <&infracfg CLK_INFRA_TRNG>;
clock-names = "rng";
};
+ - |
+ rng {
+ compatible = "mediatek,mt7981-rng";
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] hwrng: mtk - add support for hw access via SMCC
From: Daniel Golle @ 2026-04-02 0:37 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <0a951e34b7030e514091d6c0922c5982ae349221.1775090165.git.daniel@makrotopia.org>
Newer versions of ARM TrustedFirmware-A on MediaTek's ARMv8 SoCs no longer
allow accessing the TRNG from outside of the trusted firmware.
Instead, a vendor-defined custom Secure Monitor Call can be used to
acquire random bytes.
Add support for newer SoCs (MT7981, MT7987, MT7988).
As TF-A for the MT7986 may either follow the old or the new
convention, the best bet is to test if firmware blocks direct access
to the hwrng and if so, expect the SMCC interface to be usable.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2: unchanged
drivers/char/hw_random/mtk-rng.c | 127 ++++++++++++++++++++++++++-----
1 file changed, 106 insertions(+), 21 deletions(-)
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
index 5808d09d12c45..8f5856b59ad66 100644
--- a/drivers/char/hw_random/mtk-rng.c
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -3,6 +3,7 @@
* Driver for Mediatek Hardware Random Number Generator
*
* Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ * Copyright (C) 2026 Daniel Golle <daniel@makrotopia.org>
*/
#define MTK_RNG_DEV KBUILD_MODNAME
@@ -17,6 +18,8 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
+#include <linux/arm-smccc.h>
+#include <linux/soc/mediatek/mtk_sip_svc.h>
/* Runtime PM autosuspend timeout: */
#define RNG_AUTOSUSPEND_TIMEOUT 100
@@ -30,6 +33,11 @@
#define RNG_DATA 0x08
+/* Driver feature flags */
+#define MTK_RNG_SMC BIT(0)
+
+#define MTK_SIP_KERNEL_GET_RND MTK_SIP_SMC_CMD(0x550)
+
#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
struct mtk_rng {
@@ -37,6 +45,7 @@ struct mtk_rng {
struct clk *clk;
struct hwrng rng;
struct device *dev;
+ unsigned long flags;
};
static int mtk_rng_init(struct hwrng *rng)
@@ -103,6 +112,56 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
return retval || !wait ? retval : -EIO;
}
+static int mtk_rng_read_smc(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ struct arm_smccc_res res;
+ int retval = 0;
+
+ while (max >= sizeof(u32)) {
+ arm_smccc_smc(MTK_SIP_KERNEL_GET_RND, 0, 0, 0, 0, 0, 0, 0,
+ &res);
+ if (res.a0)
+ break;
+
+ *(u32 *)buf = res.a1;
+ retval += sizeof(u32);
+ buf += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static bool mtk_rng_hw_accessible(struct mtk_rng *priv)
+{
+ u32 val;
+ int err;
+
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return false;
+
+ val = readl(priv->base + RNG_CTRL);
+ val |= RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ val = readl(priv->base + RNG_CTRL);
+
+ if (val & RNG_EN) {
+ /* HW is accessible, clean up: disable RNG and clock */
+ writel(val & ~RNG_EN, priv->base + RNG_CTRL);
+ clk_disable_unprepare(priv->clk);
+ return true;
+ }
+
+ /*
+ * If TF-A blocks direct access, the register reads back as 0.
+ * Leave the clock enabled as TF-A needs it.
+ */
+ return false;
+}
+
static int mtk_rng_probe(struct platform_device *pdev)
{
int ret;
@@ -114,23 +173,42 @@ static int mtk_rng_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->rng.name = pdev->name;
-#ifndef CONFIG_PM
- priv->rng.init = mtk_rng_init;
- priv->rng.cleanup = mtk_rng_cleanup;
-#endif
- priv->rng.read = mtk_rng_read;
priv->rng.quality = 900;
-
- priv->clk = devm_clk_get(&pdev->dev, "rng");
- if (IS_ERR(priv->clk)) {
- ret = PTR_ERR(priv->clk);
- dev_err(&pdev->dev, "no clock for device: %d\n", ret);
- return ret;
+ priv->flags = (unsigned long)device_get_match_data(&pdev->dev);
+
+ if (!(priv->flags & MTK_RNG_SMC)) {
+ priv->clk = devm_clk_get(&pdev->dev, "rng");
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(&pdev->dev, "no clock for device: %d\n", ret);
+ return ret;
+ }
+
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ if (IS_ENABLED(CONFIG_HAVE_ARM_SMCCC) &&
+ of_device_is_compatible(pdev->dev.of_node,
+ "mediatek,mt7986-rng") &&
+ !mtk_rng_hw_accessible(priv)) {
+ priv->flags |= MTK_RNG_SMC;
+ dev_info(&pdev->dev,
+ "HW RNG not MMIO accessible, using SMC\n");
+ }
}
- priv->base = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(priv->base))
- return PTR_ERR(priv->base);
+ if (priv->flags & MTK_RNG_SMC) {
+ if (!IS_ENABLED(CONFIG_HAVE_ARM_SMCCC))
+ return -ENODEV;
+ priv->rng.read = mtk_rng_read_smc;
+ } else {
+#ifndef CONFIG_PM
+ priv->rng.init = mtk_rng_init;
+ priv->rng.cleanup = mtk_rng_cleanup;
+#endif
+ priv->rng.read = mtk_rng_read;
+ }
ret = devm_hwrng_register(&pdev->dev, &priv->rng);
if (ret) {
@@ -139,12 +217,15 @@ static int mtk_rng_probe(struct platform_device *pdev)
return ret;
}
- dev_set_drvdata(&pdev->dev, priv);
- pm_runtime_set_autosuspend_delay(&pdev->dev, RNG_AUTOSUSPEND_TIMEOUT);
- pm_runtime_use_autosuspend(&pdev->dev);
- ret = devm_pm_runtime_enable(&pdev->dev);
- if (ret)
- return ret;
+ if (!(priv->flags & MTK_RNG_SMC)) {
+ dev_set_drvdata(&pdev->dev, priv);
+ pm_runtime_set_autosuspend_delay(&pdev->dev,
+ RNG_AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ ret = devm_pm_runtime_enable(&pdev->dev);
+ if (ret)
+ return ret;
+ }
dev_info(&pdev->dev, "registered RNG driver\n");
@@ -181,8 +262,11 @@ static const struct dev_pm_ops mtk_rng_pm_ops = {
#endif /* CONFIG_PM */
static const struct of_device_id mtk_rng_match[] = {
- { .compatible = "mediatek,mt7986-rng" },
{ .compatible = "mediatek,mt7623-rng" },
+ { .compatible = "mediatek,mt7981-rng", .data = (void *)MTK_RNG_SMC },
+ { .compatible = "mediatek,mt7986-rng" },
+ { .compatible = "mediatek,mt7987-rng", .data = (void *)MTK_RNG_SMC },
+ { .compatible = "mediatek,mt7988-rng", .data = (void *)MTK_RNG_SMC },
{},
};
MODULE_DEVICE_TABLE(of, mtk_rng_match);
@@ -200,4 +284,5 @@ module_platform_driver(mtk_rng_driver);
MODULE_DESCRIPTION("Mediatek Random Number Generator Driver");
MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RESEND 0/5] bitmap: cleanup bitmaps printing
From: Yury Norov @ 2026-04-02 0:57 UTC (permalink / raw)
To: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev
Cc: Jakub Kicinski
In-Reply-To: <abxaIMi55N4X9JWz@yury>
On Thu, Mar 19, 2026 at 04:18:40PM -0400, Yury Norov wrote:
> Ping?
OK, taking 1-4 in bitmap-for-next.
Thanks,
Yury
> On Tue, Mar 03, 2026 at 03:08:36PM -0500, Yury Norov wrote:
> > Bitmap API has a bitmap_print_to_pagebuf() function that is intended to
> > print bitmap into a human readable format, making sure that the output
> > string will not get big enough to cross the current page limit.
> >
> > Some drivers use this function immediately before passing the result to
> > scnprintf() with no modification. This is useless because scnprintf(),
> > and helpers based on it like seq_pritf() and sysfs_emit(), take care of
> > not overflowing the buffer by itself, and perfectly print bitmaps with
> > "%*pb[l]".
> >
> > This is a resend of non-networking part of [1]. Patches #3,5 switch from
> > plain scnprintf() to sysfs_emit(), as pointed out by Thomas Weißschuh.
> >
> > [1] https://lore.kernel.org/all/20260219181407.290201-1-ynorov@nvidia.com/
> >
> > The networking part, for reference:
> >
> > https://lore.kernel.org/all/20260303185507.111841-1-ynorov@nvidia.com/
> >
> > Each patch can be applied individually per corresponding subsystem.
> >
> > Yury Norov (5):
> > powerpc/xive: simplify xive_spapr_debug_show()
> > thermal: intel: switch cpumask_get() to using
> > cpumask_print_to_pagebuf()
> > coresight: don't use bitmap_print_to_pagebuf()
> > lib/prime_numbers: drop temporary buffer in dump_primes()
> > fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
> >
> > arch/powerpc/sysdev/xive/spapr.c | 12 ++-----
> > drivers/fpga/intel-m10-bmc-sec-update.c | 3 +-
> > .../hwtracing/coresight/coresight-cti-sysfs.c | 32 ++++++++-----------
> > drivers/thermal/intel/intel_powerclamp.c | 3 +-
> > lib/math/tests/prime_numbers_kunit.c | 6 ++--
> > 5 files changed, 21 insertions(+), 35 deletions(-)
> >
> > --
> > 2.43.0
^ permalink raw reply
* Re: [RFT PATCH 0/7] perf tool: Support iostat for multiple platforms
From: Yushan Wang @ 2026-04-02 1:14 UTC (permalink / raw)
To: Ian Rogers
Cc: mike.leach, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, adrian.hunter, peterz, john.g.garry,
Jonathan.Cameron, shiju.jose, will, linux-perf-users,
linux-arm-kernel, linuxarm, liuyonglong, prime.zeng, fanghao11,
wangzhou1
In-Reply-To: <CAP-5=fUmozPRDgms0QxHS5G3O8csrhyak9TWGGXeYE+QwiSHQA@mail.gmail.com>
On 4/2/2026 4:52 AM, Ian Rogers wrote:
>
> Hi Yushan, thanks for your effort on iostat! Did you have chance to
> work on follow up?
>
> Thanks,
> Ian
>
Yes, I am still working on it.
The next version will be posted in merge window or early 7.1 cycle.
Thanks for your attention!
Yuashan
>
^ permalink raw reply
* Re: [PATCH v10 5/6] power: supply: max77759: add charger driver
From: Amit Sunil Dhamne @ 2026-04-02 1:25 UTC (permalink / raw)
To: Sebastian Reichel
Cc: André Draszik, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, Jagan Sridharan, Mark Brown,
Matti Vaittinen, Andrew Morton, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, linux-kernel, devicetree, linux-usb,
linux-pm, linux-arm-kernel, linux-samsung-soc, RD Babiera,
Kyle Tso
In-Reply-To: <ac2jYUA2F5oQsA2g@venus>
Hi Sebastian,
Thanks for the review!
On 4/1/26 4:17 PM, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Mar 31, 2026 at 11:22:20PM +0000, Amit Sunil Dhamne via B4 Relay wrote:
>> +/* Charge Termination Voltage Limits (in mV) */
>> +static const struct linear_range chg_cv_prm_ranges[] = {
>> + LINEAR_RANGE(3800, 0x38, 0x39, 100),
>> + LINEAR_RANGE(4000, 0x0, 0x32, 10),
>> +};
> Let me quote from include/linux/power_supply.h:
>
> * All voltages, currents, charges, energies, time and temperatures in uV,
> * µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
> * stated. It's driver's job to convert its raw values to units in which
> * this class operates.
>
> What makes you think that CONSTANT_CHARGE_VOLTAGE_MAX is
> special?
>
> [...]
It was an oversight, I will fix it.
>
>> +static int max77759_charger_get_property(struct power_supply *psy,
>> + enum power_supply_property psp,
>> + union power_supply_propval *pval)
>> +{
>> + struct max77759_charger *chg = power_supply_get_drvdata(psy);
>> + int ret;
>> +
>> + switch (psp) {
>> + case POWER_SUPPLY_PROP_ONLINE:
>> + ret = get_online(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_PRESENT:
>> + ret = charger_input_valid(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_STATUS:
>> + ret = get_status(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_CHARGE_TYPE:
>> + ret = get_charge_type(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_HEALTH:
>> + ret = get_health(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
>> + ret = get_fast_charge_current(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
>> + ret = get_float_voltage(chg);
>> + break;
>> + case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
>> + ret = get_input_current_limit(chg);
>> + break;
>> + default:
>> + ret = -EINVAL;
>> + }
>> +
>> + pval->intval = ret;
>> + return ret < 0 ? ret : 0;
> As people like to use existing drivers as reference this definitely
> needs a comment, that none of the properties used by this driver
> support negative values. This is not a general thing as e.g. the
> CHARGE current may be negative depending on the battery being
> charged or discharged (OTG mode).
Ah okay, thanks for letting me know. I will add a comment.
As these patches are already in flight and part of usb-next of the usb
tree, I can send the suggested improvements as a separate patch, if that
works for you and Greg.
BR,
Amit
>
> Greetings,
>
> -- Sebastian
^ permalink raw reply
* Re: [PATCH v14 3/4] arm64: Use generic TIF bits for common thread flags
From: Jinjie Ruan @ 2026-04-02 1:41 UTC (permalink / raw)
To: Catalin Marinas
Cc: will, chenhuacai, kernel, hca, gor, agordeev, borntraeger, svens,
oleg, tglx, mingo, bp, dave.hansen, hpa, arnd, shuah,
kevin.brodsky, yeoreum.yun, anshuman.khandual, thuth,
ryan.roberts, mark.rutland, song, ziyao, linusw, schuster.simon,
jremus, akpm, mathieu.desnoyers, kmal, dvyukov,
reddybalavignesh9979, x86, linux-arm-kernel, linux-kernel,
loongarch, linux-s390, linux-arch, linux-kselftest
In-Reply-To: <acz5mOrm6_E1UBwV@arm.com>
On 2026/4/1 18:55, Catalin Marinas wrote:
> On Fri, Mar 20, 2026 at 06:42:21PM +0800, Jinjie Ruan wrote:
>> Use the generic TIF bits defined in <asm-generic/thread_info_tif.h> for
>> standard thread flags (TIF_SIGPENDING, TIF_NEED_RESCHED, TIF_NOTIFY_RESUME,
>> TIF_RESTORE_SIGMASK, TIF_SINGLESTEP, etc.) instead of defining
>> them locally.
>>
>> Arm64-specific bits (TIF_FOREIGN_FPSTATE, TIF_MTE_ASYNC_FAULT, TIF_SVE,
>> TIF_SSBD, etc.) are renumbered to start at bit 16 to avoid conflicts.
>>
>> This enables RSEQ optimizations which require CONFIG_HAVE_GENERIC_TIF_BITS
>> combined with the generic entry infrastructure (already used by arm64).
>>
>> By the way, remove TIF_FREEZE because this flag became unused since
>> commit d88e4cb67197 ("freezer: remove now unused TIF_FREEZE").
>>
>> Cc: Thomas Gleixner <tglx@kernel.org>
>> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
>> Reviewed-by: Linus Walleij <linusw@kernel.org>
>> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Given that it's touching multiple trees, I guess it's a series for
> Andrew?
Yes, this series touches x86, arm64, s390 and loongarch. It's best for
Andrew to help merge this in the -mm tree.
Moreover, the latter two arm64-related patches depend on patch serise
"arm64:
entry: Convert to Generic Entry" v14 being merged first, while the first
two patches can be merged in advance.
>
^ permalink raw reply
* Re: [PATCH v2] ARM: module: fix unwind section relocation out of range error
From: William Zhang @ 2026-04-02 1:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, Song Liu, linus.walleij, florian.fainelli,
anand.gore, Broadcom Kernel List, kursad.oney,
Sebastian Andrzej Siewior, Peter Zijlstra, Luis Chamberlain,
linux-kernel, Thomas Gleixner, Christophe Leroy, Petr Pavlu,
Russell King
In-Reply-To: <bb48f874-b80f-41ef-a1a3-81f2e0a7de65@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 125 bytes --]
Hi,
>
> Please put it in Russell's patch tracker.
>
> https://www.arm.linux.org.uk/developer/patches/
>
Uploaded. Thanks!
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Coiby Xu @ 2026-04-02 1:44 UTC (permalink / raw)
To: Rob Herring
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Andrew Morton, Krzysztof Kozlowski, Thomas Staudt, Sourabh Jain,
Will Deacon, Christophe Leroy (CS GROUP), Catalin Marinas,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Saravana Kannan, open list
In-Reply-To: <CAL_Jsq+0w2hGN=Loy=ucHbZcdnn+ty3x9qS4WVX0Vj+g19tfpg@mail.gmail.com>
On Mon, Mar 30, 2026 at 06:44:15AM -0500, Rob Herring wrote:
>On Wed, Feb 25, 2026 at 12:04 AM Coiby Xu <coxu@redhat.com> wrote:
>>
>> CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
>> device dump target by addressing two challenges [1],
>> - Kdump kernel may not be able to decrypt the LUKS partition. For some
>> machines, a system administrator may not have a chance to enter the
>> password to decrypt the device in kdump initramfs after the 1st kernel
>> crashes
>>
>> - LUKS2 by default use the memory-hard Argon2 key derivation function
>> which is quite memory-consuming compared to the limited memory reserved
>> for kdump.
>>
>> To also enable this feature for ARM64 and PowerPC, the missing piece is
>> to let the kdump kernel know where to find the dm-crypt keys which are
>> randomly stored in memory reserved for kdump. Introduce a new device
>> tree property dmcryptkeys [2] as similar to elfcorehdr to pass the
>> memory address of the stored info of dm-crypt keys to the kdump kernel.
>> Since this property is only needed by the kdump kernel, it won't be
>> exposed to user space.
>>
>> [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
>> [2] https://github.com/devicetree-org/dt-schema/pull/181
>>
>> Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
>> Cc: Baoquan he <bhe@redhat.com>
>> Cc: Dave Young <dyoung@redhat.com>
>> Cc: Kairui Song <ryncsn@gmail.com>
>> Cc: Pingfan Liu <kernelfans@gmail.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Krzysztof Kozlowski <krzk@kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: Thomas Staudt <tstaudt@de.ibm.com>
>> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>> Signed-off-by: Coiby Xu <coxu@redhat.com>
>> ---
>> arch/arm64/kernel/machine_kexec_file.c | 4 ++++
>> arch/powerpc/kexec/elf_64.c | 4 ++++
>> drivers/of/fdt.c | 21 +++++++++++++++++++++
>> drivers/of/kexec.c | 19 +++++++++++++++++++
>> 4 files changed, 48 insertions(+)
>
>Acked-by: Rob Herring (Arm) <robh@kernel.org>
Hi Rob,
Thanks for acknowledging this device tree patch and also merging the
dt-schema PR!
--
Best regards,
Coiby
^ permalink raw reply
* Re: [PATCH v5 1/3] crash_dump/dm-crypt: Don't print in arch-specific code
From: Coiby Xu @ 2026-04-02 1:46 UTC (permalink / raw)
To: Baoquan He
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Andrew Morton, Vivek Goyal, Dave Young,
open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <actzxO1p6OlmK2gp@fedora>
On Tue, Mar 31, 2026 at 03:12:04PM +0800, Baoquan He wrote:
>On 02/25/26 at 02:03pm, Coiby Xu wrote:
>> When the vmcore dumping target is not a LUKS-encrypted target, it's
>> expected that there is no dm-crypt key thus no need to return -ENOENT.
>> Also print more logs in crash_load_dm_crypt_keys. The benefit is
>> arch-specific code can be more succinct.
>>
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Coiby Xu <coxu@redhat.com>
>> ---
>> arch/x86/kernel/kexec-bzimage64.c | 6 +-----
>> kernel/crash_dump_dm_crypt.c | 7 +++++--
>> 2 files changed, 6 insertions(+), 7 deletions(-)
>
>Acked-by: Baoquan He <bhe@redhat.com>
Thank Baoquan for ack'ing the kexec/kdump part of this patch set!
--
Best regards,
Coiby
^ permalink raw reply
* Re: [PATCH] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Jakub Kicinski @ 2026-04-02 1:58 UTC (permalink / raw)
To: Julian Braha
Cc: manabian, davem, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331125817.117091-1-julianbraha@gmail.com>
On Tue, 31 Mar 2026 13:58:17 +0100 Julian Braha wrote:
> @@ -53,7 +51,6 @@ config DWMAC_DWC_QOS_ETH
>
> config DWMAC_GENERIC
> tristate "Generic driver for DWMAC"
> - default STMMAC_PLATFORM
> help
This is a default not depends.
As much as I'd love to make stmmac default to y this will probably
break boot for some people..
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Alexey Klimov @ 2026-04-02 2:19 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260321-beautiful-garnet-magpie-de4fbd@quoll>
On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>> Hi all,
>>
>> This patch series introduces support for the APM-to-AP mailbox on the
>> Exynos850 SoC. This mailbox is required for communicating with the APM
>> co-processor using ACPM.
>>
>> The Exynos850 mailbox operates similarly to the existing gs101
>> implementation, but the register offsets and IRQ mask bits differ.
>> This series abstracts these differences into platform-specific data
>> structures matched via the device tree.
>>
>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>
>> In theory this can be split into two series with correct dependecies:
>> device tree node requires clock changes to be merged. The suggestion
>> is to let this go through Samsung SoC tree with corresponding acks
>> if it is okay.
>
> I don't understand why this cannot be split into two seris
> *practically*. What is exactly the dependency between mailbox and DTS,
> that it had to be combined here?
Do you suggest to send 3 single patches with proper dependencies
description? DT bindings change first, then mailbox change that specifically
depends on dt-bindings change and then dts update (which will depend on both)?
I thought that mbox driver change depends implicitly on bindings update?
Best regards,
Alexey
^ permalink raw reply
* [PATCH v2 0/3] Exynos850 APM-to-AP mailbox support
From: Alexey Klimov @ 2026-04-02 2:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Tudor Ambarus, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel,
Alexey Klimov
This patch series introduces support for the APM-to-AP mailbox on the
Exynos850 SoC. This mailbox is required for communicating with the APM
co-processor using ACPM.
The Exynos850 mailbox operates similarly to the existing gs101
implementation, but the register offsets and IRQ mask bits differ.
This series abstracts these differences into platform-specific data
structures matched via the device tree.
Also, it requires APM-to-AP mailbox clock in CMU_APM block. These
were marged already (thanks Krzysztof!) so they are dropped from
this v2.
Please also advice if mailbox change should be split out as a separate
patch.
Will be appreciated if it can be tested on gs101 to make sure that I
didn't break anything, I don't have dev gs101 devices.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Changes in v2:
- dropped clock patches (they seem to be merged);
- patch 3: updated commit description mentioning that
exynos850 is not compatible to gs101 mbox (as suggested by Krzysztof);
- fixed comment description for struct exynos_mbox_driver_data
(reported by kernel test robot <lkp@intel.com>);
- Link to v1: https://lore.kernel.org/r/20260320-exynos850-ap2apm-mailbox-v1-0-983eb3f296fc@linaro.org
---
Alexey Klimov (3):
dt-bindings: mailbox: google,gs101-mbox: Add samsung,exynos850-mbox
mailbox: exynos: Add support for Exynos850 mailbox
arm64: dts: exynos850: Add ap2apm mailbox
.../bindings/mailbox/google,gs101-mbox.yaml | 4 +-
arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++
drivers/mailbox/exynos-mailbox.c | 67 +++++++++++++++++++++-
3 files changed, 76 insertions(+), 4 deletions(-)
---
base-commit: bd0f139e5fc11182777b81cefc3893ea508544ec
change-id: 20260320-exynos850-ap2apm-mailbox-cff0c8d69898
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: mailbox: google,gs101-mbox: Add samsung,exynos850-mbox
From: Alexey Klimov @ 2026-04-02 2:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Tudor Ambarus, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel,
Alexey Klimov
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-0-ca5ffdff99d4@linaro.org>
Document support for a mailbox present on Exynos850-based platforms.
The registers offsets are different from gs101 mailbox, but the
workflow is similar, hence new compatible.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml b/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
index e249db4c1fbc..c109c1f7af24 100644
--- a/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
@@ -20,7 +20,9 @@ description:
properties:
compatible:
- const: google,gs101-mbox
+ enum:
+ - google,gs101-mbox
+ - samsung,exynos850-mbox
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Alexey Klimov @ 2026-04-02 2:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Tudor Ambarus, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel,
Alexey Klimov
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-0-ca5ffdff99d4@linaro.org>
Exynos850-based platforms support ACPM and has similar workflow
of communicating with ACPM via mailbox, however mailbox controller
registers are located at different offsets and writes/reads could be
different. To distinguish between such different behaviours,
the registers offsets for Exynos850 and the platform-specific data
structs are introduced and configuration is described in such structs
for gs101 and exynos850 based SoCs. Probe routine now selects the
corresponding platform-specific data via device_get_match_data().
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/exynos-mailbox.c b/drivers/mailbox/exynos-mailbox.c
index d2355b128ba4..f9c59c07558a 100644
--- a/drivers/mailbox/exynos-mailbox.c
+++ b/drivers/mailbox/exynos-mailbox.c
@@ -31,14 +31,61 @@
#define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
+#define EXYNOS850_MBOX_MCUCTRL 0x0 /* Mailbox Control Register */
+#define EXYNOS850_MBOX_INTGR0 0x8 /* Interrupt Generation Register 0 */
+#define EXYNOS850_MBOX_INTCR0 0x0C /* Interrupt Clear Register 0 */
+#define EXYNOS850_MBOX_INTMR0 0x10 /* Interrupt Mask Register 0 */
+#define EXYNOS850_MBOX_INTSR0 0x14 /* Interrupt Status Register 0 */
+#define EXYNOS850_MBOX_INTMSR0 0x18 /* Interrupt Mask Status Register 0 */
+#define EXYNOS850_MBOX_INTGR1 0x1C /* Interrupt Generation Register 1 */
+#define EXYNOS850_MBOX_INTMR1 0x24 /* Interrupt Mask Register 1 */
+#define EXYNOS850_MBOX_INTSR1 0x28 /* Interrupt Status Register 1 */
+#define EXYNOS850_MBOX_INTMSR1 0x2C /* Interrupt Mask Status Register 1 */
+#define EXYNOS850_MBOX_VERSION 0x70
+
+#define EXYNOS850_MBOX_INTMR1_MASK GENMASK(15, 0)
+
+/**
+ * struct exynos_mbox_driver_data - platform-specific mailbox configuration.
+ * @irq_doorbell_offset: offset to the IRQ generation register, doorbell
+ * to APM co-processor.
+ * @irq_doorbell_shift: shift to apply to the value written to IRQ
+ * generation register.
+ * @irq_mask_offset: offset to the IRQ mask register.
+ * @irq_mask_value: value to right to the mask register to mask out
+ * all interrupts.
+ */
+struct exynos_mbox_driver_data {
+ u16 irq_doorbell_offset;
+ u16 irq_doorbell_shift;
+ u16 irq_mask_offset;
+ u16 irq_mask_value;
+};
+
/**
* struct exynos_mbox - driver's private data.
* @regs: mailbox registers base address.
* @mbox: pointer to the mailbox controller.
+ * @data: pointer to driver platform-specific data.
*/
struct exynos_mbox {
void __iomem *regs;
struct mbox_controller *mbox;
+ const struct exynos_mbox_driver_data *data;
+};
+
+static const struct exynos_mbox_driver_data exynos850_mbox_data = {
+ .irq_doorbell_offset = EXYNOS850_MBOX_INTGR0,
+ .irq_doorbell_shift = 16,
+ .irq_mask_offset = EXYNOS850_MBOX_INTMR1,
+ .irq_mask_value = EXYNOS850_MBOX_INTMR1_MASK,
+};
+
+static const struct exynos_mbox_driver_data exynos_gs101_mbox_data = {
+ .irq_doorbell_offset = EXYNOS_MBOX_INTGR1,
+ .irq_doorbell_shift = 0,
+ .irq_mask_offset = EXYNOS_MBOX_INTMR0,
+ .irq_mask_value = EXYNOS_MBOX_INTMR0_MASK,
};
static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
@@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
return -EINVAL;
}
- writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
+ writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
+ exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
return 0;
}
@@ -87,13 +135,21 @@ static struct mbox_chan *exynos_mbox_of_xlate(struct mbox_controller *mbox,
}
static const struct of_device_id exynos_mbox_match[] = {
- { .compatible = "google,gs101-mbox" },
+ {
+ .compatible = "google,gs101-mbox",
+ .data = &exynos_gs101_mbox_data
+ },
+ {
+ .compatible = "samsung,exynos850-mbox",
+ .data = &exynos850_mbox_data
+ },
{},
};
MODULE_DEVICE_TABLE(of, exynos_mbox_match);
static int exynos_mbox_probe(struct platform_device *pdev)
{
+ const struct exynos_mbox_driver_data *data;
struct device *dev = &pdev->dev;
struct exynos_mbox *exynos_mbox;
struct mbox_controller *mbox;
@@ -122,6 +178,11 @@ static int exynos_mbox_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(pclk),
"Failed to enable clock.\n");
+ data = device_get_match_data(&pdev->dev);
+ if (!data)
+ return -ENODEV;
+
+ exynos_mbox->data = data;
mbox->num_chans = EXYNOS_MBOX_CHAN_COUNT;
mbox->chans = chans;
mbox->dev = dev;
@@ -133,7 +194,7 @@ static int exynos_mbox_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, exynos_mbox);
/* Mask out all interrupts. We support just polling channels for now. */
- writel(EXYNOS_MBOX_INTMR0_MASK, exynos_mbox->regs + EXYNOS_MBOX_INTMR0);
+ writel(data->irq_mask_value, exynos_mbox->regs + data->irq_mask_offset);
return devm_mbox_controller_register(dev, mbox);
}
--
2.51.0
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Alexey Klimov @ 2026-04-02 2:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Tudor Ambarus, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel,
Alexey Klimov
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-0-ca5ffdff99d4@linaro.org>
Add mailbox node that describes AP-to-APM mailbox, that can be
used for communicating with APM co-processor on Exynos850 SoCs.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index cb55015c8dce..fcb665ccc7ae 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -298,6 +298,15 @@ cmu_apm: clock-controller@11800000 {
clock-names = "oscclk", "dout_clkcmu_apm_bus";
};
+ ap2apm_mailbox: mailbox@11900000 {
+ compatible = "samsung,exynos850-mbox";
+ reg = <0x11900000 0x1000>;
+ clocks = <&cmu_apm CLK_GOUT_MAILBOX_APM_AP_PCLK>;
+ clock-names = "pclk";
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <0>;
+ };
+
cmu_cmgp: clock-controller@11c00000 {
compatible = "samsung,exynos850-cmu-cmgp";
reg = <0x11c00000 0x8000>;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/2] Add PWM support Amlogic S7 S7D S6
From: Xianwei Zhao via B4 Relay @ 2026-04-02 2:40 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Xianwei Zhao, Junyi Zhao, Krzysztof Kozlowski
Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Changes in v2:
- Simpler s7 clock desc, and drop the example in bindings.
- Make minor changes to probe based on Martin's suggestion.
- Link to v1: https://lore.kernel.org/r/20260326-s6-s7-pwm-v1-0-67e2f72b98bc@amlogic.com
---
Junyi Zhao (1):
dt-bindings: pwm: amlogic: Add new bindings for S6 S7 S7D
Xianwei Zhao (1):
pwm: meson: Add support for Amlogic S7
.../devicetree/bindings/pwm/pwm-amlogic.yaml | 19 +++++++++++++
drivers/pwm/pwm-meson.c | 32 ++++++++++++++++++++--
2 files changed, 48 insertions(+), 3 deletions(-)
---
base-commit: 8ab1fc9104158045f68fde2d0ae16f5fbcf8bfbd
change-id: 20260325-s6-s7-pwm-281658b88736
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: pwm: amlogic: Add new bindings for S6 S7 S7D
From: Xianwei Zhao via B4 Relay @ 2026-04-02 2:40 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Xianwei Zhao, Junyi Zhao, Krzysztof Kozlowski
In-Reply-To: <20260402-s6-s7-pwm-v2-0-657dce040956@amlogic.com>
From: Junyi Zhao <junyi.zhao@amlogic.com>
Amlogic S7/S7D/S6 different from the previous SoCs, a controller
includes one pwm, at the same time, the controller has only one
input clock source.
Signed-off-by: Junyi Zhao <junyi.zhao@amlogic.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
.../devicetree/bindings/pwm/pwm-amlogic.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml
index c337d85da40f..93fa97f4011b 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml
@@ -37,6 +37,7 @@ properties:
- enum:
- amlogic,meson8-pwm-v2
- amlogic,meson-s4-pwm
+ - amlogic,s7-pwm
- items:
- enum:
- amlogic,a4-pwm
@@ -45,6 +46,11 @@ properties:
- amlogic,t7-pwm
- amlogic,meson-a1-pwm
- const: amlogic,meson-s4-pwm
+ - items:
+ - enum:
+ - amlogic,s6-pwm
+ - amlogic,s7d-pwm
+ - const: amlogic,s7-pwm
- items:
- enum:
- amlogic,meson8b-pwm-v2
@@ -146,6 +152,19 @@ allOf:
clock-names: false
required:
- clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,s7-pwm
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names: false
+ required:
+ - clocks
- if:
properties:
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/2] pwm: meson: Add support for Amlogic S7
From: Xianwei Zhao via B4 Relay @ 2026-04-02 2:40 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-kernel,
linux-amlogic, Xianwei Zhao
In-Reply-To: <20260402-s6-s7-pwm-v2-0-657dce040956@amlogic.com>
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Add support for Amlogic S7 PWM. Amlogic S7 different from the
previous SoCs, a controller includes one pwm, at the same time,
the controller has only one input clock source.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
drivers/pwm/pwm-meson.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 8c6bf3d49753..7a43c42ef3d6 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -113,6 +113,7 @@ struct meson_pwm_data {
int (*channels_init)(struct pwm_chip *chip);
bool has_constant;
bool has_polarity;
+ bool single_pwm;
};
struct meson_pwm {
@@ -503,6 +504,18 @@ static void meson_pwm_s4_put_clk(void *data)
clk_put(clk);
}
+static int meson_pwm_init_channels_s7(struct pwm_chip *chip)
+{
+ struct device *dev = pwmchip_parent(chip);
+ struct meson_pwm *meson = to_meson_pwm(chip);
+
+ meson->channels[0].clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(meson->channels[0].clk))
+ return dev_err_probe(dev, PTR_ERR(meson->channels[0].clk),
+ "Failed to get clk\n");
+ return 0;
+}
+
static int meson_pwm_init_channels_s4(struct pwm_chip *chip)
{
struct device *dev = pwmchip_parent(chip);
@@ -592,6 +605,13 @@ static const struct meson_pwm_data pwm_s4_data = {
.has_polarity = true,
};
+static const struct meson_pwm_data pwm_s7_data = {
+ .channels_init = meson_pwm_init_channels_s7,
+ .has_constant = true,
+ .has_polarity = true,
+ .single_pwm = true,
+};
+
static const struct of_device_id meson_pwm_matches[] = {
{
.compatible = "amlogic,meson8-pwm-v2",
@@ -642,6 +662,10 @@ static const struct of_device_id meson_pwm_matches[] = {
.compatible = "amlogic,meson-s4-pwm",
.data = &pwm_s4_data
},
+ {
+ .compatible = "amlogic,s7-pwm",
+ .data = &pwm_s7_data
+ },
{},
};
MODULE_DEVICE_TABLE(of, meson_pwm_matches);
@@ -650,9 +674,11 @@ static int meson_pwm_probe(struct platform_device *pdev)
{
struct pwm_chip *chip;
struct meson_pwm *meson;
- int err;
+ const struct meson_pwm_data *pdata = of_device_get_match_data(&pdev->dev);
+ int err, npwm;
- chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
+ npwm = pdata->single_pwm ? 1 : MESON_NUM_PWMS;
+ chip = devm_pwmchip_alloc(&pdev->dev, npwm, sizeof(*meson));
if (IS_ERR(chip))
return PTR_ERR(chip);
meson = to_meson_pwm(chip);
@@ -664,7 +690,7 @@ static int meson_pwm_probe(struct platform_device *pdev)
spin_lock_init(&meson->lock);
chip->ops = &meson_pwm_ops;
- meson->data = of_device_get_match_data(&pdev->dev);
+ meson->data = pdata;
err = meson->data->channels_init(chip);
if (err < 0)
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Tian Zheng @ 2026-04-02 2:40 UTC (permalink / raw)
To: Leonardo Bras
Cc: maz, oupton, catalin.marinas, corbet, pbonzini, will, yuzenghui,
wangzhou1, liuyonglong, Jonathan.Cameron, yezhenyu2, linuxarm,
joey.gouly, kvmarm, kvm, linux-arm-kernel, linux-doc,
linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acvWnjG0AZBHL21q@devkitleo>
On 3/31/2026 10:13 PM, Leonardo Bras wrote:
> On Wed, Feb 25, 2026 at 12:04:16PM +0800, Tian Zheng wrote:
>> This series of patches add support to the Hardware Dirty state tracking
>> Structure(HDBSS) feature, which is introduced by the ARM architecture
>> in the DDI0601(ID121123) version.
>>
>> The HDBSS feature is an extension to the architecture that enhances
>> tracking translation table descriptors' dirty state, identified as
>> FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
>> page tracking, aiming to significantly reduce the overhead of scanning
>> for dirty pages.
>>
>> The purpose of this feature is to make the execution overhead of live
>> migration lower to both the guest and the host, compared to existing
>> approaches (write-protect or search stage 2 tables).
>>
>> After these patches, users(such as qemu) can use the
>> KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl to enable or disable the HDBSS
>> feature before and after the live migration.
>>
>> v2:
>> https://lore.kernel.org/linux-arm-kernel/20251121092342.3393318-1-zhengtian10@huawei.com/
>>
>> v2->v3 changes:
>> - Remove the ARM64_HDBSS configuration option and ensure this feature
>> is only enabled in VHE mode.
>> - Move HDBSS-related variables to the arch-independent portion of the
>> kvm structure.
>> - Remove error messages during HDBSS enable/disable operations
>> - Change HDBSS buffer flushing from handle_exit to vcpu_put,
>> check_vcpu_requests, and kvm_handle_guest_abort.
>> - Add fault handling for HDBSS including buffer full, external abort,
>> and general protection fault (GPF).
>> - Add support for a 4KB HDBSS buffer size, mapped to the value 0b0000.
>> - Add a second argument to the ioctl to turn HDBSS on or off.
>>
>> Tian Zheng (1):
>> KVM: arm64: Document HDBSS ioctl
>>
>> eillon (4):
>> arm64/sysreg: Add HDBSS related register information
>> KVM: arm64: Add support to set the DBM attr during memory abort
>> KVM: arm64: Add support for FEAT_HDBSS
>> KVM: arm64: Enable HDBSS support and handle HDBSSF events
>>
>> Documentation/virt/kvm/api.rst | 16 +++++
>> arch/arm64/include/asm/cpufeature.h | 5 ++
>> arch/arm64/include/asm/esr.h | 7 ++
>> arch/arm64/include/asm/kvm_host.h | 17 +++++
>> arch/arm64/include/asm/kvm_mmu.h | 1 +
>> arch/arm64/include/asm/kvm_pgtable.h | 4 ++
>> arch/arm64/include/asm/sysreg.h | 11 +++
>> arch/arm64/kernel/cpufeature.c | 12 ++++
>> arch/arm64/kvm/arm.c | 102 +++++++++++++++++++++++++++
>> arch/arm64/kvm/hyp/pgtable.c | 6 ++
>> arch/arm64/kvm/hyp/vhe/switch.c | 19 +++++
>> arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++
>> arch/arm64/kvm/reset.c | 3 +
>> arch/arm64/tools/cpucaps | 1 +
>> arch/arm64/tools/sysreg | 29 ++++++++
>> include/uapi/linux/kvm.h | 1 +
>> tools/include/uapi/linux/kvm.h | 1 +
>> 17 files changed, 305 insertions(+)
>>
>> --
>> 2.33.0
>>
>
> Hi Tian,
>
> I was thinking: maybe instead of putting the HDBSS (and HACDBS) stuff
> across a bunch of KVM files, we should try to focus them all on a single
> arch/arm64/kvm/dirty_bit.c file (plus a header such as
> arch/arm64/include/asm/kvm_dirty_bit.h).
>
> What is your opinion on that?
>
> Thanks!
> Leo
Sorry for the late reply. Yes, I had the same thought before. In the
next version, I will
move all the HDBSS-related content into the same file, such as
arch/arm64/kvm/dirty_bit.c
and arch/arm64/include/asm/kvm_dirty_bit.h.
Tian
>
>
^ permalink raw reply
* Re: [RFC PATCH 1/7] media: v4l2-ctrls: Add V4L2_CID_MEMORY_USAGE control
From: Ming Qian(OSS) @ 2026-04-02 3:14 UTC (permalink / raw)
To: Nicolas Dufresne, Frank Li
Cc: linux-media, mchehab, hverkuil-cisco, sebastian.fricke, shawnguo,
s.hauer, kernel, festevam, linux-imx, xiahong.bao, eagle.zhou,
imx, linux-kernel, linux-arm-kernel
In-Reply-To: <d8c12ba1-5004-4a51-8a2b-3d500184778b@oss.nxp.com>
Hi Nicolas,
On 4/1/2026 10:23 AM, Ming Qian(OSS) wrote:
> Hi Nicolas,
>
> On 3/31/2026 10:54 PM, Nicolas Dufresne wrote:
>> Le mardi 31 mars 2026 à 10:33 -0400, Frank Li a écrit :
>>> On Tue, Mar 31, 2026 at 03:23:11PM +0800, ming.qian@oss.nxp.com wrote:
>>>> From: Ming Qian <ming.qian@oss.nxp.com>
>>>>
>>>> Add a new read-only control V4L2_CID_MEMORY_USAGE that allows
>>>> applications to query the total amount of memory currently used
>>>> by a device instance.
>>>>
>>>> This control reports the memory consumption in bytes, including
>>>> internal buffers, intermediate processing data, and other
>>>> driver-managed allocations. Applications can use this information
>>>> for debugging, resource monitoring, or making informed decisions
>>>> about buffer allocation strategies.
>>>>
>>>> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
>>>> ---
>>>
>>> Not sure why not export these information by debugfs, or any benefit vs
>>> debugfs?
>>
>> There is also a on-going proposal that uses fdinfo.
>>
>> Nicolas
>>
>
> Thanks for the reminder about the ongoing fdinfo proposal.
>
> Just to confirm, you are referring to Detlev’s ongoing fdinfo proposal,
> specifically this series:
> https://lore.kernel.org/lkml/20260212162328.192217-1-
> detlev.casanova@collabora.com/
>
> I will align my work with it and switch to using fdinfo.
> Once the show_fdinfo support from that series is merged, I will prepare
> the next revision of my patch accordingly.
>
> Regards,
> Ming
>
Regarding the discussion about using fdinfo instead of a V4L2 control, I
have two questions:
1. Key consistency in fdinfo
fdinfo uses key–value pairs, which is flexible, but if multiple
drivers want to expose the same “memory usage” information,
they need to agree on a common key name and meaning. Otherwise
user‑space must handle each driver differently. A V4L2 control
naturally provides a unified interface without this coordination
effort.
2. Lack of notification in fdinfo
With a control, user‑space can subscribe to control events and
receive notifications when the memory usage changes. fdinfo does
not have a built‑in event mechanism, so users must either poll
or rely on additional eventfd‑like or custom event mechanisms.
Do you have any suggestions or existing practices to address these two
issues when using fdinfo?
Thanks again for your time and comments.
Regards,
Ming
>>>
>>> Generanlly document should be first patch, then driver change.
>>>
>>> Frank
>>>
>>>> drivers/media/v4l2-core/v4l2-ctrls-defs.c | 8 ++++++++
>>>> include/uapi/linux/v4l2-controls.h | 4 +++-
>>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/
>>>> media/v4l2-core/v4l2-ctrls-defs.c
>>>> index 551426c4cd01..053db78ff661 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
>>>> @@ -831,6 +831,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>>>> case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component";
>>>> case V4L2_CID_COLORFX_CBCR: return "Color Effects, CbCr";
>>>> case V4L2_CID_COLORFX_RGB: return "Color Effects,
>>>> RGB";
>>>> + case V4L2_CID_MEMORY_USAGE: return "Memory Usage";
>>>>
>>>> /*
>>>> * Codec controls
>>>> @@ -1476,6 +1477,13 @@ void v4l2_ctrl_fill(u32 id, const char
>>>> **name, enum v4l2_ctrl_type *type,
>>>> *min = 0;
>>>> *max = 0xffff;
>>>> break;
>>>> + case V4L2_CID_MEMORY_USAGE:
>>>> + *type = V4L2_CTRL_TYPE_INTEGER64;
>>>> + *flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>>> + *min = 0;
>>>> + *max = S64_MAX;
>>>> + *step = 1;
>>>> + break;
>>>> case V4L2_CID_FLASH_FAULT:
>>>> case V4L2_CID_JPEG_ACTIVE_MARKER:
>>>> case V4L2_CID_3A_LOCK:
>>>> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/
>>>> linux/v4l2-controls.h
>>>> index 68dd0c4e47b2..02c6f960d38e 100644
>>>> --- a/include/uapi/linux/v4l2-controls.h
>>>> +++ b/include/uapi/linux/v4l2-controls.h
>>>> @@ -110,8 +110,10 @@ enum v4l2_colorfx {
>>>> #define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
>>>> #define V4L2_CID_COLORFX_RGB (V4L2_CID_BASE+43)
>>>>
>>>> +#define V4L2_CID_MEMORY_USAGE (V4L2_CID_BASE+44)
>>>> +
>>>> /* last CID + 1 */
>>>> -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
>>>> +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+45)
>>>>
>>>> /* USER-class private control IDs */
>>>>
>>>> --
>>>> 2.53.0
>>>>
>
^ permalink raw reply
* Re: [PATCH v2 02/10] dmaengine: imx-sdma: fix spba-bus handling for i.MX8M
From: Shengjiu Wang @ 2026-04-02 3:33 UTC (permalink / raw)
To: Marco Felsch
Cc: Vinod Koul, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jiada Wang, dmaengine, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20250911-v6-16-topic-sdma-v2-2-d315f56343b5@pengutronix.de>
On Fri, Sep 12, 2025 at 6:05 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> Starting with i.MX8M* devices there are multiple spba-busses so we can't
> just search the whole DT for the first spba-bus match and take it.
> Instead we need to check for each device to which bus it belongs and
> setup the spba_{start,end}_addr accordingly per sdma_channel.
>
> While on it, don't ignore errors from of_address_to_resource() if they
> are valid.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
> drivers/dma/imx-sdma.c | 58 ++++++++++++++++++++++++++++++++++----------------
> 1 file changed, 40 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 3ecb917214b1268b148a29df697b780bc462afa4..56daaeb7df03986850c9c74273d0816700581dc0 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -429,6 +429,8 @@ struct sdma_desc {
> * @event_mask: event mask used in p_2_p script
> * @watermark_level: value for gReg[7], some script will extend it from
> * basic watermark such as p_2_p
> + * @spba_start_addr: SDMA controller SPBA bus start address
> + * @spba_end_addr: SDMA controller SPBA bus end address
> * @shp_addr: value for gReg[6]
> * @per_addr: value for gReg[2]
> * @status: status of dma channel
> @@ -461,6 +463,8 @@ struct sdma_channel {
> dma_addr_t per_address, per_address2;
> unsigned long event_mask[2];
> unsigned long watermark_level;
> + u32 spba_start_addr;
> + u32 spba_end_addr;
> u32 shp_addr, per_addr;
> enum dma_status status;
> struct imx_dma_data data;
> @@ -534,8 +538,6 @@ struct sdma_engine {
> u32 script_number;
> struct sdma_script_start_addrs *script_addrs;
> const struct sdma_driver_data *drvdata;
> - u32 spba_start_addr;
> - u32 spba_end_addr;
> unsigned int irq;
> dma_addr_t bd0_phys;
> struct sdma_buffer_descriptor *bd0;
> @@ -1236,8 +1238,6 @@ static void sdma_channel_synchronize(struct dma_chan *chan)
>
> static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
> {
> - struct sdma_engine *sdma = sdmac->sdma;
> -
> int lwml = sdmac->watermark_level & SDMA_WATERMARK_LEVEL_LWML;
> int hwml = (sdmac->watermark_level & SDMA_WATERMARK_LEVEL_HWML) >> 16;
>
> @@ -1263,12 +1263,12 @@ static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
> swap(sdmac->event_mask[0], sdmac->event_mask[1]);
> }
>
> - if (sdmac->per_address2 >= sdma->spba_start_addr &&
> - sdmac->per_address2 <= sdma->spba_end_addr)
> + if (sdmac->per_address2 >= sdmac->spba_start_addr &&
> + sdmac->per_address2 <= sdmac->spba_end_addr)
> sdmac->watermark_level |= SDMA_WATERMARK_LEVEL_SP;
>
> - if (sdmac->per_address >= sdma->spba_start_addr &&
> - sdmac->per_address <= sdma->spba_end_addr)
> + if (sdmac->per_address >= sdmac->spba_start_addr &&
> + sdmac->per_address <= sdmac->spba_end_addr)
> sdmac->watermark_level |= SDMA_WATERMARK_LEVEL_DP;
>
> sdmac->watermark_level |= SDMA_WATERMARK_LEVEL_CONT;
> @@ -1447,6 +1447,31 @@ static void sdma_desc_free(struct virt_dma_desc *vd)
> kfree(desc);
> }
>
> +static int sdma_config_spba_slave(struct dma_chan *chan)
> +{
> + struct sdma_channel *sdmac = to_sdma_chan(chan);
> + struct device_node *spba_bus;
> + struct resource spba_res;
> + int ret;
> +
> + spba_bus = of_get_parent(chan->slave->of_node);
if the chan is requested by __dma_request_channel(), the chan->slave = NULL
Then there will be an issue here.
Best regards
Shengjiu Wang
> + /* Device doesn't belong to the spba-bus */
> + if (!of_device_is_compatible(spba_bus, "fsl,spba-bus"))
> + return 0;
> +
> + ret = of_address_to_resource(spba_bus, 0, &spba_res);
> + of_node_put(spba_bus);
> + if (ret) {
> + dev_err(sdmac->sdma->dev, "Failed to get spba-bus resources\n");
> + return -EINVAL;
> + }
> +
> + sdmac->spba_start_addr = spba_res.start;
> + sdmac->spba_end_addr = spba_res.end;
> +
> + return 0;
> +}
> +
> static int sdma_alloc_chan_resources(struct dma_chan *chan)
> {
> struct sdma_channel *sdmac = to_sdma_chan(chan);
> @@ -1527,6 +1552,8 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
>
> sdmac->event_id0 = 0;
> sdmac->event_id1 = 0;
> + sdmac->spba_start_addr = 0;
> + sdmac->spba_end_addr = 0;
>
> sdma_set_channel_priority(sdmac, 0);
>
> @@ -1837,6 +1864,7 @@ static int sdma_config(struct dma_chan *chan,
> {
> struct sdma_channel *sdmac = to_sdma_chan(chan);
> struct sdma_engine *sdma = sdmac->sdma;
> + int ret;
>
> memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg));
>
> @@ -1867,6 +1895,10 @@ static int sdma_config(struct dma_chan *chan,
> sdma_event_enable(sdmac, sdmac->event_id1);
> }
>
> + ret = sdma_config_spba_slave(chan);
> + if (ret)
> + return ret;
> +
> return 0;
> }
>
> @@ -2235,11 +2267,9 @@ static struct dma_chan *sdma_xlate(struct of_phandle_args *dma_spec,
> static int sdma_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> - struct device_node *spba_bus;
> const char *fw_name;
> int ret;
> int irq;
> - struct resource spba_res;
> int i;
> struct sdma_engine *sdma;
> s32 *saddr_arr;
> @@ -2375,14 +2405,6 @@ static int sdma_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "failed to register controller\n");
> goto err_register;
> }
> -
> - spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
> - ret = of_address_to_resource(spba_bus, 0, &spba_res);
> - if (!ret) {
> - sdma->spba_start_addr = spba_res.start;
> - sdma->spba_end_addr = spba_res.end;
> - }
> - of_node_put(spba_bus);
> }
>
> /*
>
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] iommu/arm-smmu-v3: Add basic debugfs framework
From: Qinxin Xia @ 2026-04-02 3:50 UTC (permalink / raw)
To: Nicolin Chen
Cc: robin.murphy, will, jpb, linux-arm-kernel, iommu, wangzhou1,
prime.zeng, fanghao11, jonathan.cameron, wuyifan50, linuxarm
In-Reply-To: <acpUoZ7wx9gdT5BG@nvidia.com>
On 2026/3/30 18:46:57, Nicolin Chen <nicolinc@nvidia.com> wrote:
> On Sat, Mar 28, 2026 at 06:17:02PM +0800, Qinxin Xia wrote:
>> Add basic debugfs framework for ARM SMMUv3 driver.This creates the
>
> Needs a space after "."
>
>> +static int smmu_debugfs_capabilities_show(struct seq_file *seq, void *unused)
>> +{
>> + struct arm_smmu_device *smmu = seq->private;
>> +
>> + if (!smmu) {
>> + seq_puts(seq, "SMMU not available\n");
>> + return 0;
>> + }
>> +
>> + seq_puts(seq, "SMMUv3 Capabilities:\n");
>> + seq_printf(seq, " Stage1 Translation: %s\n",
>> + smmu->features & ARM_SMMU_FEAT_TRANS_S1 ? "Yes" : "No");
>> + seq_printf(seq, " Stage2 Translation: %s\n",
>> + smmu->features & ARM_SMMU_FEAT_TRANS_S2 ? "Yes" : "No");
>> + seq_printf(seq, " Coherent Walk: %s\n",
>> + smmu->features & ARM_SMMU_FEAT_COHERENCY ? "Yes" : "No");
>> + seq_printf(seq, " ATS Support: %s\n",
>> + smmu->features & ARM_SMMU_FEAT_ATS ? "Yes" : "No");
>> + seq_printf(seq, " PRI Support: %s\n",
>> + smmu->features & ARM_SMMU_FEAT_PRI ? "Yes" : "No");
>> + seq_printf(seq, " Stream Table Size: %d\n", 1 << smmu->sid_bits);
>> + seq_printf(seq, " Command Queue Depth: %d\n",
>> + 1 << smmu->cmdq.q.llq.max_n_shift);
>> + seq_printf(seq, " Event Queue Depth: %d\n",
>> + 1 << smmu->evtq.q.llq.max_n_shift);
>
> Nit: should we do all sizes or all depths? Any good reason to mix
> them here?
>
Stream Table is a table, not a queue, so 'Size' is more appropriate;
queues use 'Depth'. But I can change to unify if preferred.
>> +/**
>> + * arm_smmu_debugfs_remove() - Clean up debugfs entries for an SMMU device
>> + * @smmu: SMMU device
>> + *
>> + * This function removes the debugfs directories created by setup.
>> + */
>> +void arm_smmu_debugfs_remove(struct arm_smmu_device *smmu)
>> +{
>> + struct arm_smmu_debugfs *debugfs;
>> +
>> + scoped_guard(mutex, &arm_smmu_debugfs_lock) {
>
> It could be just normal guard().
>
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> index 4d00d796f078..cbb3fccc501b 100644
>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> @@ -4904,6 +4904,15 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> /* Check for RMRs and install bypass STEs if any */
>> arm_smmu_rmr_install_bypass_ste(smmu);
>>
>> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
>> + char name[32];
>
> This could be moved to the top, as iommu_device_sysfs_add() can use
> it, whether CONFIG_ARM_SMMU_V3_DEBUGFS=y or =n.
>
>> + snprintf(name, sizeof(name), "smmu3.%pa", &ioaddr);
>
> And this could be moved after ioaddr gets a copy from res->start.
>
>>
>> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
>> +struct arm_smmu_debugfs {
>> + struct dentry *smmu_dir;
>
> A personal preference: for new structures, maybe drop those tabs?
>
>> /* An SMMUv3 instance */
>> struct arm_smmu_device {
>> struct device *dev;
>> @@ -803,6 +813,11 @@ struct arm_smmu_device {
>>
>> struct rb_root streams;
>> struct mutex streams_mutex;
>> +
>> +#ifdef CONFIG_ARM_SMMU_V3_DEBUGFS
>> + /* DebugFS Info */
>
> Doesn't seem very useful. I'd drop it.
>
>> + struct arm_smmu_debugfs *debugfs;
>> +#endif
>
> Nicolin
>
--
Thanks,
Qinxin
^ permalink raw reply
* Re: [PATCH 00/11] Drivers: hv: Add ARM64 support in mshv_vtl
From: Naman Jain @ 2026-04-02 4:01 UTC (permalink / raw)
To: Michael Kelley, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB4157E4E088F39106979BE4EDD450A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 4/1/2026 10:24 PM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Tuesday, March 17, 2026 9:23 PM
>>
>> On 3/18/2026 3:33 AM, Michael Kelley wrote:
>>> From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
>>>>
>>>> The series intends to add support for ARM64 to mshv_vtl driver.
>
> No need to be tentative. :-) Just write as:
>
> "The series adds support for ARM64 to the mshv_vtl driver."
>
>>>> For this, common Hyper-V code is refactored, necessary support is added,
>>>> mshv_vtl_main.c is refactored and then finally support is added in
>>>> Kconfig.
>>>>
>>>> Based on commit 1f318b96cc84 ("Linux 7.0-rc3")
>>>
>>> There's now an online LLM-based tool that is automatically reviewing
>>> kernel patches. For this patch set, the results are here:
>>>
>>> https://sashiko.dev/#/patchset/20260316121241.910764-1-namjain%40linux.microsoft.com
>>>
>>> It has flagged several things that are worth checking, but I haven't
>>> reviewed them to see if they are actually valid.
>>>
>>> FWIW, the announcement about sashiko.dev is here:
>>>
>>> https://lore.kernel.org/lkml/7ia4o6kmpj5s.fsf@castle.c.googlers.com/
>>>
>>> Michael
>>
>>
>> Thanks for sharing Michael,
>> I'll check it out and do the needful.
>>
>
> I've done a full review of this patch set and provided comments in the
> individual patches. Some of my comments reference the Sashiko AI
> comments, but there are still some Sashiko AI comments to consider
> that I haven't referenced.
>
> FWIW, the Sashiko AI comments are quite good -- it found some things
> here that I missed on my own, and in my earlier reviews of the original VTL
> code. :-(
>
> Michael
Thank you so much Michael for reviewing these. I was also trying to
address review comments from Sashiko, and noticed some of them were
false positives in the sense that these were existing issues and not
introduced by arm64 changes. I thought of keeping them separate from the
scope of this series for future.
I'll review your comments and address them.
Regards,
Naman
^ 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