* [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Padmashree S S @ 2026-03-27 11:46 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, devicetree,
linux-kernel, Padmashree S S
Convert armada-380-mpcore-soc-ctrl to DT schema
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
.../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
.../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
deleted file mode 100644
index 8781073029e9..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Marvell Armada 38x CA9 MPcore SoC Controller
-============================================
-
-Required properties:
-
-- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
-
-- reg: should be the register base and length as documented in the
- datasheet for the CA9 MPcore SoC Control registers
-
-mpcore-soc-ctrl@20d20 {
- compatible = "marvell,armada-380-mpcore-soc-ctrl";
- reg = <0x20d20 0x6c>;
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
new file mode 100644
index 000000000000..a897d4ba4e32
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-380-mpcore-soc-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x CA9 MPcore SoC Controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+properties:
+ compatible:
+ const: marvell,armada-380-mpcore-soc-ctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ mpcore-soc-ctrl@20d20 {
+ compatible = "marvell,armada-380-mpcore-soc-ctrl";
+ reg = <0x20d20 0x6c>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [GIT,PULL,1/2] MediaTek ARM64 Device Tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-03-27 11:48 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg
In-Reply-To: <20260320085641.15843-1-angelogioacchino.delregno@collabora.com>
On Fri, Mar 20, 2026 at 09:56:38AM +0100, AngeloGioacchino Del Regno wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git tags/mtk-dts64-for-v7.1
>
> for you to fetch changes up to 820ed0c1a13c5fafb36232538d793f99a0986ef3:
>
> arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count (2026-03-12 13:32:17 +0100)
>
> ----------------------------------------------------------------
> MediaTek ARM64 DeviceTree updates
Thanks, applied both.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] i.MX fixes for 7.0 (v2)
From: Krzysztof Kozlowski @ 2026-03-27 11:51 UTC (permalink / raw)
To: Frank Li; +Cc: soc, arm, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260323162849.1203617-1-Frank.Li@nxp.com>
On Mon, Mar 23, 2026 at 12:28:46PM -0400, Frank Li wrote:
> From: Frank Li <Frank.li@nxp.com>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-fixes-7.0
>
> for you to fetch changes up to 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637:
>
> arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V (2026-03-17 23:24:44 -0400)
>
> ----------------------------------------------------------------
> i.MX fixes for 7.0:
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 1/2] Broadcom devicetree changes for 7.1
From: Krzysztof Kozlowski @ 2026-03-27 11:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: soc, Rosen Penev, Rob Herring, Linus Walleij, Linus Walleij,
William Zhang, Miquel Raynal, Rafał Miłecki,
linux-arm-kernel, arnd, khilman, bcm-kernel-feedback-list
In-Reply-To: <20260323190239.1890505-1-florian.fainelli@broadcom.com>
On Mon, Mar 23, 2026 at 12:02:38PM -0700, Florian Fainelli wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-7.1/devicetree
>
> for you to fetch changes up to 220bdfcb4b4788f57faa2c28454d8b2dd3bcab6c:
>
> ARM: dts: BCM5301X: EA9200: specify partitions (2026-03-20 16:57:31 -0700)
Four days after:
Days in linux-next:
----------------------------------------
0 | ++++++++++++++++ (16)
...
Commits with 0 days in linux-next (16 of 19: 84.2%)...
Are you sure your tree is included in the next?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL v2] Rockchip dts fixes for 7.0 #1
From: Krzysztof Kozlowski @ 2026-03-27 11:57 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: arm, soc, linux-rockchip, linux-arm-kernel
In-Reply-To: <5057236.GXAFRqVoOG@phil>
On Mon, Mar 23, 2026 at 10:58:16PM +0100, Heiko Stuebner wrote:
> Hi SoC maintainers,
>
> As requested by Krzysztof, here is a more condensed PR.
>
> Changes in v2 are that I dropped fixes for dt-schema errors and fixes
> for commits introduced not closesly to the current release. These have
> been moved to the current branches.
>
> The Pinebook regression fix actually also is for a commit from august
> last year, but fixes an actively tracked regression, so maybe carries
> a bit more weight.
>
>
> Please pull
>
> Thanks
> Heiko
>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.0-rockchip-dtsfixes1-v2
>
> for you to fetch changes up to 29d1f56c4f3001b7f547123e0a307c009ac717f8:
>
> Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro" (2026-02-22 23:28:06 +0100)
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: juno/fvp: Updates for v7.1
From: Krzysztof Kozlowski @ 2026-03-27 12:00 UTC (permalink / raw)
To: Sudeep Holla
Cc: ARM SoC Team, SoC Team, ALKML, Arnd Bergmann, Lorenzo Pieralisi,
Liviu Dudau
In-Reply-To: <20260325160027.4115793-1-sudeep.holla@kernel.org>
On Wed, Mar 25, 2026 at 04:00:21PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> -->8
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-7.1
>
> for you to fetch changes up to 87599f1843d3baa4083dc9dd01c95826b536de24:
>
> arm64: dts: arm/corstone1000: Add corstone-1000-a320 (2026-03-23 10:03:28 +0000)
>
> ----------------------------------------------------------------
> Armv8 Juno/FVP/Vexpress updates for v7.1
>
> 1. The primary addition is initial support for Zena CSS that includes:
> a new binding compatibility, a shared `zena-css.dtsi` description, and
> an FVP device tree.
>
> 2. Extension of Corstone-1000 FVP platform support with binding updates
> to add the new `arm,corstone1000-a320-fvp` platform, and the
> `arm,corstone1000-ethos-u85` NPU integration.
>
> Overall, this combines new platform enablement with some DTS layout
> cleanup for Arm reference FVP based systems.
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
From: patchwork-bot+netdevbpf @ 2026-03-27 12:10 UTC (permalink / raw)
To: David CARLIER
Cc: danishanwar, rogerq, andrew+netdev, davem, edumazet, kuba, pabeni,
m-malladi, jacob.e.keller, horms, linux-arm-kernel, netdev,
linux-kernel
In-Reply-To: <20260325125131.53399-1-devnexen@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Wed, 25 Mar 2026 12:51:30 +0000 you wrote:
> emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
> never copies the packet data from the XDP buffer into it. The skb is
> passed up the stack containing uninitialized heap memory instead of
> the actual received packet, leaking kernel heap contents to userspace.
>
> Copy the received packet data from the XDP buffer into the skb using
> skb_copy_to_linear_data().
>
> [...]
Here is the summary with links:
- net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
https://git.kernel.org/netdev/net/c/5597dd284ff8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Andrew Lunn @ 2026-03-27 12:23 UTC (permalink / raw)
To: Padmashree S S
Cc: gregory.clement, sebastian.hesselbarth, robh, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> Convert armada-380-mpcore-soc-ctrl to DT schema
You have already been asked once to slow down. Please don't ignore
Reviewers/Maintainer comments.
Please don't post new versions of a patch within 24 hours. And 24
hours can be too fast, particularly at the weekend.
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
Here, under the --- you should indicate what changed since the last
version of the patch.
Andrew
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Andrew Lunn @ 2026-03-27 12:24 UTC (permalink / raw)
To: Padmashree S S
Cc: gregory.clement, sebastian.hesselbarth, robh, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
> +maintainers:
> + - Andrew Lunn <andrew@lunn.ch>
> + - Gregory Clement <gregory.clement@bootlin.com>
> + - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Please drop Sebastian. He has not been active for many years.
Andrew
^ permalink raw reply
* Re: [PATCH v5 0/4] arm64: dts: rockchip: Fix vdec register blocks order on RK3576/RK3588
From: Cristian Ciocaltea @ 2026-03-27 12:51 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Detlev Casanova, Ezequiel Garcia, Mauro Carvalho Chehab,
Nicolas Dufresne, Hans Verkuil
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Conor Dooley, linux-media, Conor Dooley,
Krzysztof Kozlowski
In-Reply-To: <4358847.1IzOArtZ34@phil>
On 3/10/26 10:44 AM, Heiko Stuebner wrote:
> Am Mittwoch, 4. März 2026, 22:00:39 Mitteleuropäische Normalzeit schrieb Cristian Ciocaltea:
>> When building device trees for the RK3576 based boards, DTC shows the
>> following complaint:
>>
>> rk3576.dtsi:1282.30-1304.5: Warning (simple_bus_reg): /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
>
> [...]
>
>> Cristian Ciocaltea (4):
>> media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}
>> media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}
>
> due to media "applied" messages most of the time not reaching all Cc'ed
> recipients, please tell me once the binding patches landed somewhere.
Yeah, sadly I also haven't received any notification so far, but just noticed
the binding patches are now in next-20260326, as a result of merging branch
'next' of https://git.linuxtv.org/media-ci/media-pending.git:
a11db8d8b403 ("media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}")
35c8178ed2bd ("media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}")
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v1] arm64: mm: __ptep_set_access_flags must hint correct TTL
From: Catalin Marinas @ 2026-03-27 12:54 UTC (permalink / raw)
To: Will Deacon, Anshuman Khandual, Linu Cherian, Ryan Roberts
Cc: linux-arm-kernel, linux-kernel, Aishwarya TCV
In-Reply-To: <20260323163918.2028109-1-ryan.roberts@arm.com>
On Mon, 23 Mar 2026 16:39:16 +0000, Ryan Roberts wrote:
> It has been reported that since commit 752a0d1d483e9 ("arm64: mm:
> Provide level hint for flush_tlb_page()"), the arm64
> check_hugetlb_options selftest has been locking up while running "Check
> child hugetlb memory with private mapping, sync error mode and mmap
> memory".
>
> This is due to hugetlb (and THP) helpers casting their PMD/PUD entries
> to PTE and calling __ptep_set_access_flags(), which issues a
> __flush_tlb_page(). Now that this is hinted for level 3, in this case,
> the TLB entry does not get evicted and we end up in a spurious fault
> loop.
>
> [...]
Applied to arm64 (for-next/tlbflush), thanks!
[1/1] arm64: mm: __ptep_set_access_flags must hint correct TTL
https://git.kernel.org/arm64/c/b7d9d2e3a8ab
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-27 12:56 UTC (permalink / raw)
To: Maxime Ripard, Ville Syrjälä
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acVzwRyk_J24GrJ4@intel.com>
On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > + * semantics.
> > > > > > > > > > + *
> > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > + *
> > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > + * not subsampled)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > >
> > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > should be for each format.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > by other properties.
> > > > > > > >
> > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > knowledge, and hopefully none ever will.
> > > > > > >
> > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > >
> > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > RGB can either be full or limited range depending on the
> > > > > > > "Broadcast RGB" property and other related factors.
> > > > > >
> > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > field of its own?
> > > > >
> > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > I think the assumption is limited range everywhere.
> > > > >
> > > > > But I'm not really concerned about documenting struct members.
> > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > will want to know what the new property actually does so the
> > > > > uapi needs to be documented properly. And down the line some
> > > > > new driver might also implement the wrong behaviour if there
> > > > > is no clear specification.
> > > >
> > > > Ack
> > > >
> > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > - YCbCr limited range
> > > > > - RGB full range if "Broadcast RGB" property is not present
> > > >
> > > > Isn't it much more complicated than that for HDMI though? My
> > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > anything else full range?
> > >
> > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > those would always go hand in hand now.
> >
> > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > think?) but it looks like only vc4 registers the Broadcast RGB property
> > and uses the HDMI state helpers.
> >
> > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > drm_default_rgb_quant_range() which seems suspicious?
>
> If they want just manual full vs. limited then they should
> limit the property to not expose the "auto" option at all.
>
> amdgpu also ties this in with the "colorspace" property, which
> originally in i915 only controlled the infoframes/etc. But on
> amdgpu it now controls various aspects of output color
> transformation. The end result is that the property is a complete
> mess with most of the values making no sense. And for whatever
> reason everyone involved refused to remove/deprecate the
> nonsensical values :/
>
> Looks like this series should make sure the documentation for
> the "colorspace" property is in sync with the new property
> as well. Currently now it's giving conflicting information.
>
I take it the problematic information is in
* DOC: standard connector properties
*
* Colorspace:
and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
that they "produce RGB content".
I think we probably just have to change the statement "The variants
BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
RGB and YCbCr on its own."
The "on its own" here would get turned into "based on the color format
property".
Speaking of i915, that patch is one of the very few (5) patches in
this series still lacking a review (hint hint nudge nudge). I'd like
to get some more feedback on the remaining patches before I send out
another revision, so that it's hopefully not just docs changes (I
know better than to think those patches must be perfect and won't
need revision.)
If `drm/bridge: Act on the DRM color format property` and
`drm/atomic-helper: Add HDMI bridge output bus formats helper` get a
reviewed-by/acked-by and it's still crickets on the amdgpu and i915
front, then I will just drop the amdgpu/i915 implementations so that
they don't block this from landing.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] selftests/arm64: Fix sve2p1_sigill() and add cmpbr_sigill() for hwcap test
From: Catalin Marinas @ 2026-03-27 12:58 UTC (permalink / raw)
To: will, shuah, broonie, yeoreum.yun, jonathan.cameron, linux-kernel,
linux-arm-kernel, linux-kselftest, linuxarm, Yifan Wu
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <20260305013638.992301-1-wuyifan50@huawei.com>
On Thu, 05 Mar 2026 09:36:36 +0800, Yifan Wu wrote:
> This patch series fixes and adds two selftests in the arm64 hwcap
> test suite.
>
> Patch 1/2 fixes the sve2p1_sigill() test to correctly detect the
> FEAT_SVE2p1 feature. Previously, the test incorrectly assumed that
> the presence of FEAT_SVE2.1 implied support for the BFADD
> instruction, which actually depends on the FEAT_SVE_B16B16 feature.
> The test is updated to use the LD1Q instruction, which is
> unambiguously implied by FEAT_SVE2p1.
>
> [...]
Applied to arm64 (for-kernelci), thanks!
[2/2] selftests/arm64: Implement cmpbr_sigill() to hwcap test
https://git.kernel.org/arm64/c/74cd4e0e5399
--
Catalin
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] selftests/arm64: Fix sve2p1_sigill() and add cmpbr_sigill() for hwcap test
From: Catalin Marinas @ 2026-03-27 13:00 UTC (permalink / raw)
To: will, shuah, broonie, yeoreum.yun, jonathan.cameron, linux-kernel,
linux-arm-kernel, linux-kselftest, linuxarm, Yifan Wu
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <177461612664.2271410.12022212735709481989.b4-ty@arm.com>
On Fri, Mar 27, 2026 at 12:58:11PM +0000, Catalin Marinas wrote:
> On Thu, 05 Mar 2026 09:36:36 +0800, Yifan Wu wrote:
> > This patch series fixes and adds two selftests in the arm64 hwcap
> > test suite.
> >
> > Patch 1/2 fixes the sve2p1_sigill() test to correctly detect the
> > FEAT_SVE2p1 feature. Previously, the test incorrectly assumed that
> > the presence of FEAT_SVE2.1 implied support for the BFADD
> > instruction, which actually depends on the FEAT_SVE_B16B16 feature.
> > The test is updated to use the LD1Q instruction, which is
> > unambiguously implied by FEAT_SVE2p1.
> >
> > [...]
>
> Applied to arm64 (for-kernelci), thanks!
Wrong branch, it's for-next/kselftest (script got confused).
^ permalink raw reply
* [PATCH v4 0/3] KVM: arm64: Fix SPE and TRBE nVHE world switch
From: Will Deacon @ 2026-03-27 13:00 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Will Deacon, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
Hi all,
I got the Sashiko treatment on v3, so here's a quick respin to address
the BRBE thinko it found in the last patch.
Previous versions of the series are available at:
v1: https://lore.kernel.org/r/20260216130959.19317-1-will@kernel.org
v2: https://lore.kernel.org/r/20260227212136.7660-1-will@kernel.org
v3: https://lore.kernel.org/r/20260326141214.18990-1-will@kernel.org
Changes since v3 include:
* Retain zeroing of *brbcr_el1 when saving BRBE state
* Dropped R-b / T-b tags on the BRBE patch
Cheers,
Will
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Yabin Cui <yabinc@google.com>
--->8
Will Deacon (3):
KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest
context
KVM: arm64: Disable SPE Profiling Buffer when running in guest context
KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 116 +++++++++++++++++++++++------
arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
3 files changed, 95 insertions(+), 25 deletions(-)
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply
* [PATCH v4 1/3] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
From: Will Deacon @ 2026-03-27 13:00 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Will Deacon, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260327130047.21065-1-will@kernel.org>
The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace
generation in guest context when self-hosted TRBE is in use by the host.
Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing
TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but
per R_YCHKJ the Trace Buffer Unit will still be enabled if
TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the
Trace Buffer Unit can perform address translation for the "owning
exception level" even when it is out of context.
Consequently, we can end up in a state where TRBE performs speculative
page-table walks for a host VA/IPA in guest/hypervisor context depending
on the value of MDCR_EL2.E2TB, which changes over world-switch. The
potential result appears to be a heady mixture of SErrors, data
corruption and hardware lockups.
Extend the TRBE world-switch code to clear TRBLIMITR_EL1.E after
draining the buffer, restoring the register on return to the host. This
unfortunately means we need to tackle CPU errata #2064142 and #2038923
which add additional synchronisation requirements around manipulations
of the limit register. Hopefully this doesn't need to be fast.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Tested-by: Leo Yan <leo.yan@arm.com>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Fixes: a1319260bf62 ("arm64: KVM: Enable access to TRBE support for host")
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 71 ++++++++++++++++++++++++++----
arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
3 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 70cb9cfd760a..b1335c55dbef 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -770,6 +770,7 @@ struct kvm_host_data {
u64 pmscr_el1;
/* Self-hosted trace */
u64 trfcr_el1;
+ u64 trblimitr_el1;
/* Values of trap registers for the host before guest entry. */
u64 mdcr_el2;
u64 brbcr_el1;
diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
index 2a1c0f49792b..0955af771ad1 100644
--- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
+++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
@@ -57,12 +57,54 @@ static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr)
write_sysreg_el1(new_trfcr, SYS_TRFCR);
}
-static bool __trace_needs_drain(void)
+static void __trace_drain_and_disable(void)
{
- if (is_protected_kvm_enabled() && host_data_test_flag(HAS_TRBE))
- return read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E;
+ u64 *trblimitr_el1 = host_data_ptr(host_debug_state.trblimitr_el1);
+ bool needs_drain = is_protected_kvm_enabled() ?
+ host_data_test_flag(HAS_TRBE) :
+ host_data_test_flag(TRBE_ENABLED);
- return host_data_test_flag(TRBE_ENABLED);
+ if (!needs_drain) {
+ *trblimitr_el1 = 0;
+ return;
+ }
+
+ *trblimitr_el1 = read_sysreg_s(SYS_TRBLIMITR_EL1);
+ if (*trblimitr_el1 & TRBLIMITR_EL1_E) {
+ /*
+ * The host has enabled the Trace Buffer Unit so we have
+ * to beat the CPU with a stick until it stops accessing
+ * memory.
+ */
+
+ /* First, ensure that our prior write to TRFCR has stuck. */
+ isb();
+
+ /* Now synchronise with the trace and drain the buffer. */
+ tsb_csync();
+ dsb(nsh);
+
+ /*
+ * With no more trace being generated, we can disable the
+ * Trace Buffer Unit.
+ */
+ write_sysreg_s(0, SYS_TRBLIMITR_EL1);
+ if (cpus_have_final_cap(ARM64_WORKAROUND_2064142)) {
+ /*
+ * Some CPUs are so good, we have to drain 'em
+ * twice.
+ */
+ tsb_csync();
+ dsb(nsh);
+ }
+
+ /*
+ * Ensure that the Trace Buffer Unit is disabled before
+ * we start mucking with the stage-2 and trap
+ * configuration.
+ */
+ isb();
+ }
}
static bool __trace_needs_switch(void)
@@ -79,15 +121,26 @@ static void __trace_switch_to_guest(void)
__trace_do_switch(host_data_ptr(host_debug_state.trfcr_el1),
*host_data_ptr(trfcr_while_in_guest));
-
- if (__trace_needs_drain()) {
- isb();
- tsb_csync();
- }
+ __trace_drain_and_disable();
}
static void __trace_switch_to_host(void)
{
+ u64 trblimitr_el1 = *host_data_ptr(host_debug_state.trblimitr_el1);
+
+ if (trblimitr_el1 & TRBLIMITR_EL1_E) {
+ /* Re-enable the Trace Buffer Unit for the host. */
+ write_sysreg_s(trblimitr_el1, SYS_TRBLIMITR_EL1);
+ isb();
+ if (cpus_have_final_cap(ARM64_WORKAROUND_2038923)) {
+ /*
+ * Make sure the unit is re-enabled before we
+ * poke TRFCR.
+ */
+ isb();
+ }
+ }
+
__trace_do_switch(host_data_ptr(trfcr_while_in_guest),
*host_data_ptr(host_debug_state.trfcr_el1));
}
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 779089e42681..f00688e69d88 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -278,7 +278,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
* We're about to restore some new MMU state. Make sure
* ongoing page-table walks that have started before we
* trapped to EL2 have completed. This also synchronises the
- * above disabling of BRBE, SPE and TRBE.
+ * above disabling of BRBE and SPE.
*
* See DDI0487I.a D8.1.5 "Out-of-context translation regimes",
* rule R_LFHQG and subsequent information statements.
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v4 3/3] KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
From: Will Deacon @ 2026-03-27 13:00 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Will Deacon, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260327130047.21065-1-will@kernel.org>
Now that the SPE and BRBE nVHE world-switch routines operate on the
host_debug_state directly, tweak the BRBE code to do the same for
consistency.
This is purely cosmetic.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
index 84bc80f4e36b..f8904391c125 100644
--- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
+++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
@@ -156,8 +156,10 @@ static void __trace_switch_to_host(void)
*host_data_ptr(host_debug_state.trfcr_el1));
}
-static void __debug_save_brbe(u64 *brbcr_el1)
+static void __debug_save_brbe(void)
{
+ u64 *brbcr_el1 = host_data_ptr(host_debug_state.brbcr_el1);
+
*brbcr_el1 = 0;
/* Check if the BRBE is enabled */
@@ -173,8 +175,10 @@ static void __debug_save_brbe(u64 *brbcr_el1)
write_sysreg_el1(0, SYS_BRBCR);
}
-static void __debug_restore_brbe(u64 brbcr_el1)
+static void __debug_restore_brbe(void)
{
+ u64 brbcr_el1 = *host_data_ptr(host_debug_state.brbcr_el1);
+
if (!brbcr_el1)
return;
@@ -190,7 +194,7 @@ void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
/* Disable BRBE branch records */
if (host_data_test_flag(HAS_BRBE))
- __debug_save_brbe(host_data_ptr(host_debug_state.brbcr_el1));
+ __debug_save_brbe();
if (__trace_needs_switch())
__trace_switch_to_guest();
@@ -206,7 +210,7 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
if (host_data_test_flag(HAS_SPE))
__debug_restore_spe();
if (host_data_test_flag(HAS_BRBE))
- __debug_restore_brbe(*host_data_ptr(host_debug_state.brbcr_el1));
+ __debug_restore_brbe();
if (__trace_needs_switch())
__trace_switch_to_host();
}
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v4 2/3] KVM: arm64: Disable SPE Profiling Buffer when running in guest context
From: Will Deacon @ 2026-03-27 13:00 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Will Deacon, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260327130047.21065-1-will@kernel.org>
The nVHE world-switch code relies on zeroing PMSCR_EL1 to disable
profiling data generation in guest context when SPE is in use by the
host.
Unfortunately, this may leave PMBLIMITR_EL1.E set and consequently we
can end up running in guest/hypervisor context with the Profiling Buffer
enabled. The current "known issues" document for Rev M.a of the Arm ARM
states that this can lead to speculative, out-of-context translations:
| 2.18 D23136:
|
| When the Profiling Buffer is enabled, profiling is not stopped, and
| Discard mode is not enabled, the Statistical Profiling Unit might
| cause speculative translations for the owning translation regime,
| including when the owning translation regime is out-of-context.
In a similar fashion to TRBE, ensure that the Profiling Buffer is
disabled during the nVHE world switch before we start messing with the
stage-2 MMU and trap configuration.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Tested-by: Fuad Tabba <tabba@google.com>
Fixes: f85279b4bd48 ("arm64: KVM: Save/restore the host SPE state when entering/leaving a VM")
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 33 ++++++++++++++++++++----------
arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index b1335c55dbef..fe588760fe62 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -768,6 +768,7 @@ struct kvm_host_data {
struct kvm_guest_debug_arch regs;
/* Statistical profiling extension */
u64 pmscr_el1;
+ u64 pmblimitr_el1;
/* Self-hosted trace */
u64 trfcr_el1;
u64 trblimitr_el1;
diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
index 0955af771ad1..84bc80f4e36b 100644
--- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
+++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
@@ -14,20 +14,20 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
-static void __debug_save_spe(u64 *pmscr_el1)
+static void __debug_save_spe(void)
{
- u64 reg;
+ u64 *pmscr_el1, *pmblimitr_el1;
- /* Clear pmscr in case of early return */
- *pmscr_el1 = 0;
+ pmscr_el1 = host_data_ptr(host_debug_state.pmscr_el1);
+ pmblimitr_el1 = host_data_ptr(host_debug_state.pmblimitr_el1);
/*
* At this point, we know that this CPU implements
* SPE and is available to the host.
* Check if the host is actually using it ?
*/
- reg = read_sysreg_s(SYS_PMBLIMITR_EL1);
- if (!(reg & BIT(PMBLIMITR_EL1_E_SHIFT)))
+ *pmblimitr_el1 = read_sysreg_s(SYS_PMBLIMITR_EL1);
+ if (!(*pmblimitr_el1 & BIT(PMBLIMITR_EL1_E_SHIFT)))
return;
/* Yes; save the control register and disable data generation */
@@ -37,18 +37,29 @@ static void __debug_save_spe(u64 *pmscr_el1)
/* Now drain all buffered data to memory */
psb_csync();
+ dsb(nsh);
+
+ /* And disable the profiling buffer */
+ write_sysreg_s(0, SYS_PMBLIMITR_EL1);
+ isb();
}
-static void __debug_restore_spe(u64 pmscr_el1)
+static void __debug_restore_spe(void)
{
- if (!pmscr_el1)
+ u64 pmblimitr_el1 = *host_data_ptr(host_debug_state.pmblimitr_el1);
+
+ if (!(pmblimitr_el1 & BIT(PMBLIMITR_EL1_E_SHIFT)))
return;
/* The host page table is installed, but not yet synchronised */
isb();
+ /* Re-enable the profiling buffer. */
+ write_sysreg_s(pmblimitr_el1, SYS_PMBLIMITR_EL1);
+ isb();
+
/* Re-enable data generation */
- write_sysreg_el1(pmscr_el1, SYS_PMSCR);
+ write_sysreg_el1(*host_data_ptr(host_debug_state.pmscr_el1), SYS_PMSCR);
}
static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr)
@@ -175,7 +186,7 @@ void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
{
/* Disable and flush SPE data generation */
if (host_data_test_flag(HAS_SPE))
- __debug_save_spe(host_data_ptr(host_debug_state.pmscr_el1));
+ __debug_save_spe();
/* Disable BRBE branch records */
if (host_data_test_flag(HAS_BRBE))
@@ -193,7 +204,7 @@ void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
{
if (host_data_test_flag(HAS_SPE))
- __debug_restore_spe(*host_data_ptr(host_debug_state.pmscr_el1));
+ __debug_restore_spe();
if (host_data_test_flag(HAS_BRBE))
__debug_restore_brbe(*host_data_ptr(host_debug_state.brbcr_el1));
if (__trace_needs_switch())
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index f00688e69d88..9b6e87dac3b9 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -278,7 +278,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
* We're about to restore some new MMU state. Make sure
* ongoing page-table walks that have started before we
* trapped to EL2 have completed. This also synchronises the
- * above disabling of BRBE and SPE.
+ * above disabling of BRBE.
*
* See DDI0487I.a D8.1.5 "Out-of-context translation regimes",
* rule R_LFHQG and subsequent information statements.
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: (subset) [PATCH v17 0/8] support FEAT_LSUI
From: Catalin Marinas @ 2026-03-27 13:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, kvmarm, kvm, linux-kselftest,
Yeoreum Yun
Cc: will, maz, oupton, miko.lenczewski, kevin.brodsky, broonie, ardb,
suzuki.poulose, lpieralisi, joey.gouly, yuzenghui
In-Reply-To: <20260314175133.1084528-1-yeoreum.yun@arm.com>
On Sat, 14 Mar 2026 17:51:25 +0000, Yeoreum Yun wrote:
> Since Armv9.6, FEAT_LSUI supplies the load/store instructions for
> previleged level to access to access user memory without clearing
> PSTATE.PAN bit.
>
> This patchset support FEAT_LSUI and applies it mainly in
> futex atomic operation and others.
>
> [...]
Applied to arm64 (for-next/feat_lsui), thanks!
I decided to drop patch [6/8] (arm64: armv8_deprecated: disable swp
emulation when FEAT_LSUI present). The way FEAT_LSUI support looks now,
we still have uaccess_enable_privileged() working properly and we could
even support SWP emulation using exclusives. While it's highly unlikely
to see both 32-bit EL0 and FEAT_LSUI in practice, models may support the
combination and disabling SWP emulation feels pretty artificial.
[1/8] arm64: cpufeature: add FEAT_LSUI
https://git.kernel.org/arm64/c/7181f718cb0f
[2/8] KVM: arm64: expose FEAT_LSUI to guest
https://git.kernel.org/arm64/c/f6bff18d05ed
[3/8] KVM: arm64: kselftest: set_id_regs: add test for FEAT_LSUI
https://git.kernel.org/arm64/c/42550d7d8aa6
[4/8] arm64: futex: refactor futex atomic operation
https://git.kernel.org/arm64/c/eaa3babcceaa
[5/8] arm64: futex: support futex with FEAT_LSUI
https://git.kernel.org/arm64/c/44adf2bf40ef
[7/8] KVM: arm64: use CAST instruction for swapping guest descriptor
https://git.kernel.org/arm64/c/16dbe77a5be2
[8/8] arm64: Kconfig: add support for LSUI
https://git.kernel.org/arm64/c/377609ae8b6a
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
From: Fuad Tabba @ 2026-03-27 13:23 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, mark.rutland, linux-arm-kernel, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260327130047.21065-4-will@kernel.org>
On Fri, 27 Mar 2026 at 13:01, Will Deacon <will@kernel.org> wrote:
>
> Now that the SPE and BRBE nVHE world-switch routines operate on the
> host_debug_state directly, tweak the BRBE code to do the same for
> consistency.
>
> This is purely cosmetic.
It is indeed... until sashiko proves me wrong again :)
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Leo Yan <leo.yan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 84bc80f4e36b..f8904391c125 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -156,8 +156,10 @@ static void __trace_switch_to_host(void)
> *host_data_ptr(host_debug_state.trfcr_el1));
> }
>
> -static void __debug_save_brbe(u64 *brbcr_el1)
> +static void __debug_save_brbe(void)
> {
> + u64 *brbcr_el1 = host_data_ptr(host_debug_state.brbcr_el1);
> +
> *brbcr_el1 = 0;
>
> /* Check if the BRBE is enabled */
> @@ -173,8 +175,10 @@ static void __debug_save_brbe(u64 *brbcr_el1)
> write_sysreg_el1(0, SYS_BRBCR);
> }
>
> -static void __debug_restore_brbe(u64 brbcr_el1)
> +static void __debug_restore_brbe(void)
> {
> + u64 brbcr_el1 = *host_data_ptr(host_debug_state.brbcr_el1);
> +
> if (!brbcr_el1)
> return;
>
> @@ -190,7 +194,7 @@ void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
>
> /* Disable BRBE branch records */
> if (host_data_test_flag(HAS_BRBE))
> - __debug_save_brbe(host_data_ptr(host_debug_state.brbcr_el1));
> + __debug_save_brbe();
>
> if (__trace_needs_switch())
> __trace_switch_to_guest();
> @@ -206,7 +210,7 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
> if (host_data_test_flag(HAS_SPE))
> __debug_restore_spe();
> if (host_data_test_flag(HAS_BRBE))
> - __debug_restore_brbe(*host_data_ptr(host_debug_state.brbcr_el1));
> + __debug_restore_brbe();
> if (__trace_needs_switch())
> __trace_switch_to_host();
> }
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH v2 0/6] change young flag check functions to return bool
From: David Hildenbrand (Arm) @ 2026-03-27 13:28 UTC (permalink / raw)
To: Baolin Wang, akpm
Cc: ljs, Liam.Howlett, vbabka, rppt, surenb, mhocko, linux-arm-kernel,
x86, linux-parisc, linuxppc-dev, linux-riscv, linux-s390, kvm,
open, linux-kernel
In-Reply-To: <cover.1774075004.git.baolin.wang@linux.alibaba.com>
On 3/21/26 07:42, Baolin Wang wrote:
> This is a cleanup patchset to change all young flag check functions to
> return bool, as discussed with David in the previous thread[1]. Since
> callers only care about whether the young flag was set, returning bool
> makes the intention clearer. No functional changes intended.
>
> Ran mm selftests on Arm64 and x86 machines, and no issues were found.
Thanks!
For the whole series:
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: Deep Pani @ 2026-03-27 13:33 UTC (permalink / raw)
To: Fred-WY Chen (陳威宇),
andriy.shevchenko@intel.com, Lei Xue (薛磊),
Mandeep S
Cc: Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <cbb135cbd2c6255537fb55e35c39fc5529e7de78.camel@mediatek.com>
Hi Andy,
You mean gpiochip_add_pin_range(), correct?
IIRC, that adds to gpiochip's range, not the range we are using for our
pinctrl driver.
The range we are utilizing inside our hardware is of the type struct
pinctrl_gpio_range. There is no callback in gpiochip that handles this
type of range
I also recall that gpiochip_add_data() doesn't initialize the hw but
rather initializes the gpiochip from the hw data we will provide in
mtk_build_gpiochip(). Thus we need a function which will help
initialize the pinctrl_gpio_range inside our pinctrl driver structure.
This is why we make the mtk_pinctrl_gpio_range_init function here.
For the second question, we are keeping it because before ACPI is
invoked we still need some other pins to be configured, especially if
different pins have different styles of pull configuration. The method
we use is to define those configurations in the pinctrl-mt8901.c file
which determines the gpio ranges and maps pinctrl device to acpi, one
set of gpio ranges per configuration, for different type of pull
configurations we have different gpio ranges, this callback helps add
them into the pinctrl subsystem such that other device maintainers can
easily leverage that subsystem to add their resources in their _CRS
calls using the common interfaces.
Thus we need to keep both the functions.
Thanks and Regards,
Deep Pani
On Thu, 2026-03-26 at 12:33 +0000, Fred-WY Chen (陳威宇) wrote:
> On Wed, 2025-11-26 at 19:06 +0100, Andy Shevchenko wrote:
> >
> > External email : Please do not click links or open attachments
> > until
> > you have verified the sender or the content.
> >
> >
> > On Tue, Nov 25, 2025 at 10:36:34AM +0800, Lei Xue wrote:
> > > Kernel GPIO subsystem mapping hardware pin number to a different
> > > range of gpio number. Add gpio-range structure to hold
> > > the mapped gpio range in pinctrl driver. That enables the kernel
> > > to search a range of mapped gpio range against a pinctrl device.
> >
> > ...
> >
> > > static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
> > > {
> > > struct gpio_chip *chip = &hw->chip;
> >
> > > if (ret < 0)
> > > return ret;
> > >
> > > + mtk_pinctrl_gpio_range_init(hw, chip);
> > > +
> > > return 0;
> >
> > We have a callback for that in struct gpio_chip. Any reason not to
> > use it?
> >
> > > }
> >
> > ...
> >
> > > + pinctrl_add_gpio_range(hw->pctrl, &hw->range);
> >
> > Not sure if this is needed.
> >
>
> Hi Deep,
>
> Could you please check this and feedback?
>
> Regards,
> Fred-WY Chen
>
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
>
^ permalink raw reply
* Re: [PATCH 3/3] pinctrl: mediatek: mt8901: Add pinctrl driver for MT8901
From: Deep Pani @ 2026-03-27 13:41 UTC (permalink / raw)
To: linus.walleij@linaro.org, Fred-WY Chen (陳威宇),
AngeloGioacchino Del Regno, sean.wang@kernel.org,
matthias.bgg@gmail.com, Mandeep S, Lei Xue (薛磊)
Cc: Qingliang Li (黎晴亮),
Ye Wang (王叶), Yaoy Wang (王瑶瑶),
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
Shunxi Zhang (章顺喜),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Cathy Xu (许华婷)
In-Reply-To: <0df339f15f4ba7e55880194edfdec1155f2f20f7.camel@mediatek.com>
Hi Angelo,
MT8901 doesn't use devicetree for gpio pin configuration. ACPI ASL
macros are declared in the device's _CRS methods to define exact
configuration for the gpio pins.
We have and will always make sure ACPI is all good on this platform.
Thanks and Regards,
Deep Pani
On Thu, 2026-03-26 at 12:36 +0000, Fred-WY Chen (陳威宇) wrote:
> On Tue, 2025-11-25 at 10:56 +0100, AngeloGioacchino Del Regno wrote:
> >
> > External email : Please do not click links or open attachments
> > until
> > you have verified the sender or the content.
> >
> >
> > Il 25/11/25 03:36, Lei Xue ha scritto:
> > > Add mt8901 pinctrl, gpio and eint driver implementation.
> > >
> > > Signed-off-by: Lei Xue <lei.xue@mediatek.com>
> > > ---
> > > drivers/pinctrl/mediatek/Kconfig | 12 +
> > > drivers/pinctrl/mediatek/Makefile | 1 +
> > > drivers/pinctrl/mediatek/mtk-eint.c | 4 +
> > > drivers/pinctrl/mediatek/mtk-eint.h | 1 +
> > > drivers/pinctrl/mediatek/pinctrl-mt8901.c | 1460
> > > +++++++++++
> > > drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h | 2130
> > > +++++++++++++++++
> > > 6 files changed, 3608 insertions(+)
> > > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-
> > > mt8901.h
> > >
> > > diff --git a/drivers/pinctrl/mediatek/Kconfig
> > > b/drivers/pinctrl/mediatek/Kconfig
> > > index 4819617d9368..4820ae5197a0 100644
> > > --- a/drivers/pinctrl/mediatek/Kconfig
> > > +++ b/drivers/pinctrl/mediatek/Kconfig
> > > @@ -321,6 +321,18 @@ config PINCTRL_MT8516
> > > default ARM64 && ARCH_MEDIATEK
> > > select PINCTRL_MTK
> > >
> > > +config PINCTRL_MT8901
> > > + bool "MediaTek MT8901 pin control"
> > > + depends on ACPI
> > > + depends on ARM64 || COMPILE_TEST
> > > + default ARM64 && ARCH_MEDIATEK
> > > + select PINCTRL_MTK_PARIS
> > > + help
> > > + Say yes here to support pin controller and gpio driver
> > > + on MediaTek MT8901 SoC.
> > > + In MTK platform, we support virtual gpio and use it to
> > > + map specific eint which doesn't have real gpio pin.
> > > +
> > > # For PMIC
> > > config PINCTRL_MT6397
> > > bool "MediaTek MT6397 pin control"
> > > diff --git a/drivers/pinctrl/mediatek/Makefile
> > > b/drivers/pinctrl/mediatek/Makefile
> > > index ae765bd99965..57c69b1e5c2d 100644
> > > --- a/drivers/pinctrl/mediatek/Makefile
> > > +++ b/drivers/pinctrl/mediatek/Makefile
> > > @@ -43,3 +43,4 @@ obj-$(CONFIG_PINCTRL_MT8196) +=
> > > pinctrl-mt8196.o
> > > obj-$(CONFIG_PINCTRL_MT8365) += pinctrl-mt8365.o
> > > obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
> > > obj-$(CONFIG_PINCTRL_MT6397) += pinctrl-mt6397.o
> > > +obj-$(CONFIG_PINCTRL_MT8901) += pinctrl-mt8901.o
> > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> > > b/drivers/pinctrl/mediatek/mtk-eint.c
> > > index c8c5097c11c4..b5a5beebf9cd 100644
> > > --- a/drivers/pinctrl/mediatek/mtk-eint.c
> > > +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> > > @@ -71,6 +71,10 @@ const unsigned int debounce_time_mt6878[] = {
> > > };
> > > EXPORT_SYMBOL_GPL(debounce_time_mt6878);
> > >
> > > +const unsigned int debounce_time_mt8901[] = {
> > > + 156, 313, 625, 1250, 20000, 40000, 80000, 160000, 320000,
> > > 640000, 0};
> > > +EXPORT_SYMBOL_GPL(debounce_time_mt8901);
> > > +
> > > static void __iomem *mtk_eint_get_offset(struct mtk_eint *eint,
> > > unsigned int eint_num,
> > > unsigned int offset)
> > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > > b/drivers/pinctrl/mediatek/mtk-eint.h
> > > index 3cdd6f6310cd..1b185f660aff 100644
> > > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > > @@ -53,6 +53,7 @@ extern const unsigned int
> > > debounce_time_mt2701[];
> > > extern const unsigned int debounce_time_mt6765[];
> > > extern const unsigned int debounce_time_mt6795[];
> > > extern const unsigned int debounce_time_mt6878[];
> > > +extern const unsigned int debounce_time_mt8901[];
> > >
> > > struct mtk_eint;
> > >
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > new file mode 100644
> > > index 000000000000..77dec85fe29b
> > > --- /dev/null
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > @@ -0,0 +1,1460 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2025 MediaTek Inc.
> > > + *
> > > + */
> > > +
> > > +#include <linux/acpi.h>
> > > +#include <linux/module.h>
> > > +#include "pinctrl-mtk-mt8901.h"
> > > +#include "pinctrl-paris.h"
> > > +
> >
> > ..snip..
> >
> > > +static const char * const mt8901_pinctrl_register_base_name[] =
> > > {
> > > + "iocfg0", "iocfg_lt2", "iocfg_lt3", "iocfg_rt1",
> > > "iocfg_rt2",
> > > "iocfg_rt3",
> > > + "iocfg_tr", "iocfg_rt0", "iocfg_lt1", "iocfg_lb",
> > > "iocfg_rb",
> > > +};
> > > +
> > > +static const struct mtk_eint_hw mt8901_eint_hw = {
> > > + .port_mask = 0xf,
> > > + .ports = 7,
> > > + .ap_num = 209,
> > > + .db_cnt = 32,
> > > + .db_time = debounce_time_mt8901,
> > > +};
> > > +
> > > +static const struct mtk_pin_soc mt8901_data = {
> > > + .reg_cal = mt8901_reg_cals,
> > > + .pins = mtk_pins_mt8901,
> > > + .npins = ARRAY_SIZE(mtk_pins_mt8901),
> > > + .ngrps = ARRAY_SIZE(mtk_pins_mt8901),
> > > + .eint_hw = &mt8901_eint_hw,
> > > + .eint_pin = eint_pins_mt8901,
> > > + .nfuncs = 8,
> > > + .gpio_m = 0,
> > > + .base_names = mt8901_pinctrl_register_base_name,
> > > + .nbase_names =
> > > ARRAY_SIZE(mt8901_pinctrl_register_base_name),
> > > + .pull_type = mt8901_pull_type,
> > > + .pin_rsel = mt8901_pin_rsel_val_range,
> > > + .npin_rsel = ARRAY_SIZE(mt8901_pin_rsel_val_range),
> > > /*numsel*/
> > > + .bias_set_combo = mtk_pinconf_bias_set_combo,
> > > + .bias_get_combo = mtk_pinconf_bias_get_combo,
> > > + .drive_set = mtk_pinconf_drive_set_rev1,
> > > + .drive_get = mtk_pinconf_drive_get_rev1,
> > > + .adv_drive_set = mtk_pinconf_adv_drive_set_raw,
> > > + .adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> > > +};
> > > +
> > > +static const struct acpi_device_id mt8901_pinctrl_acpi_match[] =
> > > {
> > > + {"NVDA9221", (kernel_ulong_t)&mt8901_data },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, mt8901_pinctrl_acpi_match);
> > > +
> > > +static struct platform_driver mt8901_pinctrl_driver = {
> > > + .driver = {
> > > + .name = "mt8901-pinctrl",
> > > + .acpi_match_table =
> > > ACPI_PTR(mt8901_pinctrl_acpi_match),
> >
> > Please also add support for devicetree - I have a hunch (and I'm
> > sure
> > that I am
> > not the only one) that ACPI may give some issues at the end of the
> > day, on ARM64.
> >
> > Of course, I'd hope that ACPI is all good on this platform, but
> > still.... :-)
> >
> > static const struct of_device_id mt8901_pinctrl_of_match[] = {
> > { .compatible = "mediatek,mt8901-pinctrl", .data =
> > &mt8901_data },
> > { /* sentinel */ }
> > };
> >
> > .of_match_table = mt8901_pinctrl_of_match,
> >
> > > + .pm = pm_sleep_ptr(&mtk_paris_pinctrl_pm_ops)
> > > + },
> > > + .probe = mtk_paris_pinctrl_probe,
> > > +};
> >
>
> Hi Deep,
>
> Could you please check and feedback to Angelo?
>
> Regards,
> Fred-WY Chen
>
> > Cheers,
> > Angelo
> >
> > > +
> > > +static int __init mt8901_pinctrl_init(void)
> > > +{
> > > + return platform_driver_register(&mt8901_pinctrl_driver);
> > > +}
> > > +
> > > +arch_initcall(mt8901_pinctrl_init);
> > > +
> > > +MODULE_LICENSE("GPL");
> > > +MODULE_DESCRIPTION("MediaTek MT8901 Pinctrl Driver");
>
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Arnd Bergmann @ 2026-03-27 13:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <93439e91-cf81-477b-b880-a813bb01ad7c@app.fastmail.com>
On Fri, Mar 27, 2026, at 10:02, Arnd Bergmann wrote:
> On Fri, Mar 27, 2026, at 08:56, Geert Uytterhoeven wrote:
> but that only allowed bitfields to be marked as __attribute__((packed))
> in order to get tightly packed fields and return '4' on all architectures,
> while m68k-linux-gcc apparently has all bitfields implicitly packed unless they
> are explicitly marked __attribute__((aligned(x))). This behavior is
> independent of the -malign-int flag.
I had another look and found that this has been in gcc since ELF
support was originally added for m68k:
gcc/config/m68k/linux.h:#undef PCC_BITFIELD_TYPE_MATTERS
All other current Linux/ELF targets get the default from gcc/config/elfos.h
Arnd
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: mediatek,mt8173-rt5650-rt5514: convert to DT schema
From: Khushal Chitturi @ 2026-03-27 13:46 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
koro.chen, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Khushal Chitturi
Convert the Mediatek MT8173 with RT5650 and RT5514 sound card
bindings to DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v1 -> v2:
- Used two separate entries for two phandles.
- corrected positioning of additionalProperties.
- Fixed commit message to match subsystem.
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../sound/mediatek,mt8173-rt5650-rt5514.yaml | 41 +++++++++++++++++++
.../bindings/sound/mt8173-rt5650-rt5514.txt | 15 -------
2 files changed, 41 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
new file mode 100644
index 000000000000..ed698c9ff42b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8173-rt5650-rt5514.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8173 with RT5650 and RT5514 audio codecs
+
+maintainers:
+ - Koro Chen <koro.chen@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8173-rt5650-rt5514
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Phandles of rt5650 and rt5514 codecs
+ items:
+ - description: phandle of rt5650 codec
+ - description: phandle of rt5514 codec
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT8173 ASoC platform.
+
+required:
+ - compatible
+ - mediatek,audio-codec
+ - mediatek,platform
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8173-rt5650-rt5514";
+ mediatek,audio-codec = <&rt5650>, <&rt5514>;
+ mediatek,platform = <&afe>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
deleted file mode 100644
index e8b3c80c6fff..000000000000
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-MT8173 with RT5650 RT5514 CODECS
-
-Required properties:
-- compatible : "mediatek,mt8173-rt5650-rt5514"
-- mediatek,audio-codec: the phandles of rt5650 and rt5514 codecs
-- mediatek,platform: the phandle of MT8173 ASoC platform
-
-Example:
-
- sound {
- compatible = "mediatek,mt8173-rt5650-rt5514";
- mediatek,audio-codec = <&rt5650 &rt5514>;
- mediatek,platform = <&afe>;
- };
-
--
2.53.0
^ permalink raw reply related
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