* Re: [PATCH] futex: Optimise the size check get_futex_key()
From: Sebastian Andrzej Siewior @ 2026-07-02 10:56 UTC (permalink / raw)
To: Peter Zijlstra
Cc: K Prateek Nayak, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Catalin Marinas, Will Deacon,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Darren Hart, Davidlohr Bueso,
André Almeida, linux-arch, linux-kernel, Samuel Holland,
Charlie Jenkins, linux-arm-kernel, linux-riscv, linux-s390,
H. Peter Anvin, Thomas Huth, Sean Christopherson, Jisheng Zhang,
Alexandre Ghiti, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260702085921.GD49951@noisy.programming.kicks-ass.net>
On 2026-07-02 10:59:21 [+0200], Peter Zijlstra wrote:
> > Could someone verify this, please? The 5% look a bit high. This is on
> > top of the series (but not worsen by the series).
>
> Bah, I tried to reproduce and couldn't. Then I noticed I did a clang
> build and that is in fact clever enough to do this optimization itself.
>
> /me tries again with a GCC build.
>
> pre: [thread 0] futex: 0x561f14430680 [ 9021408 ops/sec ]
> post: [thread 0] futex: 0x55feadbbb680 [ 8977527 ops/sec ]
>
> (and this seems to be well inside the error threshold of this test).
>
> So I see the GCC build do the DIV, and no longer with his patch applied,
> but for some reason I cannot get the runtime performance to actually
> improve much of anything on my system.
I did open https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126078 for the
div.
My .config is the debian distro on the 4 node big iron. [ in case it
it has so much overhead elsewhere that this place a bigger role].
"perf top" showed this as 6% or something and red in the function. After
the removal it did not show up.
Sebastian
^ permalink raw reply
* [PATCH 0/2] ASoC: meson: aiu: fix playback issue for 24-bit mode
From: Valerio Setti @ 2026-07-02 10:56 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl
Cc: linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel,
Valerio Setti
A patch series has recently been merged in c7852d2dcf66
("ASoC: meson: aiu: align I2S design to the AXG one") which unfortunately
introduces a bug in 24 bit mode playback which this new series resolves.
Among other things the previous series moved the content of what was once
called 'aiu_encoder_i2s_setup_desc' from 'aiu-encoder-i2s' to
'aiu-formatter-i2s'.
'aiu_encoder_i2s_setup_desc' was basically accomplishing two tasks:
- reset the i2s pipeline.
- configure number of channels and physical samples width.
Before being moved 'aiu_encoder_i2s_setup_desc' was called in the encoder
DAI 'hw_params()', whereas after the move it is called at trigger time
('aiu_encoder_i2s_trigger'->'gx_stream_start' -> 'gx_formatter_enable' ->
'aiu_formatter_i2s_prepare').
In parallel 'aiu-fifo-i2s' (DAI FE) already performs the very same reset
of the pipeline at trigger time in 'aiu_fifo_i2s_trigger' and then it
triggers the playback.
Since the DAI triggering order is the default one (FE before BE) this
means that the pipeline reset happens when the BE already did it and
started the playback. This cause the 24-bit playback mode to be
corrupted.
This series:
- re-orders operations so that 'aiu_formatter_i2s_prepare' is called after
DAIs' prepare, but before triggering them.
- removes pipeline reset from 'aiu_formatter_i2s_prepare' because the
very same operation is done by 'aiu-fifo-i2s' on trigger.
This series depends on c7852d2dcf66 ("ASoC: meson: aiu: align I2S design
to the AXG one") which exists in 'broonie/sound.git#for-7.3', but which
has not been mainlined yet.
Please apologize for the inconvenience.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
---
Valerio Setti (2):
ASoC: meson: gx-formatter: prepare on attach
ASoC: meson: aiu-formatter: remove pipeline reset from prepare
sound/soc/meson/aiu-formatter-i2s.c | 9 ++++-----
sound/soc/meson/gx-formatter.c | 33 +++++++++++++++++++++++++--------
2 files changed, 29 insertions(+), 13 deletions(-)
---
base-commit: bff7fad1010eea6f183fb110b54171cf8700ef8e
change-id: 20260702-fix-24-bit-i2s-playback-6444174c7cd7
Best regards,
--
Valerio Setti <vsetti@baylibre.com>
^ permalink raw reply
* [PATCH 1/2] ASoC: meson: gx-formatter: prepare on attach
From: Valerio Setti @ 2026-07-02 10:56 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl
Cc: linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel,
Valerio Setti
In-Reply-To: <20260702-fix-24-bit-i2s-playback-v1-0-bcd3a43fe32a@baylibre.com>
Instead of calling the formatter driver prepare and enable at the same
time when 'gx_stream_start' is called (which happens at trigger time),
split the operation in 2: prepare is called when the widget is powered
up, whereas enable is kept on 'gx_stream_start'.
This resolves a problem related to i2s playback in 24-bit mode. Commit
c7852d2dcf66 ("ASoC: meson: aiu: align I2S design to the AXG one") moved
the content of what was once called 'aiu_encoder_i2s_setup_desc' from
'aiu-encoder-i2s' to 'aiu-formatter-i2s'.
'aiu_encoder_i2s_setup_desc' was basically accomplishing two tasks:
- reset the i2s pipeline.
- configure number of channels and physical samples width.
Before being moved 'aiu_encoder_i2s_setup_desc' was called in the encoder
DAI 'hw_params()', whereas after the move it is called at trigger time
('aiu_encoder_i2s_trigger'->'gx_stream_start' -> 'gx_formatter_enable' ->
'aiu_formatter_i2s_prepare').
In parallel 'aiu-fifo-i2s' (DAI FE) already performs the very same reset
of the pipeline at trigger time in 'aiu_fifo_i2s_trigger' and then it
triggers the playback.
Since the DAI triggering order is the default one (FE before BE) this
means that the pipeline reset happens when the BE already did it and
started the playback. This cause the 24-bit playback mode to be
corrupted.
This commit re-orders operations so that 'aiu_formatter_i2s_prepare' is
called after DAIs' prepare, but before triggering them.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
---
sound/soc/meson/gx-formatter.c | 33 +++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/sound/soc/meson/gx-formatter.c b/sound/soc/meson/gx-formatter.c
index 311e63affb23..c7333f624b15 100644
--- a/sound/soc/meson/gx-formatter.c
+++ b/sound/soc/meson/gx-formatter.c
@@ -15,27 +15,38 @@ struct gx_formatter {
struct gx_stream *stream;
const struct gx_formatter_driver *drv;
bool enabled;
+ bool prepared;
struct regmap *map;
};
-static int gx_formatter_enable(struct gx_formatter *formatter)
+static int gx_formatter_prepare(struct gx_formatter *formatter)
{
int ret;
- /* Do nothing if the formatter is already enabled */
- if (formatter->enabled)
+ if (formatter->prepared)
return 0;
/* Setup the stream parameter in the formatter */
if (formatter->drv->ops->prepare) {
ret = formatter->drv->ops->prepare(formatter->map,
- formatter->drv->quirks,
- formatter->stream);
+ formatter->drv->quirks,
+ formatter->stream);
if (ret)
return ret;
}
- /* Finally, actually enable the formatter */
+ formatter->prepared = true;
+
+ return 0;
+}
+
+static int gx_formatter_enable(struct gx_formatter *formatter)
+{
+ /* Do nothing if the formatter is already enabled */
+ if (formatter->enabled)
+ return 0;
+
+ /* Enable the formatter */
if (formatter->drv->ops->enable)
formatter->drv->ops->enable(formatter->map);
@@ -63,6 +74,12 @@ static int gx_formatter_attach(struct gx_formatter *formatter)
mutex_lock(&ts->lock);
+ ret = gx_formatter_prepare(formatter);
+ if (ret) {
+ pr_err("failed to prepare the formatter\n");
+ goto out;
+ }
+
/* Catch up if the stream is already running when we attach */
if (ts->ready) {
ret = gx_formatter_enable(formatter);
@@ -87,9 +104,9 @@ static void gx_formatter_detach(struct gx_formatter *formatter)
mutex_lock(&ts->lock);
list_del(&formatter->list);
- mutex_unlock(&ts->lock);
-
gx_formatter_disable(formatter);
+ formatter->prepared = false;
+ mutex_unlock(&ts->lock);
}
static int gx_formatter_power_up(struct gx_formatter *formatter,
--
2.47.3
^ permalink raw reply related
* [PATCH 2/2] ASoC: meson: aiu-formatter: remove pipeline reset from prepare
From: Valerio Setti @ 2026-07-02 10:56 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl
Cc: linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel,
Valerio Setti
In-Reply-To: <20260702-fix-24-bit-i2s-playback-v1-0-bcd3a43fe32a@baylibre.com>
'aiu-formatter-i2s' already performs the very same reset in
'aiu_fifo_i2s_trigger' for all relevant trigger scenarios. There is no
need to duplicate the operation in the formatter.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
---
sound/soc/meson/aiu-formatter-i2s.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/sound/soc/meson/aiu-formatter-i2s.c b/sound/soc/meson/aiu-formatter-i2s.c
index b4604734fe88..cb554c2e7ce4 100644
--- a/sound/soc/meson/aiu-formatter-i2s.c
+++ b/sound/soc/meson/aiu-formatter-i2s.c
@@ -13,7 +13,6 @@
#define AIU_I2S_SOURCE_DESC_MODE_8CH BIT(0)
#define AIU_I2S_SOURCE_DESC_MODE_24BIT BIT(5)
#define AIU_I2S_SOURCE_DESC_MODE_32BIT BIT(9)
-#define AIU_RST_SOFT_I2S_FAST BIT(0)
#define AIU_I2S_DAC_CFG_MSB_FIRST BIT(2)
@@ -55,11 +54,11 @@ static int aiu_formatter_i2s_prepare(struct regmap *map,
{
/* Always operate in split (classic interleaved) mode */
unsigned int desc = 0;
- unsigned int tmp;
- /* Reset required to update the pipeline */
- regmap_write(map, AIU_RST_SOFT, AIU_RST_SOFT_I2S_FAST);
- regmap_read(map, AIU_I2S_SYNC, &tmp);
+ /*
+ * Pipeline reset is already implemented in aiu_fifo_i2s_trigger() at
+ * trigger time.
+ */
switch (ts->physical_width) {
case 16: /* Nothing to do */
--
2.47.3
^ permalink raw reply related
* [PATCH v10 4/5] phy: move and rename Airoha PCIe PHY driver to dedicated directory
From: Christian Marangi @ 2026-07-02 9:38 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Christian Marangi, Vinod Koul,
Neil Armstrong, Lorenzo Bianconi, Felix Fietkau, linux-clk,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260702093812.15918-1-ansuelsmth@gmail.com>
To keep the generic PHY directory tidy, move the PCIe PHY driver for
Airoha AN7581 SoC to a dedicated directory.
Also rename the driver and add the relevant SoC name to the .c and .h
file in preparation for support of PCIe and USB PHY driver for Airoha
AN7583 SoC that use a completely different implementation and
calibration for PHYs and will have their own dedicated drivers.
The rename permits to better identify the specific usage of the driver
in the future once the airoha PHY directory will have multiple driver
for multiple SoC.
The config is changed from PHY_AIROHA_PCIE to PHY_AIROHA_AN7581_PCIE.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
MAINTAINERS | 4 ++--
drivers/phy/Kconfig | 11 +----------
drivers/phy/Makefile | 4 ++--
drivers/phy/airoha/Kconfig | 13 +++++++++++++
drivers/phy/airoha/Makefile | 3 +++
.../phy-an7581-pcie-regs.h} | 2 +-
.../{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} | 6 +++---
7 files changed, 25 insertions(+), 18 deletions(-)
create mode 100644 drivers/phy/airoha/Kconfig
create mode 100644 drivers/phy/airoha/Makefile
rename drivers/phy/{phy-airoha-pcie-regs.h => airoha/phy-an7581-pcie-regs.h} (99%)
rename drivers/phy/{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 05e90c3f7fe0..952653034c4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -765,8 +765,8 @@ M: Lorenzo Bianconi <lorenzo@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml
-F: drivers/phy/phy-airoha-pcie-regs.h
-F: drivers/phy/phy-airoha-pcie.c
+F: drivers/phy/airoha/phy-an7581-pcie-regs.h
+F: drivers/phy/airoha/phy-an7581-pcie.c
AIROHA SPI SNFI DRIVER
M: Lorenzo Bianconi <lorenzo@kernel.org>
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b7d..e93951a4a898 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -46,16 +46,6 @@ config GENERIC_PHY_MIPI_DPHY
Provides a number of helpers a core functions for MIPI D-PHY
drivers to us.
-config PHY_AIROHA_PCIE
- tristate "Airoha PCIe-PHY Driver"
- depends on ARCH_AIROHA || COMPILE_TEST
- depends on OF
- select GENERIC_PHY
- help
- Say Y here to add support for Airoha PCIe PHY driver.
- This driver create the basic PHY instance and provides initialize
- callback for PCIe GEN3 port.
-
config PHY_CAN_TRANSCEIVER
tristate "CAN transceiver PHY"
select GENERIC_PHY
@@ -168,6 +158,7 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+source "drivers/phy/airoha/Kconfig"
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d7aa516bcc49..4ca4a07963fc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,7 +7,6 @@ obj-$(CONFIG_PHY_COMMON_PROPS) += phy-common-props.o
obj-$(CONFIG_PHY_COMMON_PROPS_TEST) += phy-common-props-test.o
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
-obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
obj-$(CONFIG_PHY_ECONET_PCIE) += phy-econet-pcie.o
obj-$(CONFIG_PHY_EYEQ5_ETH) += phy-eyeq5-eth.o
@@ -20,7 +19,8 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
-obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
+obj-$(CONFIG_GENERIC_PHY) += airoha/ \
+ allwinner/ \
amlogic/ \
apple/ \
axiado/ \
diff --git a/drivers/phy/airoha/Kconfig b/drivers/phy/airoha/Kconfig
new file mode 100644
index 000000000000..9a1b625a7701
--- /dev/null
+++ b/drivers/phy/airoha/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Phy drivers for Airoha devices
+#
+config PHY_AIROHA_AN7581_PCIE
+ tristate "Airoha AN7581 PCIe-PHY Driver"
+ depends on ARCH_AIROHA || COMPILE_TEST
+ depends on OF
+ select GENERIC_PHY
+ help
+ Say Y here to add support for Airoha AN7581 PCIe PHY driver.
+ This driver create the basic PHY instance and provides initialize
+ callback for PCIe GEN3 port.
diff --git a/drivers/phy/airoha/Makefile b/drivers/phy/airoha/Makefile
new file mode 100644
index 000000000000..912f3e11a061
--- /dev/null
+++ b/drivers/phy/airoha/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_PHY_AIROHA_AN7581_PCIE) += phy-an7581-pcie.o
diff --git a/drivers/phy/phy-airoha-pcie-regs.h b/drivers/phy/airoha/phy-an7581-pcie-regs.h
similarity index 99%
rename from drivers/phy/phy-airoha-pcie-regs.h
rename to drivers/phy/airoha/phy-an7581-pcie-regs.h
index 58572c793722..b938a7b468fe 100644
--- a/drivers/phy/phy-airoha-pcie-regs.h
+++ b/drivers/phy/airoha/phy-an7581-pcie-regs.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (c) 2024 AIROHA Inc
* Author: Lorenzo Bianconi <lorenzo@kernel.org>
diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/airoha/phy-an7581-pcie.c
similarity index 99%
rename from drivers/phy/phy-airoha-pcie.c
rename to drivers/phy/airoha/phy-an7581-pcie.c
index 56e9ade8a9fd..81ddf0e7638b 100644
--- a/drivers/phy/phy-airoha-pcie.c
+++ b/drivers/phy/airoha/phy-an7581-pcie.c
@@ -13,7 +13,7 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
-#include "phy-airoha-pcie-regs.h"
+#include "phy-an7581-pcie-regs.h"
#define LEQ_LEN_CTRL_MAX_VAL 7
#define FREQ_LOCK_MAX_ATTEMPT 10
@@ -1279,12 +1279,12 @@ MODULE_DEVICE_TABLE(of, airoha_pcie_phy_of_match);
static struct platform_driver airoha_pcie_phy_driver = {
.probe = airoha_pcie_phy_probe,
.driver = {
- .name = "airoha-pcie-phy",
+ .name = "airoha-an7581-pcie-phy",
.of_match_table = airoha_pcie_phy_of_match,
},
};
module_platform_driver(airoha_pcie_phy_driver);
-MODULE_DESCRIPTION("Airoha PCIe PHY driver");
+MODULE_DESCRIPTION("Airoha AN7581 PCIe PHY driver");
MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>");
MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 3/6] KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
From: Leonardo Bras @ 2026-07-02 10:58 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: Leonardo Bras, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene
In-Reply-To: <5yy625c66j3kgoboejg7hagnmxjzp2tvmvvncmqvo444wtpmzl@sufez6t2iy3r>
On Wed, Jul 01, 2026 at 06:27:51PM +0100, Wei-Lin Chang wrote:
> On Wed, Jul 01, 2026 at 04:00:41PM +0100, Leonardo Bras wrote:
> > Hi Wei Lin,
> >
> > On Tue, Jun 30, 2026 at 01:10:02PM +0100, Wei-Lin Chang wrote:
> > > ptdump files can still be read after the pgt of the canonical mmu is
> > > freed, if they are opened before the VM debugfs directory is removed.
> > > This triggers UAF in places where we cache the pgt pointer or access it
> > > without checking its validity.
> > >
> > > Check the pgt is still alive under the mmu_lock before accessing the
> > > pgt.
> > >
> > > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > > Closes: https://sashiko.dev/#/patchset/20260623142443.648972-1-weilin.chang@arm.com?part=1
> > > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > > ---
> > > arch/arm64/kvm/ptdump.c | 38 ++++++++++++++++++++++++--------------
> > > 1 file changed, 24 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > > index d5aa9eff08d1..752d8e0cd25c 100644
> > > --- a/arch/arm64/kvm/ptdump.c
> > > +++ b/arch/arm64/kvm/ptdump.c
> > > @@ -115,13 +115,21 @@ static int kvm_ptdump_build_levels(struct ptdump_pg_level *level, u32 start_lvl)
> > > static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
> > > {
> > > struct kvm_ptdump_guest_state *st;
> > > - struct kvm_pgtable *pgtable = kvm->arch.mmu.pgt;
> > > + struct kvm_pgtable *pgtable;
> > > int ret;
> > >
> > > st = kzalloc_obj(struct kvm_ptdump_guest_state, GFP_KERNEL_ACCOUNT);
> > > if (!st)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > + guard(write_lock)(&kvm->mmu_lock);
> > > + if (!kvm->arch.mmu.pgt) {
> > > + kfree(st);
> > > + return ERR_PTR(-ENXIO);
> > > + }
> > > +
> > > + pgtable = kvm->arch.mmu.pgt;
> > > +
> > > ret = kvm_ptdump_build_levels(&st->level[0], pgtable->start_level);
> > > if (ret) {
> > > kfree(st);
> > > @@ -137,7 +145,6 @@ static struct kvm_ptdump_guest_state *kvm_ptdump_parser_create(struct kvm *kvm)
> > >
> > > static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> > > {
> > > - int ret;
> > > struct kvm_ptdump_guest_state *st = m->private;
> > > struct kvm *kvm = st->kvm;
> > > struct kvm_s2_mmu *mmu = &kvm->arch.mmu;
> > > @@ -154,11 +161,11 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> > > .seq = m,
> > > };
> > >
> > > - write_lock(&kvm->mmu_lock);
> > > - ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> > > - write_unlock(&kvm->mmu_lock);
> > > + guard(write_lock)(&kvm->mmu_lock);
> > > + if (mmu->pgt)
> > > + return kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> >
> > IIUC, that's the same behavior, right?
> > Just changed to look about the same with the rest of this file?
>
> I'm not too sure what you are referring to, if you mean the
> write_lock/unlock -> guard(write_lock) change, then yes, mostly. Just
> also checking mmu->pgt is still not freed.
I was referring just to lock+unlock -> guard() strategy.
IIUC this has the same effect, so I was wondering on why you suggested the
change.
I then supposed it was to look the same of the rest of the file.
>
> >
> > >
> > > - return ret;
> > > + return 0;
> > > }
> >
> > So if the pgt does not exist anymore, it returns zero. Is that the desired
> > behavior?
>
> Good question, so the question is what contract between the ptdump and
> user do we want to make for this case. I guess returning some error like -EIO
> could make a little more sense than just printing nothing?
>
It depends on what is the behaviour you want to see... see below..
> >
> > I guess it's aligned with the idea of single file mentioned in the cover,
> > right?
>
> Sorry, I don't get what you are asking here?
IIUC you mentioned in the cover letter that you planned to have a file
which would, on read, output ptdump for every nested pgtable. Did I get
that right?
If so, I imagine that the user has no idea how many nested pgtables are
there, and if the ioctl initially finds N, but ends up printing N-1
(because a pgtable was not there anymore), that would not be an error that
the user should be worried about.
It could be an issue if you were printing in multiple steps (multiple
checks), as a part of that pgtable could be printed while another part
could not. Which does not seem to be the case.
>
> >
> > >
> > > static int kvm_ptdump_guest_open(struct inode *m, struct file *file)
> > > @@ -206,17 +213,23 @@ static const struct file_operations kvm_ptdump_guest_fops = {
> > >
> > > static int kvm_pgtable_range_show(struct seq_file *m, void *unused)
> > > {
> > > - struct kvm_pgtable *pgtable = m->private;
> > > + struct kvm *kvm = m->private;
> > > +
> > > + guard(write_lock)(&kvm->mmu_lock);
> > > + if (kvm->arch.mmu.pgt)
> > > + seq_printf(m, "%2u\n", kvm->arch.mmu.pgt->ia_bits);
> > >
> > > - seq_printf(m, "%2u\n", pgtable->ia_bits);
> > > return 0;
> > > }
> > >
> > > static int kvm_pgtable_levels_show(struct seq_file *m, void *unused)
> > > {
> > > - struct kvm_pgtable *pgtable = m->private;
> > > + struct kvm *kvm = m->private;
> > > +
> > > + guard(write_lock)(&kvm->mmu_lock);
> > > + if (kvm->arch.mmu.pgt)
> > > + seq_printf(m, "%1d\n", KVM_PGTABLE_MAX_LEVELS - kvm->arch.mmu.pgt->start_level);
> > >
> > > - seq_printf(m, "%1d\n", KVM_PGTABLE_MAX_LEVELS - pgtable->start_level);
> > > return 0;
> > > }
> > >
> > > @@ -224,15 +237,12 @@ static int kvm_pgtable_debugfs_open(struct inode *m, struct file *file,
> > > int (*show)(struct seq_file *, void *))
> > > {
> > > struct kvm *kvm = m->i_private;
> > > - struct kvm_pgtable *pgtable;
> > > int ret;
> > >
> > > if (!kvm_get_kvm_safe(kvm))
> > > return -ENOENT;
> > >
> > > - pgtable = kvm->arch.mmu.pgt;
> > > -
> > > - ret = single_open(file, show, pgtable);
> > > + ret = single_open(file, show, kvm);
> >
> > Maybe this change is more related with the previous patch?
>
> I see your point, but I divided it into first fixing mmu UAF, then the
> pgt UAF, which I also think makes sense.
>
Okay then
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH v2 6/6] KVM: arm64: ptdump: Introduce the shadow ptdump file
From: Leonardo Bras @ 2026-07-02 11:00 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: Leonardo Bras, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Sebastian Ene
In-Reply-To: <w6ffknve2o3l5pgk7mblovsu5xzjwsgf7qyjd66nqwbtsea4ue@h5wj26fbb6kb>
On Wed, Jul 01, 2026 at 06:35:41PM +0100, Wei-Lin Chang wrote:
> On Wed, Jul 01, 2026 at 04:28:35PM +0100, Leonardo Bras wrote:
> > On Tue, Jun 30, 2026 at 01:10:05PM +0100, Wei-Lin Chang wrote:
> > > Create a ptdump file for all shadow page tables. It will dump out all
> > > valid shadow page tables at the time of request, with the mmu's index,
> > > guest VTCR_EL2, VTTBR_EL2, and whether the guest stage-2 is enabled or
> > > not.
> > >
> > > Also detach the nested mmu array under the mmu_lock in
> > > kvm_arch_flush_shadow_all() so readers cannot race with the array being
> > > removed, then free the old array after dropping the lock.
> >
> > Out of curiosity: why drop the lock before kfree'ing ?
>
> Because kvfree() can sleep! :)
>
Damn, I was certain to read kfree, not kvfree(), LOL
You are right, then :)
Thanks!
Leoy
> Thanks,
> Wei-Lin Chang
>
> >
> > Thanks!
> > Leo
> >
> > >
> > > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > > ---
> > > arch/arm64/kvm/nested.c | 12 ++++++--
> > > arch/arm64/kvm/ptdump.c | 61 ++++++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 69 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > > index 6435efd65cb5..17a180ddf6ca 100644
> > > --- a/arch/arm64/kvm/nested.c
> > > +++ b/arch/arm64/kvm/nested.c
> > > @@ -1283,6 +1283,7 @@ void kvm_nested_s2_flush(struct kvm *kvm)
> > >
> > > void kvm_arch_flush_shadow_all(struct kvm *kvm)
> > > {
> > > + struct kvm_s2_mmu *mmus;
> > > int i;
> > >
> > > for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
> > > @@ -1291,9 +1292,14 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
> > > if (!WARN_ON(atomic_read(&mmu->refcnt)))
> > > kvm_free_stage2_pgd(mmu);
> > > }
> > > - kvfree(kvm->arch.nested_mmus);
> > > - kvm->arch.nested_mmus = NULL;
> > > - kvm->arch.nested_mmus_size = 0;
> > > +
> > > + scoped_guard(write_lock, &kvm->mmu_lock) {
> > > + mmus = kvm->arch.nested_mmus;
> > > + kvm->arch.nested_mmus = NULL;
> > > + kvm->arch.nested_mmus_size = 0;
> > > + }
> > > +
> > > + kvfree(mmus);
> > > kvm_uninit_stage2_mmu(kvm);
> > > }
> > >
> > > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > > index 40f93b7c7ad9..1649eaa75798 100644
> > > --- a/arch/arm64/kvm/ptdump.c
> > > +++ b/arch/arm64/kvm/ptdump.c
> > > @@ -181,6 +181,50 @@ static int kvm_ptdump_guest_canonical_show(struct seq_file *m, void *unused)
> > > return 0;
> > > }
> > >
> > > +static int kvm_ptdump_guest_nested_show(struct seq_file *m, void *unused)
> > > +{
> > > + int ret = 0, i;
> > > + struct kvm_ptdump_guest_state *st = m->private;
> > > + struct kvm *kvm = st->kvm;
> > > + struct kvm_pgtable_walker walker = (struct kvm_pgtable_walker) {
> > > + .cb = kvm_ptdump_visitor,
> > > + .arg = &st->parser_state,
> > > + .flags = KVM_PGTABLE_WALK_LEAF,
> > > + };
> > > +
> > > + guard(write_lock)(&kvm->mmu_lock);
> > > +
> > > + if (!kvm->arch.nested_mmus)
> > > + return 0;
> > > +
> > > + for (i = 0; i < kvm->arch.nested_mmus_size; i++) {
> > > + struct kvm_s2_mmu *mmu = &kvm->arch.nested_mmus[i];
> > > +
> > > + if (!mmu->pgt)
> > > + continue;
> > > +
> > > + if (kvm_s2_mmu_valid(mmu)) {
> > > + memset(st, 0, sizeof(*st));
> > > + ret = kvm_ptdump_parser_init(st, kvm, mmu->pgt);
> > > + if (ret)
> > > + return ret;
> > > + st->parser_state = (struct ptdump_pg_state) {
> > > + .marker = &st->ipa_marker[0],
> > > + .level = -1,
> > > + .pg_level = &st->level[0],
> > > + .seq = m,
> > > + };
> > > + seq_printf(m, "nested mmu %d VTCR: 0x%016llx VTTBR: 0x%016llx s2: %s\n",
> > > + i, mmu->tlb_vtcr, mmu->tlb_vttbr,
> > > + mmu->nested_stage2_enabled ? "enabled" : "disabled");
> > > + ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > + }
> > > + return ret;
> > > +}
> > > +
> > > static int kvm_ptdump_guest_open(struct inode *m, struct file *file,
> > > int (*show)(struct seq_file *, void *))
> > > {
> > > @@ -212,6 +256,11 @@ static int kvm_ptdump_guest_canonical_open(struct inode *m, struct file *file)
> > > return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_canonical_show);
> > > }
> > >
> > > +static int kvm_ptdump_guest_nested_open(struct inode *m, struct file *file)
> > > +{
> > > + return kvm_ptdump_guest_open(m, file, kvm_ptdump_guest_nested_show);
> > > +}
> > > +
> > > static int kvm_ptdump_guest_close(struct inode *m, struct file *file)
> > > {
> > > struct kvm *kvm = m->i_private;
> > > @@ -230,6 +279,13 @@ static const struct file_operations kvm_ptdump_guest_canonical_fops = {
> > > .release = kvm_ptdump_guest_close,
> > > };
> > >
> > > +static const struct file_operations kvm_ptdump_guest_nested_fops = {
> > > + .open = kvm_ptdump_guest_nested_open,
> > > + .read = seq_read,
> > > + .llseek = seq_lseek,
> > > + .release = kvm_ptdump_guest_close,
> > > +};
> > > +
> > > static int kvm_pgtable_range_show(struct seq_file *m, void *unused)
> > > {
> > > struct kvm *kvm = m->private;
> > > @@ -307,6 +363,9 @@ void kvm_s2_ptdump_create_debugfs(struct kvm *kvm)
> > > kvm, &kvm_pgtable_range_fops);
> > > debugfs_create_file("stage2_levels", 0400, kvm->debugfs_dentry,
> > > kvm, &kvm_pgtable_levels_fops);
> > > - if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT))
> > > + if (cpus_have_final_cap(ARM64_HAS_NESTED_VIRT)) {
> > > kvm->arch.debugfs_nv_dentry = debugfs_create_dir("nested", kvm->debugfs_dentry);
> > > + debugfs_create_file("shadow_page_tables", 0400, kvm->arch.debugfs_nv_dentry,
> > > + kvm, &kvm_ptdump_guest_nested_fops);
> > > + }
> > > }
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* Re: [PATCH v7 4/8] mfd: khadas-mcu: Add support for VIM4 MCU variant
From: linux-kernel-dev @ 2026-07-02 9:45 UTC (permalink / raw)
To: Lee Jones
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andi Shyti, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260611164053.GC1212816@google.com>
On 6/11/26 6:40 PM, Lee Jones wrote:
> /* Sashiko Automation: Reviewed (0 Findings) */
>
> On Wed, 03 Jun 2026, Ronald Claveau via B4 Relay wrote:
>
>> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>
>> Refactor probe() to use per-variant values
>> instead of hardcoded globals.
>>
>> Add dedicated regmap configuration for the VIM4 MCU,
>> with its own volatile/writeable registers.
>>
>> Add the fan control register
>> (0–100 levels vs 0–3 for previous supported boards).
>>
>> Add a new compatible string "khadas,vim4-mcu".
>>
>> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> drivers/mfd/khadas-mcu.c | 115 ++++++++++++++++++++++++++++++++++++++++-------
>> 1 file changed, 99 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
>> index ba981a7886921..1bf260729d73b 100644
>> --- a/drivers/mfd/khadas-mcu.c
>> +++ b/drivers/mfd/khadas-mcu.c
>> @@ -75,47 +75,129 @@ static const struct regmap_config khadas_mcu_regmap_config = {
>> .cache_type = REGCACHE_MAPLE,
>> };
>>
>> -static struct mfd_cell khadas_mcu_fan_cells[] = {
>> +static const struct khadas_mcu_fan_pdata khadas_mcu_fan_pdata = {
>> + .fan_reg = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> + .max_level = 3, /* Fan speed: 0 = off, 1 = low, 2 = medium, 3 = high */
>
> Instead of this comment, you could always just define the value(s)?
>
I will do that with define.
>> +};
>> +
>> +static const struct mfd_cell khadas_mcu_fan_cells[] = {
>> /* VIM1/2 Rev13+ and VIM3 only */
>> - { .name = "khadas-mcu-fan-ctrl", },
>> + {
>> + .name = "khadas-mcu-fan-ctrl",
>> + .platform_data = &khadas_mcu_fan_pdata,
>> + .pdata_size = sizeof(khadas_mcu_fan_pdata),
>
> No need to attempt to align the '=' like this, please.
>
I will remove these extra spaces.
>> + },
>> };
>>
>> -static struct mfd_cell khadas_mcu_cells[] = {
>> +static const struct mfd_cell khadas_mcu_cells[] = {
>> { .name = "khadas-mcu-user-mem", },
>> };
>>
>> +static bool khadas_mcu_vim4_reg_volatile(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case KHADAS_MCU_PWR_OFF_CMD_REG:
>> + case KHADAS_MCU_VIM4_REST_CONF_REG:
>> + case KHADAS_MCU_WOL_INIT_START_REG:
>> + case KHADAS_MCU_VIM4_LED_ON_RAM_REG:
>> + case KHADAS_MCU_VIM4_FAN_CTRL_REG:
>> + case KHADAS_MCU_VIM4_WDT_EN_REG:
>> + case KHADAS_MCU_VIM4_SYS_RST_REG:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> +static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case KHADAS_MCU_VERSION_0_REG:
>> + case KHADAS_MCU_VERSION_1_REG:
>> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
>> + return false;
>> + default:
>> + return true;
>> + }
>> +}
>> +
>> +static const struct regmap_config khadas_mcu_vim4_regmap_config = {
>> + .reg_bits = 8,
>> + .reg_stride = 1,
>> + .val_bits = 8,
>> + .max_register = KHADAS_MCU_VIM4_SYS_RST_REG,
>> + .volatile_reg = khadas_mcu_vim4_reg_volatile,
>> + .writeable_reg = khadas_mcu_vim4_reg_writeable,
>> + .cache_type = REGCACHE_MAPLE,
>> +};
>> +
>> +static const struct khadas_mcu_fan_pdata khadas_vim4_fan_pdata = {
>> + .fan_reg = KHADAS_MCU_VIM4_FAN_CTRL_REG,
>> + .max_level = 0x64,
>> +};
>> +
>> +static const struct mfd_cell khadas_mcu_vim4_cells[] = {
>> + {
>> + .name = "khadas-mcu-fan-ctrl",
>> + .platform_data = &khadas_vim4_fan_pdata,
>> + .pdata_size = sizeof(khadas_vim4_fan_pdata),
>> + },
>> +};
>> +
>> static int khadas_mcu_probe(struct i2c_client *client)
>> {
>> + const struct mfd_cell *cells, *fan_cells;
>> + const struct regmap_config *regmap_cfg;
>> struct device *dev = &client->dev;
>> + int ncells, nfan_cells, ret;
>> struct khadas_mcu *ddata;
>> - int ret;
>>
>> ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
>> if (!ddata)
>> return -ENOMEM;
>>
>> + switch ((uintptr_t)i2c_get_match_data(client)) {
>> + case KHADAS_MCU_GENERIC:
>> + regmap_cfg = &khadas_mcu_regmap_config;
>> + cells = khadas_mcu_cells;
>> + ncells = ARRAY_SIZE(khadas_mcu_cells);
>> + fan_cells = khadas_mcu_fan_cells;
>> + nfan_cells = ARRAY_SIZE(khadas_mcu_fan_cells);
>> + break;
>> + case KHADAS_MCU_VIM4:
>> + regmap_cfg = &khadas_mcu_vim4_regmap_config;
>> + cells = NULL;
>> + ncells = 0;
>> + fan_cells = khadas_mcu_vim4_cells;
>> + nfan_cells = ARRAY_SIZE(khadas_mcu_vim4_cells);
>
> I'm not as offended by this as I thought I would be!
>
>> + break;
>> + default:
>> + return -ENODEV;
>> + }
>> +
>> i2c_set_clientdata(client, ddata);
>>
>> ddata->dev = dev;
>>
>> - ddata->regmap = devm_regmap_init_i2c(client, &khadas_mcu_regmap_config);
>> + ddata->regmap = devm_regmap_init_i2c(client, regmap_cfg);
>> if (IS_ERR(ddata->regmap)) {
>> ret = PTR_ERR(ddata->regmap);
>> - dev_err(dev, "Failed to allocate register map: %d\n", ret);
>> - return ret;
>> + return dev_err_probe(dev, ret, "Failed to allocate register map\n");
>> }
>>
>> - ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
>> - khadas_mcu_cells,
>> - ARRAY_SIZE(khadas_mcu_cells),
>> - NULL, 0, NULL);
>> - if (ret)
>> - return ret;
>> + if (cells && ncells) {
>> + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
>> + cells,
>> + ncells,
>> + NULL, 0, NULL);
>> + if (ret)
>> + return ret;
>> + }
>>
>> if (of_property_present(dev->of_node, "#cooling-cells"))
>> return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
>> - khadas_mcu_fan_cells,
>> - ARRAY_SIZE(khadas_mcu_fan_cells),
>> + fan_cells,
>> + nfan_cells,
>> NULL, 0, NULL);
>>
>> return 0;
>> @@ -123,7 +205,8 @@ static int khadas_mcu_probe(struct i2c_client *client)
>>
>> #ifdef CONFIG_OF
>> static const struct of_device_id khadas_mcu_of_match[] = {
>> - { .compatible = "khadas,mcu", },
>> + { .compatible = "khadas,mcu", .data = (void *)KHADAS_MCU_GENERIC },
>> + { .compatible = "khadas,vim4-mcu", .data = (void *)KHADAS_MCU_VIM4 },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
>>
>> --
>> 2.49.0
>>
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 2/3] can: rockchip: add RK3588 CAN-FD support
From: Marc Kleine-Budde @ 2026-07-02 11:11 UTC (permalink / raw)
To: Cunhao Lu
Cc: heiko, linux-can, mailhol, kernel, robh, krzk+dt, conor+dt,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <tencent_C422347432620914231601BC882C7E604D08@qq.com>
[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]
On 02.07.2026 17:23:59, Cunhao Lu wrote:
> Hi Marc,
>
> > Is the SoC you're using actually a 'v2' silicon revision? At least on
> > the rk3568 the downstream kernel has code to read the revision.
>
> The kernel reports the CAN-FD controller as rk3588v2 rev2.2:
>
> rockchip_canfd fea60000.can can0: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
> rockchip_canfd fea70000.can can1: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
>
> Following your earlier feedback, I have changed the v2 series to use
> rockchip,rk3588-canfd instead of rockchip,rk3588v2-canfd unless we get
> more information about RK3588 CAN-FD errata and SoC silicon revisions
> from Rockchip.
>
> > Compile the latest https://github.com/linux-can/can-utils/ and test:
> >
> > $ cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32 -b
> > $ cansequence -rv can1 -f
>
> I tested with can0 and can1 directly connected. The CAN clock was
> 200 MHz, and the interfaces were configured as follows:
>
> ip link set can0 down
> ip link set can0 type can bitrate 500000 sample-point 0.8 dbitrate 1000000 dsample-point 0.8 fd on
> ip link set can0 up
>
> ip link set can1 down
> ip link set can1 type can bitrate 500000 sample-point 0.8 dbitrate 1000000 dsample-point 0.8 fd on
> ip link set can1 up
>
> Without BRS, this test ran for 15 minutes without problems:
>
> cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32
>
> With BRS enabled:
>
> cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32 -b
>
> the test only worked when dbitrate was equal to bitrate, for example
> with both set to 1M. If dbitrate differed from bitrate, the
> controller went bus-off immediately.
>
> So my current conclusion is that CAN-FD itself works on RK3588, but the
> support appears incomplete: using a faster data phase with BRS does not
> work in my setup.
Then CAN-FD is broken. :/
Maybe in a later patch we can hack something, to allow working
configurations.
> This looks different from the issue described by the current
> RKCANFD_QUIRK_CANFD_BROKEN comment. That quirk is about specific
> CAN-FD frames triggering Error Interrupt or Error-Warning during
> reception. In my test the non-BRS CAN-FD frames work, while the failure
> is tied to using BRS with a data bitrate different from the nominal
> bitrate, which immediately drives the controller bus-off.
Can you update the description of the quirk for the rk3588 and add how
to reproduce it?
> Given this result, should I still keep CAN-FD disabled for RK3588, or is
> it acceptable to enable CAN-FD but document that BRS with a faster data
> phase is currently not working?
Please keep it disabled for now.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v10 0/5] airoha: an7581: USB support
From: Christian Marangi @ 2026-07-02 9:38 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Christian Marangi, Vinod Koul,
Neil Armstrong, Lorenzo Bianconi, Felix Fietkau, linux-clk,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
This is a major rework of the old v2 series.
The SoC always support USB 2.0 but for USB 3.0 it needs additional
configuration for the Serdes port. Such port can be either configured
for USB usage or for PCIe lines or HSGMII and these are configured
in the SCU space.
The previous implementation of a dedicated SSR driver was too
complex and fragile for the simple task of configuring a register
hence it was dropped and the handling is entirely in the PHY driver.
Everything was reducted to the dt-bindings to describe the Serdes line.
Also the property for the PHY are renamed to a more suitable name and
everything is now mandatory to simplify the implementation.
(the PHY are always present and active on the SoC)
Also other unrelated patch are dropped from this series.
Changes v10:
- Rebase on top of linux-next
- Add review tag for DT patch
Changes v9:
- Add spinlock init
- Add ack tag
- Add review tag
- Add additional comments for phys on USB 3.0
- Add extra logic to make phys optional for USB 3.0
Changes v8:
- Squash header to clk Documentation patch
- Address comments from AI Bot
Link: https://lore.kernel.org/all/20260520150912.11614-1-ansuelsmth@gmail.com/
Changes v7:
- Rework to double PHY implementation
(suggested by Rob)
Now the clk driver expose a PHY for Serdes port
USB PHY driver selects it
- Rebase on top of linux-next
Link: https://lore.kernel.org/all/20260519220813.28468-1-ansuelsmth@gmail.com/
Changes v6:
- Fix kernel test robot (sparse warning)
Link: https://lore.kernel.org/all/20260306190156.22297-1-ansuelsmth@gmail.com/
Changes v5:
- Add Ack and Review tag from Connor
- Implement Ethernet support in the USB driver
(testing support for this Serdes on a special reference board)
- Use an7581 prefix for USB PHY driver
Link: https://lore.kernel.org/all/20251107160251.2307088-1-ansuelsmth@gmail.com/
Changes v4:
- Rename PCIe and USB PHY to AN7581
- Drop airoha,scu (handled directly in driver)
- Drop dt-bindings for monitor clock in favor of raw values
- Better describe the usage of airoha,usb3-serdes
- Simplify values of dt-bindings SSR SERDES
Link: https://lore.kernel.org/all/20251107160251.2307088-1-ansuelsmth@gmail.com/
Changes v3:
- Drop clk changes
- Drop SSR driver
- Rename property in Documentation
- Simplify PHY handling
- Move SSR handling inside the PHY driver
Link: https://lore.kernel.org/all/20251029173713.7670-1-ansuelsmth@gmail.com/
Changes v2:
- Drop changes for simple-mfd
- Rework PHY node structure to single node
- Drop port-id property in favor of serdes-port and
usb2-monitor-clock-sel
- Make the SSR driver probe from the clock driver
Christian Marangi (5):
dt-bindings: clock: airoha: Add PHY binding for Serdes port
dt-bindings: phy: Add documentation for Airoha AN7581 USB PHY
clk: en7523: Add support for selecting the Serdes port in SCU
phy: move and rename Airoha PCIe PHY driver to dedicated directory
phy: airoha: Add support for Airoha AN7581 USB PHY
.../bindings/clock/airoha,en7523-scu.yaml | 9 +
.../bindings/phy/airoha,an7581-usb-phy.yaml | 62 ++
MAINTAINERS | 11 +-
drivers/clk/Kconfig | 1 +
drivers/clk/clk-en7523.c | 218 ++++++-
drivers/phy/Kconfig | 11 +-
drivers/phy/Makefile | 4 +-
drivers/phy/airoha/Kconfig | 24 +
drivers/phy/airoha/Makefile | 4 +
.../phy-an7581-pcie-regs.h} | 2 +-
.../phy-an7581-pcie.c} | 6 +-
drivers/phy/airoha/phy-an7581-usb.c | 559 ++++++++++++++++++
include/dt-bindings/soc/airoha,scu-ssr.h | 11 +
13 files changed, 901 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/airoha,an7581-usb-phy.yaml
create mode 100644 drivers/phy/airoha/Kconfig
create mode 100644 drivers/phy/airoha/Makefile
rename drivers/phy/{phy-airoha-pcie-regs.h => airoha/phy-an7581-pcie-regs.h} (99%)
rename drivers/phy/{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} (99%)
create mode 100644 drivers/phy/airoha/phy-an7581-usb.c
create mode 100644 include/dt-bindings/soc/airoha,scu-ssr.h
--
2.53.0
^ permalink raw reply
* Re: [PATCH] futex: Optimise the size check get_futex_key()
From: Peter Zijlstra @ 2026-07-02 11:18 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: K Prateek Nayak, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Catalin Marinas, Will Deacon,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Darren Hart, Davidlohr Bueso,
André Almeida, linux-arch, linux-kernel, Samuel Holland,
Charlie Jenkins, linux-arm-kernel, linux-riscv, linux-s390,
H. Peter Anvin, Thomas Huth, Sean Christopherson, Jisheng Zhang,
Alexandre Ghiti, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260702105615.PiYhQ9Rt@linutronix.de>
On Thu, Jul 02, 2026 at 12:56:15PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-07-02 10:59:21 [+0200], Peter Zijlstra wrote:
> > > Could someone verify this, please? The 5% look a bit high. This is on
> > > top of the series (but not worsen by the series).
> >
> > Bah, I tried to reproduce and couldn't. Then I noticed I did a clang
> > build and that is in fact clever enough to do this optimization itself.
> >
> > /me tries again with a GCC build.
> >
> > pre: [thread 0] futex: 0x561f14430680 [ 9021408 ops/sec ]
> > post: [thread 0] futex: 0x55feadbbb680 [ 8977527 ops/sec ]
> >
> > (and this seems to be well inside the error threshold of this test).
> >
> > So I see the GCC build do the DIV, and no longer with his patch applied,
> > but for some reason I cannot get the runtime performance to actually
> > improve much of anything on my system.
>
> I did open https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126078 for the
> div.
>
> My .config is the debian distro on the 4 node big iron. [ in case it
> it has so much overhead elsewhere that this place a bigger role].
>
> "perf top" showed this as 6% or something and red in the function. After
> the removal it did not show up.
Right, I build whatever random config I had on the SPR test box. But I
can't argue with the patch, it is sane and GCC does generate better code
with it. For $raisins it just didn't translate into actual performance
for me.
^ permalink raw reply
* Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
From: Leonardo Bras @ 2026-07-02 11:18 UTC (permalink / raw)
To: Marc Zyngier
Cc: Leonardo Bras, Bradley Morgan, Oliver Upton, Fuad Tabba,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Quentin Perret, Vincent Donnefort,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <86qzllpy1g.wl-maz@kernel.org>
On Thu, Jul 02, 2026 at 09:59:23AM +0100, Marc Zyngier wrote:
> + Vincent, Leo
>
> On Wed, 01 Jul 2026 20:24:28 +0100,
> Bradley Morgan <include@grrlz.net> wrote:
> >
> > pKVM keeps its own mapping list for stage 2 operations. Its flush path
> > uses that list directly, so it lost the PTE attribute check done by the
> > generic stage 2 walker.
> >
> > Record whether a mapping is cacheable and skip cache maintenance for
> > mappings that are not cacheable.
> >
> > Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > ---
> > Changes since V3:
> > - addressed some review :)
>
> This isn't a change log. If you want to be taken seriously, I'd
> suggest you start by following the process. You are otherwise wasting
> people's time. Again.
Agree... the process has a reason: the changelog here helps the reviewer
having an overview of what actually changed between versions, and that
makes reviewing much easier, and costs very little to the contributor.
Also, the 1 week waiting time is really important, as mentioned before, as
it allows more reviewers and maintainers to give feedback: different
people, from different companies and lifestyles have different schedules
for dev/rev, but in general it happens weekly. So waiting for a week is
really recommended, as it tends to avoid people re-reading 2+ versions of
the same patchset, and allows revs time to discuss the suggestions in the
same thread.
(I know the waiting can be really frustating, and that sending a vN+1 fast
seems to show that you are interested in it, but it really does not help)
>
> You also failed to Cc people who have provided feedback on previous
> versions. That's not right.
(Bradley: usually you want as many people as possible to review your stuff,
so CC'ing previous reviewers is actually good for you)
>
> >
> > arch/arm64/kvm/pkvm.c | 51 ++++++++++++++++++++++++++++++++++---------
> > 1 file changed, 41 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > index 053e4f733e4b..6d1cad890c7e 100644
> > --- a/arch/arm64/kvm/pkvm.c
> > +++ b/arch/arm64/kvm/pkvm.c
> > @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct pkvm_mapping *m)
> > return m->gfn * PAGE_SIZE;
> > }
> >
> > +#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
> > +#define PKVM_MAPPING_NC BIT_ULL(48)
> > +
> > +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
> > +{
> > + return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> > +}
>
> No. You've been pointed to the correct data structure (an anonymous
> structure containing bit fields). Please consider taking the review
> comments into account.
(and if you do not agree with the suggestion, discuss it in the same
thread. Although as Marc shows below, it becames much simpler like that)
Thanks!
Leo
>
> This would avoid most of the churn in this patch, and make it easy to
> backport. Something like the untested hack below.
>
> M.
>
> diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
> index 74fedd9c5ff02..cdddc9e3a11f5 100644
> --- a/arch/arm64/include/asm/kvm_pkvm.h
> +++ b/arch/arm64/include/asm/kvm_pkvm.h
> @@ -195,7 +195,10 @@ struct pkvm_mapping {
> struct rb_node node;
> u64 gfn;
> u64 pfn;
> - u64 nr_pages;
> + struct {
> + unsigned long nr_pages:48;
> + unsigned int nc:1;
> + };
> u64 __subtree_last; /* Internal member for interval tree */
> };
>
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 428723b1b0f5c..5932b93bded58 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -369,7 +369,7 @@ static int __pkvm_pgtable_stage2_unshare(struct kvm_pgtable *pgt, u64 start, u64
>
> for_each_mapping_in_range_safe(pgt, start, end, mapping) {
> ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
> - mapping->nr_pages);
> + (u64)mapping->nr_pages);
> if (WARN_ON(ret))
> return ret;
> pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> @@ -473,6 +473,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
> mapping->gfn = gfn;
> mapping->pfn = pfn;
> mapping->nr_pages = size / PAGE_SIZE;
> + mapping->nc = !!(prot & (KVM_PGTABLE_PROT_DEVICE | KVM_PGTABLE_PROT_NORMAL_NC));
> pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
>
> return ret;
> @@ -503,7 +504,7 @@ int pkvm_pgtable_stage2_wrprotect(struct kvm_pgtable *pgt, u64 addr, u64 size)
> lockdep_assert_held(&kvm->mmu_lock);
> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
> - mapping->nr_pages);
> + (u64)mapping->nr_pages);
> if (WARN_ON(ret))
> break;
> }
> @@ -517,10 +518,11 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable *pgt, u64 addr, u64 size)
> struct pkvm_mapping *mapping;
>
> lockdep_assert_held(&kvm->mmu_lock);
> - for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> - __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
> - PAGE_SIZE * mapping->nr_pages);
> -
> + for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> + if (!mapping->nc)
> + __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
> + PAGE_SIZE * mapping->nr_pages);
> + }
> return 0;
> }
>
> @@ -537,7 +539,7 @@ bool pkvm_pgtable_stage2_test_clear_young(struct kvm_pgtable *pgt, u64 addr, u64
> lockdep_assert_held(&kvm->mmu_lock);
> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
> - mapping->nr_pages, mkold);
> + (u64)mapping->nr_pages, mkold);
>
> return young;
> }
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel
From: Kiryl Shutsemau (Meta) @ 2026-07-02 11:28 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel
Cc: Jason Gunthorpe, Nicolin Chen, Kyle McMartin, Breno Leitao,
Usama Arif, linux-arm-kernel, iommu, linux-kernel,
Kiryl Shutsemau (Meta)
The command, event and PRI queues are sized from the maxima the hardware
advertises in IDR1, which can be several megabytes each. On systems with
many SMMUv3 instances that cost is paid per instance and adds up to tens
of megabytes of coherent DMA in the capture kernel.
A kdump capture kernel runs from a small crashkernel reservation and only
has to drive the few devices used to save the dump, so deep queues serve
no purpose. The queues carry invalidation commands and fault records, not
DMA data, so dump throughput is unaffected; a shallower queue only bounds
how many commands may be in flight before a sync, which does not matter for
the capture kernel's small device count and modest I/O.
Clamp every queue to a single page when is_kdump_kernel() is true. Doing
it in arm_smmu_init_one_queue() covers the command, event and PRI queues
in one place. The command queue still holds at least one batch plus a sync
(256 entries on a 4K-page kernel, well above CMDQ_BATCH_ENTRIES), so
command batching keeps working.
Suggested-by: Kyle McMartin <jkkm@meta.com>
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
---
v2:
- Use min() instead of min_t(); both operands are u32 so the cast was
redundant (Jason Gunthorpe, Breno Leitao).
- Add Reviewed-by from Breno.
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e8d7dbe495f0..a4ec4a59e527 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4414,6 +4414,20 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
{
size_t qsz;
+ /*
+ * A kdump capture kernel runs from a small crashkernel reservation and
+ * only has to drive the few devices used to save the dump, so there is
+ * no point sizing the queues for the (multi-megabyte) maxima the
+ * hardware advertises. Clamp each queue to a single page. ent_sz_shift
+ * is the log2 of the entry size in bytes (dwords * 8).
+ */
+ if (is_kdump_kernel()) {
+ u32 ent_sz_shift = ilog2(dwords) + 3;
+
+ q->llq.max_n_shift = min(q->llq.max_n_shift,
+ PAGE_SHIFT - ent_sz_shift);
+ }
+
do {
qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] irqchip/gic-v3-its: Reconfigure ITS from software state on resume
From: Bjoern Doebel @ 2026-07-02 11:57 UTC (permalink / raw)
To: stable, Marc Zyngier, Thomas Gleixner, linux-arm-kernel,
linux-kernel, David Woodhouse, Ali Saidi, David Arinzon,
Zeev Zilberman
Cc: Bjoern Doebel
In-Reply-To: <20260507183102.1897629-1-doebel@amazon.de>
Hi all,
gentle ping on this one.
Since the original posting I've re-validated the fix against current
mainline:
- It still applies cleanly to v7.2-rc1 (and to v7.1.0).
- I reproduced the original failure on *stock* v7.2-rc1. On EC2
Graviton instances, hibernation resume fails 100% of the time: the
ITS comes back reset, MAPD/MAPTI are never replayed, and the ENA
NIC silently loses its LPIs:
ena 0000:00:05.0: ... didn't receive a MSI-X interrupt (cmd 3)
ena 0000:00:05.0: Failed to create IO CQ. error: -62
The instance then has no networking after resume.
- With this patch applied, the same kernel survives hibernate/resume
cleanly: 9/9 cycles with zero failures, across all three Graviton
generations (Graviton 2/3/4, i.e. Neoverse N1/V1/V2), networking
fully restored on every resume.
As described in the previous message, this is the fallout from 713335b6ee29
("irqchip/gic-v3-its: Implement .msi_teardown() callback"): device
teardown no longer happens across a suspend/resume that keeps the MSI
domain, so the ITS is never reprogrammed and drops interrupts after the
hardware has been reset.
Could you take a look when you get a chance?
Thanks,
Bjoern
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [PATCH v2 09/19] ARM: update FPE_NWFPE help text
From: Ralph Siemsen @ 2026-07-02 11:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Arnd Bergmann, Aaro Koskinen,
Alexander Sverdlin, Alexandre Belloni, Alexandre Torgue,
Andrew Lunn, Ard Biesheuvel, Claudiu Beznea, Daniel Mack,
Ethan Nelson-Moore, Frank Li, Gregory Clement, Haojian Zhuang,
Jeremy J. Peper, Kristoffer Ericson, Krzysztof Kozlowski,
Linus Walleij, Mark Brown, Marc Zyngier, Mike Rapoport,
Nicolas Ferre, Patrice Chotard, Ralph Siemsen, Robert Jarzmik,
Russell King, Sascha Hauer, Sebastian Hesselbarth, Stefan Agner,
Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy, Will Deacon,
Linus Walleij
In-Reply-To: <20260701212353.2196041-10-arnd@kernel.org>
On Wed, Jul 01, 2026 at 11:23:43PM +0200, Arnd Bergmann wrote:
>
>The help text is seriously outdated and predates the introduction of
>VFP floating point units that were available as early as some ARM926
>based systems.
>
>Change the help text to reflect that this is now a legacy feature
>and that it will go away along with OABI support in the future.
Indeed NWFPE was initially added in order to be able to execute
pre-existing binaries from even earlier systems.
Once soft-float became available in the toolchain, the netwinder
userspace was rebuilt, and NWFPE became largely unnecessary.
All of this happened in the early 2000's.
>Acked-by: Linus Walleij <linus.walleij@linaro.org>
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ralph Siemsen <ralphs@netwinder.org>
Regards,
Ralph
^ permalink raw reply
* Re: [PATCH v2 07/19] ARM: update DEPRECATED_PARAM_STRUCT removal timeline
From: Ralph Siemsen @ 2026-07-02 12:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ethan Nelson-Moore, Arnd Bergmann, linux-arm-kernel, soc,
linux-kernel, Aaro Koskinen, A. Sverdlin, Alexandre Belloni,
Alexandre Torgue, Andrew Lunn, Ard Biesheuvel, Claudiu Beznea,
Daniel Mack, Frank Li, Gregory Clement, Haojian Zhuang,
Jeremy J. Peper, Kristoffer Ericson, Krzysztof Kozlowski,
Linus Walleij, Mark Brown, Marc Zyngier, Mike Rapoport,
Nicolas Ferre, Patrice Chotard, Ralph Siemsen, Robert Jarzmik,
Russell King, Sascha Hauer, Sebastian Hesselbarth, Stefan Agner,
Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <46f76624-ba35-427d-8a60-ec0fe39e5b8c@app.fastmail.com>
On Thu, Jul 02, 2026 at 07:36:02AM +0200, Arnd Bergmann wrote:
>On Thu, Jul 2, 2026, at 02:54, Ethan Nelson-Moore wrote:
>> Hi, Arnd,
>>
>> On Wed, Jul 1, 2026 at 2:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
>>> This configuration option is for the older boot method that preceeded
>>> ATAGS. This was scheduled for removal back in 2001, but the removal
>>> never happened, presumably because nobody cared enough to actually do it,
>>> not because there are any users left.
>>
>> Only netwinder_defconfig selects this option. Do the most recent
>> NetWinder firmware versions actually need it? (LinusW, do you know
>> this?) If not, can't we just drop it entirely?
Support for ATAG was added in firmware v2.0.6 in roughly Jan 1999,
meanwhile the most recent firmware is v2.3.3 (still 20+ years old).
It is quite safe to disable support for the older parameter method.
>If all StrongARM platforms are on the way out after the LTS kernel,
>I don't see a need to remove this any earlier, even if the chance
>that it's still needed is low.
Also agree with this, might as well remove it all in one go.
Regards,
Ralph
^ permalink raw reply
* [PATCH 3/3] arm64: dts: apple: Add pmgr-misc nodes to t60xx
From: Sasha Finkelstein @ 2026-07-02 12:06 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel,
Sasha Finkelstein
In-Reply-To: <20260702-pmgr-misc-v1-0-4f075a3a95c1@chaosmail.tech>
Adds the PMGR misc control nodes for M1/2 Pro/Max/Ultra series devices.
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
arch/arm64/boot/dts/apple/t600x-die0.dtsi | 7 +++++++
arch/arm64/boot/dts/apple/t602x-die0.dtsi | 7 +++++++
2 files changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/apple/t600x-die0.dtsi b/arch/arm64/boot/dts/apple/t600x-die0.dtsi
index f715b19efd16..3271d234b483 100644
--- a/arch/arm64/boot/dts/apple/t600x-die0.dtsi
+++ b/arch/arm64/boot/dts/apple/t600x-die0.dtsi
@@ -24,6 +24,13 @@ aic: interrupt-controller@28e100000 {
power-domains = <&ps_aic>;
};
+ pmgr_misc: power-management@28e20c000 {
+ compatible = "apple,t6000-pmgr-misc";
+ reg = <0x2 0x8e20c000 0 0x400>,
+ <0x2 0x8e20c800 0 0x400>;
+ reg-names = "fabric-ps", "dcs-ps";
+ };
+
smc: smc@290400000 {
compatible = "apple,t6000-smc", "apple,smc";
reg = <0x2 0x90400000 0x0 0x4000>,
diff --git a/arch/arm64/boot/dts/apple/t602x-die0.dtsi b/arch/arm64/boot/dts/apple/t602x-die0.dtsi
index 8622ddea7b44..121f2cf75915 100644
--- a/arch/arm64/boot/dts/apple/t602x-die0.dtsi
+++ b/arch/arm64/boot/dts/apple/t602x-die0.dtsi
@@ -23,6 +23,13 @@ aic: interrupt-controller@28e100000 {
power-domains = <&ps_aic>;
};
+ pmgr_misc: power-management@28e20c000 {
+ compatible = "apple,t6020-pmgr-misc";
+ reg = <0x2 0x8e20c000 0 0x400>,
+ <0x2 0x8e20c400 0 0x400>;
+ reg-names = "fabric-ps", "dcs-ps";
+ };
+
nub_spmi0: spmi@29e114000 {
compatible = "apple,t6020-spmi", "apple,t8103-spmi";
reg = <0x2 0x9e114000 0x0 0x100>;
--
2.55.0
^ permalink raw reply related
* [PATCH 0/3] soc: apple: Add "PMGR misc" power controls driver
From: Sasha Finkelstein @ 2026-07-02 12:06 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel,
Sasha Finkelstein, Hector Martin
Certain Apple SoCs have additional power state controls that are using
a separate "misc" mmio interface. Currently this includes the fabric
and memory controllers on pro/max/ultra SoCs.
This series adds a driver to put those in a low power state when the
machine enters sleep. The power savings are SoC-dependent and are
around 1W.
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
Hector Martin (1):
soc: apple: Add driver for Apple PMGR misc controls
Sasha Finkelstein (2):
dt-bindings: soc: apple: Add bindings for apple PMGR misc controls
arm64: dts: apple: Add pmgr-misc nodes to t60xx
Documentation/devicetree/bindings/soc/apple/apple,t6000-pmgr-misc.yaml | 45 +++++++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm64/boot/dts/apple/t600x-die0.dtsi | 7 +++++
arch/arm64/boot/dts/apple/t602x-die0.dtsi | 7 +++++
drivers/soc/apple/Kconfig | 10 ++++++
drivers/soc/apple/Makefile | 2 ++
drivers/soc/apple/apple-pmgr-misc.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 249 insertions(+)
---
base-commit: 59574e5978abfc2ce1c194ea0200eb6fc718d8ce
change-id: 20260702-pmgr-misc-ae1cbd5bc2c7
Best regards,
--
Sasha Finkelstein <k@chaosmail.tech>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: soc: apple: Add bindings for apple PMGR misc controls
From: Sasha Finkelstein @ 2026-07-02 12:06 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel,
Sasha Finkelstein
In-Reply-To: <20260702-pmgr-misc-v1-0-4f075a3a95c1@chaosmail.tech>
Certain Apple SoCs include additional PMGR power states that are
controlled via a different "misc" control block. On existing SoCs, this
includes the fabric and memory controller state.
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
Documentation/devicetree/bindings/soc/apple/apple,t6000-pmgr-misc.yaml | 45 +++++++++++++++++++++++++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/apple/apple,t6000-pmgr-misc.yaml b/Documentation/devicetree/bindings/soc/apple/apple,t6000-pmgr-misc.yaml
new file mode 100644
index 000000000000..30abedc67fa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/apple/apple,t6000-pmgr-misc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/apple/apple,t6000-pmgr-misc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SoC PMGR Misc Power States
+
+maintainers:
+ - Sasha Finkelstein <k@chaosmail.tech>
+
+description: |
+ Certain Apple SoCs include additional PMGR power states that are controlled
+ via a different "misc" control block. On existing SoCs, this includes the
+ fabric and memory controller state.
+
+properties:
+ compatible:
+ enum:
+ - apple,t6000-pmgr-misc
+ - apple,t6020-pmgr-misc
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: fabric-ps
+ - const: dcs-ps
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ pmgr_misc: power-management@8e20c000 {
+ compatible = "apple,t6000-pmgr-misc";
+ reg = <0x8e20c000 0x400>,
+ <0x8e20c800 0x400>;
+ reg-names = "fabric-ps", "dcs-ps";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..5a29bb86499f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2607,6 +2607,7 @@ F: Documentation/devicetree/bindings/power/apple*
F: Documentation/devicetree/bindings/power/reset/apple,smc-reboot.yaml
F: Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
F: Documentation/devicetree/bindings/rtc/apple,smc-rtc.yaml
+F: Documentation/devicetree/bindings/soc/apple/apple,t6000-pmgr-misc.yaml
F: Documentation/devicetree/bindings/spi/apple,spi.yaml
F: Documentation/devicetree/bindings/spmi/apple,spmi.yaml
F: Documentation/devicetree/bindings/usb/apple,dwc3.yaml
--
2.55.0
^ permalink raw reply related
* [PATCH 2/3] soc: apple: Add driver for Apple PMGR misc controls
From: Sasha Finkelstein @ 2026-07-02 12:06 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel,
Sasha Finkelstein, Hector Martin
In-Reply-To: <20260702-pmgr-misc-v1-0-4f075a3a95c1@chaosmail.tech>
From: Hector Martin <marcan@marcan.st>
Apple SoCs have PMGR blocks that control a bunch of power-related
features. Besides the existing device power state controls (which are
very uniform and handled by apple-pmgr-pwrstate), we also need to manage
more random registers such as SoC-wide fabric and memory controller
power states, which have a different interface.
Add a driver for these kitchen sink controls. Right now it implements
fabric and memory controller power state switching on system
standby/s2idle, which saves about 1W of power or so on t60xx platforms.
Signed-off-by: Hector Martin <marcan@marcan.st>
Co-developed-by: Sasha Finkelstein <k@chaosmail.tech>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
drivers/soc/apple/Kconfig | 10 ++++++++
drivers/soc/apple/Makefile | 2 ++
drivers/soc/apple/apple-pmgr-misc.c | 177 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 189 insertions(+)
diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
index d0ff32182a2b..cad847c90df8 100644
--- a/drivers/soc/apple/Kconfig
+++ b/drivers/soc/apple/Kconfig
@@ -16,6 +16,16 @@ config APPLE_MAILBOX
Say Y here if you have an Apple SoC.
+config APPLE_PMGR_MISC
+ bool "Apple SoC PMGR miscellaneous support"
+ depends on PM
+ help
+ The PMGR block in Apple SoCs provides high-level power state
+ controls for SoC devices. This driver manages miscellaneous
+ power controls.
+
+ Say 'y' here if you have a Pro/Max/Ultra Apple SoC.
+
config APPLE_RTKIT
tristate "Apple RTKit co-processor IPC protocol"
depends on APPLE_MAILBOX
diff --git a/drivers/soc/apple/Makefile b/drivers/soc/apple/Makefile
index 0b85ab61aefe..0481f7f43b06 100644
--- a/drivers/soc/apple/Makefile
+++ b/drivers/soc/apple/Makefile
@@ -3,6 +3,8 @@
obj-$(CONFIG_APPLE_MAILBOX) += apple-mailbox.o
apple-mailbox-y = mailbox.o
+obj-$(CONFIG_APPLE_PMGR_MISC) += apple-pmgr-misc.o
+
obj-$(CONFIG_APPLE_RTKIT) += apple-rtkit.o
apple-rtkit-y = rtkit.o rtkit-crashlog.o
diff --git a/drivers/soc/apple/apple-pmgr-misc.c b/drivers/soc/apple/apple-pmgr-misc.c
new file mode 100644
index 000000000000..d487a87ecddb
--- /dev/null
+++ b/drivers/soc/apple/apple-pmgr-misc.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Apple SoC PMGR device power state driver
+ *
+ * Copyright The Asahi Linux Contributors
+ */
+
+#include <linux/bitops.h>
+#include <linux/bitfield.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+
+#define APPLE_CLKGEN_PSTATE 0
+#define APPLE_CLKGEN_PSTATE_DESIRED GENMASK(3, 0)
+
+#define SYS_DEV_PSTATE_SUSPEND 1
+
+enum sys_device {
+ DEV_FABRIC,
+ DEV_DCS,
+ DEV_MAX,
+};
+
+struct apple_pmgr_sys_device {
+ void __iomem *base;
+ u32 active_state;
+ u32 suspend_state;
+};
+
+struct apple_pmgr_misc_hw {
+ u32 dev_min_ps[DEV_MAX];
+};
+
+struct apple_pmgr_misc {
+ struct device *dev;
+ struct apple_pmgr_sys_device devices[DEV_MAX];
+};
+
+static void apple_pmgr_sys_dev_set_pstate(struct apple_pmgr_misc *misc,
+ enum sys_device dev, bool active)
+{
+ u32 pstate;
+ u32 val;
+
+ if (!misc->devices[dev].base)
+ return;
+
+ if (active)
+ pstate = misc->devices[dev].active_state;
+ else
+ pstate = misc->devices[dev].suspend_state;
+
+ dev_dbg(misc->dev, "set %d ps to pstate %d\n", dev, pstate);
+
+ val = readl_relaxed(misc->devices[dev].base + APPLE_CLKGEN_PSTATE);
+ val &= ~APPLE_CLKGEN_PSTATE_DESIRED;
+ val |= FIELD_PREP(APPLE_CLKGEN_PSTATE_DESIRED, pstate);
+ writel_relaxed(val, misc->devices[dev].base);
+}
+
+static int __maybe_unused apple_pmgr_misc_suspend_noirq(struct device *dev)
+{
+ struct apple_pmgr_misc *misc = dev_get_drvdata(dev);
+ int i;
+
+ for (i = 0; i < DEV_MAX; i++)
+ apple_pmgr_sys_dev_set_pstate(misc, i, false);
+
+ return 0;
+}
+
+static int __maybe_unused apple_pmgr_misc_resume_noirq(struct device *dev)
+{
+ struct apple_pmgr_misc *misc = dev_get_drvdata(dev);
+ int i;
+
+ for (i = 0; i < DEV_MAX; i++)
+ apple_pmgr_sys_dev_set_pstate(misc, i, true);
+
+ return 0;
+}
+
+static bool apple_pmgr_init_device(struct apple_pmgr_misc *misc,
+ const struct apple_pmgr_misc_hw *hw,
+ enum sys_device dev,
+ const char *device_name)
+{
+ void __iomem *base;
+ char name[32];
+ u32 val;
+
+ snprintf(name, sizeof(name), "%s-ps", device_name);
+
+ base = devm_platform_ioremap_resource_byname(
+ to_platform_device(misc->dev), name);
+ if (!base)
+ return false;
+
+ val = readl_relaxed(base + APPLE_CLKGEN_PSTATE);
+
+ misc->devices[dev].base = base;
+ misc->devices[dev].active_state =
+ FIELD_GET(APPLE_CLKGEN_PSTATE_DESIRED, val);
+ misc->devices[dev].suspend_state = hw->dev_min_ps[dev];
+
+ return true;
+}
+
+static int apple_pmgr_misc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct apple_pmgr_misc_hw *hw;
+ struct apple_pmgr_misc *misc;
+ int ret = -ENODEV;
+
+ misc = devm_kzalloc(dev, sizeof(*misc), GFP_KERNEL);
+ if (!misc)
+ return -ENOMEM;
+
+ misc->dev = dev;
+ hw = of_device_get_match_data(dev);
+
+ if (apple_pmgr_init_device(misc, hw, DEV_FABRIC, "fabric"))
+ ret = 0;
+
+ if (apple_pmgr_init_device(misc, hw, DEV_DCS, "dcs"))
+ ret = 0;
+
+ platform_set_drvdata(pdev, misc);
+
+ return ret;
+}
+
+static const struct apple_pmgr_misc_hw apple_pmgr_misc_hw_t600x = {
+ .dev_min_ps = {
+ [DEV_FABRIC] = SYS_DEV_PSTATE_SUSPEND,
+ [DEV_DCS] = 7,
+ },
+};
+
+static const struct apple_pmgr_misc_hw apple_pmgr_misc_hw_t602x = {
+ .dev_min_ps = {
+ [DEV_FABRIC] = SYS_DEV_PSTATE_SUSPEND,
+ [DEV_DCS] = SYS_DEV_PSTATE_SUSPEND,
+ },
+};
+
+static const struct of_device_id apple_pmgr_misc_of_match[] = {
+ { .compatible = "apple,t6000-pmgr-misc", .data = &apple_pmgr_misc_hw_t600x },
+ { .compatible = "apple,t6020-pmgr-misc", .data = &apple_pmgr_misc_hw_t602x },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, apple_pmgr_misc_of_match);
+
+static const struct dev_pm_ops apple_pmgr_misc_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(apple_pmgr_misc_suspend_noirq,
+ apple_pmgr_misc_resume_noirq)
+};
+
+static struct platform_driver apple_pmgr_misc_driver = {
+ .probe = apple_pmgr_misc_probe,
+ .driver = {
+ .name = "apple-pmgr-misc",
+ .of_match_table = apple_pmgr_misc_of_match,
+ .pm = pm_ptr(&apple_pmgr_misc_pm_ops),
+ },
+};
+
+MODULE_AUTHOR("Hector Martin <marcan@marcan.st>");
+MODULE_DESCRIPTION("PMGR misc driver for Apple SoCs");
+MODULE_LICENSE("GPL");
+
+module_platform_driver(apple_pmgr_misc_driver);
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v15 0/8] arm64: add ARCH_HAS_COPY_MC support
From: Ashok Raj @ 2026-07-02 12:17 UTC (permalink / raw)
To: Ruidong Tian
Cc: catalin.marinas, will, rafael, tony.luck, guohanjun, mchehab,
xueshuai, tongtiangen, james.morse, robin.murphy, andreyknvl,
dvyukov, vincenzo.frascino, mpe, npiggin, ryabinin.a.a, glider,
christophe.leroy, aneesh.kumar, naveen.n.rao, tglx, mingo,
linux-arm-kernel, linux-mm, linuxppc-dev, linux-kernel, kasan-dev,
Ashok Raj
In-Reply-To: <20260618092124.3901230-1-tianruidong@linux.alibaba.com>
On Thu, Jun 18, 2026 at 05:21:14PM +0800, Ruidong Tian wrote:
> This series continues Tong Tiangen's work on arm64 ARCH_HAS_COPY_MC
> support. We encounter the same problem, and from a forward-looking
> perspective, large-memory ARM machines will suffer more from this class
> of issues, which motivates us to push this feature upstream.
>
> Problem
> =========
> With the increase of memory capacity and density, the probability of memory
> error also increases. The increasing size and density of server RAM in data
> centers and clouds have shown increased uncorrectable memory errors.
>
> Currently, more and more scenarios that can tolerate memory errors, such as
> COW[1,2,8,9], KSM copy[3], coredump copy[4], khugepaged[5,6], uaccess copy[7],
> page migration[10,11], etc.
>
Hi Ruidong,
just a minor editorial nit :-)
> [PATCH v15 0/8] arm64: add ARCH_HAS_COPY_MC support
the series has 9 patches, but Subject says 0/8.
Cheers,
Ashok
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: dts: lx2160a: transition to device-specific SerDes compatible strings
From: Frank Li @ 2026-07-02 12:23 UTC (permalink / raw)
To: Ioana Ciornei
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel, imx
In-Reply-To: <b5lpw3xu6svsq7xmmgp3jn4cg455zhp3iw4q6lcsxq4bqy7mwh@guuitghg3xal>
On Thu, Jul 02, 2026 at 10:35:00AM +0300, Ioana Ciornei wrote:
> On Wed, Jul 01, 2026 at 09:27:03AM -0500, Frank Li wrote:
> > On Wed, Jul 01, 2026 at 04:11:33PM +0300, Ioana Ciornei wrote:
> > > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > >
> > > Align to the modern fsl,lynx-28g.yaml binding, where the SoC and SerDes
> > > instance is present in the compatible string, to allow reliable per-lane
> > > capability detection and per-lane customization of electrical properties.
> > >
> > > The modern bindings are backward-incompatible with old kernels, due
> > > to the consumer phandles being either in one form or in another, as
> > > explained here:
> > > https://lore.kernel.org/lkml/20250930140735.mvo3jii7wgmzh2bs@skbuf/
> > >
> > > One of the major differences between the LX2160A and LX2162A is the
> > > SerDes. So far, LX2162A has used fsl-lx2160a-rev2.dtsi, but we need to
> > > split that up even further, and derive a fsl-lx2162a.dtsi which
> > > overrides the SerDes properties.
> > >
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > > ---
> > > Changes in v2:
> > > - Enable serdes_1 on all board DTs that has consumers for it.
> > > - Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
> > > - Remove paragraph from commit message which mentioned some consumer
> > > changes that are no longer needed nor part of the commit.
> > > ---
> > > .../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
> > > .../dts/freescale/fsl-lx2160a-half-twins.dts | 4 +
> > > .../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
> > > .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
> > > .../dts/freescale/fsl-lx2162a-clearfog.dts | 6 +-
> > > .../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
> > > .../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
> > > 7 files changed, 190 insertions(+), 4 deletions(-)
> > > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
> > >
> > ...
> > >
> > > +&serdes_1 {
> > > + status = "okay";
> > > +};
> > > +
> >
> > Can you try keep alphabet order? may old file is not ordersed, but try
> > best, at least should before &uart0
>
> Sure, will move it.
>
> >
> > > &uart1 {
> > > status = "okay";
> > > };
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > index 1d73abffa6b7..a687eb3e3190 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >
> > Please split chips dtsi and boards dts to two patch.
>
> Ok, I will split the serdes_1 explicit enable into a prep patch.
>
> >
> > > @@ -621,17 +621,163 @@ soc: soc {
> > > ranges;
> > > dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
> > >
> > > + /* Note on the interpretation of SerDes lane numbering from
> > > + * LX2160ARM lane mappings for RCW[SRDS_PRTCL_S1]:
> > > + * The letters (A-H) correspond to logical lane numbers in the
> > > + * SerDes register map (lane A's registers start with LNAGCR0),
> > > + * while the numbers (0-7) correspond to physical lanes as
> > > + * routed to pins. SerDes block #1 is flipped in the LX2160A
> > > + * floorplan (logical lane A goes to physical lane 7's pins),
> > > + * while SerDes blocks #2 and #3 are not. The lanes below are
> > > + * listed right to left when looking at that table.
> > > + * Both the numbers and the letters are according to the logical
> > > + * numbering scheme, and do not account for the flipping.
> > > + */
> > ...
> > > + compatible = "fsl,lx2160a-serdes3";
> > > + reg = <0x0 0x1ec0000 0x0 0x1e30>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + status = "disabled";
> >
> > status should be last property
>
> Ok, will move it.
>
> >
> > > + #phy-cells = <1>;
> > > +
> > > + serdes_3_lane_a: phy@0 {
> > > + reg = <0>;
> > > + #phy-cells = <0>;
> > > + };
> > > +
> > ...
> > > +
> > > +#include "fsl-lx2160a-rev2.dtsi"
> > > +
> > > +&serdes_1 {
> > > + compatible = "fsl,lx2162a-serdes1", "fsl,lynx-28g";
> > > +
> > > + /delete-node/ phy@0;
> > > + /delete-node/ phy@1;
> > > + /delete-node/ phy@2;
> > > + /delete-node/ phy@3;
> >
> > Now, do not perfer delete-node. if ver2 is not include phy@0, ...
> >
> > create ver2 files, let ver2 include it. Now most people like A + B, not
> > A - B.
> >
>
> I am not sure I follow what you say about the ver2 files - are you
> referring to -rev2 or LX2162A?
>
> The LX2162A is a version of the LX2160A SoC, also known as "LX2-Lite".
> And the main difference is that the LX2162A does not have the 3rd SerDes
> block and only 4 SerDes lanes on the first block.
If it is the same die and it is disable by fuse box. I suggest leave it here
now because default it is disabled and try to access-control-cell in future.
https://lore.kernel.org/imx/20241212-imx-ocotp-v1-1-198bb0af86a0@nxp.com/
That these nodes can be dymatically disabled it.
If it is difference die, it should lx2160a.dtsi include lx2-lite. you
can rename old lx2160a.dtsi to lx2-lites.dtsi. You need adjust file name
and I just said overwhole method.
Frank
>
> The delete-node is reflecting exactly how the SoCs came about, the
> LX2162A is a smaller version of the LX2160A (which came first) and not
> the other way around.
>
> I feel like it's unnecessary churn but let me know if you feel strongly
> about this.
>
> Thanks,
> Ioana
^ permalink raw reply
* Re: [PATCH v15 10/11] arm64: entry: Convert to generic entry
From: Will Deacon @ 2026-07-02 12:34 UTC (permalink / raw)
To: Ada Couprie Diaz
Cc: Jinjie Ruan, catalin.marinas, oleg, tglx, peterz, luto, kees, wad,
mark.rutland, yeoreum.yun, linusw, kevin.brodsky, ldv, thuth,
james.morse, song, anshuman.khandual, broonie, ryan.roberts,
pengcan, liqiang01, linux-arm-kernel, linux-kernel
In-Reply-To: <cfa07466-225b-476f-adf9-346bd1377a4d@arm.com>
On Wed, Jun 24, 2026 at 04:32:17PM +0100, Ada Couprie Diaz wrote:
> On 11/05/2026 10:21, Jinjie Ruan wrote:
> > 3. Architecture-Specific Hooks (asm/entry-common.h):
> > - Implement arch_ptrace_report_syscall_entry() and _exit() by
> > porting the existing arm64 logic to the generic interface.
> >
> > - Add arch_syscall_is_vdso_sigreturn() to asm/syscall.h to
> > support Syscall User Dispatch (SUD).
> Related to the above : I feel this is missing an important information.
> Given that SUD is only controlled by `CONFIG_GENERIC_ENTRY`,
> converting to generic entry _requires_ supporting SUD, so we do it here.
> I think this would be important to mention, as I otherwise felt like this
> change did not belong in this patch.
>
> General question that follows : does it make sense to require an arch
> to support Syscall User Dispatch to be able to convert to generic entry ?
> (I assume not really, given that only `arch_syscall_is_vdso_sigreturn()` is
> required on the arch side, but I am curious)
I think SUD should be separated from generic entry. I'm certainly keen
on the latter for arm64 and far less interested in the former. See this
series from Gregory:
https://lore.kernel.org/all/20260627205551.769684-1-gourry@gourry.net/
Will
^ permalink raw reply
* Re: [PATCH 0/4 v2] Serdes: s32g: Add support for serdes subsystem
From: Jan Petrous @ 2026-07-02 12:42 UTC (permalink / raw)
To: Vincent Guittot
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, linux, ghennadi.procopciuc, Ionut.Vicovan,
linux-phy, devicetree, linux-kernel, linux-arm-kernel, netdev,
horms, Frank.li
In-Reply-To: <20260203161917.1666696-1-vincent.guittot@linaro.org>
On Tue, Feb 03, 2026 at 05:19:13PM +0100, Vincent Guittot wrote:
> s32g SoC family includes 2 serdes subsystems which are made of one PCIe
> controller, 2 XPCS and a shared Phy. The Phy got 2 lanes that can be
> configured to output PCIe lanes and/or SGMII.
>
> Implement PCIe phy and XPCS support.
>
> Change since v1:
> - Fix compile_test
> - Use devm_reset_control_get_exclusive()
> - Fix s32g_serdes_phy_set_mode_ext()
> - Manage devm_clk_bulk_get_all() returns 0
> - Fix s32g_serdes_parse_lanes() error management
> - Move xpcs filein drivers/net/pcs/
> - Add pcs_inband_caps()
> - Fix functions in phylink_pcs_ops
> - Fix MAINTAINERS
>
>
> Vincent Guittot (4):
> dt-bindings: serdes: s32g: Add NXP serdes subsystem
> phy: s32g: Add serdes subsystem phy
> phy: s32g: Add serdes xpcs subsystem
> MAINTAINERS: Add MAINTAINER for NXP S32G Serdes driver
>
> .../bindings/phy/nxp,s32g-serdes.yaml | 154 +++
> MAINTAINERS | 10 +
> drivers/net/pcs/Makefile | 1 +
> drivers/net/pcs/pcs-nxp-s32g-xpcs.c | 1006 +++++++++++++++++
> drivers/phy/freescale/Kconfig | 10 +
> drivers/phy/freescale/Makefile | 1 +
> drivers/phy/freescale/phy-nxp-s32g-serdes.c | 953 ++++++++++++++++
> include/linux/pcs/pcs-nxp-s32g-xpcs.h | 50 +
> 8 files changed, 2185 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> create mode 100644 drivers/net/pcs/pcs-nxp-s32g-xpcs.c
> create mode 100644 drivers/phy/freescale/phy-nxp-s32g-serdes.c
> create mode 100644 include/linux/pcs/pcs-nxp-s32g-xpcs.h
>
> --
> 2.43.0
>
Hi Vincent, all,
I'm taking over the S32G SerDes/XPCS upstreaming. The effort has moved in-house
at NXP and I'll be carrying it forward, continuing from this v2 rather than
restarting from zero.
Vincent, thanks for the v1->v2 groundwork. I'll keep your authorship on the
patches that originate from your series (Co-developed-by plus your
Signed-off-by) and build on top; I'll send you v3 off-list first, as you
offered.
A v3 is in preparation and will come as an RFC, with the v2 review comments
addressed.
Vincent, if you're OK with the handoff, a short ack here would help make the
transition visible to the reviewers.
Thanks.
/Jan
^ permalink raw reply
* Re: [PATCH 0/4 v2] Serdes: s32g: Add support for serdes subsystem
From: Vincent Guittot @ 2026-07-02 12:46 UTC (permalink / raw)
To: Jan Petrous
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, linux, ghennadi.procopciuc, Ionut.Vicovan,
linux-phy, devicetree, linux-kernel, linux-arm-kernel, netdev,
horms, Frank.li
In-Reply-To: <akZcpgDSjAg6gcok@lsv051416.swis.nl-cdc01.nxp.com>
On Thu, 2 Jul 2026 at 14:42, Jan Petrous <jan.petrous@oss.nxp.com> wrote:
>
> On Tue, Feb 03, 2026 at 05:19:13PM +0100, Vincent Guittot wrote:
> > s32g SoC family includes 2 serdes subsystems which are made of one PCIe
> > controller, 2 XPCS and a shared Phy. The Phy got 2 lanes that can be
> > configured to output PCIe lanes and/or SGMII.
> >
> > Implement PCIe phy and XPCS support.
> >
> > Change since v1:
> > - Fix compile_test
> > - Use devm_reset_control_get_exclusive()
> > - Fix s32g_serdes_phy_set_mode_ext()
> > - Manage devm_clk_bulk_get_all() returns 0
> > - Fix s32g_serdes_parse_lanes() error management
> > - Move xpcs filein drivers/net/pcs/
> > - Add pcs_inband_caps()
> > - Fix functions in phylink_pcs_ops
> > - Fix MAINTAINERS
> >
> >
> > Vincent Guittot (4):
> > dt-bindings: serdes: s32g: Add NXP serdes subsystem
> > phy: s32g: Add serdes subsystem phy
> > phy: s32g: Add serdes xpcs subsystem
> > MAINTAINERS: Add MAINTAINER for NXP S32G Serdes driver
> >
> > .../bindings/phy/nxp,s32g-serdes.yaml | 154 +++
> > MAINTAINERS | 10 +
> > drivers/net/pcs/Makefile | 1 +
> > drivers/net/pcs/pcs-nxp-s32g-xpcs.c | 1006 +++++++++++++++++
> > drivers/phy/freescale/Kconfig | 10 +
> > drivers/phy/freescale/Makefile | 1 +
> > drivers/phy/freescale/phy-nxp-s32g-serdes.c | 953 ++++++++++++++++
> > include/linux/pcs/pcs-nxp-s32g-xpcs.h | 50 +
> > 8 files changed, 2185 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> > create mode 100644 drivers/net/pcs/pcs-nxp-s32g-xpcs.c
> > create mode 100644 drivers/phy/freescale/phy-nxp-s32g-serdes.c
> > create mode 100644 include/linux/pcs/pcs-nxp-s32g-xpcs.h
> >
> > --
> > 2.43.0
> >
>
> Hi Vincent, all,
> I'm taking over the S32G SerDes/XPCS upstreaming. The effort has moved in-house
> at NXP and I'll be carrying it forward, continuing from this v2 rather than
> restarting from zero.
>
> Vincent, thanks for the v1->v2 groundwork. I'll keep your authorship on the
> patches that originate from your series (Co-developed-by plus your
> Signed-off-by) and build on top; I'll send you v3 off-list first, as you
> offered.
>
> A v3 is in preparation and will come as an RFC, with the v2 review comments
> addressed.
>
> Vincent, if you're OK with the handoff, a short ack here would help make the
> transition visible to the reviewers.
Ack
Thanks
Vincent
>
> Thanks.
> /Jan
>
^ 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