* [PATCH net v2 1/5] net: dsa: mt7530: fix FDB entries not aging out with short timeout
From: Daniel Golle @ 2026-05-14 14:04 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, DENG Qingfang,
Florian Fainelli, Arınç ÜNAL, Sean Wang, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1778766629.git.daniel@makrotopia.org>
The DSA forwarding selftests bridge_vlan_aware.sh and
bridge_vlan_unaware.sh configure the bridge with ageing_time set to
LOW_AGEING_TIME (1000 centiseconds, i.e. 10 seconds) and then run
learning_test() in lib.sh, which expects a learned FDB entry to be
removed after ageing_time + 10 seconds. On MT7530/MT7531 the entry
persisted past the deadline and the "Found FDB record when should
not" assertion failed.
With msecs=10000, the algorithm in mt7530_set_ageing_time() finds
AGE_CNT=0 and AGE_UNIT=9 as the first exact match (starting the
search from tmp_age_count=0). The per-entry aging counter is
initialized to AGE_CNT when a MAC address is learned, so with
AGE_CNT=0 new entries start with a counter value of 0, which the
hardware treats as "already aged" and never removes, effectively
disabling aging.
Fix this by starting the search from tmp_age_count=1 to ensure
entries always have a non-zero initial aging counter. For a
10-second ageing time this yields AGE_CNT=1 and AGE_UNIT=4 instead:
the timer ticks every 5 seconds and entries are removed after 2
ticks.
Starting the search at AGE_CNT=1 raises the minimum representable
ageing time from 1 to 2 seconds. Without bounds, a stale ageing_time
of 1 second would now make the loop fall through without setting
age_count and age_unit, leaving them uninitialized when written to
the MT7530_AAC hardware register. Set ds->ageing_time_min and
ds->ageing_time_max so the DSA core validates the range before the
callback is invoked, and drop the now-redundant range check from
mt7530_set_ageing_time().
Fixes: ea6d5c924e39 ("net: dsa: mt7530: support setting ageing time")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2:
- Set ds->ageing_time_min = 2 * 1000 and
ds->ageing_time_max = (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1) * 1000
in mt7530_setup() and mt7531_setup_common() so the DSA core
rejects out-of-range values before calling the driver.
- Drop the now-redundant `if (secs < 1 || ...)` range check from
mt7530_set_ageing_time(); v1 left it in place and would have
written uninitialized age_count/age_unit to MT7530_AAC for
secs == 1 (loop falls through without ever finding a match
once tmp_age_count starts at 1).
- Reworked commit message to lead with the bridge_vlan_aware.sh /
bridge_vlan_unaware.sh learning_test() scenario that exposes
the bug, walk through the search-loop math for LOW_AGEING_TIME
(10 s), and document the new lower bound.
drivers/net/dsa/mt7530.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 44d670904ad8..cd311dfd3600 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1023,12 +1023,16 @@ mt7530_set_ageing_time(struct dsa_switch *ds, unsigned int msecs)
unsigned int age_count;
unsigned int age_unit;
- /* Applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds */
- if (secs < 1 || secs > (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1))
- return -ERANGE;
-
- /* iterate through all possible age_count to find the closest pair */
- for (tmp_age_count = 0; tmp_age_count <= AGE_CNT_MAX; ++tmp_age_count) {
+ /* Applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds.
+ * The DSA core has already validated the range using
+ * ds->ageing_time_min and ds->ageing_time_max.
+ *
+ * Iterate through all possible age_count values to find the closest
+ * pair. Start from 1 because the per-entry aging counter is
+ * initialized to AGE_CNT and a value of 0 means the entry will
+ * never be aged out.
+ */
+ for (tmp_age_count = 1; tmp_age_count <= AGE_CNT_MAX; ++tmp_age_count) {
unsigned int tmp_age_unit = secs / (tmp_age_count + 1) - 1;
if (tmp_age_unit <= AGE_UNIT_MAX) {
@@ -2428,6 +2432,8 @@ mt7530_setup(struct dsa_switch *ds)
ds->assisted_learning_on_cpu_port = true;
ds->mtu_enforcement_ingress = true;
+ ds->ageing_time_min = 2 * 1000;
+ ds->ageing_time_max = (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1) * 1000;
if (priv->id == ID_MT7530) {
regulator_set_voltage(priv->core_pwr, 1000000, 1000000);
@@ -2617,6 +2623,8 @@ mt7531_setup_common(struct dsa_switch *ds)
ds->assisted_learning_on_cpu_port = true;
ds->mtu_enforcement_ingress = true;
+ ds->ageing_time_min = 2 * 1000;
+ ds->ageing_time_max = (AGE_CNT_MAX + 1) * (AGE_UNIT_MAX + 1) * 1000;
mt753x_trap_frames(priv);
--
2.54.0
^ permalink raw reply related
* [PATCH net v2 0/5] net: dsa: mt7530: assorted fixes
From: Daniel Golle @ 2026-05-14 14:04 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, DENG Qingfang,
Florian Fainelli, Arınç ÜNAL, Sean Wang, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
A batch of small, independent fixes for the MediaTek MT7530 family DSA
driver, addressing long-standing correctness issues that surface on
hardware with bridge VLAN filtering enabled, on link-local frame
reception, and during bridge join/leave transitions.
---
Changes since v1:
- rework patch 1/5 following up Paolo Abeni and Sashiko reviews
Daniel Golle (4):
net: dsa: mt7530: fix FDB entries not aging out with short timeout
net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
net: dsa: mt7530: fix CPU port VLAN not being reset to unaware
net: dsa: mt7530: clear flood flags on bridge leave
Edward Parker (1):
net: dsa: mt7530: untag VLAN-aware bridge PVID
drivers/net/dsa/mt7530.c | 165 +++++++++++++++++++++++----------------
1 file changed, 98 insertions(+), 67 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH net-next v6 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Rob Herring @ 2026-05-14 14:01 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree
In-Reply-To: <20260511-airoha-eth-multi-serdes-v6-1-c899462c4f75@kernel.org>
On Mon, May 11, 2026 at 12:49:27PM +0200, Lorenzo Bianconi wrote:
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet-port property in order to model a given net_device
> that is connected via the external arbiter to the GDM{3,4} port (that
> is represented by the ethernet property. Please note GDM1 or GDM2 does not
> support the connection with the external arbiter and are represented
> by ethernet property.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 64 +++++++++++++++++++++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909..642f300c0945 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,50 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + '#address-cells':
> + const: 1
blank line
> + '#size-cells':
> + const: 0
> +
> + allOf:
> + - if:
> + properties:
> + reg:
> + contains:
> + items:
> + - enum:
> + - 3
> + - 4
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
Why do you have these twice? Drop this one.
> +
> + patternProperties:
> + "^ethernet-port@[0-5]$":
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
> + description: External ethernet port ID available on the GDM port
> +
> + properties:
> + compatible:
> + const: airoha,eth-port
> +
> + reg:
> + maxItems: 1
Instead, 'maximum: 5'.
> + description: External ethernet port identifier
> +
> + required:
> + - reg
> + - compatible
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> +
> required:
> - reg
> - compatible
> @@ -191,9 +235,27 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - mac: ethernet@1 {
> + mac1: ethernet@1 {
Just drop unused labels.
> compatible = "airoha,eth-mac";
> reg = <1>;
> };
> +
> + mac4: ethernet@4 {
> + compatible = "airoha,eth-mac";
> + reg = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-port@0 {
> + compatible = "airoha,eth-port";
> + reg = <0>;
> + };
> +
> + ethernet-port@1 {
> + compatible = "airoha,eth-port";
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.54.0
>
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt8189: Fix probe resource cleanup
From: Cássio Gabriel @ 2026-05-14 13:52 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno, Cyril Chao
Cc: linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek,
Cássio Gabriel
The MT8189 AFE probe assigns reserved memory with
of_reserved_mem_device_init(), but only releases that assignment from
.remove(). If probe fails after the reserved memory has been assigned,
the assignment record is left behind.
The probe path also uses pm_runtime_get_sync() without checking its
return value. If runtime resume fails, pm_runtime_get_sync() leaves the
usage count incremented and the driver continues initialization without
the device being resumed. Use pm_runtime_resume_and_get() so resume
errors abort probe without leaking a PM usage count.
Finally, component registration failure currently jumps to a label that
drops a runtime PM reference even though the temporary probe reference
was already released. Return the component registration error directly,
and do not drop an unmatched PM reference from .remove().
Fixes: 7eb153585598 ("ASoC: mediatek: mt8189: add platform driver")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
sound/soc/mediatek/mt8189/mt8189-afe-pcm.c | 38 ++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c b/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c
index 24b0c78815f6..77cf2b604f6c 100644
--- a/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c
+++ b/sound/soc/mediatek/mt8189/mt8189-afe-pcm.c
@@ -2351,9 +2351,13 @@ static int mt8189_afe_runtime_resume(struct device *dev)
static int mt8189_afe_component_probe(struct snd_soc_component *component)
{
struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component);
+ int ret;
/* enable clock for regcache get default value from hw */
- pm_runtime_get_sync(afe->dev);
+ ret = pm_runtime_resume_and_get(afe->dev);
+ if (ret)
+ return dev_err_probe(afe->dev, ret, "failed to resume device\n");
+
mtk_afe_add_sub_dai_control(component);
pm_runtime_put_sync(afe->dev);
@@ -2417,6 +2421,11 @@ static const struct reg_sequence mt8189_cg_patch[] = {
{ AUDIO_TOP_CON4, 0x361c },
};
+static void mt8189_afe_release_reserved_mem(void *data)
+{
+ of_reserved_mem_device_release(data);
+}
+
static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
{
int ret, i;
@@ -2431,8 +2440,15 @@ static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
ret = of_reserved_mem_device_init(dev);
- if (ret)
+ if (ret) {
dev_warn(dev, "failed to assign memory region: %d\n", ret);
+ } else {
+ ret = devm_add_action_or_reset(dev,
+ mt8189_afe_release_reserved_mem,
+ dev);
+ if (ret)
+ return ret;
+ }
afe = devm_kzalloc(dev, sizeof(*afe), GFP_KERNEL);
if (!afe)
@@ -2533,18 +2549,22 @@ static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
dev_pm_syscore_device(dev, true);
/* enable clock for regcache get default value from hw */
- pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to resume device\n");
afe->regmap = devm_regmap_init_mmio(dev, afe->base_addr,
&mt8189_afe_regmap_config);
- if (IS_ERR(afe->regmap))
- return PTR_ERR(afe->regmap);
+ if (IS_ERR(afe->regmap)) {
+ ret = PTR_ERR(afe->regmap);
+ goto err_pm_put;
+ }
ret = regmap_register_patch(afe->regmap, mt8189_cg_patch,
ARRAY_SIZE(mt8189_cg_patch));
if (ret < 0) {
dev_err(dev, "Failed to apply cg patch\n");
- goto err_pm_disable;
+ goto err_pm_put;
}
regmap_read(afe->regmap, AFE_IRQ_MCU_EN, &tmp_reg);
@@ -2563,12 +2583,12 @@ static int mt8189_afe_pcm_dev_probe(struct platform_device *pdev)
afe->num_dai_drivers);
if (ret) {
dev_err(dev, "afe component err: %d\n", ret);
- goto err_pm_disable;
+ return ret;
}
return 0;
-err_pm_disable:
+err_pm_put:
pm_runtime_put_sync(dev);
return ret;
}
@@ -2578,14 +2598,12 @@ static void mt8189_afe_pcm_dev_remove(struct platform_device *pdev)
struct mtk_base_afe *afe = platform_get_drvdata(pdev);
struct device *dev = &pdev->dev;
- pm_runtime_put_sync(dev);
if (!pm_runtime_status_suspended(dev))
mt8189_afe_runtime_suspend(dev);
mt8189_afe_disable_main_clock(afe);
/* disable afe clock */
mt8189_afe_disable_reg_rw_clk(afe);
- of_reserved_mem_device_release(dev);
}
static const struct of_device_id mt8189_afe_pcm_dt_match[] = {
---
base-commit: eeecc92a9f1dd213dd52d9b8f42d155595b1d278
change-id: 20260512-asoc-mt8189-probe-cleanup-57d911861f86
Best regards,
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
^ permalink raw reply related
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Catalin Marinas @ 2026-05-14 13:46 UTC (permalink / raw)
To: Greg KH
Cc: Suzuki K Poulose, Aneesh Kumar K.V (Arm), linux-coco,
linux-arm-kernel, linux-kernel, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price
In-Reply-To: <2026051445-magician-coffee-962f@gregkh>
On Thu, May 14, 2026 at 03:25:34PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 14, 2026 at 02:19:19PM +0100, Catalin Marinas wrote:
> > On Thu, May 14, 2026 at 02:55:48PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> > > > On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> > > > > Make the SMCCC driver responsible for registering the arm-smccc platform
> > > > > device and after confirming the relevant SMCCC function IDs, create
> > > > > the arm_cca_guest auxiliary device.
> > > > >
> > > >
> > > > There are a few changes squashed in to this patch. Please could we
> > > > split the patch in the following order ?
> > > >
> > > > 1. Add platform device for arm-smccc
> > >
> > > Do not make any more "fake" platform devices please.
> > >
> > > > 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> > > > it before the RSI changes)
> > >
> > > No, move it to the faux api please.
> >
> > So should we end up with:
> >
> > /sys/devices/faux/arm-smccc/
> > smccc_trng/
> > arm-rsi-dev/
>
> What types are these child devices? Also faux ones?
They'd also be faux devices with this structure (in practice they are
firmware interfaces that may be backed by some hardware like in the TRNG
case, though not directly accessible to Linux).
--
Catalin
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Greg KH @ 2026-05-14 13:25 UTC (permalink / raw)
To: Catalin Marinas
Cc: Suzuki K Poulose, Aneesh Kumar K.V (Arm), linux-coco,
linux-arm-kernel, linux-kernel, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price
In-Reply-To: <agXL12bNh4gGyK1K@arm.com>
On Thu, May 14, 2026 at 02:19:19PM +0100, Catalin Marinas wrote:
> On Thu, May 14, 2026 at 02:55:48PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> > > On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> > > > Make the SMCCC driver responsible for registering the arm-smccc platform
> > > > device and after confirming the relevant SMCCC function IDs, create
> > > > the arm_cca_guest auxiliary device.
> > > >
> > >
> > > There are a few changes squashed in to this patch. Please could we
> > > split the patch in the following order ?
> > >
> > > 1. Add platform device for arm-smccc
> >
> > Do not make any more "fake" platform devices please.
> >
> > > 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> > > it before the RSI changes)
> >
> > No, move it to the faux api please.
>
> So should we end up with:
>
> /sys/devices/faux/arm-smccc/
> smccc_trng/
> arm-rsi-dev/
What types are these child devices? Also faux ones?
If so, great.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Catalin Marinas @ 2026-05-14 13:23 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-coco, linux-arm-kernel, linux-kernel, Greg KH,
Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland,
Sudeep Holla, Will Deacon, Steven Price, Suzuki K Poulose
In-Reply-To: <20260514094030.42495-2-aneesh.kumar@kernel.org>
On Thu, May 14, 2026 at 03:10:28PM +0530, Aneesh Kumar K.V (Arm) wrote:
> diff --git a/drivers/firmware/smccc/rmm.h b/drivers/firmware/smccc/rmm.h
> new file mode 100644
> index 000000000000..a47a650d4f51
> --- /dev/null
> +++ b/drivers/firmware/smccc/rmm.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _SMCCC_RMM_H
> +#define _SMCCC_RMM_H
> +
> +#include <linux/platform_device.h>
> +
> +#ifdef CONFIG_ARM64
> +#include <asm/rsi_cmds.h>
> +void __init register_rsi_device(struct platform_device *pdev);
> +#else
> +
> +static void __init register_rsi_device(struct platform_device *pdev)
Nit: static inline here (I think Sashiko mentioned it on a previous
version.
> +{
> +
> +}
And unnecessary empty line between curly braces.
Just these notpicks for now. Suzuki and Sudeep already covered the
splitting of this patch and we need to agree on the sysfs hierarchy.
--
Catalin
^ permalink raw reply
* Re: [PATCH v2] nvme-apple: Reset q->sq_tail during queue init
From: Sven Peter @ 2026-05-14 13:20 UTC (permalink / raw)
To: Nick Chan, Janne Grunau, Neal Gompa, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg
Cc: asahi, linux-arm-kernel, linux-nvme, linux-kernel, stable,
Yuriy Havrylyuk
In-Reply-To: <20260514-nvme-apple-sq-reset-v2-1-84cbb5c70bf5@gmail.com>
On 14.05.26 15:16, Nick Chan wrote:
> Fixes a "duplicate tag error for tag 0" firmware crash during controller
> reset while setting up the admin queue on Apple A11 / T8015.
... caused by stale entries in the submission queue due to an invalid
sq_tail offset after reset.
And I guess this also happens on the i/o queue and is fixed by this as
well, isn't it?
>
> Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support")
> Cc: stable@vger.kernel.org
> Suggested-by: Yuriy Havrylyuk <yhavry@gmail.com>
> Signed-off-by: Nick Chan <towinchenmi@gmail.com>
> ---
Reviewed-by: Sven Peter <sven@kernel.org>
Best,
Sven
^ permalink raw reply
* Re: [PATCH v2 02/16] dt-bindings: iio: adc: mt6359: add mt6323 PMIC AUXADC
From: Krzysztof Kozlowski @ 2026-05-14 13:20 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-2-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:16AM +0300, Roman Vivchar wrote:
> The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
> temperature, and other internal measurements.
>
> Add the devicetree binding documentation and the associated header file
> defining the ADC channel constants.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 1 +
> .../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
> 2 files changed, 25 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Catalin Marinas @ 2026-05-14 13:19 UTC (permalink / raw)
To: Greg KH
Cc: Suzuki K Poulose, Aneesh Kumar K.V (Arm), linux-coco,
linux-arm-kernel, linux-kernel, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price
In-Reply-To: <2026051420-amusement-drove-73e6@gregkh>
On Thu, May 14, 2026 at 02:55:48PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> > On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> > > Make the SMCCC driver responsible for registering the arm-smccc platform
> > > device and after confirming the relevant SMCCC function IDs, create
> > > the arm_cca_guest auxiliary device.
> > >
> >
> > There are a few changes squashed in to this patch. Please could we
> > split the patch in the following order ?
> >
> > 1. Add platform device for arm-smccc
>
> Do not make any more "fake" platform devices please.
>
> > 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> > it before the RSI changes)
>
> No, move it to the faux api please.
So should we end up with:
/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/
tsm/tsm0
/sys/class/tsm/tsm0
-> ../../devices/faux/arm-smccc/arm-rsi-dev/tsm/tsm0
/sys/firmware/cca/
realm_guest
--
Catalin
^ permalink raw reply
* [PATCH v2] nvme-apple: Reset q->sq_tail during queue init
From: Nick Chan @ 2026-05-14 13:16 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg
Cc: asahi, linux-arm-kernel, linux-nvme, linux-kernel, stable,
Yuriy Havrylyuk, Nick Chan
Fixes a "duplicate tag error for tag 0" firmware crash during controller
reset while setting up the admin queue on Apple A11 / T8015.
Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support")
Cc: stable@vger.kernel.org
Suggested-by: Yuriy Havrylyuk <yhavry@gmail.com>
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
---
Changes in v2:
- Cc stable
- Details on how controller reset is fixed
- Link to v1: https://lore.kernel.org/r/20260514-nvme-apple-sq-reset-v1-1-8931e455281e@gmail.com
---
drivers/nvme/host/apple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index 423c9c628e7b..c692fc73babf 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -1009,6 +1009,7 @@ static void apple_nvme_init_queue(struct apple_nvme_queue *q)
unsigned int depth = apple_nvme_queue_depth(q);
struct apple_nvme *anv = queue_to_apple_nvme(q);
+ q->sq_tail = 0;
q->cq_head = 0;
q->cq_phase = 1;
if (anv->hw->has_lsq_nvmmu)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260514-nvme-apple-sq-reset-53e22e88c7b0
Best regards,
--
Nick Chan <towinchenmi@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 15/16] MAINTAINERS: add MediaTek mt6323 PMIC EFUSE driver maintainer
From: Krzysztof Kozlowski @ 2026-05-14 13:05 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260514-spiritual-grouse-of-abracadabra-d91bc9@quoll>
On 14/05/2026 15:04, Krzysztof Kozlowski wrote:
> On Tue, May 12, 2026 at 08:18:29AM +0300, Roman Vivchar wrote:
>> Add myself as MediaTek mt6323 EFUSE driver maintainer.
>>
>> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
>> ---
>> MAINTAINERS | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 52249c301633..bf2e066f377d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -16342,6 +16342,11 @@ M: Roman Vivchar <rva333@protonmail.com>
>> S: Odd Fixes
>> F: drivers/iio/adc/mt6323-auxadc.c
>>
>> +MEDIATEK PMIC EFUSE DRIVER
>> +M: Roman Vivchar <rva333@protonmail.com>
>> +S: Odd Fixes
>> +F: drivers/nvmem/mt6323-efuse.c
>
> I don't understand why this cannot be one maintainer entry.
> Really, these are just single drivers.
Heh, and now I see my comment on v1 which you did not implement.
SQUASHED. Please see git rebase and the meaning of squash.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 15/16] MAINTAINERS: add MediaTek mt6323 PMIC EFUSE driver maintainer
From: Krzysztof Kozlowski @ 2026-05-14 13:04 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-15-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:29AM +0300, Roman Vivchar wrote:
> Add myself as MediaTek mt6323 EFUSE driver maintainer.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 52249c301633..bf2e066f377d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16342,6 +16342,11 @@ M: Roman Vivchar <rva333@protonmail.com>
> S: Odd Fixes
> F: drivers/iio/adc/mt6323-auxadc.c
>
> +MEDIATEK PMIC EFUSE DRIVER
> +M: Roman Vivchar <rva333@protonmail.com>
> +S: Odd Fixes
> +F: drivers/nvmem/mt6323-efuse.c
I don't understand why this cannot be one maintainer entry.
Really, these are just single drivers.
> +
> MEDIATEK PMIC LED DRIVER
> M: Sen Chu <sen.chu@mediatek.com>
> M: Sean Wang <sean.wang@mediatek.com>
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v2 16/16] MAINTAINERS: add MediaTek mt6323 PMIC thermal driver maintainer
From: Krzysztof Kozlowski @ 2026-05-14 13:03 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-16-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:30AM +0300, Roman Vivchar wrote:
> Add myself as MediaTek mt6323 thermal driver maintainer.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> MAINTAINERS | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf2e066f377d..3001a713b083 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16355,6 +16355,11 @@ S: Maintained
> F: Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> F: drivers/leds/leds-mt6323.c
>
> +MEDIATEK PMIC THERMAL DRIVER
> +M: Roman Vivchar <rva333@protonmail.com>
> +S: Odd Fixes
Odd Fixes means driver is half-abandonded, so please explain in the
commit msg why you add yourself as maintainer but not really committed.
Such entry makes more sense for subsystems, but if individual driver has
odd-fixes stage, shouldn't we just remove this maintainer entry? If so,
why adding it in the first place?
> +F: drivers/thermal/mediatek/mtk_pmic_thermal.c
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] nvme-apple: Reset q->sq_tail during queue init
From: Greg KH @ 2026-05-14 13:02 UTC (permalink / raw)
To: Nick Chan
Cc: Sven Peter, Janne Grunau, Neal Gompa, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, asahi, linux-arm-kernel,
linux-nvme, linux-kernel, stable, Yuriy Havrylyuk
In-Reply-To: <20260514-nvme-apple-sq-reset-v1-1-8931e455281e@gmail.com>
On Thu, May 14, 2026 at 08:54:59PM +0800, Nick Chan wrote:
> Fixes controller reset on Apple A11 / T8015.
>
> Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support")
> Suggested-by: Yuriy Havrylyuk <yhavry@gmail.com>
> Signed-off-by: Nick Chan <towinchenmi@gmail.com>
> ---
> drivers/nvme/host/apple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
> index 423c9c628e7b..c692fc73babf 100644
> --- a/drivers/nvme/host/apple.c
> +++ b/drivers/nvme/host/apple.c
> @@ -1009,6 +1009,7 @@ static void apple_nvme_init_queue(struct apple_nvme_queue *q)
> unsigned int depth = apple_nvme_queue_depth(q);
> struct apple_nvme *anv = queue_to_apple_nvme(q);
>
> + q->sq_tail = 0;
> q->cq_head = 0;
> q->cq_phase = 1;
> if (anv->hw->has_lsq_nvmmu)
>
> ---
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
> change-id: 20260514-nvme-apple-sq-reset-53e22e88c7b0
>
> Best regards,
> --
> Nick Chan <towinchenmi@gmail.com>
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You have marked a patch with a "Fixes:" tag for a commit that is in an
older released kernel, yet you do not have a cc: stable line in the
signed-off-by area at all, which means that the patch will not be
applied to any older kernel releases. To properly fix this, please
follow the documented rules in the
Documentation/process/stable-kernel-rules.rst file for how to resolve
this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series
From: Krzysztof Kozlowski @ 2026-05-14 12:57 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512-mt6323-v2-1-3efcba579e88@protonmail.com>
On Tue, May 12, 2026 at 08:18:15AM +0300, Roman Vivchar wrote:
> Update binding title to the MT63xx, since the list of compatibles already
> includes mt6363 and mt6373 which don't belong to the mt6350 family.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> index 5d4ab701f51a..2e8857e104f5 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: MediaTek MT6350 series PMIC AUXADC
> +title: MediaTek MT63xx series PMIC AUXADC
Honestly that's close to churn... Do it while adding new compatibles.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Greg KH @ 2026-05-14 12:55 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Aneesh Kumar K.V (Arm), linux-coco, linux-arm-kernel,
linux-kernel, Catalin Marinas, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price
In-Reply-To: <0c88bcee-65b5-4328-87e6-e1c714c3d1ca@arm.com>
On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> Hi Aneesh
>
> On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> > Make the SMCCC driver responsible for registering the arm-smccc platform
> > device and after confirming the relevant SMCCC function IDs, create
> > the arm_cca_guest auxiliary device.
> >
>
> There are a few changes squashed in to this patch. Please could we
> split the patch in the following order ?
>
> 1. Add platform device for arm-smccc
Do not make any more "fake" platform devices please.
> 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> it before the RSI changes)
No, move it to the faux api please.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] nvme-apple: Reset q->sq_tail during queue init
From: Nick Chan @ 2026-05-14 12:54 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg
Cc: asahi, linux-arm-kernel, linux-nvme, linux-kernel, stable,
Yuriy Havrylyuk, Nick Chan
Fixes controller reset on Apple A11 / T8015.
Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support")
Suggested-by: Yuriy Havrylyuk <yhavry@gmail.com>
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
---
drivers/nvme/host/apple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index 423c9c628e7b..c692fc73babf 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -1009,6 +1009,7 @@ static void apple_nvme_init_queue(struct apple_nvme_queue *q)
unsigned int depth = apple_nvme_queue_depth(q);
struct apple_nvme *anv = queue_to_apple_nvme(q);
+ q->sq_tail = 0;
q->cq_head = 0;
q->cq_phase = 1;
if (anv->hw->has_lsq_nvmmu)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260514-nvme-apple-sq-reset-53e22e88c7b0
Best regards,
--
Nick Chan <towinchenmi@gmail.com>
^ permalink raw reply related
* Re: [PATCH v2 03/11] m68k: mcf5441x: setup DAC clock name as per driver name
From: Greg Ungerer @ 2026-05-14 12:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Steven King, Arnd Bergmann, Maxime Coquelin,
Alexandre Torgue, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Greg Ungerer, linux-m68k, linux-kernel,
linux-stm32, linux-arm-kernel, linux-iio
In-Reply-To: <ugda72734f6vn67jp6cz6hpkif55a5m4yey3yo2dswicqbyrdx@zk4lhc7k4dxu>
Hi Angelo,
On 14/5/26 17:05, Angelo Dureghello wrote:
> Hi Greg,
>
> On 14.05.2026 11:27, Greg Ungerer wrote:
>> Hi Angelo,
>>
>> On 13/5/26 19:14, Angelo Dureghello wrote:
>>> From: Angelo Dureghello <adureghello@baylibre.com>
>>>
>>> Later in this patchset, the mcf54415 DAC driver is added.
>>> Considering some other different ColdFire cpu DACs exists, the DAC driver
>>> is named as "mcf54415_dac", related to the mcf5441x family SoCs with
>>> DACs (mcf54415/6/7/8).
>>>
>>> So updating DAC clock names to bind with proper driver name.
>>
>> I am not sure I like naming the clocks here with a prefix for the
>> specific SoC part number this is in. It might be unlikely now, but
>> what if another ColdFire family SoC member uses this same hardware block?
>> That is very common amongst other hardware blocks within the ColdFire
>> family. Can we come up with a name more specific to just this type
>> of DAC hardware block?
>>
>
> from a brief study, this 12bit DAC, and DAC module in general, is only on
> this mcf45441x family. There are some ColdFire with ADC only, as those
> mcf5249/53/82.
> The mcf51mm/ag/je are the opnly to have a 5bit dacs, but these are mcus.
> So, if i don't miss any existing model, the name may be correct,
> unless we want rename it to a more generic mcf_dac.
Yes, I would suggest just leaving it as is, "mcfdac".
That is not currently used by any other ColdFire variants supported by
the kernel.
Regards
Greg
>> Regards
>> Greg
>>
>>
>
> Regards,
> angelo
>>
>>
>>> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
>>> ---
>>> arch/m68k/coldfire/m5441x.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
>>> index 5b5e09ecf487..b724d7fc1a08 100644
>>> --- a/arch/m68k/coldfire/m5441x.c
>>> +++ b/arch/m68k/coldfire/m5441x.c
>>> @@ -43,8 +43,8 @@ DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
>>> DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
>>> DEFINE_CLK(0, "mcfeport.0", 36, MCF_CLK);
>>> DEFINE_CLK(0, "mcfadc.0", 37, MCF_CLK);
>>> -DEFINE_CLK(0, "mcfdac.0", 38, MCF_CLK);
>>> -DEFINE_CLK(0, "mcfdac.1", 39, MCF_CLK);
>>> +DEFINE_CLK(0, "mcf54415_dac.0", 38, MCF_CLK);
>>> +DEFINE_CLK(0, "mcf54415_dac.1", 39, MCF_CLK);
>>> DEFINE_CLK(0, "mcfrtc.0", 42, MCF_CLK);
>>> DEFINE_CLK(0, "mcfsim.0", 43, MCF_CLK);
>>> DEFINE_CLK(0, "mcfusb-otg.0", 44, MCF_CLK);
>>> @@ -106,8 +106,8 @@ static struct clk_lookup m5411x_clk_lookup[] = {
>>> CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
>>> CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_36),
>>> CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_37),
>>> - CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_38),
>>> - CLKDEV_INIT("mcfdac.1", NULL, &__clk_0_39),
>>> + CLKDEV_INIT("mcf54415_dac.0", NULL, &__clk_0_38),
>>> + CLKDEV_INIT("mcf54415_dac.1", NULL, &__clk_0_39),
>>> CLKDEV_INIT("mcfrtc.0", NULL, &__clk_0_42),
>>> CLKDEV_INIT("mcfsim.0", NULL, &__clk_0_43),
>>> CLKDEV_INIT("mcfusb-otg.0", NULL, &__clk_0_44),
>>>
>>
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor description
From: Marek Vasut @ 2026-05-14 12:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Marc Zyngier, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Kuninori Morimoto, Magnus Damm, Rob Herring,
devicetree, linux-renesas-soc
The Renesas R-Car X5H (R8A78000) SoC contains Arm CoreLink GIC-720AE
Generic Interrupt Controller with Multi View capability. Firmware has
access to configuration View 0, Linux kernel has access to View 1.
The Arm CoreLink GIC-720AE Generic Interrupt Controller Technical
Reference Manual, currently latest r2p1 [1], chapter "5. Programmers
model for GIC-720AE", subchapter "5.4 Redistributor registers
for control and physical LPIs summary", part "5.4.3 GICR_TYPER,
Redistributor Type Register", "Table 5-50: GICR_TYPER bit descriptions"
on page 200, clarifies register "GICR_TYPER" bit 4 "Last" behavior
in Multi View setup as follows:
"
Last
Last Redistributor:
0 ... This Redistributor is not the last Redistributor on the chip.
1 ... This Redistributor is the last Redistributor on the chip.
When GICD_CFGID.VIEW == 1, for views 1, 2, or 3 this bit
always returns 1.
"
On this SoC, GICD_CFGID.VIEW is 1 and the Linux kernel has access to
View 1, therefore Linux kernel GICv3 driver will interpret register
"GICR_TYPER" bit 4 "Last" = 1 in the first Redistributor in continuous
Redistributor page as that first Redistributor being the one and only
Redistributor and will stop processing the continuous Redistributor
page further. This will prevent the other Redistributors from being
recognized by the system and used for other PEs.
Because the hardware indicates that the continuous Redistributor page
is not continuous for View 1, 2, or 3, describe every Redistributor
separately in the DT. This makes all Redistributors for all cores
accessible in Linux.
[1] https://documentation-service.arm.com/static/69ef3c1cd35efd294e335c43
Arm® CoreLink™ GIC-720AE Generic Interrupt Controller
Revision: r2p1 / Issue 12 / 102666_0201_12_en
Fixes: 63500d12cf76 ("arm64: dts: renesas: Add R8A78000 SoC support")
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: - Update GIC-700AE documentation link to generated PDF
- Update commit message to match the PDF
- Add AB from Marc
---
arch/arm64/boot/dts/renesas/r8a78000.dtsi | 36 +++++++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a78000.dtsi b/arch/arm64/boot/dts/renesas/r8a78000.dtsi
index 3ec1b53d27828..73be51787265c 100644
--- a/arch/arm64/boot/dts/renesas/r8a78000.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a78000.dtsi
@@ -689,8 +689,40 @@ gic: interrupt-controller@39000000 {
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
- reg = <0 0x39000000 0 0x10000>,
- <0 0x39080000 0 0x800000>;
+ #redistributor-regions = <32>;
+ reg = <0x0 0x39000000 0x0 0x10000>,
+ <0x0 0x39080000 0x0 0x40000>,
+ <0x0 0x390c0000 0x0 0x40000>,
+ <0x0 0x39100000 0x0 0x40000>,
+ <0x0 0x39140000 0x0 0x40000>,
+ <0x0 0x39180000 0x0 0x40000>,
+ <0x0 0x391c0000 0x0 0x40000>,
+ <0x0 0x39200000 0x0 0x40000>,
+ <0x0 0x39240000 0x0 0x40000>,
+ <0x0 0x39280000 0x0 0x40000>,
+ <0x0 0x392c0000 0x0 0x40000>,
+ <0x0 0x39300000 0x0 0x40000>,
+ <0x0 0x39340000 0x0 0x40000>,
+ <0x0 0x39380000 0x0 0x40000>,
+ <0x0 0x393c0000 0x0 0x40000>,
+ <0x0 0x39400000 0x0 0x40000>,
+ <0x0 0x39440000 0x0 0x40000>,
+ <0x0 0x39480000 0x0 0x40000>,
+ <0x0 0x394c0000 0x0 0x40000>,
+ <0x0 0x39500000 0x0 0x40000>,
+ <0x0 0x39540000 0x0 0x40000>,
+ <0x0 0x39580000 0x0 0x40000>,
+ <0x0 0x395c0000 0x0 0x40000>,
+ <0x0 0x39600000 0x0 0x40000>,
+ <0x0 0x39640000 0x0 0x40000>,
+ <0x0 0x39680000 0x0 0x40000>,
+ <0x0 0x396c0000 0x0 0x40000>,
+ <0x0 0x39700000 0x0 0x40000>,
+ <0x0 0x39740000 0x0 0x40000>,
+ <0x0 0x39780000 0x0 0x40000>,
+ <0x0 0x397c0000 0x0 0x40000>,
+ <0x0 0x39800000 0x0 0x40000>,
+ <0x0 0x39840000 0x0 0x40000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 3/3] usb: dwc3: xilinx: fix error handling in zynqmp init error paths
From: Pandey, Radhey Shyam @ 2026-05-14 12:52 UTC (permalink / raw)
To: Thinh Nguyen, Radhey Shyam Pandey
Cc: gregkh@linuxfoundation.org, michal.simek@amd.com,
p.zabel@pengutronix.de, linux-usb@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, git@amd.com, stable@vger.kernel.org
In-Reply-To: <agUnwgXyyrGQ2t2y@vbox>
On 5/14/2026 7:13 AM, Thinh Nguyen wrote:
> On Mon, May 11, 2026, Radhey Shyam Pandey wrote:
>> Fix error handling and resource cleanup i.e remove invalid
>> phy_exit() after failed phy_init(), route failures through
>> proper cleanup paths and return 0 explicitly on success.
>>
>> Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>> ---
>> drivers/usb/dwc3/dwc3-xilinx.c | 27 +++++++++++++++------------
>> 1 file changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
>> index 94458b3da1a0..b832505e1b04 100644
>> --- a/drivers/usb/dwc3/dwc3-xilinx.c
>> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
>> @@ -176,15 +176,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
>> }
>>
>> ret = phy_init(priv_data->usb3_phy);
>> - if (ret < 0) {
>> - phy_exit(priv_data->usb3_phy);
>> + if (ret < 0)
>> goto err;
>> - }
>>
>> ret = reset_control_deassert(apbrst);
>> if (ret < 0) {
>> dev_err(dev, "Failed to release APB reset\n");
>> - goto err;
>> + goto err_phy_exit;
>> }
>>
>> if (priv_data->usb3_phy) {
>> @@ -200,26 +198,24 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
>> ret = reset_control_deassert(crst);
>> if (ret < 0) {
>> dev_err(dev, "Failed to release core reset\n");
>> - goto err;
>> + goto err_phy_exit;
>> }
>>
>> ret = reset_control_deassert(hibrst);
>> if (ret < 0) {
>> dev_err(dev, "Failed to release hibernation reset\n");
>> - goto err;
>> + goto err_phy_exit;
>> }
>>
>> ret = phy_power_on(priv_data->usb3_phy);
>> - if (ret < 0) {
>> - phy_exit(priv_data->usb3_phy);
>> - goto err;
>> - }
>> + if (ret < 0)
>> + goto err_phy_exit;
>>
>> /* ulpi reset via gpio-modepin or gpio-framework driver */
>> reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
>> if (IS_ERR(reset_gpio)) {
>> - return dev_err_probe(dev, PTR_ERR(reset_gpio),
>> - "Failed to request reset GPIO\n");
>> + ret = PTR_ERR(reset_gpio);
>> + goto err_phy_power_off;
>> }
>>
>> if (reset_gpio) {
>> @@ -229,6 +225,13 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
>> }
>>
>> dwc3_xlnx_set_coherency(priv_data, XLNX_USB_TRAFFIC_ROUTE_CONFIG);
>> +
>> + return 0;
>> +
>> +err_phy_power_off:
>> + phy_power_off(priv_data->usb3_phy);
>> +err_phy_exit:
>> + phy_exit(priv_data->usb3_phy);
>> err:
>> return ret;
>> }
>> --
>> 2.44.4
>>
>
> This fix should be a separate patch from this cleanup series.
>
Sure, will split it into a separate patch. Does this patch look fine?
If so i can add the Reviewed-by tag in v2 or address any further
comments if needed.
Thanks,
Radhey
^ permalink raw reply
* Re: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
From: kernel test robot @ 2026-05-14 12:50 UTC (permalink / raw)
To: Hans Zhang, bhelgaas, lpieralisi, kwilczynski, mani, vigneshr,
jingoohan1, thomas.petazzoni, pali, ryder.lee, jianjun.wang,
claudiu.beznea.uj, mpillai
Cc: oe-kbuild-all, robh, s-vadapalli, linux-omap, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel,
Hans Zhang
In-Reply-To: <20260506152346.166056-9-18255117159@163.com>
Hi Hans,
kernel test robot noticed the following build warnings:
[auto build test WARNING on a293ec25d59dd96309058c70df5a4dd0f889a1e4]
url: https://github.com/intel-lab-lkp/linux/commits/Hans-Zhang/PCI-Add-pcie_wait_after_link_train-helper/20260514-132815
base: a293ec25d59dd96309058c70df5a4dd0f889a1e4
patch link: https://lore.kernel.org/r/20260506152346.166056-9-18255117159%40163.com
patch subject: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260514/202605141445.2Ag4i8fZ-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260514/202605141445.2Ag4i8fZ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605141445.2Ag4i8fZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/pci/hotplug/pciehp_ctrl.c:24:
drivers/pci/hotplug/../pci.h: In function 'pcie_wait_after_link_train':
drivers/pci/hotplug/../pci.h:73:17: error: implicit declaration of function 'msleep' [-Wimplicit-function-declaration]
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^~~~~~
In file included from drivers/pci/hotplug/pciehp.h:21,
from drivers/pci/hotplug/pciehp_ctrl.c:25:
include/linux/delay.h: At top level:
>> include/linux/delay.h:61:6: warning: conflicting types for 'msleep'; have 'void(unsigned int)'
61 | void msleep(unsigned int msecs);
| ^~~~~~
drivers/pci/hotplug/../pci.h:73:17: note: previous implicit declaration of 'msleep' with type 'void(unsigned int)'
73 | msleep(PCIE_RESET_CONFIG_WAIT_MS);
| ^~~~~~
vim +61 include/linux/delay.h
^1da177e4c3f41 Linus Torvalds 2005-04-16 56
f3f3149f35b919 Alok Kataria 2008-06-23 57 extern unsigned long lpj_fine;
^1da177e4c3f41 Linus Torvalds 2005-04-16 58 void calibrate_delay(void);
ad1a48301f659a Arnd Bergmann 2023-05-17 59 unsigned long calibrate_delay_is_known(void);
8496ecd0bed4c7 Valdis Kletnieks 2019-03-07 60 void __attribute__((weak)) calibration_delay_done(void);
^1da177e4c3f41 Linus Torvalds 2005-04-16 @61 void msleep(unsigned int msecs);
^1da177e4c3f41 Linus Torvalds 2005-04-16 62 unsigned long msleep_interruptible(unsigned int msecs);
e4779015fd5d2f SeongJae Park 2021-12-10 63 void usleep_range_state(unsigned long min, unsigned long max,
e4779015fd5d2f SeongJae Park 2021-12-10 64 unsigned int state);
e4779015fd5d2f SeongJae Park 2021-12-10 65
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v5 1/3] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Sudeep Holla @ 2026-05-14 12:50 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Aneesh Kumar K.V (Arm), linux-coco, linux-arm-kernel,
Sudeep Holla, linux-kernel, Catalin Marinas, Greg KH,
Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland,
Will Deacon, Steven Price
In-Reply-To: <0c88bcee-65b5-4328-87e6-e1c714c3d1ca@arm.com>
On Thu, May 14, 2026 at 12:04:13PM +0100, Suzuki K Poulose wrote:
> Hi Aneesh
>
> On 14/05/2026 10:40, Aneesh Kumar K.V (Arm) wrote:
> > Make the SMCCC driver responsible for registering the arm-smccc platform
> > device and after confirming the relevant SMCCC function IDs, create
> > the arm_cca_guest auxiliary device.
> >
>
> There are a few changes squashed in to this patch.
I had similar thoughts but I didn't get into forming a reply, now I can keep
it small, thanks for that 😉.
> Please could we split the patch in the following order ?
>
> 1. Add platform device for arm-smccc
> 2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move
> it before the RSI changes)
> 3. Move RSI dev as Auxilliary
> 4. Add the firmware sysfs ABI.
>
I agree with the logical split of functionality above.
> That way, first two could be merged while we figure out (3) and (4)
>
I disagree with this though. We don't want to merge this unless (3) is
agreed. There is no point in doing that unless we agree the approach for
RSI as well.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-05-14 12:48 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Jason Gunthorpe,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agW5rhE9n2gDQ0w5@google.com>
Mostafa Saleh <smostafa@google.com> writes:
> On Thu, May 14, 2026 at 11:24:42AM +0530, Aneesh Kumar K.V wrote:
>> Mostafa Saleh <smostafa@google.com> writes:
>>
>> > On Tue, May 12, 2026 at 02:33:59PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> Teach swiotlb to distinguish between encrypted and decrypted bounce
>> >> buffer pools, and make allocation and mapping paths select a pool whose
>> >> state matches the requested DMA attributes.
>> >>
>> >> Add a decrypted flag to io_tlb_mem, initialize it for the default and
>> >> restricted pools, and propagate DMA_ATTR_CC_SHARED into swiotlb pool
>> >> allocation. Reject swiotlb alloc/map requests when the selected pool does
>> >> not match the required encrypted/decrypted state.
>> >>
>> >> Also return DMA addresses with the matching phys_to_dma_{encrypted,
>> >> unencrypted} helper so the DMA address encoding stays consistent with the
>> >> chosen pool.
>> >>
>> >> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> >> ---
>> >> include/linux/dma-direct.h | 10 ++++
>> >> include/linux/swiotlb.h | 8 ++-
>> >> kernel/dma/direct.c | 14 +++--
>> >> kernel/dma/swiotlb.c | 108 +++++++++++++++++++++++++++----------
>> >> 4 files changed, 107 insertions(+), 33 deletions(-)
>> >>
>> >> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
>> >> index c249912456f9..94fad4e7c11e 100644
>> >> --- a/include/linux/dma-direct.h
>> >> +++ b/include/linux/dma-direct.h
>> >> @@ -77,6 +77,10 @@ static inline dma_addr_t dma_range_map_max(const struct bus_dma_region *map)
>> >> #ifndef phys_to_dma_unencrypted
>> >> #define phys_to_dma_unencrypted phys_to_dma
>> >> #endif
>> >> +
>> >> +#ifndef phys_to_dma_encrypted
>> >> +#define phys_to_dma_encrypted phys_to_dma
>> >> +#endif
>> >> #else
>> >> static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
>> >> {
>> >> @@ -90,6 +94,12 @@ static inline dma_addr_t phys_to_dma_unencrypted(struct device *dev,
>> >> {
>> >> return dma_addr_unencrypted(__phys_to_dma(dev, paddr));
>> >> }
>> >> +
>> >> +static inline dma_addr_t phys_to_dma_encrypted(struct device *dev,
>> >> + phys_addr_t paddr)
>> >> +{
>> >> + return dma_addr_encrypted(__phys_to_dma(dev, paddr));
>> >> +}
>> >> /*
>> >> * If memory encryption is supported, phys_to_dma will set the memory encryption
>> >> * bit in the DMA address, and dma_to_phys will clear it.
>> >> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
>> >> index 3dae0f592063..b3fa3c6e0169 100644
>> >> --- a/include/linux/swiotlb.h
>> >> +++ b/include/linux/swiotlb.h
>> >> @@ -81,6 +81,7 @@ struct io_tlb_pool {
>> >> struct list_head node;
>> >> struct rcu_head rcu;
>> >> bool transient;
>> >> + bool unencrypted;
>> >> #endif
>> >> };
>> >>
>> >> @@ -111,6 +112,7 @@ struct io_tlb_mem {
>> >> struct dentry *debugfs;
>> >> bool force_bounce;
>> >> bool for_alloc;
>> >> + bool unencrypted;
>> >> #ifdef CONFIG_SWIOTLB_DYNAMIC
>> >> bool can_grow;
>> >> u64 phys_limit;
>> >> @@ -282,7 +284,8 @@ static inline void swiotlb_sync_single_for_cpu(struct device *dev,
>> >> extern void swiotlb_print_info(void);
>> >>
>> >> #ifdef CONFIG_DMA_RESTRICTED_POOL
>> >> -struct page *swiotlb_alloc(struct device *dev, size_t size);
>> >> +struct page *swiotlb_alloc(struct device *dev, size_t size,
>> >> + unsigned long attrs);
>> >> bool swiotlb_free(struct device *dev, struct page *page, size_t size);
>> >>
>> >> static inline bool is_swiotlb_for_alloc(struct device *dev)
>> >> @@ -290,7 +293,8 @@ static inline bool is_swiotlb_for_alloc(struct device *dev)
>> >> return dev->dma_io_tlb_mem->for_alloc;
>> >> }
>> >> #else
>> >> -static inline struct page *swiotlb_alloc(struct device *dev, size_t size)
>> >> +static inline struct page *swiotlb_alloc(struct device *dev, size_t size,
>> >> + unsigned long attrs)
>> >> {
>> >> return NULL;
>> >> }
>> >> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>> >> index dc2907439b3d..97ae4fa10521 100644
>> >> --- a/kernel/dma/direct.c
>> >> +++ b/kernel/dma/direct.c
>> >> @@ -104,9 +104,10 @@ static void __dma_direct_free_pages(struct device *dev, struct page *page,
>> >> dma_free_contiguous(dev, page, size);
>> >> }
>> >>
>> >> -static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size)
>> >> +static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size,
>> >> + unsigned long attrs)
>> >> {
>> >> - struct page *page = swiotlb_alloc(dev, size);
>> >> + struct page *page = swiotlb_alloc(dev, size, attrs);
>> >>
>> >> if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
>> >> swiotlb_free(dev, page, size);
>> >> @@ -266,8 +267,12 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>> >> gfp, attrs);
>> >>
>> >> if (is_swiotlb_for_alloc(dev)) {
>> >> - page = dma_direct_alloc_swiotlb(dev, size);
>> >> + page = dma_direct_alloc_swiotlb(dev, size, attrs);
>> >> if (page) {
>> >> + /*
>> >> + * swiotlb allocations comes from pool already marked
>> >> + * decrypted
>> >> + */
>> >> mark_mem_decrypt = false;
>> >> goto setup_page;
>> >> }
>> >> @@ -374,6 +379,7 @@ void dma_direct_free(struct device *dev, size_t size,
>> >> return;
>> >>
>> >> if (swiotlb_find_pool(dev, dma_to_phys(dev, dma_addr)))
>> >> + /* Swiotlb doesn't need a page attribute update on free */
>> >> mark_mem_encrypted = false;
>> >>
>> >> if (is_vmalloc_addr(cpu_addr)) {
>> >> @@ -403,7 +409,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
>> >> gfp, attrs);
>> >>
>> >> if (is_swiotlb_for_alloc(dev)) {
>> >> - page = dma_direct_alloc_swiotlb(dev, size);
>> >> + page = dma_direct_alloc_swiotlb(dev, size, attrs);
>> >> if (!page)
>> >> return NULL;
>> >>
>> >> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>> >> index ab4eccbaa076..065663be282c 100644
>> >> --- a/kernel/dma/swiotlb.c
>> >> +++ b/kernel/dma/swiotlb.c
>> >> @@ -259,10 +259,21 @@ void __init swiotlb_update_mem_attributes(void)
>> >> struct io_tlb_pool *mem = &io_tlb_default_mem.defpool;
>> >> unsigned long bytes;
>> >>
>> >> + /*
>> >> + * if platform support memory encryption, swiotlb buffers are
>> >> + * decrypted by default.
>> >> + */
>> >> + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> >> + io_tlb_default_mem.unencrypted = true;
>> >> + else
>> >> + io_tlb_default_mem.unencrypted = false;
>> >> +
>> >> if (!mem->nslabs || mem->late_alloc)
>> >> return;
>> >> bytes = PAGE_ALIGN(mem->nslabs << IO_TLB_SHIFT);
>> >> - set_memory_decrypted((unsigned long)mem->vaddr, bytes >> PAGE_SHIFT);
>> >> +
>> >> + if (io_tlb_default_mem.unencrypted)
>> >> + set_memory_decrypted((unsigned long)mem->vaddr, bytes >> PAGE_SHIFT);
>> >> }
>> >>
>> >> static void swiotlb_init_io_tlb_pool(struct io_tlb_pool *mem, phys_addr_t start,
>> >> @@ -505,8 +516,10 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
>> >> if (!mem->slots)
>> >> goto error_slots;
>> >>
>> >> - set_memory_decrypted((unsigned long)vstart,
>> >> - (nslabs << IO_TLB_SHIFT) >> PAGE_SHIFT);
>> >> + if (io_tlb_default_mem.unencrypted)
>> >> + set_memory_decrypted((unsigned long)vstart,
>> >> + (nslabs << IO_TLB_SHIFT) >> PAGE_SHIFT);
>> >> +
>> >> swiotlb_init_io_tlb_pool(mem, virt_to_phys(vstart), nslabs, true,
>> >> nareas);
>> >> add_mem_pool(&io_tlb_default_mem, mem);
>> >> @@ -539,7 +552,9 @@ void __init swiotlb_exit(void)
>> >> tbl_size = PAGE_ALIGN(mem->end - mem->start);
>> >> slots_size = PAGE_ALIGN(array_size(sizeof(*mem->slots), mem->nslabs));
>> >>
>> >> - set_memory_encrypted(tbl_vaddr, tbl_size >> PAGE_SHIFT);
>> >> + if (io_tlb_default_mem.unencrypted)
>> >> + set_memory_encrypted(tbl_vaddr, tbl_size >> PAGE_SHIFT);
>> >> +
>> >> if (mem->late_alloc) {
>> >> area_order = get_order(array_size(sizeof(*mem->areas),
>> >> mem->nareas));
>> >> @@ -563,6 +578,7 @@ void __init swiotlb_exit(void)
>> >> * @gfp: GFP flags for the allocation.
>> >> * @bytes: Size of the buffer.
>> >> * @phys_limit: Maximum allowed physical address of the buffer.
>> >> + * @unencrypted: true to allocate unencrypted memory, false for encrypted memory
>> >> *
>> >> * Allocate pages from the buddy allocator. If successful, make the allocated
>> >> * pages decrypted that they can be used for DMA.
>> >> @@ -570,7 +586,8 @@ void __init swiotlb_exit(void)
>> >> * Return: Decrypted pages, %NULL on allocation failure, or ERR_PTR(-EAGAIN)
>> >> * if the allocated physical address was above @phys_limit.
>> >> */
>> >> -static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes, u64 phys_limit)
>> >> +static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes,
>> >> + u64 phys_limit, bool unencrypted)
>> >> {
>> >> unsigned int order = get_order(bytes);
>> >> struct page *page;
>> >> @@ -588,13 +605,13 @@ static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes, u64 phys_limit)
>> >> }
>> >>
>> >> vaddr = phys_to_virt(paddr);
>> >> - if (set_memory_decrypted((unsigned long)vaddr, PFN_UP(bytes)))
>> >> + if (unencrypted && set_memory_decrypted((unsigned long)vaddr, PFN_UP(bytes)))
>> >> goto error;
>> >> return page;
>> >>
>> >> error:
>> >> /* Intentional leak if pages cannot be encrypted again. */
>> >> - if (!set_memory_encrypted((unsigned long)vaddr, PFN_UP(bytes)))
>> >> + if (unencrypted && !set_memory_encrypted((unsigned long)vaddr, PFN_UP(bytes)))
>> >> __free_pages(page, order);
>> >> return NULL;
>> >> }
>> >> @@ -604,30 +621,26 @@ static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes, u64 phys_limit)
>> >> * @dev: Device for which a memory pool is allocated.
>> >> * @bytes: Size of the buffer.
>> >> * @phys_limit: Maximum allowed physical address of the buffer.
>> >> + * @attrs: DMA attributes for the allocation.
>> >> * @gfp: GFP flags for the allocation.
>> >> *
>> >> * Return: Allocated pages, or %NULL on allocation failure.
>> >> */
>> >> static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
>> >> - u64 phys_limit, gfp_t gfp)
>> >> + u64 phys_limit, unsigned long attrs, gfp_t gfp)
>> >> {
>> >> struct page *page;
>> >> - unsigned long attrs = 0;
>> >>
>> >> /*
>> >> * Allocate from the atomic pools if memory is encrypted and
>> >> * the allocation is atomic, because decrypting may block.
>> >> */
>> >> - if (!gfpflags_allow_blocking(gfp) && dev && force_dma_unencrypted(dev)) {
>> >> + if (!gfpflags_allow_blocking(gfp) && (attrs & DMA_ATTR_CC_SHARED)) {
>> >> void *vaddr;
>> >>
>> >> if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
>> >> return NULL;
>> >>
>> >> - /* swiotlb considered decrypted by default */
>> >> - if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> >> - attrs = DMA_ATTR_CC_SHARED;
>> >> -
>> >> return dma_alloc_from_pool(dev, bytes, &vaddr, gfp,
>> >> attrs, dma_coherent_ok);
>> >> }
>> >> @@ -638,7 +651,8 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
>> >> else if (phys_limit <= DMA_BIT_MASK(32))
>> >> gfp |= __GFP_DMA32;
>> >>
>> >> - while (IS_ERR(page = alloc_dma_pages(gfp, bytes, phys_limit))) {
>> >> + while (IS_ERR(page = alloc_dma_pages(gfp, bytes, phys_limit,
>> >> + !!(attrs & DMA_ATTR_CC_SHARED)))) {
>> >> if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
>> >> phys_limit < DMA_BIT_MASK(64) &&
>> >> !(gfp & (__GFP_DMA32 | __GFP_DMA)))
>> >> @@ -657,15 +671,18 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
>> >> * swiotlb_free_tlb() - free a dynamically allocated IO TLB buffer
>> >> * @vaddr: Virtual address of the buffer.
>> >> * @bytes: Size of the buffer.
>> >> + * @unencrypted: true if @vaddr was allocated decrypted and must be
>> >> + * re-encrypted before being freed
>> >> */
>> >> -static void swiotlb_free_tlb(void *vaddr, size_t bytes)
>> >> +static void swiotlb_free_tlb(void *vaddr, size_t bytes, bool unencrypted)
>> >> {
>> >> if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
>> >> dma_free_from_pool(NULL, vaddr, bytes))
>> >> return;
>> >>
>> >> /* Intentional leak if pages cannot be encrypted again. */
>> >> - if (!set_memory_encrypted((unsigned long)vaddr, PFN_UP(bytes)))
>> >> + if (!unencrypted ||
>> >> + !set_memory_encrypted((unsigned long)vaddr, PFN_UP(bytes)))
>> >> __free_pages(virt_to_page(vaddr), get_order(bytes));
>> >> }
>> >>
>> >> @@ -676,6 +693,7 @@ static void swiotlb_free_tlb(void *vaddr, size_t bytes)
>> >> * @nslabs: Desired (maximum) number of slabs.
>> >> * @nareas: Number of areas.
>> >> * @phys_limit: Maximum DMA buffer physical address.
>> >> + * @attrs: DMA attributes for the allocation.
>> >> * @gfp: GFP flags for the allocations.
>> >> *
>> >> * Allocate and initialize a new IO TLB memory pool. The actual number of
>> >> @@ -686,7 +704,8 @@ static void swiotlb_free_tlb(void *vaddr, size_t bytes)
>> >> */
>> >> static struct io_tlb_pool *swiotlb_alloc_pool(struct device *dev,
>> >> unsigned long minslabs, unsigned long nslabs,
>> >> - unsigned int nareas, u64 phys_limit, gfp_t gfp)
>> >> + unsigned int nareas, u64 phys_limit, unsigned long attrs,
>> >> + gfp_t gfp)
>> >> {
>> >> struct io_tlb_pool *pool;
>> >> unsigned int slot_order;
>> >> @@ -704,9 +723,10 @@ static struct io_tlb_pool *swiotlb_alloc_pool(struct device *dev,
>> >> if (!pool)
>> >> goto error;
>> >> pool->areas = (void *)pool + sizeof(*pool);
>> >> + pool->unencrypted = !!(attrs & DMA_ATTR_CC_SHARED);
>> >>
>> >> tlb_size = nslabs << IO_TLB_SHIFT;
>> >> - while (!(tlb = swiotlb_alloc_tlb(dev, tlb_size, phys_limit, gfp))) {
>> >> + while (!(tlb = swiotlb_alloc_tlb(dev, tlb_size, phys_limit, attrs, gfp))) {
>> >> if (nslabs <= minslabs)
>> >> goto error_tlb;
>> >> nslabs = ALIGN(nslabs >> 1, IO_TLB_SEGSIZE);
>> >> @@ -724,7 +744,8 @@ static struct io_tlb_pool *swiotlb_alloc_pool(struct device *dev,
>> >> return pool;
>> >>
>> >> error_slots:
>> >> - swiotlb_free_tlb(page_address(tlb), tlb_size);
>> >> + swiotlb_free_tlb(page_address(tlb), tlb_size,
>> >> + !!(attrs & DMA_ATTR_CC_SHARED));
>> >> error_tlb:
>> >> kfree(pool);
>> >> error:
>> >> @@ -742,7 +763,9 @@ static void swiotlb_dyn_alloc(struct work_struct *work)
>> >> struct io_tlb_pool *pool;
>> >>
>> >> pool = swiotlb_alloc_pool(NULL, IO_TLB_MIN_SLABS, default_nslabs,
>> >> - default_nareas, mem->phys_limit, GFP_KERNEL);
>> >> + default_nareas, mem->phys_limit,
>> >> + mem->unencrypted ? DMA_ATTR_CC_SHARED : 0,
>> >> + GFP_KERNEL);
>> >> if (!pool) {
>> >> pr_warn_ratelimited("Failed to allocate new pool");
>> >> return;
>> >> @@ -762,7 +785,7 @@ static void swiotlb_dyn_free(struct rcu_head *rcu)
>> >> size_t tlb_size = pool->end - pool->start;
>> >>
>> >> free_pages((unsigned long)pool->slots, get_order(slots_size));
>> >> - swiotlb_free_tlb(pool->vaddr, tlb_size);
>> >> + swiotlb_free_tlb(pool->vaddr, tlb_size, pool->unencrypted);
>> >> kfree(pool);
>> >> }
>> >>
>> >> @@ -1232,6 +1255,7 @@ static int swiotlb_find_slots(struct device *dev, phys_addr_t orig_addr,
>> >> nslabs = nr_slots(alloc_size);
>> >> phys_limit = min_not_zero(*dev->dma_mask, dev->bus_dma_limit);
>> >> pool = swiotlb_alloc_pool(dev, nslabs, nslabs, 1, phys_limit,
>> >> + mem->unencrypted ? DMA_ATTR_CC_SHARED : 0,
>> >> GFP_NOWAIT);
>> >> if (!pool)
>> >> return -1;
>> >> @@ -1394,6 +1418,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr,
>> >> enum dma_data_direction dir, unsigned long attrs)
>> >> {
>> >> struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
>> >> + bool require_decrypted = false;
>> >> unsigned int offset;
>> >> struct io_tlb_pool *pool;
>> >> unsigned int i;
>> >> @@ -1411,6 +1436,16 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr,
>> >> if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> >> pr_warn_once("Memory encryption is active and system is using DMA bounce buffers\n");
>> >>
>> >> + /*
>> >> + * if we are trying to swiotlb map a decrypted paddr or the paddr is encrypted
>> >> + * but the device is forcing decryption, use decrypted io_tlb_mem
>> >> + */
>> >> + if ((attrs & DMA_ATTR_CC_SHARED) || force_dma_unencrypted(dev))
>> >> + require_decrypted = true;
>> >> +
>> >> + if (require_decrypted != mem->unencrypted)
>> >> + return (phys_addr_t)DMA_MAPPING_ERROR;
>> >> +
>> >> /*
>> >> * The default swiotlb memory pool is allocated with PAGE_SIZE
>> >> * alignment. If a mapping is requested with larger alignment,
>> >> @@ -1608,8 +1643,14 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t paddr, size_t size,
>> >> if (swiotlb_addr == (phys_addr_t)DMA_MAPPING_ERROR)
>> >> return DMA_MAPPING_ERROR;
>> >>
>> >> - /* Ensure that the address returned is DMA'ble */
>> >> - dma_addr = phys_to_dma_unencrypted(dev, swiotlb_addr);
>> >> + /*
>> >> + * Use the allocated io_tlb_mem encryption type to determine dma addr.
>> >> + */
>> >> + if (dev->dma_io_tlb_mem->unencrypted)
>> >> + dma_addr = phys_to_dma_unencrypted(dev, swiotlb_addr);
>> >> + else
>> >> + dma_addr = phys_to_dma_encrypted(dev, swiotlb_addr);
>> >> +
>> >> if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
>> >> __swiotlb_tbl_unmap_single(dev, swiotlb_addr, size, dir,
>> >> attrs | DMA_ATTR_SKIP_CPU_SYNC,
>> >> @@ -1773,7 +1814,8 @@ static inline void swiotlb_create_debugfs_files(struct io_tlb_mem *mem,
>> >>
>> >> #ifdef CONFIG_DMA_RESTRICTED_POOL
>> >>
>> >> -struct page *swiotlb_alloc(struct device *dev, size_t size)
>> >> +struct page *swiotlb_alloc(struct device *dev, size_t size,
>> >> + unsigned long attrs)
>> >> {
>> >> struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
>> >> struct io_tlb_pool *pool;
>> >> @@ -1784,6 +1826,9 @@ struct page *swiotlb_alloc(struct device *dev, size_t size)
>> >> if (!mem)
>> >> return NULL;
>> >>
>> >> + if (mem->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED))
>> >> + return NULL;
>> >> +
>> >> align = (1 << (get_order(size) + PAGE_SHIFT)) - 1;
>> >> index = swiotlb_find_slots(dev, 0, size, align, &pool);
>> >> if (index == -1)
>> >> @@ -1853,9 +1898,18 @@ static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
>> >> kfree(mem);
>> >> return -ENOMEM;
>> >> }
>> >> + /*
>> >> + * if platform supports memory encryption,
>> >> + * restricted mem pool is decrypted by default
>> >> + */
>> >> + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
>> >> + mem->unencrypted = true;
>> >> + set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
>> >> + rmem->size >> PAGE_SHIFT);
>> >> + } else {
>> >> + mem->unencrypted = false;
>> >> + }
>> >
>> > This breaks pKVM as it doesn’t set CC_ATTR_MEM_ENCRYPT, so all virtio
>> > traffic now fails.
>> >
>> > Also, by design, some drivers are clueless about bouncing, so
>> > I believe that the pool should have a way to control it’s property
>> > (encrypted or decrypted) and that takes priority over whatever
>> > attributes comes from allocation.
>> > And that brings us to the same point whether it’s better to return
>> > the memory along with it’s state or we pass the requested state.
>> > I think for other cases it’s fine for the device/DMA-API to dictate
>> > the attrs, but not in restricted-dma case, the firmware just knows better.
>> >
>>
>> Is it that the pKVM guest kernel does not have awareness of
>> encrypted/decrypted DMA allocations? Instead, the firmware attaches
>> hypervisor-shared pages to the device via restricted-dma-pool? The
>> kernel then has swiotlb->for_alloc = true, and hence all DMA allocations
>> go through the restricted-dma-pool?
>
> Yes.
>
>>
>> Given that pKVM supports pkvm_set_memory_encrypted() and
>> pkvm_set_memory_decrypted(), can we consider adding CC_ATTR_MEM_ENCRYPT
>> support to pKVM? It would also be good to investigate whether we can set
>> force_dma_unencrypted(dev) to true where needed.
>
> I was looking in to that, but it didn't work because
> force_dma_unencrypted() is broken with restricted-dma due to the
> double decryption issue, that's when I sent my first series [1]
>
> May be we should land some basic fixes for that path so we can
> convert pKVM, then we do the full rework.
>
> I will revive my old work and see if I can send a RFC.
>
> [1] https://lore.kernel.org/all/20260305170335.963568-1-smostafa@google.com/
>
With this series, can you check whether the only change needed is
something like the following?
modified kernel/dma/swiotlb.c
@@ -1905,7 +1905,8 @@ static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
* if platform supports memory encryption,
* restricted mem pool is decrypted by default
*/
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
+ //if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
+ if (true) {
mem->unencrypted = true;
set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
rmem->size >> PAGE_SHIFT);
>
>>
>> I agree that this patch, as it stands, can break pKVM because we are now
>> missing the set_memory_decrypted() call required for pKVM to work.
>>
>> We now mark the swiotlb io_tlb_mem as unencrypted/encrypted in the guest
>> using struct io_tlb_mem->unencrypted. I am not clear what we can use for
>> pKVM to conditionalize this so that it works for both protected and
>> unprotected guests.
>
> There is no problem with non-protected guests as they don't use memory
> encryption, my initial thought was that th encrpyted/decrypted is
> per-pool property which is decided by FW (device-tree).
>
What I meant was that we need a generic way to identify a pKVM guest, so
that we can use it in the conditional above.
-aneesh
^ permalink raw reply
* Re: [PATCH v5 0/3] Switch Arm CCA to use an auxiliary device instead of a platform device
From: Greg KH @ 2026-05-14 12:45 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland,
Sudeep Holla, Will Deacon, Steven Price, Suzuki K Poulose
In-Reply-To: <yq5ase7u5kmz.fsf@kernel.org>
On Thu, May 14, 2026 at 04:21:48PM +0530, Aneesh Kumar K.V wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
> > On Thu, May 14, 2026 at 03:10:27PM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> As discussed here:
> >> https://lore.kernel.org/all/20250728135216.48084-12-aneesh.kumar@kernel.org
> >>
> >> The general feedback was that a platform device should not be used when
> >> there is no underlying platform resource to represent. The existing CCA
> >> support uses a platform device solely to anchor the TSM interface in the
> >> device hierarchy, which is not an appropriate use of a platform device.
> >> Use an auxiliary device instead to track CCA support.
> >
> > Why an aux device? If this has no platform resources, please use the
> > faux bus support instead, that is what it is there for. aux devices are
> > used when you are sharing a real resource among different "child"
> > drivers, and need some way to coordinate that sharing. If you have no
> > resources, there's nothing to share, so no need for the complexity that
> > aux gives you, just use faux instead.
> >
>
> We did discuss between faux an auxiliary devices early here
> https://lore.kernel.org/all/20251010135922.GC3833649@ziepe.ca
>
> To summarize auxiliary device was choosen so that we can do module
> autoloading.
That's not a valid reason to use the aux driver, sorry. If you have
hardware that triggers an auto-module-load, then this is really a
hardware driver. If it is a "virtual" driver like this, then you need
to explicitly load it on your own. Don't abuse apis for reasons that
they are not designed for.
thanks,
greg k-h
^ 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