* [PATCH v2 3/3] arm64: dts: allwinner: a523: Add missing GPIO interrupt
From: Andre Przywara @ 2026-03-27 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-1-andre.przywara@arm.com>
Even though the Allwinner A523 SoC implements 10 GPIO banks, it has
actually registers for 11 IRQ banks, and even an interrupt assigned to
the first, non-implemented IRQ bank.
Add that first interrupt to the list of GPIO interrupts, to correct the
association between IRQs and GPIO banks.
This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by
broken SD card detect functionality, for instance.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fixes: 35ac96f79664 ("arm64: dts: allwinner: Add Allwinner A523 .dtsi file")
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
---
arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
index 9335977751e2..cea5b166c00f 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
@@ -128,7 +128,8 @@ gpu: gpu@1800000 {
pio: pinctrl@2000000 {
compatible = "allwinner,sun55i-a523-pinctrl";
reg = <0x2000000 0x800>;
- interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
From: Andre Przywara @ 2026-03-27 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-1-andre.przywara@arm.com>
The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
that line is muxed for IRQ triggering (muxval 6), but only if it's
explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
behaviour, so we added a optional workaround, triggered by a quirk bit,
which triggers remuxing the pin when it's configured for IRQ, while we
need to read its value.
For some reasons this quirk flag was copied over to newer SoCs, even
though they don't show this behaviour, and the GPIO data register
reflects the true GPIO state even with a pin muxed to IRQ trigger.
Remove the unneeded quirk from the A523 family, where it's definitely
not needed (confirmed by experiments), and where it actually breaks,
because the workaround is not compatible with the newer generation
pinctrl IP used in that chip.
Together with a DT change this fixes GPIO IRQ operation on the A523
family of SoCs, as for instance used for the SD card detection.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
---
drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
index 69cd2b4ebd7d..462aa1c4a5fa 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
@@ -26,7 +26,6 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
.irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
.irq_bank_map = a523_r_irq_bank_map,
- .irq_read_needs_mux = true,
.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
.pin_base = PL_BASE,
};
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
index 7d2308c37d29..b6f78f1f30ac 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
@@ -26,7 +26,6 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
static struct sunxi_pinctrl_desc a523_pinctrl_data = {
.irq_banks = ARRAY_SIZE(a523_irq_bank_map),
.irq_bank_map = a523_irq_bank_map,
- .irq_read_needs_mux = true,
.io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] pinctrl: sunxi: a523: fix GPIO IRQ operation
From: Andre Przywara @ 2026-03-27 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Hi,
this is the minimal fix version for the GPIO IRQ operation on the
Allwinner A523/A527/T527 SoCs. SD card detection is broken as a result,
which is a major annoyance. Those patches here fix that problem, and
should go into v7.0 still, if possible.
I dropped the more involved fixes from v1, the risk for regressions is
now very low:
- The quirk flag is just dropped from the A523, not the other SoCs. I
confirmed this again with an experiment, for both the primary and
secondary pincontroller. This avoids fixing the workaround code for
now, which is more involved, but for now unneeded.
- The DT patch just adds the missing interrupt. The IRQ association was
always wrong and never worked, so this can't make it possibly worse.
Together those two patches (plus the required binding change) fix the
problem, I would appreciate if this could be taken ASAP, into v7.0 still.
The generic pinctrl code is now untouched, which makes this also much
easier to backport, and drops the dependencies on other v7.0-rc fixes.
Bases on v7.0-rc1, but applies on later revisions as well.
Please have a look and test, especially on A523/A527/T527 boards!
Changelog v1 .. v2:
- drop generic pinctrl fixes (for now)
- drop quirk removal from other SoCs (for now)
- add Chen-Yu's tag
Cheers,
Andre
Andre Przywara (3):
pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
arm64: dts: allwinner: a523: Add missing GPIO interrupt
.../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 3 ++-
drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
4 files changed, 6 insertions(+), 7 deletions(-)
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
--
2.43.0
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Vladimir Oltean @ 2026-03-27 11:28 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <gq4sswslkjaoe5hhxe2mz6z57uiumotqknkryadvfsstj4srx4@qgenqekgrqv4>
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
On Fri, Mar 27, 2026 at 12:22:46PM +0530, Manivannan Sadhasivam wrote:
> I tested the patch. But it fails ufs_qcom_power_up_sequence() if PHY was already
> powered on:
>
> [ 31.513321] qcom-qmp-ufs-phy 1d87000.phy: phy initialization timed-out
> [ 31.513335] ufshcd-qcom 1d84000.ufshc: Failed to calibrate PHY: -110
> [ 31.565273] ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
>
> Funny thing is, it didn't affect the functionality since the UFS core retries
> ufshcd_hba_enable() and in the error path of ufs_qcom_power_up_sequence(),
> phy_power_off() gets called and that causes the next try to succeed. So it is
> evident that, if PHY was already powered ON, it should be powered off before
> ufs_qcom_phy_power_on(). And due to the UFS driver design,
> ufs_qcom_power_up_sequence() can get called multiple times. So we cannot just
> remove phy_power_off().
>
> Below diff on top of your patch fixes the issue:
>
> ```
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index ed067247d72a..2c9fe03f349e 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -567,6 +567,8 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> if (ret)
> return ret;
>
> + ufs_qcom_phy_power_off(host);
> +
> ret = ufs_qcom_phy_set_gear(host, mode);
> if (ret) {
> dev_err(hba->dev, "%s: phy_set_mode_ext() failed, ret = %d\n",
> ```
>
> - Mani
Understood. Thanks for testing.
I'm still not satisfied with this level of complexity. If I get you
right, ufs_qcom_phy_power_off() is still needed because phy_calibrate()
expects a "fresh after power on" state, otherwise it fails? That would
be the second reason, apart from the first one I already identified
(undo a phy_power_on() done prior to phy_init()).
If so, could you please test the 3 patches attached (no relationship
with anything else we've exchanged thus far)?
[-- Attachment #2: 0001-phy-qcom-qmp-ufs-support-dynamic-gear-changing.patch --]
[-- Type: text/x-diff, Size: 2013 bytes --]
From 2d42c2d40e6ddfd0c73fc39601f93f7b81a42401 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 27 Mar 2026 12:41:00 +0200
Subject: [PATCH 1/3] phy: qcom-qmp-ufs: support dynamic gear changing
Currently, phy_set_mode_ext() on the QMP UFS PHY expects the PHY to be
powered down, and it makes no change to the hardware state, instead
phy_power_on() followed by phy_calibrate() must be run afterwards.
"Order of API calls" from Documentation/driver-api/phy/phy.rst has a
roundabout and not really clear way of saying that both calling
sequences should be supported. This was further discussed here,
documentation is pending an update:
https://lore.kernel.org/linux-phy/E1vo0mF-00000007kbg-1OeA@rmk-PC.armlinux.org.uk/
By absorbing the phy_power_off() -> ... -> phy_power_on() ->
phy_configure() surrounding sequence into phy_set_mode_ext(), consumer
drivers can be greatly simplified, and we also have a proper
self-standing phy_set_mode_ext() implementation which does not rely on
other calls to do its job.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
index df138a5442eb..e75b059bf246 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
@@ -2004,15 +2004,24 @@ static int qmp_ufs_set_mode(struct phy *phy, enum phy_mode mode, int submode)
{
struct qmp_ufs *qmp = phy_get_drvdata(phy);
const struct qmp_phy_cfg *cfg = qmp->cfg;
+ bool powered_on = phy->power_count;
if (submode > cfg->max_supported_gear || submode == 0) {
dev_err(qmp->dev, "Invalid PHY submode %d\n", submode);
return -EINVAL;
}
+ if (powered_on)
+ qmp_ufs_power_off(phy);
+
qmp->mode = mode;
qmp->submode = submode;
+ if (powered_on) {
+ qmp_ufs_power_on(phy);
+ return qmp_ufs_phy_calibrate(phy);
+ }
+
return 0;
}
--
2.34.1
[-- Attachment #3: 0002-scsi-ufs-qcom-call-phy_init-before-phy_power_on.patch --]
[-- Type: text/x-diff, Size: 3707 bytes --]
From 8d156781d38597865da37a86417f553143d74eaa Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 27 Mar 2026 13:14:39 +0200
Subject: [PATCH 2/3] scsi: ufs: qcom: call phy_init() before phy_power_on()
The Qualcomm UFS host controller driver violates the Generic PHY API
expectation, documented in section "Order of API calls" from
Documentation/driver-api/phy/phy.rst, and then tries to hide it.
The expectation is that calls must be made in the phy_init() ->
phy_power_on() -> phy_power_off() -> phy_exit() sequence.
What we actually have is:
ufshcd_init()
-> ufshcd_hba_init()
-> ufshcd_setup_clocks(hba, true)
-> ufshcd_vops_setup_clocks(hba, true, POST_CHANGE)
-> ufs_qcom_setup_clocks(hba, true, POST_CHANGE)
-> phy_power_on(phy)
-> ufshcd_variant_hba_init()
-> ufs_qcom_init()
-> ufs_qcom_setup_clocks(hba, true, POST_CHANGE)
-> phy_power_on(phy)
-> ufshcd_hba_enable()
-> ufshcd_vops_hce_enable_notify()
-> ufs_qcom_hce_enable_notify()
-> ufs_qcom_power_up_sequence()
-> if (phy->power_count) phy_power_off(phy)
-> phy_init(phy)
This "works" because the way that the "phy_power_on was called before
phy_init\n" condition is detected in phy-core.c is if the power_count is
positive at the phy_init() call time.
By having that "if (phy->power_count) phy_power_off(phy)" logic, the
ufs-qcom.c technically sidesteps the test, but actually violates the
Generic PHY API even more (calls phy_power_on() *and* phy_power_off()
before phy_init()).
The reason why I stumbled upon this was that I was trying to remove
dereferences of phy->power_count from drivers. This is a PHY-internal
field, and using it from drivers is highly likely to be incorrect, as
this case showcases rather well.
As commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls") shows, this driver tries to couple the PHY power state with the
HBA clocks, for power saving reasons. I won't try to change that, I will
just move the phy_init() call earlier, to ufs_qcom_init().
After the phy_init() movement, ufs_qcom_power_up_sequence() should no
longer need to do either phy_init() nor the conditional phy_power_off().
However, phy_power_off() is still needed, for a separate reason which
will be dealt with separately.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Nitin Rawat <quic_nitirawa@quicinc.com>
v5->v6: rewrite after actually understanding the core issue
v4->v5: patch is new
---
drivers/ufs/host/ufs-qcom.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 375fd24ba458..ffa70c6c7143 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -513,13 +513,6 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
/* phy initialization - calibrate the phy */
- ret = phy_init(phy);
- if (ret) {
- dev_err(hba->dev, "%s: phy init failed, ret = %d\n",
- __func__, ret);
- return ret;
- }
-
ret = phy_set_mode_ext(phy, mode, host->phy_gear);
if (ret)
goto out_disable_phy;
@@ -1441,6 +1434,13 @@ static int ufs_qcom_init(struct ufs_hba *hba)
if (err)
goto out_variant_clear;
+ err = phy_init(host->generic_phy);
+ if (err) {
+ dev_err(hba->dev, "%s: phy_init failed, ret = %d\n",
+ __func__, err);
+ goto out_variant_clear;
+ }
+
ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
ufs_qcom_get_default_testbus_cfg(host);
--
2.34.1
[-- Attachment #4: 0003-scsi-ufs-qcom-make-use-of-QMP-PHY-dynamic-gear-switc.patch --]
[-- Type: text/x-diff, Size: 1696 bytes --]
From 88f4bdfee770cd433a940a14e318d8c8b5dfa516 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 27 Mar 2026 13:18:05 +0200
Subject: [PATCH 3/3] scsi: ufs: qcom: make use of QMP PHY dynamic gear
switching ability
The QMP UFS PHY can now tolerate having phy_set_mode_ext() being called
while the PHY is powered up. We no longer need to power it down, back up
and calibrate it.
Simplify ufs_qcom_power_up_sequence() by relying on just phy_set_mode_ext()
and let PHY power management be handled just by ufs_qcom_setup_clocks().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/ufs/host/ufs-qcom.c | 25 +------------------------
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index ffa70c6c7143..cf7b67f2021e 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -508,37 +508,14 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
if (ret)
return ret;
- if (phy->power_count)
- phy_power_off(phy);
-
-
/* phy initialization - calibrate the phy */
ret = phy_set_mode_ext(phy, mode, host->phy_gear);
if (ret)
- goto out_disable_phy;
-
- /* power on phy - start serdes and phy's power and clocks */
- ret = phy_power_on(phy);
- if (ret) {
- dev_err(hba->dev, "%s: phy power on failed, ret = %d\n",
- __func__, ret);
- goto out_disable_phy;
- }
-
- ret = phy_calibrate(phy);
- if (ret) {
- dev_err(hba->dev, "Failed to calibrate PHY: %d\n", ret);
- goto out_disable_phy;
- }
+ return ret;
ufs_qcom_select_unipro_mode(host);
return 0;
-
-out_disable_phy:
- phy_exit(phy);
-
- return ret;
}
/*
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] arm64: defconfig: Enable pinctrl/gpio/pcie for CIX Sky1 SoC
From: Krzysztof Kozlowski @ 2026-03-27 11:21 UTC (permalink / raw)
To: Peter Chen
Cc: arnd, geert+renesas, linux-kernel, linux-arm-kernel,
cix-kernel-upstream, Yunseong Kim
In-Reply-To: <acZmPUIHwJhJNT4x@nchen-desktop>
On 27/03/2026 12:13, Peter Chen wrote:
> On 26-03-27 11:22:33, Krzysztof Kozlowski wrote:
>
> Krzysztof, thanks for reviewing.
>
>>> Pinctrl, PCIe, and GPIO device are used at Radxa Orion O6 board.
>>> - Pinctrl is the base for peripheral IP and peripheral device.
>>> - PCIe NVMe is needed for Debian boot.
>>
>> I don't see NVMe there, only PCI controller.
>>
>>> - GPIO is added due to Debian bug report[1].
>>
>> Rationale must be here, not in external references - this explicitly
>> requested in submitting patches.
>>
>> This entire Debian reference does not really matter. It is enough to
>> explain what hardware you are enabling it for, so the board, its
>> contents, and SoC.
>>
>> This is as simple as - does board use it or not? Does SoC with this
>> board has it or not?
>
>
> So, I just only keep the below summary, is it right?
>
> Pinctrl, PCIe, and GPIO device are used at Radxa Orion O6 board which Sky1
> SoC is on it.
Which pinctrl? Which PCIe? Which GPIO device? Read it again and follow
its meaning and tell me if following understanding is correct:
"Pinctrl is used on Radxa Orion O6 board which Sky1 therefore I enable
Pinctrl Samsung".
Did you look at existing history for this type of changes? This is
triviality so I don't understand why we keep bugging for that simple
answer to describe WHY you are doing something.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: defconfig: Enable pinctrl/gpio/pcie for CIX Sky1 SoC
From: Peter Chen @ 2026-03-27 11:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arnd, geert+renesas, linux-kernel, linux-arm-kernel,
cix-kernel-upstream, Yunseong Kim
In-Reply-To: <55875ef5-7959-454e-b071-c9f5c6f87bc0@oss.qualcomm.com>
On 26-03-27 11:22:33, Krzysztof Kozlowski wrote:
Krzysztof, thanks for reviewing.
> > Pinctrl, PCIe, and GPIO device are used at Radxa Orion O6 board.
> > - Pinctrl is the base for peripheral IP and peripheral device.
> > - PCIe NVMe is needed for Debian boot.
>
> I don't see NVMe there, only PCI controller.
>
> > - GPIO is added due to Debian bug report[1].
>
> Rationale must be here, not in external references - this explicitly
> requested in submitting patches.
>
> This entire Debian reference does not really matter. It is enough to
> explain what hardware you are enabling it for, so the board, its
> contents, and SoC.
>
> This is as simple as - does board use it or not? Does SoC with this
> board has it or not?
So, I just only keep the below summary, is it right?
Pinctrl, PCIe, and GPIO device are used at Radxa Orion O6 board which Sky1
SoC is on it.
Peter
>
>
> Best regards,
> Krzysztof
--
Best regards,
Peter
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Krzysztof Kozlowski @ 2026-03-27 10:59 UTC (permalink / raw)
To: Padmashree S S, andrew, gregory.clement, sebastian.hesselbarth
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260327104344.578113-1-padmashreess2006@gmail.com>
On 27/03/2026 11:43, Padmashree S S wrote:
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
Please slow down. You already received review and you should carefully
read it. Otherwise you keep repeating the same mistakes.
How did you address my existing review? Or you just intend to ignore it?
> ---
> .../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
> .../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
I doubt that your previous two postings were reviewed before by the GSoC
mentors.
One of your patches did not even build test.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'
From: Ben Horgan @ 2026-03-27 10:47 UTC (permalink / raw)
To: Qinxin Xia
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, xhao, zengheng4, Linuxarm
In-Reply-To: <d13fdc75-b647-44f3-9657-d592353e8a1a@huawei.com>
Hi Qinxin,
On 3/27/26 10:21, Qinxin Xia wrote:
>
> Hello everyone!
>
> In earlier versions, mpam supports the configuration of iommu_groups.
>
> 823 static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
> 824 char *buf, size_t nbytes,
> loff_t off)
> 825 {
> 826 struct rdtgroup *rdtgrp;
> 827 int iommu_group_id;
> 828 bool is_iommu;
> 829 char *pid_str;
> 830 int ret = 0;
> 831 pid_t pid;
> 832
> 833 rdtgrp = rdtgroup_kn_lock_live(of->kn);
> 834 if (!rdtgrp) {
> 835 rdtgroup_kn_unlock(of->kn);
> 836 return -ENOENT;
> 837 }
> 838 rdt_last_cmd_clear();
> 839
> 840 if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
> 841 rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
> 842 ret = -EINVAL;
> 843 rdt_last_cmd_puts("Pseudo-locking in progress\n");
> 844 goto unlock;
> 845 }
> 846
> 847 while (buf && buf[0] != '\0' && buf[0] != '\n') {
> 848 pid_str = strim(strsep(&buf, ","));
> 849
> 850 is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
>
> What puzzles me is why we would put it under 'task'—this seems a little
> strange to users.It seems they are not related.Why don't we add a new
> interface like 'iommu'?
I think it is likely that this interface would change if upstream support is added.
>
> 851 if (is_iommu)
> 852 ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
> 853 else if (kstrtoint(pid_str, 0, &pid)) {
> 854 rdt_last_cmd_printf("Task list parsing error pid %s\n", pid_str);
> 855 ret = -EINVAL;
> 856 break;
> 857 }
> 858
> 859 if (pid < 0) {
> 860 rdt_last_cmd_printf("Invalid pid %d\n", pid);
> 861 ret = -EINVAL;
> 862 break;
> 863 }
> 864
>
> In future glue versions, will you re-enable support for iommu_group, and
> if so, will the configuration scheme be changed?
Please can you let us know about your usecase so that we can get more information to decide
what the best interface would be?
Thanks,
Ben
^ permalink raw reply
* [PATCH] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Padmashree S S @ 2026-03-27 10:43 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, devicetree,
linux-kernel, Padmashree S S
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
.../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
.../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
deleted file mode 100644
index 8781073029e9..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Marvell Armada 38x CA9 MPcore SoC Controller
-============================================
-
-Required properties:
-
-- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
-
-- reg: should be the register base and length as documented in the
- datasheet for the CA9 MPcore SoC Control registers
-
-mpcore-soc-ctrl@20d20 {
- compatible = "marvell,armada-380-mpcore-soc-ctrl";
- reg = <0x20d20 0x6c>;
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
new file mode 100644
index 000000000000..a897d4ba4e32
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-380-mpcore-soc-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x CA9 MPcore SoC Controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+properties:
+ compatible:
+ const: marvell,armada-380-mpcore-soc-ctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ mpcore-soc-ctrl@20d20 {
+ compatible = "marvell,armada-380-mpcore-soc-ctrl";
+ reg = <0x20d20 0x6c>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
From: David CARLIER @ 2026-03-27 10:39 UTC (permalink / raw)
To: Simon Horman
Cc: danishanwar, rogerq, andrew+netdev, davem, edumazet, kuba, pabeni,
m-malladi, jacob.e.keller, linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260327102924.GF111839@horms.kernel.org>
Hi Simon and thanks for the feedback, will keep this in mind. Cheers !
On Fri, 27 Mar 2026 at 10:29, Simon Horman <horms@kernel.org> wrote:
>
> + Meghana Malladi
>
> On Wed, Mar 25, 2026 at 12:51:30PM +0000, David Carlier wrote:
> > emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
> > never copies the packet data from the XDP buffer into it. The skb is
> > passed up the stack containing uninitialized heap memory instead of
> > the actual received packet, leaking kernel heap contents to userspace.
> >
> > Copy the received packet data from the XDP buffer into the skb using
> > skb_copy_to_linear_data().
> >
> > Additionally, remove the skb_mark_for_recycle() call since the skb is
> > backed by the NAPI page frag allocator, not page_pool. Marking a
> > non-page_pool skb for recycle causes the free path to return pages to
> > a page_pool that does not own them, corrupting page_pool state.
> >
> > The non-ZC path (emac_rx_packet) does not have these issues because it
> > uses napi_build_skb() to wrap the existing page_pool page directly,
> > requiring no copy, and correctly marks for recycle since the page comes
> > from page_pool_dev_alloc_pages().
> >
> > Fixes: 7a64bb388df3 ("net: ti: icssg-prueth: Add AF_XDP zero copy for RX")
> > Signed-off-by: David Carlier <devnexen@gmail.com>
> > ---
> > drivers/net/ethernet/ti/icssg/icssg_common.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Hi David,
>
> Thanks for the update.
> My understanding is that this addresses the review of v1.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> v1: https://lore.kernel.org/all/20260324211402.342474-1-devnexen@gmail.com/
>
> Some points to keep in mind for the future:
>
> * Please include a version number in the subject when posting versions >
> This helps a lot in tracking things.
>
> Subject: [PATCH v2] ...
>
> * Please include the target tree. As a fix for code, which I asusme
> is present in net, in this case that would be the net tree.
>
> Subject: [PATCH net v2] ...
>
> Otherwise it would probably be the net-next tree.
>
> * Please CC all relevant parties. In this case that would
> include Meghana as he provided review of v1.
>
> * Please consider including a changelog, along with links to earlier
> versions below the scissors ("---")
>
> * b4 can help with most of these things
>
> * More information on the Netdev development process can be found at
> https://docs.kernel.org/process/maintainer-netdev.html
>
> ...
^ permalink raw reply
* Re: [PATCH] net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
From: Simon Horman @ 2026-03-27 10:29 UTC (permalink / raw)
To: David Carlier
Cc: danishanwar, rogerq, andrew+netdev, davem, edumazet, kuba, pabeni,
m-malladi, jacob.e.keller, linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260325125131.53399-1-devnexen@gmail.com>
+ Meghana Malladi
On Wed, Mar 25, 2026 at 12:51:30PM +0000, David Carlier wrote:
> emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
> never copies the packet data from the XDP buffer into it. The skb is
> passed up the stack containing uninitialized heap memory instead of
> the actual received packet, leaking kernel heap contents to userspace.
>
> Copy the received packet data from the XDP buffer into the skb using
> skb_copy_to_linear_data().
>
> Additionally, remove the skb_mark_for_recycle() call since the skb is
> backed by the NAPI page frag allocator, not page_pool. Marking a
> non-page_pool skb for recycle causes the free path to return pages to
> a page_pool that does not own them, corrupting page_pool state.
>
> The non-ZC path (emac_rx_packet) does not have these issues because it
> uses napi_build_skb() to wrap the existing page_pool page directly,
> requiring no copy, and correctly marks for recycle since the page comes
> from page_pool_dev_alloc_pages().
>
> Fixes: 7a64bb388df3 ("net: ti: icssg-prueth: Add AF_XDP zero copy for RX")
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
> drivers/net/ethernet/ti/icssg/icssg_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi David,
Thanks for the update.
My understanding is that this addresses the review of v1.
Reviewed-by: Simon Horman <horms@kernel.org>
v1: https://lore.kernel.org/all/20260324211402.342474-1-devnexen@gmail.com/
Some points to keep in mind for the future:
* Please include a version number in the subject when posting versions >
This helps a lot in tracking things.
Subject: [PATCH v2] ...
* Please include the target tree. As a fix for code, which I asusme
is present in net, in this case that would be the net tree.
Subject: [PATCH net v2] ...
Otherwise it would probably be the net-next tree.
* Please CC all relevant parties. In this case that would
include Meghana as he provided review of v1.
* Please consider including a changelog, along with links to earlier
versions below the scissors ("---")
* b4 can help with most of these things
* More information on the Netdev development process can be found at
https://docs.kernel.org/process/maintainer-netdev.html
...
^ permalink raw reply
* Re: [PATCH 00/10] PCI: Improve head free space usage
From: Ilpo Järvinen @ 2026-03-27 10:28 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, LKML, Xifer
In-Reply-To: <20260326192520.GA1337681@bhelgaas>
[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]
On Thu, 26 Mar 2026, Bjorn Helgaas wrote:
> [+cc Xifer; thanks very much for reporting and testing!]
>
> On Tue, Mar 24, 2026 at 06:56:23PM +0200, Ilpo Järvinen wrote:
> > Hi all,
> >
> > This series attempts to take advantage of free head space (the free
> > space before the aligned start address) in order to generally produce a
> > tighter packing of the resources/bridge windows.
> >
> > The recent changes to the resource fitting algorithm caused resource
> > allocation failures in some cases where a bridge window that is sized
> > to be gapless could no longer be assigned. The previous algorithm left
> > a huge gaps which allowed it to place the remainder (non-aligning part
> > of the size) before the start address of used for the gapless fit,
> > whereas the new gapless approach always had to place the remainder
> > after the aligning part of the resources. There is not always space
> > for the remainder triggering those failures (e.g., when the aligning
> > part must be placed at the top of the window).
> >
> > This series attempts to allow placing the remainder once again before
> > the aligning part, but now without leaving huge gaps to retain the
> > benefits of the gapless bridge windows. The approach is somewhat hacky
> > but should work thanks to PCI resources fundamentally consisting only
> > power-of-two atoms.
> >
> > There maybe cases where architecture would not want to do such
> > relocation. This series adds the relocation to arch
> > pcibios_align_resource() functions to allow all of them taking
> > advantage of the better resource packing but if somebody objects doing
> > this relocation for a particular arch, I can remove it, please just let
> > me know (this relocation doesn't seem critical unless there are
> > regressions).
> >
> > Ilpo Järvinen (10):
> > resource: Add __resource_contains_unbound() for internal contains
> > checks
> > resource: Pass full extent of empty space to resource_alignf CB
> > resource: Rename 'tmp' variable to 'full_avail'
> > ARM/PCI: Remove unnecessary second application of align
> > am68k/PCI: Remove unnecessary second application of align
> > MIPS: PCI: Remove unnecessary second application of align
> > parisc/PCI: Cleanup align handling
> > PCI: Rename window_alignment() to pci_min_window_alignment()
> > PCI: Align head space better
> > PCI: Fix alignment calculation for resource size larger than align
> >
> > arch/alpha/kernel/pci.c | 1 +
> > arch/arm/kernel/bios32.c | 9 ++++---
> > arch/m68k/kernel/pcibios.c | 8 +++++--
> > arch/mips/pci/pci-generic.c | 8 ++++---
> > arch/mips/pci/pci-legacy.c | 3 +++
> > arch/parisc/kernel/pci.c | 17 ++++++++------
> > arch/powerpc/kernel/pci-common.c | 6 ++++-
> > arch/s390/pci/pci.c | 1 +
> > arch/sh/drivers/pci/pci.c | 6 ++++-
> > arch/x86/pci/i386.c | 5 +++-
> > arch/xtensa/kernel/pci.c | 3 +++
> > drivers/pci/pci.h | 3 +++
> > drivers/pci/setup-bus.c | 15 ++++++++----
> > drivers/pci/setup-res.c | 40 +++++++++++++++++++++++++++++++-
> > drivers/pcmcia/rsrc_nonstatic.c | 3 ++-
> > include/linux/ioport.h | 22 +++++++++++++++---
> > include/linux/pci.h | 12 +++++++---
> > kernel/resource.c | 33 +++++++++++++-------------
> > 18 files changed, 149 insertions(+), 46 deletions(-)
>
> I added Xifer's tested-by, fixed the "am68k" and missing "if"
> typos, and applied these to pci/resource for v7.1.
>
> Ilpo, if you post a v2 with more changes, I'll update to it. I
> applied the series now to get a head start on 0-day building and into
> next.
Thanks.
I don't have anything in addition to those.
--
i.
^ permalink raw reply
* Re: [PATCH v2] arm64: defconfig: Enable Rockchip video decoder
From: Krzysztof Kozlowski @ 2026-03-27 10:25 UTC (permalink / raw)
To: Detlev Casanova, linux-kernel, Heiko Stuebner, linux-arm-kernel,
kernel, linux-rockchip
In-Reply-To: <20260326-rkvdec-add-defconfig-v2-1-d65c296da9ba@collabora.com>
On 26/03/2026 22:33, Detlev Casanova wrote:
> The rkvdec driver is now out of staging and can be built by default.
This is not a reason "why" we enable it. Many drivers are not in staging
and we do not enable them by default. With that explanation, why not
enable everything from allyesconfig? That "everything" can be built by
default and for example is out of staging. So why are we not making
allyesconfig->defconfig?
BTW, git log or lore/lei also would help you here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: defconfig: Enable pinctrl/gpio/pcie for CIX Sky1 SoC
From: Krzysztof Kozlowski @ 2026-03-27 10:22 UTC (permalink / raw)
To: Peter Chen, arnd
Cc: geert+renesas, linux-kernel, linux-arm-kernel,
cix-kernel-upstream, Yunseong Kim
In-Reply-To: <20260327095652.3793688-1-peter.chen@cixtech.com>
On 27/03/2026 10:56, Peter Chen wrote:
> Pinctrl, PCIe, and GPIO device are used at Radxa Orion O6 board.
> - Pinctrl is the base for peripheral IP and peripheral device.
> - PCIe NVMe is needed for Debian boot.
I don't see NVMe there, only PCI controller.
> - GPIO is added due to Debian bug report[1].
Rationale must be here, not in external references - this explicitly
requested in submitting patches.
This entire Debian reference does not really matter. It is enough to
explain what hardware you are enabling it for, so the board, its
contents, and SoC.
This is as simple as - does board use it or not? Does SoC with this
board has it or not?
Best regards,
Krzysztof
^ permalink raw reply
* [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'
From: Qinxin Xia @ 2026-03-27 10:21 UTC (permalink / raw)
To: ben.horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, xhao, zengheng4, Linuxarm
Hello everyone!
In earlier versions, mpam supports the configuration of iommu_groups.
823 static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
824 char *buf, size_t nbytes,
loff_t off)
825 {
826 struct rdtgroup *rdtgrp;
827 int iommu_group_id;
828 bool is_iommu;
829 char *pid_str;
830 int ret = 0;
831 pid_t pid;
832
833 rdtgrp = rdtgroup_kn_lock_live(of->kn);
834 if (!rdtgrp) {
835 rdtgroup_kn_unlock(of->kn);
836 return -ENOENT;
837 }
838 rdt_last_cmd_clear();
839
840 if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
841 rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
842 ret = -EINVAL;
843 rdt_last_cmd_puts("Pseudo-locking in progress\n");
844 goto unlock;
845 }
846
847 while (buf && buf[0] != '\0' && buf[0] != '\n') {
848 pid_str = strim(strsep(&buf, ","));
849
850 is_iommu = string_is_iommu_group(pid_str,
&iommu_group_id);
What puzzles me is why we would put it under 'task'—this seems a little
strange to users.It seems they are not related.Why don't we add a new
interface like 'iommu'?
851 if (is_iommu)
852 ret = rdtgroup_move_iommu(iommu_group_id,
rdtgrp, of);
853 else if (kstrtoint(pid_str, 0, &pid)) {
854 rdt_last_cmd_printf("Task list parsing
error pid %s\n", pid_str);
855 ret = -EINVAL;
856 break;
857 }
858
859 if (pid < 0) {
860 rdt_last_cmd_printf("Invalid pid %d\n", pid);
861 ret = -EINVAL;
862 break;
863 }
864
In future glue versions, will you re-enable support for iommu_group, and
if so, will the configuration scheme be changed?
--
Thanks,
Qinxin
^ permalink raw reply
* Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios
From: Baolin Wang @ 2026-03-27 10:20 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle)
Cc: David Hildenbrand (Arm), Barry Song, akpm, catalin.marinas, will,
lorenzo.stoakes, ryan.roberts, Liam.Howlett, vbabka, rppt, surenb,
mhocko, riel, harry.yoo, jannh, willy, dev.jain, linux-mm,
linux-arm-kernel, linux-kernel
In-Reply-To: <5b1c0687-a4e4-4a95-8e8f-2d2ce171247c@lucifer.local>
On 3/26/26 8:21 PM, Lorenzo Stoakes (Oracle) wrote:
> On Thu, Mar 26, 2026 at 08:04:10PM +0800, Baolin Wang wrote:
>>
>>
>> On 3/26/26 7:10 PM, Lorenzo Stoakes (Oracle) wrote:
>>> On Thu, Mar 26, 2026 at 09:47:51AM +0800, Baolin Wang wrote:
>>>>
>>>>
>>>> On 3/25/26 11:06 PM, Lorenzo Stoakes (Oracle) wrote:
>>>>> On Wed, Mar 25, 2026 at 03:58:36PM +0100, David Hildenbrand (Arm) wrote:
>>>>>> On 3/25/26 15:36, Lorenzo Stoakes (Oracle) wrote:
>>>>>>> On Mon, Mar 16, 2026 at 03:15:18PM +0100, David Hildenbrand (Arm) wrote:
>>>>>>>> On 3/16/26 07:25, Baolin Wang wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sure. However, after investigating RISC‑V and x86, I found that
>>>>>>>>> ptep_clear_flush_young() does not flush the TLB on these architectures:
>>>>>>>>>
>>>>>>>>> int ptep_clear_flush_young(struct vm_area_struct *vma,
>>>>>>>>> unsigned long address, pte_t *ptep)
>>>>>>>>> {
>>>>>>>>> /*
>>>>>>>>> * On x86 CPUs, clearing the accessed bit without a TLB flush
>>>>>>>>> * doesn't cause data corruption. [ It could cause incorrect
>>>>>>>>> * page aging and the (mistaken) reclaim of hot pages, but the
>>>>>>>>> * chance of that should be relatively low. ]
>>>>>>>>> *
>>>>>>>>> * So as a performance optimization don't flush the TLB when
>>>>>>>>> * clearing the accessed bit, it will eventually be flushed by
>>>>>>>>> * a context switch or a VM operation anyway. [ In the rare
>>>>>>>>> * event of it not getting flushed for a long time the delay
>>>>>>>>> * shouldn't really matter because there's no real memory
>>>>>>>>> * pressure for swapout to react to. ]
>>>>>>>>> */
>>>>>>>>> return ptep_test_and_clear_young(vma, address, ptep);
>>>>>>>>> }
>>>>>>>>
>>>>>>>> You'd probably want an arch helper then, that tells you whether
>>>>>>>> a flush_tlb_range() after ptep_test_and_clear_young() is required.
>>>>>>>>
>>>>>>>> Or some special flush_tlb_range() helper.
>>>>>>>>
>>>>>>>> I agree that it requires more work.
>>>>
>>>> (Sorry, David. I forgot to reply to your email because I've had a lot to
>>>> sort out recently.)
>>>>
>>>> Rather than adding more arch helpers (we already have plenty for the young
>>>> flag check), I think we should try removing the TLB flush, as I mentioned to
>>>> Barry[1]. MGLRU reclaim already skips the TLB flush, and it seems to work
>>>> fine. What do you think?
>>>>
>>>> Here are our previous attempts to remove the TLB flush:
>>>>
>>>> My patch: https://lkml.org/lkml/2023/10/24/533
>>>> Barry's patch:
>>>> https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@gmail.com/
>>>>
>>>> [1] https://lore.kernel.org/all/6bdc4b03-9631-4717-a3fa-2785a7930aba@linux.alibaba.com/
>>>>
>>>>>>> Sorry unclear here - does the series need more work or does a follow up patch
>>>>>>> need more work?
>>>>>>
>>>>>> Follow up!
>>>>>
>>>>> Ok good as in mm-stable now. Sadly means I don't get to review it but there we
>>>>> go.
>>>>
>>>> Actually this patchset has already been merged upstream:)
>>
>> Let me try to make things clear.
>>
>>> Err but this revision was sent _during_ the merge window...?
>>>
>>> Was sent on 9th Feb on Monday in merge window week 1, with a functional change
>>> listed:
>>>
>>> - Skip batched unmapping for uffd case, reported by Dev. Thanks.
>>>
>>> And then sent in 2nd batch on 18th Feb (see [0]).
>>>
>>> So we were ok with 1 week of 'testing' (does anybody actually test -next during
>>> the merge window? Was it even sent to -next?) for what appears to be a
>>> functional change?
>>
>> I posted v5 on Dec 26th[0], and it collected quite a few Reviewed-by tags
>> and sat in mm-unstable for testing.
>>
>> Later, Dev reported a uffd-related issue (I hope you recall that
>> discussion). I posted a fix[1] for it on Jan 16th, which Andrew accepted.
>>
>> Since then, the v5 series (plus the fix) continued to be tested in
>> mm-unstable. We kept it there mainly because David mentioned he wanted to
>> review the series, so we were waiting for his time.
>>
>> On Feb 9th, after returning from vacation, David reviewed the series
>> (thanks, David!). I replied to and addressed all his comments, then posted
>> v6 on the same day[2].
>
> OK thanks, I see that now.
>
> I still don't think we should have made any changes _during_ the merge window,
> even if they were simple code quality things.
>
> Changing patches then seems just crazy to me, as even code quality stuff can
> cause unexpected bugs, and now we're having upstream take it.
>
> Also this speaks to -fix patches just being broken in general.
>
> If you'd just respun with the fix as a v6, then we'd know 'v6 sent on 16th Jan
> addressed this' and there'd be no isssue.
>
> Now v5 isn't v5, there's v5 and something-not-v5 and to have a sense of the
> testing you have to go read a bunch of email chains.
>
> It also means change logs are now really inaccurate:
>
> Changes from v5:
> - Collect reviewed tags from Ryan, Harry and David. Thanks.
> - Fix some coding style issues (per David).
> - Skip batched unmapping for uffd case, reported by Dev. Thanks.
>
> And that to me means 'v5 didn't have this, v6 does'.
>
> And it's really hard to track timelines for testing.
Indeed. At least I need make the change history clearer.
>> Additionally, v6 had no functional changes compared to v5 + the fix, and it
>> mainly addressed some coding style issues pointed out by David. I also
>> discussed this with David off-list, and since there were no functional
>> changes, my expectation was that it could still make it into the merge
>> window. That is why v6 was merged.
>
> Yeah, we still shouldn't have taken changes to a series DURING the merge window,
> it's just crazy.
>
>>
>> [0] https://lore.kernel.org/linux-mm/cover.1766631066.git.baolin.wang@linux.alibaba.com/#t
>> [1] https://lore.kernel.org/linux-mm/20260116162652.176054-1-baolin.wang@linux.alibaba.com/
>> [2] https://lore.kernel.org/all/cover.1770645603.git.baolin.wang@linux.alibaba.com/
>>
>>> And there was ongoing feedback on this and the v5 series (at [1])?
>>
>> Regarding the feedback on v5, I believe everything has been addressed.
>>
>>> This doesn't really feel sane?
>>>
>>> And now I'm confused as to whether mm-stable patches can collect tags, since
>>> presumably this was in mm-stable at the point this respin was done?
>>>
>>> Maybe I'm missing something here but this doesn't feel like a sane process?
>>
>> Andrew, David, please correct me if I've missed anything. Also, please let
>> me know if there's anything in the process that needs to be improved.
>> Thanks.
>
> This isn't on you, it's about the process as a whole. We need clear rules about
> when changes will be accepted and when not.
>
> And frankly I think we need to do away with fix patches as a whole based on
> this, or at least anything even vaguely non-trivial or that potentially impacts
> code.
Understood. I'll check first before sending fixes to avoid confusion
next time.
^ permalink raw reply
* Re: [PATCH 1/2] crypto: stm32 - use list_first_entry_or_null to simplify hash_find_dev
From: Herbert Xu @ 2026-03-27 10:08 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Maxime Coquelin, Alexandre Torgue, Sakari Ailus,
linux-crypto, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260320084914.7180-3-thorsten.blum@linux.dev>
On Fri, Mar 20, 2026 at 09:49:13AM +0100, Thorsten Blum wrote:
> Use list_first_entry_or_null() to simplify stm32_hash_find_dev() and
> remove the now-unused local variable 'struct stm32_hash_dev *tmp'.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/stm32/stm32-hash.c | 16 +++++-----------
> 1 file changed, 5 insertions(+), 11 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - Add test vectors for authenc(hmac(md5),rfc3686(ctr(aes)))
From: Herbert Xu @ 2026-03-27 10:08 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: davem, mcoquelin.stm32, alexandre.torgue, linux-crypto,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260319171128.10566-1-olek2@wp.pl>
On Thu, Mar 19, 2026 at 06:11:21PM +0100, Aleksander Jan Bajkowski wrote:
> Test vectors were generated starting from existing RFC3686(CTR(AES)) test
> vectors and adding HMAC(MD5) computed with software implementation.
> Then, the results were double-checked on Mediatek MT7986 (safexcel).
> Platform pass self-tests.
>
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
> crypto/testmgr.c | 7 ++
> crypto/testmgr.h | 207 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 214 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 1/1] arm64: defconfig: Enable pinctrl/gpio/pcie for CIX Sky1 SoC
From: Peter Chen @ 2026-03-27 9:56 UTC (permalink / raw)
To: arnd
Cc: krzysztof.kozlowski, geert+renesas, linux-kernel,
linux-arm-kernel, cix-kernel-upstream, Peter Chen, Yunseong Kim
Pinctrl, PCIe, and GPIO device are used at Radxa Orion O6 board.
- Pinctrl is the base for peripheral IP and peripheral device.
- PCIe NVMe is needed for Debian boot.
- GPIO is added due to Debian bug report[1].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131772
Cc: Yunseong Kim <ysk@kzalloc.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
Changes for v2:
- Delete CIX HDA configurations due to it is not used at current
Orion O6 board device tree.
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..f9be52484008 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -241,6 +241,7 @@ CONFIG_PCIE_XILINX_DMA_PL=y
CONFIG_PCIE_XILINX_NWL=y
CONFIG_PCIE_XILINX_CPM=y
CONFIG_PCI_J721E_HOST=m
+CONFIG_PCI_SKY1_HOST=m
CONFIG_PCI_IMX6_HOST=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
@@ -676,6 +677,7 @@ CONFIG_PINCTRL_SDM660=y
CONFIG_PINCTRL_SDM670=y
CONFIG_PINCTRL_SDM845=y
CONFIG_PINCTRL_SDX75=y
+CONFIG_PINCTRL_SKY1=y
CONFIG_PINCTRL_SM4450=y
CONFIG_PINCTRL_SM6115=y
CONFIG_PINCTRL_SM6125=y
@@ -701,6 +703,7 @@ CONFIG_PINCTRL_SM8550_LPASS_LPI=m
CONFIG_PINCTRL_SM8650_LPASS_LPI=m
CONFIG_PINCTRL_SOPHGO_SG2000=y
CONFIG_GPIO_ALTERA=m
+CONFIG_GPIO_CADENCE=m
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_MB86S7X=y
--
2.50.1
^ permalink raw reply related
* Re: [PATCH] coresight: cti: fix the check condition in inout_sel_store
From: Leo Yan @ 2026-03-27 9:56 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Mathieu Poirier, Greg Kroah-Hartman, Tingwei Zhang, coresight,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260327-fix-cti-issue-v1-1-2c8921e21fc8@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 02:24:14PM +0800, Jie Gan wrote:
> Correct the upper bound from CTIINOUTEN_MAX to config->nr_trig_max,
> since nr_trig_max varies across CTI devices. An out-of-bounds issue
> occurs when a value greater than config->nr_trig_max is provided,
> leading to unexpected errors.
>
> Fixes: b5213376c240 ("coresight: cti: Add sysfs access to program function registers")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Reviewed-by: Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [RFC PATCH v2 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors
From: Ben Horgan @ 2026-03-27 9:54 UTC (permalink / raw)
To: Shaopeng Tan (Fujitsu)
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
xhao@linux.alibaba.com, zengheng4@huawei.com
In-Reply-To: <TY4PR01MB16930BFFB7CE7FEB56CA693098B57A@TY4PR01MB16930.jpnprd01.prod.outlook.com>
Hi Shaopeng,
On 3/27/26 03:00, Shaopeng Tan (Fujitsu) wrote:
> Hello Ben,
>
>> MPAM is able to emulate ABMC, i.e. mbm_event mode, by making memory
>> bandwidth monitors assignable. Rather than supporting the 'default'
>> mbm_assign_mode always use 'mbm_event'mode even if there are sufficient
>> memory bandwidth monitors. The per monitor event configuration is only
>> provided by resctrl when in 'mbm_event' mode and so only allowing
>> 'mbm_event' mode will make it easier to support per-monitor event
>> configuration for MPAM. For the moment, the only event supported is
>> mbm_total_event with no bandwidth type configuration. The 'mbm_assign_mode'
>> file will still show 'default' when there is no support for memory
>> bandwidth monitoring.
>>
>> The monitors need to be allocated from the driver, and mapped to whichever
>> control/monitor group resctrl wants to use them with.
>>
>> Add a second array to hold the monitor values indexed by resctrl's cntr_id.
>>
>> When CDP is in use, two monitors are needed so the available number of
>> counters halves. Platforms with one monitor will have zero monitors when
>> CDP is in use.
>>
>> Co-developed-by: James Morse <james.morse@arm.com>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>>
>> +/*
>> + * This must run after all event counters have been picked so that any free
>> + * running counters have already been allocated.
>> + */
>> +static int mpam_resctrl_monitor_init_abmc(struct mpam_resctrl_mon *mon)
>> +{
>> + struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
>> + struct rdt_resource *l3 = &res->resctrl_res;
>> + struct mpam_class *class = mon->class;
>> + u16 num_mbwu_mon;
>> + size_t num_rmid = resctrl_arch_system_num_rmid_idx();
>> +
>> + if (mon->mbwu_idx_to_mon) {
>> + pr_debug("monitors free running\n");
>> + return 0;
>> + }
>
> ABMC is not supported under this condition.
> Why does this condition conclude that there are enough monitors(monitors freee running)?
This is just a mistake. I missed removing this condition when support for using mbwu in
"free running"/non-AMBC mode was removed.
Thanks,
Ben
>
> Best regards,
> Shaopeng TAN
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] arm_mpam: resctrl: Pick classes for use as mbm counters
From: Ben Horgan @ 2026-03-27 9:50 UTC (permalink / raw)
To: Shaopeng Tan (Fujitsu)
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
xhao@linux.alibaba.com, zengheng4@huawei.com
In-Reply-To: <TY4PR01MB169309AB957008DE0FCA442F18B57A@TY4PR01MB16930.jpnprd01.prod.outlook.com>
Hi Shaopeng,
On 3/27/26 02:53, Shaopeng Tan (Fujitsu) wrote:
> Hello Ben,
>
>
>> resctrl has two types of counters, NUMA-local and global. MPAM can only
>> count global either using MSC at the L3 cache or in the memory controllers.
>> When global and local equate to the same thing continue just to call it
>> global.
>>
>> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
>> Tested-by: Zeng Heng <zengheng4@huawei.com>
>> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
>> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>
> There are environments with multiple L3 caches within a single NUMA node.
> In this case, mbm_total will be the sum of traffic from all caches within that NUAM node.
> Is my understanding correct?
No, currently you only get mbm_total if there is single L3 cache and a single corresponding NUMA node. Rather than
adding partial support by summing across numa nodes we plan to add support for memory bandwidth monitoring with NUMA
node scope.
Thanks,
Ben
>
>
> Best regards,
> Shaopeng TAN
^ permalink raw reply
* [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: Lorenzo Bianconi @ 2026-03-27 9:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In order to properly cleanup hw rx QDMA queues and bring the device to
the initial state, reset rx DMA queue head/tail index. Moreover, reset
queued DMA descriptor fields.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 56cf9a926a83da38bb03373ced9728f1fecdbce7..c2a54dbcbb0d576da298f2a36a354afaef89b240 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -794,18 +794,34 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
static void airoha_qdma_cleanup_rx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int qid = q - &qdma->q_rx[0];
while (q->queued) {
struct airoha_queue_entry *e = &q->entry[q->tail];
+ struct airoha_qdma_desc *desc = &q->desc[q->tail];
struct page *page = virt_to_head_page(e->buf);
dma_sync_single_for_cpu(eth->dev, e->dma_addr, e->dma_len,
page_pool_get_dma_dir(q->page_pool));
page_pool_put_full_page(q->page_pool, page, false);
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+ WRITE_ONCE(desc->msg3, 0);
+
q->tail = (q->tail + 1) % q->ndesc;
q->queued--;
}
+
+ q->head = q->tail;
+ airoha_qdma_rmw(qdma, REG_RX_DMA_IDX(qid), RX_RING_DMA_IDX_MASK,
+ FIELD_PREP(RX_RING_DMA_IDX_MASK, q->tail));
}
static int airoha_qdma_init_rx(struct airoha_qdma *qdma)
---
base-commit: ae05340ccaa9d347fe85415609e075545bec589f
change-id: 20260326-airoha_qdma_cleanup_rx_queue-fix-5efd8e392bd0
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 3/3] remoteproc: imx_rproc: Add support for i.MX94
From: Daniel Baluta @ 2026-03-27 9:46 UTC (permalink / raw)
To: Peng Fan (OSS), Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-3-a547a3588730@nxp.com>
On 3/27/26 04:42, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add basic remoteproc support for the i.MX94 M-core processors, including
> address translation tables(dev addr is from view of remote processor,
> sys addr is from view of main processor) and device configuration data for
> the CM70, CM71, and CM33S cores.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Daniel Baluta @ 2026-03-27 9:45 UTC (permalink / raw)
To: Peng Fan (OSS), Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-2-a547a3588730@nxp.com>
On 3/27/26 04:42, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Cortex-M[7,33] processors use a fixed reset vector table format:
>
> 0x00 Initial SP value
> 0x04 Reset vector
> 0x08 NMI
> 0x0C ...
> ...
> IRQ[n]
>
> In ELF images, the corresponding layout is:
>
> reset_vectors: --> hardware reset address
> .word __stack_end__
> .word Reset_Handler
> .word NMI_Handler
> .word HardFault_Handler
> ...
> .word UART_IRQHandler
> .word SPI_IRQHandler
> ...
>
> Reset_Handler: --> ELF entry point address
> ...
>
> The hardware fetches the first two words from reset_vectors and populates
> SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
> Reset_Handler.
>
> However, the ELF entry point does not always match the hardware reset
> address. For example, on i.MX94 CM33S:
>
> ELF entry point: 0x0ffc211d
> hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
>
> To derive the correct hardware reset address, the unused lower bits must
> be masked off. The boot code should apply a SoC-specific mask before
> programming the reset address registers, e.g.:
>
> reset_address = entry & reset_vector_mask
>
> Current driver always programs the reset vector as 0. But i.MX94 CM33S's
> default reset base is 0x0ffc0000, so the correct reset vector must be
> passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
>
> rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
> hardware reset vector address. To derive the proper reset vector, this
> patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
> point using the SoC‑specific 'reset_vector_mask'. The resulting reset
> vector address is then passed to the SM CPU/LMM reset vector API calls.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ 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