* Re: [RFC PATCH] KVM: Ignore MMU notifiers for guest_memfd-only memslots
From: Alexandru Elisei @ 2026-06-17 13:50 UTC (permalink / raw)
To: David Hildenbrand
Cc: pbonzini, kvm, linux-kernel, maz, oupton, suzuki.poulose, kvmarm,
linux-arm-kernel, seanjc, mark.rutland
In-Reply-To: <3b1cda8e-96d2-4b66-9916-caef7762209e@arm.com>
Hi David,
On Wed, Jun 17, 2026 at 03:41:41PM +0200, David Hildenbrand wrote:
> On 6/17/26 15:23, Alexandru Elisei wrote:
> > Hi David,
> >
> > On Mon, Jun 15, 2026 at 09:07:50PM +0200, David Hildenbrand wrote:
> >> On 6/15/26 17:52, Alexandru Elisei wrote:
> >>> For guest_memfd-only memslots (kvm_memslot_is_gmem_only() is true), the
> >>> memory provider for the virtual machine is the guest_memfd file, not the
> >>> userspace mapping. Faults are resolved using the guest_memfd page cache,
> >>> and the permissions for the secondary MMU mapping depends exclusively on
> >>> the memslot (i.e, if the memslot is read-only). How userspace happens to
> >>> have the memory mmaped at fault time, or even if the memory is mapped at
> >>> all into userspace, is not taken into consideration.
> >>>
> >>> guest_memfd memory is not evictable, is not movable and there's no backing
> >>> storage. Once memory is allocated for an offset in guest_memfd file, the
> >>> offset will not change, and that memory is not freed unless userspace
> >>> explicitly punches a hole in the file. As a result, memory reclaim, page
> >>> migration, page aging and dirty page tracking for the userspace mapping
> >>> serve little purpose.
> >>
> >> I don't think any of that is relevant for the patch at hand?
> >>
> >> The thing is: invalidation (truncation, later migration, for any other reason)
> >> is driven through guest_memfd notifications, not through unrelated page tables.
> >>
> >> If we don't lookup pages for the KVM MMU through the page table, then there is
> >> also no need for MMU notifiers. It's all guest_memfd only.
> >>
> >> Or am I missing something?
> >
> > My thinking was that, because guest_memfd is not evictable, there is no need to
> > do page ageing, which would require that secondary MMU mappings be made old.
>
> Not really.
>
> The KVM MMU did not obtain the folios through the page tables, but directly
> through guest_memfd. Any aging would, therefore, have to be done through
> guest_memfd.
>
> Which we don't support and don't want to support :)
>
> That we happen to have a matching user space range that maps the guest_memfd is
> just coincidence from a KVM MMU point of view.
>
> >
> > The invalidate callbacks are also used when userspace memory is marked read-only
> > for dirty state tracking. I was trying to explaing that, since there is no
> > backing for the guest_memfd file, host doesn't need to keep track of dirty state
> > for the memory, and ignoring the invalidate callbacks is correct for all cases.
> >
> > I can drop the paragraph entirely, if you think that would make the commit
> > message clearer.
>
> I think the real motivation is:
>
> "Mappings in the secondary MMU were established by obtaining folios from
> guest_memfd directly, not by looking the folios up through the page tables
> through GUP. Consequently, there is no relationship between the page tables and
> the secondary MMU: MMU notifiers do not apply."
That's much better than my version, thanks!
Alex
^ permalink raw reply
* Re: [PATCH v2] arm64: tlbflush: Don't broadcast if mm was only active on local cpu
From: Will Deacon @ 2026-06-17 13:58 UTC (permalink / raw)
To: Mark Rutland
Cc: Linu Cherian, Catalin Marinas, Ryan Roberts, Kevin Brodsky,
Anshuman Khandual, Yang Shi, Huang Ying, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajDpc1-c2_zhycr6@J2N7QTR9R3>
On Tue, Jun 16, 2026 at 07:13:07AM +0100, Mark Rutland wrote:
> On Mon, Jun 15, 2026 at 03:44:20PM +0100, Will Deacon wrote:
> > On Mon, Jun 15, 2026 at 01:39:43PM +0100, Mark Rutland wrote:
> > > Regardless of the erratum, to correctly handle a vCPU being migrated
> > > from pCPU-x to pCPU-y, we rely on:
> > >
> > > * The host to set HCR_EL2.FB to ensure that TLB maintenance is
> > > broadcast to the ISH domain.
> > >
> > > * The host to set HCR_EL2.BSU to ensure the DSB is upgrade to ISH such
> > > that any guest-issued DSB NSH will it can complete any TLB maintenance
> > > that was upgraded to ISH.
> > >
> > > * The host to issue a DSB ISH on pCPU-x before the vCPU can run on
> > > pCPU-y, to complete any outstanding maintenance that was issued on
> > > pCPU-x. IIUC a DSB ISH on pCPU-y is not architecturally sufficient; it
> > > must be executed on the same CPU which issued the TLB maintenance.
> > >
> > > ... but as above, all of that should be independent of any of the errata
> > > that require the workaround.
> >
> > Yes, I understand all of the above but the case I'm struggling with is
> > where a vCPU runs on a system that needs the TLB invalidation to be
> > performed twice. For non-broadcast invalidation (from the guest
> > perspective), this patch will mean that it only performs the
> > invalidation once. So if the vCPU migrates to another physical CPU, can
> > that effectively undo the HCR_EL2.FB upgrade unless KVM issues TLB
> > invalidation as well as a DSB on migration?
> >
> > Maybe I'm missing something, as it looks like upstream already elides
> > the call to __tlbi_sync_s1ish() for the NOBROADCAST case.
>
> The key thing is that these errata only affect the completion of memory
> accesses, and only those accesses made by other (physical) PEs.
Thanks. That sort of detail isn't generally disclosed in the writeups,
but if you're certain that applies to all of the errata workarounds
selecting CONFIG_ARM64_WORKAROUND_REPEAT_TLBI, then let's rename
that config option and document this somewhere (in the Kconfig help?)
to make sure that anybody trying to use this workaround to e.g. resolve
problems on the broadcasting side, are aware that it won't necessarily
help.
> A single TLBI will correctly remove the actual TLB entries, and
> HCR_EL2.{FB,BSU} will still ensure that TLB entries are removed from the
> TLBs of other PEs.
>
> The errata only prevent completion of memory accesses made on other
> (physical) PEs, and:
>
> * For accesses made by the vCPU which is issuing the TLBI(s):
>
> - Regardless of the errata, the hypervisor has to ensure that when a
> vCPU is migrated from pCPU-x to pCPU-y, any prior CMOs or TLBIs are
> completed, which requires the host to execute a DSB ISH on pCPU-x
> before the vCPU can be run on pCPU-y.
>
> Maybe we have a latent bug here?
I think that should happen in the context switch path (see the
barrier in __switch_to()).
Will
^ permalink raw reply
* Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper
From: Ahmed Tiba @ 2026-06-17 13:41 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, will, xueshuai, saket.dumbre, mchehab, dave,
djbw, bp, tony.luck, guohanjun, lenb, skhan, vishal.l.verma,
rafael, corbet, ira.weiny, dave.jiang, krzk+dt, catalin.marinas,
alison.schofield, conor+dt, linux-arm-kernel, Michael.Zhao2,
linux-doc, linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree,
linux-acpi, linux-edac, acpica-devel
In-Reply-To: <20260612144910.GA989816-robh@kernel.org>
On 12/06/2026 15:49, Rob Herring wrote:
> On Thu, Jun 11, 2026 at 03:22:21PM +0100, Ahmed Tiba wrote:
>> On 29/05/2026 17:44, Jonathan Cameron wrote:
>>> On Fri, 29 May 2026 10:50:49 +0100
>>> Ahmed Tiba<ahmed.tiba@arm.com> wrote:
>>>> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 54 ++++++++++++++++++++++
>>>> MAINTAINERS | 5 ++
>>>> 2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>>>> new file mode 100644
>>>> index 000000000000..3d4de096093f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>>>> @@ -0,0 +1,54 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id:http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Arm RAS CPER provider
>>>> +
>>>> +maintainers:
>>>> + - Ahmed Tiba<ahmed.tiba@arm.com>
>>>> +
>>>> +description:
>>>> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
>>>> + a firmware-first CPER error source directly via DeviceTree. Firmware
>>>> + provides the CPER Generic Error Status block and notifies the OS through
>>>> + an interrupt.
>>> I'd like some spec references in here if possible.
>> I can add a reference to the UEFI CPER specification for the Generic
>> Error Status record format.
>>
>> For the firmware-first DT description itself I do not have a more specific
>> public reference to cite.
>
> Is there a platform actually using this with DT (FVP doesn't really
> count)?
>
> Rob
Yes. The initial intended user is the upstream zena-css platform,
with validation so far on FVP.
I will note that in the next revision commit message and cover letter.
Best regards,
Ahmed
^ permalink raw reply
* Re: [RFC PATCH] KVM: Ignore MMU notifiers for guest_memfd-only memslots
From: David Hildenbrand @ 2026-06-17 13:41 UTC (permalink / raw)
To: Alexandru Elisei
Cc: pbonzini, kvm, linux-kernel, maz, oupton, suzuki.poulose, kvmarm,
linux-arm-kernel, seanjc, mark.rutland
In-Reply-To: <ajKf41Fgy_jKBAMI@raptor>
On 6/17/26 15:23, Alexandru Elisei wrote:
> Hi David,
>
> On Mon, Jun 15, 2026 at 09:07:50PM +0200, David Hildenbrand wrote:
>> On 6/15/26 17:52, Alexandru Elisei wrote:
>>> For guest_memfd-only memslots (kvm_memslot_is_gmem_only() is true), the
>>> memory provider for the virtual machine is the guest_memfd file, not the
>>> userspace mapping. Faults are resolved using the guest_memfd page cache,
>>> and the permissions for the secondary MMU mapping depends exclusively on
>>> the memslot (i.e, if the memslot is read-only). How userspace happens to
>>> have the memory mmaped at fault time, or even if the memory is mapped at
>>> all into userspace, is not taken into consideration.
>>>
>>> guest_memfd memory is not evictable, is not movable and there's no backing
>>> storage. Once memory is allocated for an offset in guest_memfd file, the
>>> offset will not change, and that memory is not freed unless userspace
>>> explicitly punches a hole in the file. As a result, memory reclaim, page
>>> migration, page aging and dirty page tracking for the userspace mapping
>>> serve little purpose.
>>
>> I don't think any of that is relevant for the patch at hand?
>>
>> The thing is: invalidation (truncation, later migration, for any other reason)
>> is driven through guest_memfd notifications, not through unrelated page tables.
>>
>> If we don't lookup pages for the KVM MMU through the page table, then there is
>> also no need for MMU notifiers. It's all guest_memfd only.
>>
>> Or am I missing something?
>
> My thinking was that, because guest_memfd is not evictable, there is no need to
> do page ageing, which would require that secondary MMU mappings be made old.
Not really.
The KVM MMU did not obtain the folios through the page tables, but directly
through guest_memfd. Any aging would, therefore, have to be done through
guest_memfd.
Which we don't support and don't want to support :)
That we happen to have a matching user space range that maps the guest_memfd is
just coincidence from a KVM MMU point of view.
>
> The invalidate callbacks are also used when userspace memory is marked read-only
> for dirty state tracking. I was trying to explaing that, since there is no
> backing for the guest_memfd file, host doesn't need to keep track of dirty state
> for the memory, and ignoring the invalidate callbacks is correct for all cases.
>
> I can drop the paragraph entirely, if you think that would make the commit
> message clearer.
I think the real motivation is:
"Mappings in the secondary MMU were established by obtaining folios from
guest_memfd directly, not by looking the folios up through the page tables
through GUP. Consequently, there is no relationship between the page tables and
the secondary MMU: MMU notifiers do not apply."
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Mark Brown @ 2026-06-16 12:03 UTC (permalink / raw)
To: linux-spi, Kunihiko Hayashi
Cc: linux-arm-kernel, linux-kernel, Sangyun Kim, Kyungwook Boo,
stable, Masami Hiramatsu
In-Reply-To: <20260616011223.201357-1-hayashi.kunihiko@socionext.com>
On Tue, 16 Jun 2026 10:12:23 +0900, Kunihiko Hayashi wrote:
> spi: uniphier: Fix completion initialization order before devm_request_irq()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2
Thanks!
[1/1] spi: uniphier: Fix completion initialization order before devm_request_irq()
https://git.kernel.org/broonie/spi/c/37f18700d941
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH v2 3/5] ARM: dts: mediatek: mt8127: Fix indentation error
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Fix an indentation error caused by a space at the start of a line.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index aced173c2a52..bd61ec7e70c0 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -75,7 +75,7 @@ uart_clk: dummy26m {
compatible = "fixed-clock";
clock-frequency = <26000000>;
#clock-cells = <0>;
- };
+ };
};
timer {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: mediatek: mt8127: Add watchdog support
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add watchdog node and disable it by default as it was not present
initially.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index bd61ec7e70c0..3e23673e7a9e 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -99,6 +99,13 @@ soc {
compatible = "simple-bus";
ranges;
+ watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8127-wdt","mediatek,mt6589-wdt";
+ reg = <0 0x10007000 0 0x100>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
+ status = "disabled";
+ };
+
timer: timer@10008000 {
compatible = "mediatek,mt8127-timer",
"mediatek,mt6577-timer";
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: watchdog: mediatek: Add MT8127
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:36 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami, Krzysztof Kozlowski
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for MT8127 SoC's watchdog which is compatible with MT6589's
one.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 953629cb9558..e6e4546da0aa 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -40,6 +40,7 @@ properties:
- mediatek,mt7622-wdt
- mediatek,mt7623-wdt
- mediatek,mt7629-wdt
+ - mediatek,mt8127-wdt
- mediatek,mt8173-wdt
- mediatek,mt8188-wdt
- mediatek,mt8189-wdt
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for the MT8127 based Amazon ford tablet.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af..853f5e8cd158 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -122,6 +122,7 @@ properties:
- const: mediatek,mt7988a
- items:
- enum:
+ - amazon,ford
- mediatek,mt8127-moose
- const: mediatek,mt8127
- items:
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/5] ARM: Basic support for Amazon ford tablet (MT8127)
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:36 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami, Krzysztof Kozlowski
This series of patches adds basic support for MT8127 SoC based Amazon ford
tablet and fixes a small indentation error in the dtsi file.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Changes in v2:
- Move amazon ford compatible string to existing enum.
- Fix watchdog node not sorted in unit address ascending order (sashiko report).
- Move bindings documentation patches before patches implementing the bindings.
- Link to v1: https://lore.kernel.org/r/20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me
---
Zakariya Hadrami (5):
dt-bindings: watchdog: mediatek: Add MT8127
dt-bindings: arm: mediatek: Add MT8127 Amazon ford
ARM: dts: mediatek: mt8127: Fix indentation error
ARM: dts: mediatek: mt8127: Add watchdog support
ARM: dts: mediatek: Add basic support for Amazon ford board
.../devicetree/bindings/arm/mediatek.yaml | 1 +
.../bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 ++++++++++++++++++++++
arch/arm/boot/dts/mediatek/mt8127.dtsi | 9 ++++-
5 files changed, 57 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260616-mt8127-amazon-ford-basic-1509d7052f7e
Best regards,
--
Zakariya Hadrami <zkh1@proton.me>
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: mediatek: Add basic support for Amazon ford board
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
This tablet uses a MediaTek MT8127 system-on-chip with 1GB of RAM.
It can currently boot into initramfs with a working UART and
Simple Framebuffer using already initialized panel by the bootloader.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 +++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/Makefile b/arch/arm/boot/dts/mediatek/Makefile
index 37c4cded0eae..a610bc75c7d9 100644
--- a/arch/arm/boot/dts/mediatek/Makefile
+++ b/arch/arm/boot/dts/mediatek/Makefile
@@ -14,5 +14,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-rfb-emmc.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
+ mt8127-amazon-ford.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
diff --git a/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
new file mode 100644
index 000000000000..21bdab0e43f8
--- /dev/null
+++ b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+#include "mt8127.dtsi"
+
+/ {
+ model = "MediaTek MT8127 Amazon Ford";
+ compatible = "amazon,ford", "mediatek,mt8127";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+
+ framebuffer0: framebuffer@b7a00000 {
+ compatible = "simple-framebuffer";
+ memory-region = <&framebuffer_reserved>;
+ width = <1024>;
+ height = <600>;
+ stride = <(1024 * 2)>;
+ format = "r5g6b5";
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0 0x80000000 0 0x40000000>;
+ };
+
+ reserved-memory {
+ framebuffer_reserved: framebuffer@b7a00000 {
+ reg = <0 0xb7a00000 0 0x1000000>;
+ no-map;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&watchdog {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Add missing hyp_enter when trapping sysreg
From: Vincent Donnefort @ 2026-06-17 13:31 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, kernel-team
In-Reply-To: <CA+EHjTz2Hc-mCA4Q0ayw0KV6KJ9_-qN5oPahVqMeKKUs93xtZQ@mail.gmail.com>
On Wed, Jun 17, 2026 at 11:28:11AM +0100, Fuad Tabba wrote:
> On Wed, 17 Jun 2026 at 10:55, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > Add a missing hypervisor event call for hyp_enter on sysreg trapping,
> > causing an unbalanced hyp_enter/hyp_exit.
> >
> > The enum hyp_enter_exit_reason is not ABI, so we can keep the ERET
> > reasons at the end for clarity.
> >
> > Fixes: 696dfec22b8e ("KVM: arm64: Add hyp_enter/hyp_exit events to nVHE/pKVM hyp")
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> One thing that caught my eye (as Sashiko would say: pre-existing, not
> introduced here), __hyp_enter_exit_reason_str() relies on positional
> correspondence between strs[] and enum hyp_enter_exit_reason, with no
> compile-time check. Inserting a new value in the middle of the enum
> (as you do here) silently shifts all the strings after it if the table
> isn't updated in lockstep.
>
> A BUILD_BUG_ON(ARRAY_SIZE(strs)...) would at least catch size
> mismatches; catching ordering bugs is harder without per-entry
> initialisers like [HYP_REASON_SYS] = "sys".
Both are declared in a different file. You're correct this would be less error
prone to define [ XXX ] = "xxx". Perhaps I should convert that later.
>
> Something for a future patch, for now:
>
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Tested-by: Fuad Tabba <tabba@google.com>
Thanks!
>
> Cheers,
> /fuad
>
>
> >
> > diff --git a/arch/arm64/include/asm/kvm_hypevents.h b/arch/arm64/include/asm/kvm_hypevents.h
> > index 743c49bd878f..5f6e6789d121 100644
> > --- a/arch/arm64/include/asm/kvm_hypevents.h
> > +++ b/arch/arm64/include/asm/kvm_hypevents.h
> > @@ -12,6 +12,7 @@
> > enum hyp_enter_exit_reason {
> > HYP_REASON_SMC,
> > HYP_REASON_HVC,
> > + HYP_REASON_SYS,
> > HYP_REASON_PSCI,
> > HYP_REASON_HOST_ABORT,
> > HYP_REASON_GUEST_EXIT,
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index 06db299c37a8..45a4abb9619d 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -913,6 +913,7 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
> > handle_host_mem_abort(host_ctxt);
> > break;
> > case ESR_ELx_EC_SYS64:
> > + trace_hyp_enter(host_ctxt, HYP_REASON_SYS);
> > if (handle_host_mte(esr))
> > break;
> > fallthrough;
> > diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> > index c4b3ee552131..c84434e2349a 100644
> > --- a/arch/arm64/kvm/hyp_trace.c
> > +++ b/arch/arm64/kvm/hyp_trace.c
> > @@ -398,6 +398,7 @@ static const char *__hyp_enter_exit_reason_str(u8 reason)
> > static const char strs[][12] = {
> > "smc",
> > "hvc",
> > + "sys",
> > "psci",
> > "host_abort",
> > "guest_exit",
> >
> > base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> > --
> > 2.54.0.1136.gdb2ca164c4-goog
> >
^ permalink raw reply
* Re: [RFC PATCH] KVM: Ignore MMU notifiers for guest_memfd-only memslots
From: Alexandru Elisei @ 2026-06-17 13:23 UTC (permalink / raw)
To: David Hildenbrand
Cc: pbonzini, kvm, linux-kernel, maz, oupton, suzuki.poulose, kvmarm,
linux-arm-kernel, seanjc, mark.rutland
In-Reply-To: <42323088-c06e-42e2-b095-136062a8d27c@arm.com>
Hi David,
On Mon, Jun 15, 2026 at 09:07:50PM +0200, David Hildenbrand wrote:
> On 6/15/26 17:52, Alexandru Elisei wrote:
> > For guest_memfd-only memslots (kvm_memslot_is_gmem_only() is true), the
> > memory provider for the virtual machine is the guest_memfd file, not the
> > userspace mapping. Faults are resolved using the guest_memfd page cache,
> > and the permissions for the secondary MMU mapping depends exclusively on
> > the memslot (i.e, if the memslot is read-only). How userspace happens to
> > have the memory mmaped at fault time, or even if the memory is mapped at
> > all into userspace, is not taken into consideration.
> >
> > guest_memfd memory is not evictable, is not movable and there's no backing
> > storage. Once memory is allocated for an offset in guest_memfd file, the
> > offset will not change, and that memory is not freed unless userspace
> > explicitly punches a hole in the file. As a result, memory reclaim, page
> > migration, page aging and dirty page tracking for the userspace mapping
> > serve little purpose.
>
> I don't think any of that is relevant for the patch at hand?
>
> The thing is: invalidation (truncation, later migration, for any other reason)
> is driven through guest_memfd notifications, not through unrelated page tables.
>
> If we don't lookup pages for the KVM MMU through the page table, then there is
> also no need for MMU notifiers. It's all guest_memfd only.
>
> Or am I missing something?
My thinking was that, because guest_memfd is not evictable, there is no need to
do page ageing, which would require that secondary MMU mappings be made old.
The invalidate callbacks are also used when userspace memory is marked read-only
for dirty state tracking. I was trying to explaing that, since there is no
backing for the guest_memfd file, host doesn't need to keep track of dirty state
for the memory, and ignoring the invalidate callbacks is correct for all cases.
I can drop the paragraph entirely, if you think that would make the commit
message clearer.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] Revert "ASoC: rockchip: rockchip_sai: Use guard() for spin locks"
From: Mark Brown @ 2026-06-17 13:22 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Heiko Stuebner,
bui duc phuc, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel, kernel
In-Reply-To: <20260617-sai-revert-v1-1-e46adda2213b@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
On Wed, Jun 17, 2026 at 01:46:04PM +0200, Nicolas Frattaroli wrote:
> This reverts commit f7fe9f7073602958d6b63cc58a144094533377fa.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] KVM: arm64: Add Fuad Tabba as a reviewer
From: Fuad Tabba @ 2026-06-17 13:12 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, kvmarm, linux-arm-kernel, linux-kernel, tabba
I have been working on KVM/arm64 for a couple of years, mostly on
pKVM, and am currently upstreaming protected guest support, with more
to come later. I already review KVM/arm64 patches more broadly, and
am happy to continue doing so in an official capacity.
Add myself to the KVM/arm64 reviewer list.
Signed-off-by: Fuad Tabba <tabba@google.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c3fe46d7c4bc..61eb5dc2bd03 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13991,6 +13991,7 @@ F: virt/kvm/*
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
M: Marc Zyngier <maz@kernel.org>
M: Oliver Upton <oupton@kernel.org>
+R: Fuad Tabba <tabba@google.com>
R: Joey Gouly <joey.gouly@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Zenghui Yu <yuzenghui@huawei.com>
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* Re: [PATCH v6] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Karthikeyan KS @ 2026-06-17 13:10 UTC (permalink / raw)
To: andrew
Cc: joel, andrew, Kees Cook, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-hardening
In-Reply-To: <033f2657ae6a94ad13d22f717a2900afb75d892d.camel@codeconstruct.com.au>
This looks like a lot of heavily LLM-assisted effort. Please review the
relevant documentation, starting here:
https://docs.kernel.org/process/submitting-patches.html#using-assisted-by
==> I partly agree. The code and bug analysis are done manually.
LLM use was the out of tree test harness and lightly polishing
the commit message. None of the submitted code is generated.
If you'd prefer, I can reword the changelog in my own words or
add an Assisted-by tag ?
V1 was a simple clamp
v2/V3 was a simple locking mechanism which is pretty straight forward.
V4 bounce buffer, modelled on gpiolib-cdev (acknowledged in patch)
V5 and V6 entirely your review comments (__free, scoped_guard,
kfifo_out_spinlocked, __guarded_by, context analysis)
I feel the testing strategy is pretty questionable. Any invariant
violation is possible with that type of meddling.
==> The underlying bug is a kfifo SPSC contract violation. My intent with the
test wasn't to simulate the race itself, but to reconstruct the post race state
specifically where (in - out) exceeds the buffer size and show it causes a
usercopy overflow in the unpatched code, handled safely after the fix.
==> I take your point that forcing that state can itself produce violations that
wouldn't occur naturally. Since the bug is provable from the source but hard to
trigger on demand, I'd rather ask what validation you'd accept here?
I was interested in whether you drove the interrupt sequence via
emulated hardware. I asked because upstream qemu doesn't currently
support the snoop device.
==> My apologies for the confusion, I mixed up things. I have not driven the
interrupt sequence in emulation; as you noted, upstream QEMU doesn't model the
snoop device. I've described the actual hardware context below.
In v3 you said:
The issue was observed on physical AST2600 (dual-core Cortex-A7)
in production under heavy POST code traffic during concurrent
userspace reads.
https://lore.kernel.org/all/20260527175939.2939714-1-karthiproffesional@gmail.com/
Is this true? What platform did you test with?
==> Yes, the underlying failure is real. It was observed on an AST2600-based
production BMC running a vendor BSP kernel under continuous host reboot
cycles. Because that platform can't currently be brought up on pure
mainline without substantial out-of-tree board support, I have not run
this exact mainline patch on the physical silicon, observed under the
BSP kernel, not yet verified as the mainline patch. I should have made
that distinction clear earlier in the thread.
==> If there's a way you'd consider valid for validating a fix like this
without a full mainline bring up on the SoC, such as a targeted kfifo unit
test, or something else you'd accept.I'd appreciate the pointer and I'll
do that.
^ permalink raw reply
* Re: [PATCH 15/78] ASoC: codecs: cs42l43: Use guard() for mutex locks
From: David Laight @ 2026-06-17 13:02 UTC (permalink / raw)
To: Charles Keepax
Cc: phucduc.bui, Mark Brown, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Cheng-Yi Chiang, Tzung-Bi Shih, Guenter Roeck,
Benson Leung, David Rhodes, Richard Fitzgerald, povik+lin,
Support Opensource, Nick Li, Herve Codina, Srinivas Kandagatla,
Matthias Brugger, AngeloGioacchino Del Regno, Shenghao Ding,
Kevin Lu, Baojun Xu, Sen Wang, Oder Chiou, Lars-Peter Clausen,
nuno.sa, Steven Eckhoff, patches, chrome-platform, asahi,
linux-arm-msm, linux-sound, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <ajJ9rbHTspXHo6Ou@opensource.cirrus.com>
On Wed, 17 Jun 2026 11:57:49 +0100
Charles Keepax <ckeepax@opensource.cirrus.com> wrote:
> On Wed, Jun 17, 2026 at 05:31:32PM +0700, phucduc.bui@gmail.com wrote:
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > Clean up the code using guard() for mutex locks.
> > Merely code refactoring, and no behavior change.
> >
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
> > @@ -913,17 +908,13 @@ int cs42l43_jack_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *u
> > if (override >= e->items)
> > return -EINVAL;
> >
> > - mutex_lock(&priv->jack_lock);
> > + guard(mutex)(&priv->jack_lock);
>
> I believe you have to use scoped_guard here, as there is a return
> from the function above, if memory serves it attempts to release
> the mutex on that path despite it being above the guard.
Indeed.
I believe clang will complain.
That makes these mechanical conversions of existing code dangerous churn.
While using guard() (etc) can make it easier to ensure the lock is released
when functions have multiple error exits, I'm not convinced it makes the
code any easier to read (other people may disagree).
David
>
> Be worth having a quick scan through the rest of the series for
> this as well.
>
> Thanks,
> Charles
>
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPC-T6
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can inject mac-address
properties from its ethaddr/eth1addr env. The on-NIC EEPROMs on this
board are not pre-programmed with a unique MAC, so this gives a
stable MAC across boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
index 84b6b53f016ab..0c11033f9d8e4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
@@ -20,6 +20,8 @@ / {
compatible = "friendlyarm,nanopc-t6", "rockchip,rk3588";
aliases {
+ ethernet0 = &rtl_eth0;
+ ethernet1 = &rtl_eth1;
mmc0 = &sdhci;
mmc1 = &sdmmc;
};
@@ -635,6 +637,20 @@ &pcie2x1l0 {
pinctrl-names = "default";
pinctrl-0 = <&pcie2_0_rst>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x200000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x21 0x2f>;
+
+ rtl_eth0: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x210000 0 0 0 0>;
+ };
+ };
};
&pcie2x1l1 {
@@ -651,6 +667,20 @@ &pcie2x1l2 {
pinctrl-names = "default";
pinctrl-0 = <&pcie2_2_rst>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x400000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x41 0x4f>;
+
+ rtl_eth1: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x410000 0 0 0 0>;
+ };
+ };
};
&pcie30phy {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 3/3] arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on Radxa ROCK 5 family
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
The Radxa ROCK 5B / 5B+ / 5T all carry on-board Realtek RTL8125 NICs.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can inject mac-address
properties from its ethaddr/eth1addr env, for stable MACs across
boots that both U-Boot and the kernel agree on.
The RTL8125 on pcie2x1l2 is shared by all three variants. The ROCK 5T
additionally describes pcie2x1l1 with its second RTL8125.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
.../arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts | 18 ++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index bf4a1d2e55ca3..b53dfe6848cce 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -10,6 +10,7 @@
/ {
aliases {
+ ethernet0 = &rtl_eth0;
mmc0 = &sdhci;
mmc1 = &sdmmc;
mmc2 = &sdio;
@@ -482,6 +483,20 @@ &pcie2x1l2 {
reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc3v3_pcie2x1l2>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x400000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x41 0x4f>;
+
+ rtl_eth0: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x410000 0 0 0 0>;
+ };
+ };
};
&pcie30phy {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts
index 425036146b6d9..b1a3e4b2165f9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts
@@ -8,6 +8,10 @@ / {
model = "Radxa ROCK 5T";
compatible = "radxa,rock-5t", "rockchip,rk3588";
+ aliases {
+ ethernet1 = &rtl_eth1;
+ };
+
analog-sound {
compatible = "audio-graph-card";
label = "rk3588-es8316";
@@ -76,6 +80,20 @@ &pcie2x1l1 {
reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc3v3_pcie2x1l1>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x300000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x31 0x3f>;
+
+ rtl_eth1: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x310000 0 0 0 0>;
+ };
+ };
};
&pcie30phy {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
controller.
The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
compatibles documented in their own bindings (e.g. microchip,lan95xx)
so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
these PCI function nodes can be validated.
Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
new file mode 100644
index 0000000000000..eee13fbc1e6a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/realtek,rtl8125.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTL8125 2.5 Gigabit PCIe Ethernet Controller
+
+maintainers:
+ - Heiner Kallweit <hkallweit1@gmail.com>
+
+description:
+ The Realtek RTL8125 is a 2.5GBASE-T Ethernet controller with a PCIe host
+ interface.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ const: pci10ec,8125
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x10000 0 0 0 0>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c8d4b913f26c1..e5fbd82946aec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
M: nic_swsd@realtek.com
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
F: drivers/net/ethernet/realtek/r8169*
8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/3] describe RTL8125 PCIe NICs on Rockchip boards (and add DT binding)
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
Several Rockchip rk35xx boards carry on-board Realtek RTL8125 2.5GbE
NICs whose PCI function nodes are not described in the DT. Describing
them allows for stable ethernetN aliases (matching the GMAC alias
convention on these boards) and lets U-Boot's fdt_fixup_ethernet()
inject mac-address properties from its ethaddr/ethNaddr env, so MACs
stay stable across boots and U-Boot and kernel MAC match.
Patch 1 adds a DT binding for Realtek RTL8125 family PCIe Ethernet
controllers.
Patch 2 describes the on-board RTL8125 function nodes on the
FriendlyElec NanoPC-T6 (and variants).
Patch 3 describes the on-board RTL8125 function nodes on the Radxa
ROCK 5B / 5B+ / 5T family done based on lspci output provided by
helpful Armbian folks.
---
Changes in v4:
- binding: simplify the binding YAML ref Sashiko's and Krzysztof's
reviews
- binding: describe only the RTL8125 + rename to match ref Heiner's
review.
- dt: fix the bus-range according to Sashiko's review.
- Link to v3: https://patch.msgid.link/20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-0-8a8857b39daf@pardini.net
Changes in v3:
- new patch: add a DT binding for Realtek r8169 family PCIe Ethernet
controllers, per Sebastian Reichel's review (the "pciVVVV,DDDD" OF
spelling still needs a binding when used in a board DT).
- new patch for Rock5 series, and include a brief rationale in each.
- retitle the series, since it now covers a few boards and a binding
rather than just DeviceTree changes for the NanoPC-T6.
- drop the v2 "rename vcc3v3_pcie2x1l0 regulator" patch from this
series; it will be sent separately as it is not relevant to this.
- Link to v2: https://patch.msgid.link/20260529-rk3588-dts-rtl-eth-describe-dt-alias-v2-0-49700248143f@pardini.net
Changes in v2:
- fix: pcie2x1l0, not pcie2x1l1; indirectly caught by Sashiko's review [1]
- while-at-it: rename regulator vcc3v3_pcie2x1l0 to l1
- Link to v1: https://patch.msgid.link/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7@pardini.net
[1] https://sashiko.dev/#/patchset/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7%40pardini.net
To: Heiner Kallweit <hkallweit1@gmail.com>
To: nic_swsd@realtek.com
To: Andrew Lunn <andrew+netdev@lunn.ch>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
Ricardo Pardini (3):
dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPC-T6
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on Radxa ROCK 5 family
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 +++++++++++++++
.../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 15 ++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts | 18 +++++++++
5 files changed, 107 insertions(+)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260524-rk3588-dts-rtl-eth-describe-dt-alias-c1ed187b7c50
Best regards,
--
Ricardo Pardini <ricardo@pardini.net>
^ permalink raw reply
* Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support
From: Christian Brauner @ 2026-06-17 12:58 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, arm-scmi, linux-fsdevel,
linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek, d-gole,
jic23, elif.topuz, lukasz.luba, philip.radford,
souvik.chakravarty, leitao, kas, puranjay, usama.arif,
kernel-team
In-Reply-To: <20260612223802.1337232-1-cristian.marussi@arm.com>
On Fri, Jun 12, 2026 at 11:37:30PM +0100, Cristian Marussi wrote:
> Hi all,
>
> --------------------------------------------------------------------------------
> [TLDR Summary]
> This series introduces a new SCMI driver which uses a new Telemetry FS to expose
> and configure SCMI Telemetry Data Events retrieved from the platform SCMI FW
> at runtime. The patches carrying the new STLMFS Filesystem support are tagged
> with 'stlmfs'.
> --------------------------------------------------------------------------------
>
> the upcoming SCMI v4.0 specification [0] introduces a new SCMI protocol
> dedicated to System Telemetry.
>
> In a nutshell, the SCMI Telemetry protocol allows an agent to discover at
> runtime the set of Telemetry Data Events (DEs) available on a specific
> platform and provides the means to configure the set of DEs that a user is
> interested into, while reading them back using the collection method that
> is deeemed more suitable for the usecase at hand. (...amongst the various
> possible collection methods allowed by SCMI specification)
>
> Without delving into the gory details of the whole SCMI Telemetry protocol
> let's just say that the SCMI platform/server firmware advertises a number
> of Telemetry Data Events, each one identified by a 32bit unique ID, and an
> SCMI agent/client, like Linux, can discover them and read back at will the
> associated data value in a number of ways.
> Data collection is mainly intended to happen on demand via shared memory
> areas exposed by the platform firmware, discovered dynamically via SCMI
> Telemetry and accessed by Linux on-demand, but some DE can also be reported
> via SCMI Notifications asynchronous messages or via direct dedicated
> FastChannels (another kind of SCMI memory based access): all of this
> underlying mechanism is anyway hidden to the user since it is mediated by
> the kernel driver which will return the proper data value when queried.
>
> Anyway, the set of well-known architected DE IDs defined by the spec is
> limited to a dozen IDs, which means that the vast majority of DE IDs are
> customizable per-platform: as a consequence, though, the same ID, say
> '0x1234', could represent completely different things on different systems.
>
> Precise definitions and semantic of such custom Data Event IDs are out of
> the scope of the SCMI Telemetry specification and of this implementation:
> they are supposed to be provided using some kind of JSON-like description
> file that will have to be consumed by a userspace tool which would be
> finally in charge of making sense of the set of available DEs.
>
> IOW, in turn, this means that even though the DEs enumerated via SCMI come
> with some sort of topological and qualitative description provided by the
> protocol (like unit of measurements, name, topology info etc), kernel-wise
> we CANNOT be completely sure of "what is what" without being fed-back some
> sort of information about the DEs by the afore mentioned userspace tool.
>
> For these reasons, currently this series does NOT attempt to register any
> of these DEs with any of the usual in-kernel subsystems (like HWMON, IIO,
> PERF etc), simply because we cannot be sure which DE is suitable, or even
> desirable, for a given subsystem. This also means there are NO in-kernel
> users of these Telemetry data events as of now.
>
> So, while we do not exclude, for the future, to feed/register some of the
> discovered DEs to/with some of the above mentioned Kernel subsystems, as
> of now we have ONLY modeled a custom userspace API to make SCMI Telemetry
> available to userspace tools.
>
> In deciding which kind of interface to expose SCMI Telemetry data to a
> user, this new SCMI Telemetry driver aims at satisfying 2 main reqs:
>
> - exposing an FS-based human-readable interface that can be used to
> discover, configure and access our Telemetry data directly also from
> the shell without special tools
>
> - exposing alternative machine-friendly, more-performant, binary
> interfaces that can be used to avoid the overhead of multiple accesses
> to the VFS and that can be more suitable to access with custom tools
>
> In the initial RFC posted a few months ago [1], the above was achieved
> with a combination of a SysFS interface, for the human-readable side of
> the story, and a classic chardev/ioctl for the plain binary access.
>
> Since V1, instead, we moved away from this combined approach, especially
> away from SysFS, for the following reason:
>
> 1. "Abusing SysFS": SysFS is a handy way to expose device related
> properties in a common way, using a few common helpers built on
> kernfs; this means, though, that unfortunately in our scenario I had
> to generate a dummy simple device for EACH SCMI Telemetry DataEvent
> that I got to discover at runtime and attach to them, all of the
> properties I need.
> This by itself seemed to me abusing the SysFS framework, but, even
> ignoring this, the impact on the system when we have to deal with
> hundreds or tens of thousands of DEs is sensible.
> In some test scenario I ended with 50k DE devices and half-a-millon
> related property files ... O_o
>
> 2. "SysFS constraints": SysFS usage itself has its well-known constraints
> and best practices, like the one-file/one-value rule, and due to the
> fact that any virtual file with a complex structure or handling logic
> is frowned upon, you can forget about IOCTLs and mmap'ing to provide
> a more performant interface within SysFs, which is the reason why,
> in the previous RFC, there was an additional alternative chardev
> interface.
> These latter limitations around the implementation of files with a
> more complex semantic (i.e. with a broader set of file_operations)
> derive from the underlying KernFS support, so KernFS is equally not
> suitable as a building block for our implementation.
>
> 2. "Chardev limitations": Given the nature of the protocol, the hybrid
> approach employing character devices was itself problematic: first
> of all because there is an upper limit on the number of chardev we
> can create, dictated by the range of available minor numbers, and
> then because the fact itself to have to maintain 2 completely
> different interfaces (FS + chardev) is painful.
>
> As a final remark, please NOTE THAT all of this is supposed to be available
> in production systems across a number of heterogeneous platforms: for these
> reasons the easy choice, debugFS, is NOT an option here.
>
> Due to the above reasoning, since V1 we opted for a new approach with the
> proposed interfaces now based on a full fledged, unified, virtual pseudo
> filesystem implemented from scratch, so that we can:
>
> - expose all the DEs property we like as before with SysFS, but without
> any of the constraint imposed by the usage of SysFs or kernfs.
>
> - easily expose additional alternative views of the same set of DEs
> using symlinking capabilities (e.g. alternative topological view)
>
> - additionally expose a few alternative and more performant interfaces
> by embedding in that same FS, a few special virtual files:
>
> + 'control': to issue IOCTLs for quicker discovery and on-demand access
> to data
> + 'pipe' [TBD]: to provide a stream of events using a virtual
> infinite-style file
> + 'raw_<N>' [TBD]: to provide direct memory mapped access to the raw
> SCMI Telemetry data from userspace
A filsystem driver for telemetry like this is really misguided. I think
shell access is really not an argument for adding a filesystem into the
kernel like this. That's just not appropriate justification to push
thousand and thousands of lines of code into the kernel.
You're building completely new infrastructure. The format is whatever it
is. If you stream it somehow just add a binary that userspace can use to
consume or translate it. If you need a filesystem interface for
convenience build it via FUSE on top of whatever streams that data and
get it ouf of the kernels way.
You also buy into all kinds of really wonky properties. If you split it
over multiple files you can never get a snapshot of data that is
consistent if it's across multiple files.
Telemetry over a filesystem is just not a great idea. If you did it via
sysfs I really wouldn't care because all because the infrastructure
already exists and I couldn't be bothered if this grew yet another wart
but as a separate massive hand-rolled pseudofs, no I'm not seeing it.
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: Clean up RX queues in airoha_dev_stop
From: Lorenzo Bianconi @ 2026-06-17 12:48 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178170026659.2238511.17652659042899875248@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
> Thanks Simon for forwarding the AI review. I've reviewed all three
> concerns:
>
> #1 (NAPI race) and #2 (RX refill) are valid. #2 is the decisive
> issue: airoha_dev_open() has no RX ring refill, so draining the
> queues in stop would cause RX stall on next open. This aligns with
> Lorenzo's earlier feedback — RX queues don't need cleanup in
> dev_stop(). I'll drop this patch.
>
> #3 (q->skb leak) is a pre-existing issue, not introduced by this
> patch. It exists even in the module unload path
> (airoha_qdma_cleanup()). @Lorenzo — do you think this warrants a
> fix? A one-liner in airoha_qdma_cleanup_rx_queue() would cover both
> paths. Or is this too unlikely to matter in practice?
Soon I will post a patch to run airoha_qdma_cleanup_tx_queue() just in
airoha_hw_cleanup() so I think we should just drop this patch.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: Clean up RX queues in airoha_dev_stop
From: Wayen Yan @ 2026-06-17 12:44 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161160256.2165161.14322392784449633554@gmail.com>
Thanks Simon for forwarding the AI review. I've reviewed all three
concerns:
#1 (NAPI race) and #2 (RX refill) are valid. #2 is the decisive
issue: airoha_dev_open() has no RX ring refill, so draining the
queues in stop would cause RX stall on next open. This aligns with
Lorenzo's earlier feedback — RX queues don't need cleanup in
dev_stop(). I'll drop this patch.
#3 (q->skb leak) is a pre-existing issue, not introduced by this
patch. It exists even in the module unload path
(airoha_qdma_cleanup()). @Lorenzo — do you think this warrants a
fix? A one-liner in airoha_qdma_cleanup_rx_queue() would cover both
paths. Or is this too unlikely to matter in practice?
^ permalink raw reply
* Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Christian Brauner @ 2026-06-17 12:41 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Jens Axboe, Davidlohr Bueso, Alexander Viro, Jan Kara,
linux-kernel, linux-block, linux-efi, linux-fsdevel,
Richard Henderson, Matt Turner, Magnus Lindholm, linux-alpha,
Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui, loongarch,
Thomas Bogendoerfer, linux-mips, James E.J. Bottomley,
Helge Deller, linux-parisc, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote:
> DPS [1] defines GPT partition type UUIDs for OS partitions and
> attributes that control whether such partitions should be
> automatically discovered. The specification states that:
>
> The OS can discover and mount the necessary file systems with a
> non-existent or incomplete /etc/fstab file and without the root=
> kernel command line option.
>
> DPS is already implemented in systemd-gpt-auto-generator [2], which,
> when embedded in an initrd, indeed allows automatic detection of the
> root filesystem through its partition type UUID.
>
> This series adds this discovery feature directly into the kernel so
> that people who are not using systemd or not using an initrd can still
> benefit from it. The implementation follows the same model as
> systemd-gpt-auto-generator:
I happen to co-maintain the DPS. It is userspace policy and complex
userspace policy at that and does not belong into the kernel.
This also implements a really tiny portion of the spec. It deals with a
lot more complex concepts such as automatic partitioning during
installation, verity, LUKS, containers. This is really not intended for
the kernel at all. I mean, it's great that this spec is being used but I
do not want this in the kernel just for the sake of auto-discovery.
The DPS is completely generic and can be implemented by tooling other
than systemd (util-linux implements it and so does refind iirc). I think
not wanting to use or build alternative userspace tooling for this is a
really weak argument for pushing this into the kernel.
^ 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