* [PATCH V3 0/3] arm64: dts: imx: Disable PCIe by default and add overlay support for M.2 connector
From: Sherry Sun @ 2026-03-25 8:31 UTC (permalink / raw)
To: Frank.Li, s.hauer, kernel, festevam, robh, krzk+dt, conor+dt,
hongxing.zhu
Cc: imx, linux-arm-kernel, devicetree, linux-kernel
On both i.MX8MP EVK and i.MX95-15x15 EVK boards, the M.2 connector
shares a common regulator between USDHC (for SDIO WiFi) and PCIe
controllers. The non-deterministic probe order between these two
buses can break the PCIe initialization sequence, causing PCIe
devices to fail detection intermittently.
The out-of-box module on i.MX8MP EVK and i.MX95-15x15 EVK are SDIO
WiFi (IW612), this series changes the default configuration to
match the out-of-box hardware (SDIO WiFi) and provides a device
tree overlay for users who need PCIe functionality:
1. Disable PCIe in the default device tree
2. Keep USDHC enabled for SDIO WiFi
3. Add 'm2_usdhc' label to support overlay
4. Provide a common overlay (imx-m2-pcie.dtso) to enable PCIe and
disable USDHC when needed
---
Changes in V3:
1. Add a common overlay imx-m2-pcie.dtso for both i.MX8MP EVK and
i.MX95-15x15 EVK.
2. Add 'm2_usdhc' label to support overlay.
Changes in V2:
1. Improve the commit message to clarify SDIO WiFi is the out-of-box
module on i.MX8MP EVK and i.MX95-15x15 EVK.
---
Sherry Sun (3):
arm64: dts: imx8mp-evk: Disable PCIe bus in the default dts
arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts
arm64: dts: imx: Add common imx-m2-pcie.dtso to enable PCIe on M.2
connector
arch/arm64/boot/dts/freescale/Makefile | 9 +++++++--
arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso | 15 +++++++++++++++
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
4 files changed, 26 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso
--
2.37.1
^ permalink raw reply
* [PATCH V3 1/3] arm64: dts: imx8mp-evk: Disable PCIe bus in the default dts
From: Sherry Sun @ 2026-03-25 8:31 UTC (permalink / raw)
To: Frank.Li, s.hauer, kernel, festevam, robh, krzk+dt, conor+dt,
hongxing.zhu
Cc: imx, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325083201.2637520-1-sherry.sun@nxp.com>
Disable the PCIe bus in the default device tree to avoid shared
regulator conflicts between SDIO and PCIe buses. The non-deterministic
probe order between these two buses can break the PCIe initialization
sequence, causing PCIe devices to fail detection intermittently.
On i.MX8MP EVK board, the M.2 connector is physically wired to both
USDHC1 and PCIe0, however the out-of-box module is SDIO IW612 WiFi, so
enable the SDIO WiFi in the default imx8mp-evk.dts.
Add 'm2_usdhc' label to USDHC1 to support device tree overlay for PCIe
modules. Users who need PCIe can use imx8mp-evk-pcie.dtb (added in a
follow-up patch) which applies an overlay to enable PCIe and disable
USDHC1.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index aedc09937716..315a4e1c5809 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -773,7 +773,7 @@ &pcie0 {
vpcie-supply = <®_pcie0>;
vpcie3v3aux-supply = <®_pcie0>;
supports-clkreq;
- status = "okay";
+ status = "disabled";
};
&pcie0_ep {
@@ -869,7 +869,7 @@ &uart3 {
status = "okay";
};
-&usdhc1 {
+m2_usdhc: &usdhc1 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc1>;
pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
--
2.37.1
^ permalink raw reply related
* [PATCH V3 2/3] arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts
From: Sherry Sun @ 2026-03-25 8:32 UTC (permalink / raw)
To: Frank.Li, s.hauer, kernel, festevam, robh, krzk+dt, conor+dt,
hongxing.zhu
Cc: imx, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325083201.2637520-1-sherry.sun@nxp.com>
Disable the PCIe bus in the default device tree to avoid shared
regulator conflicts between SDIO and PCIe buses. The non-deterministic
probe order between these two buses can break the PCIe initialization
sequence, causing PCIe devices to fail detection intermittently.
On i.MX95-15x15 EVK board, the M.2 connector is physically wired to both
USDHC3 and PCIe0, however the out-of-box module is SDIO IW612 WiFi, so
enable SDIO WiFi in the default imx95-15x15-evk.dts.
Add 'm2_usdhc' label to USDHC3 to support device tree overlay for PCIe
modules. Users who need PCIe can use imx95-15x15-evk-pcie.dtb (added in
a follow-up patch) which applies an overlay to enable PCIe and disable
USDHC3.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
index 7eb12e7d5014..e4649d7f9122 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts
@@ -557,7 +557,7 @@ &pcie0 {
vpcie-supply = <®_m2_pwr>;
vpcie3v3aux-supply = <®_m2_pwr>;
supports-clkreq;
- status = "okay";
+ status = "disabled";
};
&pcie0_ep {
@@ -1137,7 +1137,7 @@ &usdhc2 {
status = "okay";
};
-&usdhc3 {
+m2_usdhc: &usdhc3 {
bus-width = <4>;
keep-power-in-suspend;
mmc-pwrseq = <&usdhc3_pwrseq>;
--
2.37.1
^ permalink raw reply related
* [PATCH V3 3/3] arm64: dts: imx: Add common imx-m2-pcie.dtso to enable PCIe on M.2 connector
From: Sherry Sun @ 2026-03-25 8:32 UTC (permalink / raw)
To: Frank.Li, s.hauer, kernel, festevam, robh, krzk+dt, conor+dt,
hongxing.zhu
Cc: imx, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325083201.2637520-1-sherry.sun@nxp.com>
Some i.MX boards (i.MX8MP EVK and i.MX95-15x15 EVK) have M.2 connectors
that are physically wired to both USDHC and PCIe controllers. The
default device tree enables USDHC for SDIO WiFi modules and disables
PCIe to avoid regulator conflicts.
Add a common imx-m2-pcie.dtso that can be applied to enable PCIe and
disable USDHC when a PCIe module is installed in the M.2 connector.
This creates the following DTB files:
- imx8mp-evk-pcie.dtb: i.MX8MP EVK with PCIe enabled
- imx95-15x15-evk-pcie.dtb: i.MX95-15x15 EVK with PCIe enabled
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 9 +++++++--
arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso | 15 +++++++++++++++
2 files changed, 22 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 155213c45319..1f542324b4fc 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -333,12 +333,14 @@ imx8mp-evk-lvds0-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds0-imx-lvds-
imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtbo
imx8mp-evk-lvds1-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds1-imx-lvds-hdmi.dtbo
imx8mp-evk-mx8-dlvds-lcd1-dtbs += imx8mp-evk.dtb imx8mp-evk-mx8-dlvds-lcd1.dtbo
-imx8mp-evk-pcie-ep-dtbs += imx8mp-evk.dtb imx-pcie0-ep.dtbo
+imx8mp-evk-pcie-dtbs += imx8mp-evk.dtb imx-m2-pcie.dtbo
+imx8mp-evk-pcie-ep-dtbs += imx8mp-evk-pcie.dtb imx-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds0-imx-lvds-hdmi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds1-imx-lvds-hdmi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-mx8-dlvds-lcd1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie-ep.dtb
imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33-dtbs += imx8mp-tqma8mpql-mba8mpxl.dtb imx8mp-tqma8mpql-mba8mpxl-lvds-tm070jvhg33.dtbo
@@ -481,7 +483,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
-imx95-15x15-evk-pcie0-ep-dtbs = imx95-15x15-evk.dtb imx-pcie0-ep.dtbo
+imx95-15x15-evk-pcie-dtbs += imx95-15x15-evk.dtb imx-m2-pcie.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie.dtb
+
+imx95-15x15-evk-pcie0-ep-dtbs = imx95-15x15-evk-pcie.dtb imx-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie0-ep.dtb
imx95-19x19-evk-pcie0-ep-dtbs += imx95-19x19-evk.dtb imx-pcie0-ep.dtbo
imx95-19x19-evk-pcie1-ep-dtbs += imx95-19x19-evk.dtb imx-pcie1-ep.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso b/arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso
new file mode 100644
index 000000000000..1930de058a08
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+&pcie0 {
+ status = "okay";
+};
+
+&m2_usdhc {
+ status = "disabled";
+};
--
2.37.1
^ permalink raw reply related
* Re: [PATCH v2 0/5] powervr: MT8173 GPU support
From: Icenowy Zheng @ 2026-03-25 8:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, linux-clk,
devicetree, linux-mediatek, dri-devel, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAGXv+5FL2rs35V4F0bwq-a4ccvFaWKcr1cuKxT6sfTj9h+d6iA@mail.gmail.com>
在 2026-03-25三的 16:08 +0800，Chen-Yu Tsai写道：
> On Wed, Mar 25, 2026 at 4:04 PM Icenowy Zheng <uwu@icenowy.me> wrote:
> >
> > 在 2026-03-25三的 15:19 +0800，Chen-Yu Tsai写道：
> > > Hi everyone,
> > >
> > > This is v2 of my MT8173 PowerVR GPU support series.
> > >
> > > Changes since v1:
> > > - Adapted to changed DT bindings
> > > - Dropped driver change
> > > - Use same power domain for "a" and "b" GPU power domains
> > >
> > > This update was requested by Icenowy.
> > >
> > >
> > > This series enables the PowerVR GPU found in the MT8173 SoC,
> > > found in
> > > some Chromebooks.
> > >
> > > This version is different from the initial powervr driver
> > > submission
> > > [1]
> > > in that it splits out the GPU glue layer support out of the
> > > powervr
> > > driver and into a separate clock and power domain driver. The
> > > glue
> > > code
> > > is otherwise the same, and also the same as found in the ChromeOS
> > > kernels, with some extra comments and macro names added where
> > > possible.
> > >
> > > Patch 1 adds a binding for the glue layer, called mfgtop. The
> > > glue
> > > layer
> > > contains clock and power controls for the GPU.
> > >
> > > Patch 2 adds a driver for the glue layer.
> > >
> > > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the
> > > PowerVR
> > > binding.
> > >
> > > Patch 4 adds an entry for the PowerVR 6XT series GPU to the
> > > driver.
> > >
> > > Patch 5 corrects the clock for the GPU (called MFG) power domain.
> > >
> > > Patch 6 adds device nodes for the GPU and glue layer to the
> > > MT8173
> > > dtsi
> > > file.
> > >
> > > Patch 2 and 6 depend on patch 1 to build. I suppose some common
> > > immutable tree would be needed from the MediaTek maintainers.
> > >
> > > The kernel driver successfully probes the hardware and loads the
> > > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination
> > > Technologies
> > > [2].
> > > Userspace was tested with Mesa 24.0.8 from Debian Trixie rebuilt
> > > with
> > > the powervr vulkan driver enabled. `vulkaninfo` gives some
> > > information
> > > about the GPU (attached at the end), but running the `triangle`
> > > example
> > > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as
> > > recommended [4]
> > > failed with:
> > >
> > > Can't find a display and a display mode!
> >
> > I think when using D2D the demos want width and height to be
> > explicitly
> > specified, otherwise it seems to hardcode 1280x720.
> >
> > If you're using an elm, could you try to add `-w 1920 -h 1080` or
> > for
> > hana `-w 1366 -h 768` ?
>
> I only did the basic `vulkaninfo` test this time around. To do
> anything
> interesting probably requires the Mesa 26.1 release.
>
> PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 \
> vkmark --winsys kms -D b81f54f8568deb0fb70a6a1ed845b65d
>
> just reports "Error: Device specified by uuid is not available"
I am very sorry to tell you that, when I run Sascha's demo with Mesa
main, I got GPU lost immediately...
```
[ 441.509433] powervr 13000000.gpu: [drm] *ERROR* GPU device lost
```
Icenowy
>
> This is with Mesa 26.0.2 packages from Debian testing. At least now
> have the powervr vulkan driver enabled by default, so I don't have
> to rebuild the packages again.
>
>
> ChenYu
>
> > Thanks
> > Icenowy
> >
> > >
> > > Same program worked correctly on a BeaglePlay and displayed a
> > > color
> > > gradient triangle. Not sure what went wrong here.
> > >
> > > Anyway, please have a look and test.
> > >
> > >
> > > Thanks
> > > ChenYu
> > >
> > > [1]
> > > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
> > > [2]
> > > https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> > > [3] https://github.com/SaschaWillems/Vulkan
> > > [4]
> > > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
> > >
> > > Chen-Yu Tsai (5):
> > > dt-bindings: clock: mediatek: Add mt8173 mfgtop
> > > clk: mediatek: Add mt8173-mfgtop driver
> > > dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> > > arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
> > > arm64: dts: mediatek: mt8173: Add GPU device nodes
> > >
> > > .../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
> > > .../bindings/gpu/img,powervr-rogue.yaml | 1 +
> > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
> > > drivers/clk/mediatek/Kconfig | 9 +
> > > drivers/clk/mediatek/Makefile | 1 +
> > > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243
> > > ++++++++++++++++++
> > > include/dt-bindings/clock/mt8173-clk.h | 7 +
> > > 7 files changed, 363 insertions(+), 1 deletion(-)
> > > create mode 100644
> > > Documentation/devicetree/bindings/clock/mediatek,mt8173-
> > > mfgtop.yaml
> > > create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
^ permalink raw reply
* Re: [PATCH 0/4] Add i.MX94 remoteproc support and reset vector handling improvements
From: Daniel Baluta @ 2026-03-25 8:41 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Peng Fan (OSS), Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <acFPGVNOornxsPG6@p14s>
On 3/23/26 16:32, Mathieu Poirier wrote:
> On Fri, Mar 20, 2026 at 11:19:06AM +0200, Daniel Baluta wrote:
>> On 3/12/26 14:36, Peng Fan (OSS) wrote:
>>> This series adds remoteproc support for the i.MX94 family, including the
>>> CM70, CM71, and CM33S cores, and introduces a new device‑tree property to
>>> correctly derive the hardware reset vector for Cortex‑M processors whose
>>> ELF entry point does not directly correspond to the actual reset address.
>>>
>>> Background:
>>> Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
>>> table. While ELF images embed the entry point (e_entry), this value is
>>> not always aligned to the hardware reset address. On platforms such as
>>> i.MX94 CM33S, masking is required to compute the correct reset vector
>>> address before programming the SoC reset registers.
>> What happens if the reset vector is at 0 and the e_entry point is at 0x800...?
>>
>> In this case masking will no longer work! Can we implement a generic approach?
>>
> I will wait to see an R-B from Daniel before looking at this set.
>
> Thanks,
> Mathieu
>
>
Hi Mathieu, Peng,
Patchseries mostly looks good to me. The only blocking issue here is how to correctly specify the hardware reset address.
I see two options here:
1) Create a special section in TCM that holds the PC/Stack initial value as concluded here [1]. But this
doesn't work in all the cases
2) Add a per device data that holds the hardware reset mask that gets applied to entry address read from ELF.
I'm fine going with option 2) and that's because this change is IMX rproc driver specific, it scales well and will be maintained by Peng.
thanks,
Daniel.
[1] https://lore.kernel.org/linux-remoteproc/38476dd0-07a6-310f-1fba-2b3021a5b007@kontron.de/
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-03-25 8:41 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Jeffery, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <0f7f0f96-a918-47d5-a0bd-bbde494c8fed@app.fastmail.com>
Hi Arnd,
> On Tue, Mar 17, 2026, at 09:14, YH Chung wrote:
> >
> > In the meantime, my understanding is that this driver is for the Intel
> > eSPI interface used by the AST2600 BMC,
> > rather than fitting a conventional SPI controller/device model. That
> > was the reason for initially placing it under
> > drivers/soc/aspeed/, since there does not appear to be an in-tree eSPI
> > subsystem at present.
> > However, if that is not the preferred upstream direction, we are happy
> > to restructure the series accordingly.
> > It would be very helpful if you could advise on the preferred placement.
>
> I think we need to make sure everyone understands what the options are
> here based on what the hardware can do, and what your use cases require.
>
For reference, Intel's eSPI base specification is defined here:
https://www.intel.com/content/www/us/en/content-details/841685/enhanced-serial-peripheral-interface-espi-interface-base-specification-for-client-and-server-platforms.html
Although eSPI physically reuses some SPI pins, it is not used as a
conventional SPI controller/device interface. It also adds RESET# and ALERT#
beyond the usual SPI signals.
The spec also defines two roles in eSPI transaction model: Controller and
Target Device. ASPEED SoCs act as the Target Device side to interact with the
host. In this case, the hardware is not exposed in a form that maps naturally
onto the existing SPI subsystem model.
> If I understood this correctly, I think there is a general agreement
> upstream that the low-level device access should indeed be in a
> drivers/spi driver, with no ports of it in drivers/soc/aspeed. Using
> a portable driver subsystem is always better than a custom solution
> if it works at all.
We understand the preference for using a generic subsystem where possible.
Our hesitation is that the eSPI functionality appears to software primarily
in terms of the eSPI Peripherals, Virtual Wires, OOB (SMBus), and Flash
channel semantics and backend routing, rather than low-level bus signaling.
Since this driver is responsible for configuring those Aspeed-specific
backend interfaces so they can service host requests, we initially placed it
under drivers/soc/aspeed.
> From reading the old comments that Andrew linked to at
>
> https://lore.kernel.org/linux-aspeed/HK0PR06MB377924CFCBFE9BD40E1C4A5D91
> D49@HK0PR06MB3779.apcprd06.prod.outlook.com/
>
> I understand that the SoC has a "hardware mode" in which eSPI is
> directly implemented by redirecting upper-level eSPI transactions into
> functional blocks of the chip, while the software mode behaves like
> a regular SPI endpoint controller and your driver implements the
> same interfaces in a mix of kernel and userspace components. Can you
> confirm that this is a correct understanding of what the hardware
> does, or where I misunderstand parts?
Broadly yes, except that the AST2600 does not operate in a single global
"hardware mode" or "software mode". Instead, some backends in the eSPI target
controller support per-function HW/SW mode selection.
Depending on that function-specific setting, the controller either forwards a
received transaction directly to the corresponding hardware block or traps it
for software handling instead.
This mechanism exists because some backend blocks include their own hardware
filtering, but not all request types could be validated generically in
hardware. For example, the LPC bridge can reject illegal requests. In some
cases, blindly forwarding host requests to the target block would also have
security implications.
The channel/backend mapping on AST2600 can be summarized as:
eSPI
├── Peripheral
│ ├── Memory (HW mode only)
│ └── LPC bridge (HW mode only)
├── Virtual Wire
│ └── GPIO (HW/SW mode selection)
├── Out-of-Band (SW mode only)
└── Flash
└── Storage controller (HW/SW mode selection)
From the link thread, what Jeremy mentioned is the GPIO HW/SW mode for CH1,
which determines whether the host can directly control the corresponding BMC
GPIO output, or whether BMC software can inspect and decide whether to act on
that request.
Another example is the Target Attached Flash Sharing (TAFS) defined by the
eSPI specification that allows BMC to share its storage with the host.
In hardware mode, the eSPI Target Device controller routes the request
directly to a predefined storage controller on AST2600.
In software mode, it raises an interrupt and lets software handle the
transaction instead.
So I would not describe the AST2600 eSPI block as being globally in either
"hardware mode" or "software mode".
That choice is made per backend function, and some backend functions do not
implement such a switch at all.
So far, this series only covers the LPC bridge and flash channel parts.
> For the higher-level interfaces (flash, gpio, ...), I don't think
> there is any consensus yet about how this should be done, but again
> I think this won't be drivers/soc but instead something more
> generic.
For the flash-related interface, would it make sense to follow the
configuration model used by the USB gadget mass-storage function, and expose
the backing storage selection through configfs?
For the attributes, perhaps the only backing storage object and read-only
flag would be required in our case.
For the Virtual Wire GPIO, we think GPIO subsystem may be leveraged here,
though some corner cases may not map cleanly to a typical GPIO controller
model.
For the Out-of-band channel, since the eSPI spec models it for tunneled SMBus
packets, we may want to integrate it with the kernel's MCTP stack if that is
a suitable fit.
Thanks,
Yun Hsuan
^ permalink raw reply
* Re: [PATCH v3 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Ronald Claveau @ 2026-03-25 8:40 UTC (permalink / raw)
To: Xianwei Zhao
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel
In-Reply-To: <316efeff-477d-4d8d-9c60-ac7c4e5b9b33@amlogic.com>
On 3/25/26 3:48 AM, Xianwei Zhao wrote:
> Hi Ronald,
>
> On 2026/3/23 17:55, Ronald Claveau wrote:
>> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
>> to configure pin muxing at runtime.
>>
>> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
>> - SD card: data, clock, command and clock gate pins
>> - SDIO: data, clock, command and clock gate pins
>>
>> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
>> ---
>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++
>> ++++++++++
>> 1 file changed, 98 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/
>> boot/dts/amlogic/amlogic-t7.dtsi
>> index 6510068bcff92..ac8de8e9b8010 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> @@ -250,6 +250,104 @@ gpio: bank@4000 {
>> #gpio-cells = <2>;
>> gpio-ranges =
>> <&periphs_pinctrl 0 0 157>;
>> };
>> +
>> + emmc_ctrl_pins: emmc-ctrl {
>> + mux-0 {
>> + groups = "emmc_cmd";
>> + function = "emmc";
>> + bias-pull-up;
>> + };
>> +
>> + mux-1 {
>> + groups = "emmc_clk";
>> + function = "emmc";
>> + bias-disable;
>> + };
>> + };
>> +
>> + emmc_data_4b_pins: emmc-data-4b {
>> + mux-0 {
>> + groups = "emmc_nand_d0",
>> + "emmc_nand_d1",
>> + "emmc_nand_d2",
>> + "emmc_nand_d3";
>> + function = "emmc";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + emmc_data_8b_pins: emmc-data-8b {
>> + mux-0 {
>> + groups = "emmc_nand_d0",
>> + "emmc_nand_d1",
>> + "emmc_nand_d2",
>> + "emmc_nand_d3",
>> + "emmc_nand_d4",
>> + "emmc_nand_d5",
>> + "emmc_nand_d6",
>> + "emmc_nand_d7";
>> + function = "emmc";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + emmc_ds_pins: emmc-ds {
>> + mux {
>> + groups = "emmc_nand_ds";
>> + function = "emmc";
>> + bias-pull-down;
>> + };
>> + };
>> +
>> + emmc_clk_gate_pins: emmc_clk_gate {
>
> Node names should use hyphens ('-') instead of underscores ('_'),
> consistent with the following nodes.
>
Thanks for your feedback Xianwei.
I will change that.
>> + mux {
>> + groups = "GPIOB_8";
>> + function =
>> "gpio_periphs";
>> + bias-pull-down;
>> + };
>> + };
>> +
>> + sdcard_pins: sdcard {
>> + mux {
>> + groups = "sdcard_d0",
>> + "sdcard_d1",
>> + "sdcard_d2",
>> + "sdcard_d3",
>> + "sdcard_clk",
>> + "sdcard_cmd";
>> + function = "sdcard";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + sdcard_clk_gate_pins: sdcard_clk_gate {
>> + mux {
>> + groups = "GPIOC_4";
>> + function =
>> "gpio_periphs";
>> + bias-pull-down;
>> + };
>> + };
>> +
>> + sdio_pins: sdio {
>> + mux-0 {
>> + groups = "sdio_d0",
>> + "sdio_d1",
>> + "sdio_d2",
>> + "sdio_d3",
>> + "sdio_clk",
>> + "sdio_cmd";
>> + function = "sdio";
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + sdio_clk_gate_pins: sdio_clk_gate {
>> + mux {
>> + groups = "GPIOX_4";
>> + function =
>> "gpio_periphs";
>> + bias-pull-up;
>> + };
>> + };
>> };
>>
>> gpio_intc: interrupt-controller@4080 {
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH v2 0/5] powervr: MT8173 GPU support
From: Icenowy Zheng @ 2026-03-25 8:41 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, linux-clk,
devicetree, linux-mediatek, dri-devel, linux-arm-kernel,
linux-kernel
In-Reply-To: <0739597b7a9c162525c10d82c3993e37af1c8a75.camel@icenowy.me>
在 2026-03-25三的 16:30 +0800，Icenowy Zheng写道：
> 在 2026-03-25三的 16:08 +0800，Chen-Yu Tsai写道：
> > On Wed, Mar 25, 2026 at 4:04 PM Icenowy Zheng <uwu@icenowy.me>
> > wrote:
> > >
> > > 在 2026-03-25三的 15:19 +0800，Chen-Yu Tsai写道：
> > > > Hi everyone,
> > > >
> > > > This is v2 of my MT8173 PowerVR GPU support series.
> > > >
> > > > Changes since v1:
> > > > - Adapted to changed DT bindings
> > > > - Dropped driver change
> > > > - Use same power domain for "a" and "b" GPU power domains
> > > >
> > > > This update was requested by Icenowy.
> > > >
> > > >
> > > > This series enables the PowerVR GPU found in the MT8173 SoC,
> > > > found in
> > > > some Chromebooks.
> > > >
> > > > This version is different from the initial powervr driver
> > > > submission
> > > > [1]
> > > > in that it splits out the GPU glue layer support out of the
> > > > powervr
> > > > driver and into a separate clock and power domain driver. The
> > > > glue
> > > > code
> > > > is otherwise the same, and also the same as found in the
> > > > ChromeOS
> > > > kernels, with some extra comments and macro names added where
> > > > possible.
> > > >
> > > > Patch 1 adds a binding for the glue layer, called mfgtop. The
> > > > glue
> > > > layer
> > > > contains clock and power controls for the GPU.
> > > >
> > > > Patch 2 adds a driver for the glue layer.
> > > >
> > > > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the
> > > > PowerVR
> > > > binding.
> > > >
> > > > Patch 4 adds an entry for the PowerVR 6XT series GPU to the
> > > > driver.
> > > >
> > > > Patch 5 corrects the clock for the GPU (called MFG) power
> > > > domain.
> > > >
> > > > Patch 6 adds device nodes for the GPU and glue layer to the
> > > > MT8173
> > > > dtsi
> > > > file.
> > > >
> > > > Patch 2 and 6 depend on patch 1 to build. I suppose some common
> > > > immutable tree would be needed from the MediaTek maintainers.
> > > >
> > > > The kernel driver successfully probes the hardware and loads
> > > > the
> > > > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination
> > > > Technologies
> > > > [2].
> > > > Userspace was tested with Mesa 24.0.8 from Debian Trixie
> > > > rebuilt
> > > > with
> > > > the powervr vulkan driver enabled. `vulkaninfo` gives some
> > > > information
> > > > about the GPU (attached at the end), but running the `triangle`
> > > > example
> > > > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as
> > > > recommended [4]
> > > > failed with:
> > > >
> > > > Can't find a display and a display mode!
> > >
> > > I think when using D2D the demos want width and height to be
> > > explicitly
> > > specified, otherwise it seems to hardcode 1280x720.
> > >
> > > If you're using an elm, could you try to add `-w 1920 -h 1080` or
> > > for
> > > hana `-w 1366 -h 768` ?
> >
> > I only did the basic `vulkaninfo` test this time around. To do
> > anything
> > interesting probably requires the Mesa 26.1 release.
> >
> > PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 \
> > vkmark --winsys kms -D b81f54f8568deb0fb70a6a1ed845b65d
> >
> > just reports "Error: Device specified by uuid is not available"
>
> I am very sorry to tell you that, when I run Sascha's demo with Mesa
> main, I got GPU lost immediately...
>
> ```
> [ 441.509433] powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> ```
Sidenote: I think this is some power domain management issue, because I
saw the kernel saying `vgpu: disabling` , which shouldn't happen if the
GPU is active?
>
> Icenowy
>
> >
> > This is with Mesa 26.0.2 packages from Debian testing. At least now
> > have the powervr vulkan driver enabled by default, so I don't have
> > to rebuild the packages again.
> >
> >
> > ChenYu
> >
> > > Thanks
> > > Icenowy
> > >
> > > >
> > > > Same program worked correctly on a BeaglePlay and displayed a
> > > > color
> > > > gradient triangle. Not sure what went wrong here.
> > > >
> > > > Anyway, please have a look and test.
> > > >
> > > >
> > > > Thanks
> > > > ChenYu
> > > >
> > > > [1]
> > > > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
> > > > [2]
> > > > https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> > > > [3] https://github.com/SaschaWillems/Vulkan
> > > > [4]
> > > > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
> > > >
> > > > Chen-Yu Tsai (5):
> > > > dt-bindings: clock: mediatek: Add mt8173 mfgtop
> > > > clk: mediatek: Add mt8173-mfgtop driver
> > > > dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> > > > arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain
> > > > clock
> > > > arm64: dts: mediatek: mt8173: Add GPU device nodes
> > > >
> > > > .../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
> > > > .../bindings/gpu/img,powervr-rogue.yaml | 1 +
> > > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
> > > > drivers/clk/mediatek/Kconfig | 9 +
> > > > drivers/clk/mediatek/Makefile | 1 +
> > > > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243
> > > > ++++++++++++++++++
> > > > include/dt-bindings/clock/mt8173-clk.h | 7 +
> > > > 7 files changed, 363 insertions(+), 1 deletion(-)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/clock/mediatek,mt8173-
> > > > mfgtop.yaml
> > > > create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
^ permalink raw reply
* Re: [PATCH v3 2/9] dt-bindings: mmc: amlogic: Add compatible for T7 mmc
From: Ronald Claveau @ 2026-03-25 8:45 UTC (permalink / raw)
To: Xianwei Zhao
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel
In-Reply-To: <c01c4e7e-1c0c-4bbf-b126-831160c8e32b@amlogic.com>
On 3/25/26 3:38 AM, Xianwei Zhao wrote:
> Hi Ronald,
>
> On 2026/3/23 17:55, Ronald Claveau wrote:
>> Add amlogic,t7-mmc compatible string, falling back to amlogic,meson-
>> axg-mmc
>> as the T7 MMC controller is compatible with the AXG implementation.
>>
>> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
>> ---
>> Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml | 5
>> ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
>> b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
>> index 57646575a13f8..40dccf9715781 100644
>> --- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
>> @@ -19,7 +19,10 @@ allOf:
>> properties:
>> compatible:
>> oneOf:
>> - - const: amlogic,meson-axg-mmc
>> + - items:
>> + - enum:
>> + - amlogic,t7-mmc
>> + - const: amlogic,meson-axg-mmc
>
> It seems that break API here.
> One item should be added here instead of being replaced.
>
Thanks Xianwei, ok I will change that in a new version.
>> - items:
>> - const: amlogic,meson-gx-mmc
>> - const: amlogic,meson-gxbb-mmc
>>
>> --
>> 2.49.0
--
Best regards,
Ronald
^ permalink raw reply
* RE: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600 new register set
From: Ryan Chen @ 2026-03-25 8:46 UTC (permalink / raw)
To: Jeremy Kerr, andriy.shevchenko@linux.intel.com, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Benjamin Herrenschmidt, Philipp Zabel
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <db921d6b820a13d59d0ffb0ab042dc6c8c11897f.camel@codeconstruct.com.au>
> Subject: Re: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600
> new register set
>
> Hi Ryan,
>
> > +static void ast2600_i2c_set_xfer_mode(struct ast2600_i2c_bus
> > +*i2c_bus,
> > + enum xfer_mode
> mode) {
> > + i2c_bus->mode = mode;
> > +
> > + switch (mode) {
> > + case DMA_MODE:
> > + i2c_bus->setup_tx = ast2600_i2c_setup_dma_tx;
> > + i2c_bus->setup_rx = ast2600_i2c_setup_dma_rx;
> > + break;
> > + case BYTE_MODE:
> > + i2c_bus->setup_tx = ast2600_i2c_setup_byte_tx;
> > + i2c_bus->setup_rx = ast2600_i2c_setup_byte_rx;
> > + break;
> > + case BUFF_MODE:
> > + default:
> > + i2c_bus->setup_tx = ast2600_i2c_setup_buff_tx;
> > + i2c_bus->setup_rx = ast2600_i2c_setup_buff_rx;
> > + break;
> > + }
> > +}
> > +
> > +static int ast2600_i2c_xfer_mode_parse(struct ast2600_i2c_bus
> > +*i2c_bus,
> > + const char *buf,
> enum xfer_mode
> > +*mode) {
> > + if (sysfs_streq(buf, "byte")) {
> > + *mode = BYTE_MODE;
> > + return 0;
> > + }
> > +
> > + if (sysfs_streq(buf, "buffer")) {
> > + if (!i2c_bus->buf_base)
> > + return -EINVAL;
> > + *mode = BUFF_MODE;
> > + return 0;
> > + }
> > +
> > + if (sysfs_streq(buf, "dma")) {
> > + if (!i2c_bus->dma_available)
> > + return -EINVAL;
> > + *mode = DMA_MODE;
> > + return 0;
> > + }
> > +
> > + return -EINVAL;
> > +}
>
> I would suggest separating the string parsing from the "is the mode available"
> logic, more on that below.
>
I will separate with following.
static int ast2600_i2c_xfer_mode_parse(const char *buf, enum xfer_mode *mode)
{
if (sysfs_streq(buf, "byte")) { *mode = BYTE_MODE; return 0; }
if (sysfs_streq(buf, "buffer")) { *mode = BUFF_MODE; return 0; }
if (sysfs_streq(buf, "dma")) { *mode = DMA_MODE; return 0; }
return -EINVAL;
}
static int ast2600_i2c_xfer_mode_check(struct ast2600_i2c_bus *i2c_bus,
enum xfer_mode mode)
{
if (mode == BUFF_MODE && !i2c_bus->buf_base)
return -EINVAL;
if (mode == DMA_MODE && !i2c_bus->dma_available)
return -EINVAL;
return 0;
}
> > +
> > +static const char *ast2600_i2c_xfer_mode_name(enum xfer_mode mode) {
> > + switch (mode) {
> > + case BYTE_MODE:
> > + return "byte";
> > + case DMA_MODE:
> > + return "dma";
> > + case BUFF_MODE:
> > + default:
> > + return "buffer";
> > + }
> > +}
> > +
> > +static ssize_t xfer_mode_show(struct device *dev, struct
> > +device_attribute *attr, char *buf) {
> > + struct ast2600_i2c_bus *i2c_bus = dev_get_drvdata(dev);
> > +
> > + return sysfs_emit(buf, "%s\n",
> > +ast2600_i2c_xfer_mode_name(i2c_bus->mode));
> > +}
> > +
> > +static ssize_t xfer_mode_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
> {
> > + struct ast2600_i2c_bus *i2c_bus = dev_get_drvdata(dev);
> > + enum xfer_mode mode;
> > + int ret;
> > +
> > + ret = ast2600_i2c_xfer_mode_parse(i2c_bus, buf, &mode);
> > + if (ret)
> > + return ret;
> > +
> > + i2c_lock_bus(&i2c_bus->adap, I2C_LOCK_ROOT_ADAPTER);
> > + ast2600_i2c_set_xfer_mode(i2c_bus, mode);
> > + i2c_unlock_bus(&i2c_bus->adap, I2C_LOCK_ROOT_ADAPTER);
> > +
> > + return count;
> > +}
> > +
> > +static DEVICE_ATTR_RW(xfer_mode);
>
> This will need sysfs ABI documentation.
Since it is in sysfs /sys/bus/platform/drivers/i2c_ast2600
So I add Documentation/ABI/testing/sysfs-bus-platform-drivers-i2c-ast2600
am I right?
What: /sys/bus/platform/drivers/i2c-ast2600/.../xfer_mode
Date: March 2026
KernelVersion: 6.x
Contact: Ryan Chen <ryan_chen@aspeedtech.com>
Description:
Shows or sets the transfer mode for the ASPEED AST2600 I2C
controller. Valid values are:
- "byte": Programmed I/O, one byte at a time.
- "buffer": Programmed I/O using the hardware FIFO buffer.
- "dma": DMA transfer (only available if aspeed,enable-dma
is set in the device tree).
Writing an unsupported mode returns -EINVAL.
>
> > +
> > +static int ast2600_i2c_probe(struct platform_device *pdev) {
> > + struct device *dev = &pdev->dev;
> > + struct ast2600_i2c_bus *i2c_bus;
> > + struct reset_control *rst;
> > + struct resource *res;
> > + u32 global_ctrl;
> > + int ret;
> > +
> > + if (!device_property_present(dev, "aspeed,global-regs"))
> > + return -ENODEV;
> > +
> > + i2c_bus = devm_kzalloc(dev, sizeof(*i2c_bus), GFP_KERNEL);
> > + if (!i2c_bus)
> > + return -ENOMEM;
> > +
> > + i2c_bus->reg_base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(i2c_bus->reg_base))
> > + return PTR_ERR(i2c_bus->reg_base);
> > +
> > + rst = devm_reset_control_get_shared_deasserted(dev, NULL);
> > + if (IS_ERR(rst))
> > + return dev_err_probe(dev, PTR_ERR(rst), "Missing
> reset
> > +ctrl\n");
> > +
> > + i2c_bus->global_regs =
> >
> + syscon_regmap_lookup_by_phandle(dev_of_node(dev
> ),
> > +"aspeed,global-regs");
> > + if (IS_ERR(i2c_bus->global_regs))
> > + return PTR_ERR(i2c_bus->global_regs);
> > +
> > + regmap_read(i2c_bus->global_regs, AST2600_I2CG_CTRL,
> > +&global_ctrl);
> > + if ((global_ctrl & AST2600_GLOBAL_INIT) !=
> > +AST2600_GLOBAL_INIT) {
> > + regmap_write(i2c_bus->global_regs,
> AST2600_I2CG_CTRL,
> > +AST2600_GLOBAL_INIT);
> > + regmap_write(i2c_bus->global_regs,
> > +AST2600_I2CG_CLK_DIV_CTRL, I2CCG_DIV_CTRL);
> > + }
> > +
> > + i2c_bus->dev = dev;
> > + i2c_bus->multi_master = device_property_read_bool(dev,
> > +"multi-master");
> > + i2c_bus->dma_available = device_property_read_bool(dev,
> > +"aspeed,enable-dma");
> > + if (i2c_bus->dma_abailable)
>
> dma_abailable? you didn't even build this? :(
OH, Sorry it is my bad.
>
> > + i2c_bus->mode = DMA_MODE;
> > + else
> > + i2c_bus->mode = BUFF_MODE;
> > +
> > + if (i2c_bus->mode == BUFF_MODE) {
> > + i2c_bus->buf_base =
> > +devm_platform_get_and_ioremap_resource(pdev, 1, &res);
>
> So you only set ->buf_base if we are in buffer mode during probe.
>
> However, the ->buf_base check in xfer_mode_parse() will fail when trying to
> change from any other mode to buffer mode. This means you can never select
> buffer mode after probe.
Will modify with following.
i2c_bus->buf_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
if (!IS_ERR(i2c_bus->buf_base))
i2c_bus->buf_size = resource_size(res) / 2;
else
i2c_bus->buf_base = NULL;
>
>
> > + if (IS_ERR(i2c_bus->buf_base))
> > + i2c_bus->mode = BYTE_MODE;
> > + else
> > + i2c_bus->buf_size = resource_size(res) /
> 2;
> > + }
> > +
> > + ast2600_i2c_set_xfer_mode(i2c_bus, i2c_bus->mode);
>
> Minor: set_xfer_mode() sets i2c_bus->mode itself. Maybe you want a
> temporary instead, or change the semantics of that?
Will update
if (i2c_bus->dma_available)
mode = DMA_MODE;
else if (i2c_bus->buf_base)
mode = BUFF_MODE;
else
mode = BYTE_MODE;
ast2600_i2c_set_xfer_mode(i2c_bus, mode);
>
> > +
> > + /*
> > + * i2c timeout counter: use base clk4 1Mhz,
> > + * per unit: 1/(1000/1024) = 1024us
> > + */
> > + ret = device_property_read_u32(dev,
> > +"i2c-scl-clk-low-timeout-us", &i2c_bus->timeout);
> > + if (!ret)
> > + i2c_bus->timeout =
> DIV_ROUND_UP(i2c_bus->timeout,
> > +1024);
> > +
> > + init_completion(&i2c_bus->cmd_complete);
> > +
> > + i2c_bus->irq = platform_get_irq(pdev, 0);
> > + if (i2c_bus->irq < 0)
> > + return i2c_bus->irq;
> > +
> > + platform_set_drvdata(pdev, i2c_bus);
> > +
> > + i2c_bus->clk = devm_clk_get(i2c_bus->dev, NULL);
> > + if (IS_ERR(i2c_bus->clk))
> > + return dev_err_probe(i2c_bus->dev,
> > +PTR_ERR(i2c_bus->clk), "Can't get clock\n");
> > +
> > + i2c_bus->apb_clk = clk_get_rate(i2c_bus->clk);
> > +
> > + i2c_parse_fw_timings(i2c_bus->dev, &i2c_bus->timing_info,
> > +true);
> > +
> > + /* Initialize the I2C adapter */
> > + i2c_bus->adap.owner = THIS_MODULE;
> > + i2c_bus->adap.algo = &i2c_ast2600_algorithm;
> > + i2c_bus->adap.retries = 0;
> > + i2c_bus->adap.dev.parent = i2c_bus->dev;
> > + device_set_node(&i2c_bus->adap.dev, dev_fwnode(dev));
> > + i2c_bus->adap.algo_data = i2c_bus;
> > + strscpy(i2c_bus->adap.name, pdev->name);
> > + i2c_set_adapdata(&i2c_bus->adap, i2c_bus);
> > +
> > + ret = ast2600_i2c_init(i2c_bus);
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "Unable to initial i2c
> > +%d\n", ret);
>
> Super minor: `initial` is not a verb in this context, you want `initialise`
> (Australian) or `initialize` (US) or `init` (keeping everyone happy)
Will update
>
> > +
> > + ret = devm_request_irq(dev, i2c_bus->irq, ast2600_i2c_bus_irq,
> > +0,
> > + dev_name(dev), i2c_bus);
> > + if (ret < 0) {
> > + ret = dev_err_probe(dev, ret, "Unable to request irq
> > +%d\n",
> > + i2c_bus->irq);
> > + goto err;
> > + }
> > +
> > + writel(AST2600_I2CM_PKT_DONE |
> AST2600_I2CM_BUS_RECOVER,
> > + i2c_bus->reg_base + AST2600_I2CM_IER);
> > +
> > + ret = devm_i2c_add_adapter(dev, &i2c_bus->adap);
> > + if (ret)
> > + goto err;
> > +
> > + ret = sysfs_create_file(&dev->kobj, &dev_attr_xfer_mode.attr);
> > + if (ret)
> > + goto err;
>
> This error path will fail the probe but not unregister the i2c adapter.
> You probably want to only register the adapter last (and remove the sysfs file if
> that fails).
Will update
sysfs_create_file();
if (ret)
goto err;
devm_i2c_add_adapter();
if (ret) {
sysfs_remove_file();
goto err;
}
>
> > +
> > + return 0;
> > +
> > +err:
> > + writel(0, i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
> > + writel(0, i2c_bus->reg_base + AST2600_I2CM_IER);
> > + return ret;
> > +}
> > +
> > +static void ast2600_i2c_remove(struct platform_device *pdev) {
> > + struct ast2600_i2c_bus *i2c_bus = platform_get_drvdata(pdev);
> > +
> > + sysfs_remove_file(&pdev->dev.kobj, &dev_attr_xfer_mode.attr);
> > +
> > + /* Disable everything. */
> > + writel(0, i2c_bus->reg_base + AST2600_I2CC_FUN_CTRL);
> > + writel(0, i2c_bus->reg_base + AST2600_I2CM_IER); }
> > +
> > +static const struct of_device_id ast2600_i2c_of_match[] = {
> > + { .compatible = "aspeed,ast2600-i2c-bus" },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, ast2600_i2c_of_match);
> > +
> > +static struct platform_driver ast2600_i2c_driver = {
> > + .probe = ast2600_i2c_probe,
> > + .remove = ast2600_i2c_remove,
> > + .driver = {
> > + .name = "ast2600-i2c",
> > + .of_match_table = ast2600_i2c_of_match,
> > + },
> > +};
> > +module_platform_driver(ast2600_i2c_driver);
> > +
> > +MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
> > +MODULE_DESCRIPTION("ASPEED AST2600 I2C Controller Driver");
> > +MODULE_LICENSE("GPL");
>
> Cheers,
>
>
> Jeremy
^ permalink raw reply
* Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Per-process page size
From: Askar Safin @ 2026-03-25 8:46 UTC (permalink / raw)
To: jack
Cc: Liam.Howlett, akpm, ardb, baolin.wang, catalin.marinas, david,
dev.jain, hughd, linux-arm-kernel, linux-kernel, linux-mm,
lorenzo.stoakes, lsf-pc, mhocko, rppt, ryan.roberts, surenb,
vbabka, will, willy
In-Reply-To: <pqwem5hownnfwcqrubksdwwraqbkthpzucknhavrghmw5lyszs@vdorbx4fyyaf>
Jan Kara <jack@suse.cz>:
> > Is there some other way for someone to block a page from getting evicted
> > from the pagecache?
> >
> > We have this memfd_pin_folios() thing, but I don't think we have something
> > comparable for ordinary pagecache files.
> >
> > ... putting them into a pipe and never reading from the pipe maybe (I assume
> > that's what splice() does, but not sure if it actually places the pages in
> > there or whether it creates a copy first)?
>
> Standard splice copies data first (it's using standard IO callbacks such as
> ->read_iter) so that doesn't pin page cache AFAICT. Only vmsplice(2) does
> but that requires mmap.
Splice from page cache to pipe sometimes doesn't copy data.
That is why test program mentioned here may print "new":
https://lore.kernel.org/all/CAHk-=wjixHw6n_R5TQWW1r0a+GgFAPGw21KMj6obkzr3qXXbYA@mail.gmail.com/
--
Askar Safin
^ permalink raw reply
* Re: [PATCH v2 0/9] memblock: improve late freeing of reserved memory
From: Mike Rapoport @ 2026-03-25 8:51 UTC (permalink / raw)
To: Andrew Morton, Mike Rapoport
Cc: Alexander Potapenko, Alexander Viro, Andreas Larsson,
Ard Biesheuvel, Borislav Petkov, Brendan Jackman,
Christophe Leroy (CS GROUP), Catalin Marinas, Christian Brauner,
David S. Miller, Dave Hansen, David Hildenbrand, Dmitry Vyukov,
Ilias Apalodimas, Ingo Molnar, Jan Kara, Johannes Weiner,
Liam R. Howlett, Madhavan Srinivasan, Marco Elver,
Marek Szyprowski, Masami Hiramatsu, Michael Ellerman,
Michal Hocko, Nicholas Piggin, H. Peter Anvin, Rob Herring,
Robin Murphy, Saravana Kannan, Suren Baghdasaryan,
Thomas Gleixner, Vlastimil Babka, Will Deacon, Zi Yan, devicetree,
iommu, kasan-dev, linux-arm-kernel, linux-efi, linux-fsdevel,
linux-kernel, linux-mm, linux-trace-kernel, linuxppc-dev,
sparclinux, x86, Lorenzo Stoakes
In-Reply-To: <20260323074836.3653702-1-rppt@kernel.org>
On Mon, 23 Mar 2026 09:48:27 +0200, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>
> Hi,
>
> Following a recent discussion about leaks in x86 EFI [1], I audited usage of
> memblock_free_late() and free_reserved_area() and made some imporovements how
> we handle late freeing of the memory allocated with memblock.
>
> [...]
Applied to for-next branch of memblock.git tree, thanks!
[1/9] memblock: reserve_mem: fix end caclulation in reserve_mem_release_by_name()
commit: ea459d3c24fefd90b60a702f4a73833434ae0248
[2/9] powerpc: fadump: pair alloc_pages_exact() with free_pages_exact()
commit: 6e827110aea5fb9c53a5bf070413ffe5cad105b0
[3/9] powerpc: opal-core: pair alloc_pages_exact() with free_pages_exact()
commit: 3cf80188ecb828ed034ba562614cf1d48156b126
[4/9] mm: move free_reserved_area() to mm/memblock.c
commit: 0aa264cda784f9fbe1a80ef13144cf81610086c7
[5/9] memblock: make free_reserved_area() more robust
commit: 456ac994018598bc57ceaacb8a2c72e722c9755b
[6/9] memblock: extract page freeing from free_reserved_area() into a helper
commit: 40191dae9ed84c816b593bb1b36a80f86c2279d1
[7/9] memblock: make free_reserved_area() update memblock if ARCH_KEEP_MEMBLOCK=y
commit: b9e028ca869de24df00206d7ec640380670fc38f
[8/9] memblock, treewide: make memblock_free() handle late freeing
commit: 64cb853c2ab4d8bd25b965f05e33ac0c6672bae7
[9/9] memblock: warn when freeing reserved memory before memory map is initialized
commit: c7fc9cde41be029cf6675befbafcbb2dab40b39b
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock
branch: for-next
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH] arm64: panic if IRQ shadow call stack allocation fails
From: Breno Leitao @ 2026-03-25 8:54 UTC (permalink / raw)
To: Osama Abdelkader
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
Ryo Takakura, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324161545.5441-1-osama.abdelkader@gmail.com>
On Tue, Mar 24, 2026 at 05:15:41PM +0100, Osama Abdelkader wrote:
> scs_alloc() can return NULL when vmalloc fails. init_irq_scs() previously
> stored that NULL in per-cpu irq_shadow_call_stack_ptr, which IRQ entry
> would then use under CONFIG_SHADOW_CALL_STACK. Match other SCS setup paths
> (e.g. SDEI) by failing explicitly instead of continuing with a NULL
> pointer.
Right, _init_sdei_scs() doesn't not assign the per cpu pointer with
NULL, but, at the same time it doesn't panic. SDEI propagates -ENOMEM
back up the call chain and even frees already allocated stacks via
free_sdei_scs(). Should it panic as well?
> Mark init_irq_scs() __init since it is only called from init_IRQ().
>
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> ---
> arch/arm64/kernel/irq.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
> index 15dedb385b9e..b32ed7ef8e00 100644
> --- a/arch/arm64/kernel/irq.c
> +++ b/arch/arm64/kernel/irq.c
> @@ -14,6 +14,7 @@
> #include <linux/init.h>
> #include <linux/irq.h>
> #include <linux/irqchip.h>
> +#include <linux/kernel.h>
Why do you need kernel.h in here? I initially thought it was
for panic(), but, later I found panic() is already in use in this file.
Isn't kernel.h being included transitively?
> #include <linux/kprobes.h>
> #include <linux/memory.h>
> #include <linux/scs.h>
> @@ -32,23 +33,26 @@ DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts);
>
> DEFINE_PER_CPU(unsigned long *, irq_stack_ptr);
>
> -
> DECLARE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr);
>
> #ifdef CONFIG_SHADOW_CALL_STACK
> DEFINE_PER_CPU(unsigned long *, irq_shadow_call_stack_ptr);
> #endif
>
> -static void init_irq_scs(void)
> +static void __init init_irq_scs(void)
> {
> int cpu;
> + void *s;
>
> if (!scs_is_enabled())
> return;
>
> - for_each_possible_cpu(cpu)
> - per_cpu(irq_shadow_call_stack_ptr, cpu) =
> - scs_alloc(early_cpu_to_node(cpu));
> + for_each_possible_cpu(cpu) {
> + s = scs_alloc(early_cpu_to_node(cpu));
> + if (!s)
> + panic("irq: Failed to allocate shadow call stack\n");
> + per_cpu(irq_shadow_call_stack_ptr, cpu) = s;
> + }
> }
Reading RISC-V code, it seems it has the same problem. Is it worth fixing also?
static void init_irq_scs(void)
{
int cpu;
if (!scs_is_enabled())
return;
for_each_possible_cpu(cpu)
per_cpu(irq_shadow_call_stack_ptr, cpu) =
scs_alloc(cpu_to_node(cpu));
}
Other than these nits, feel free to add:
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH RESEND 1/2] regulator: dt-bindings: mt6315: Add regulator supplies
From: Krzysztof Kozlowski @ 2026-03-25 8:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260324053030.4077453-2-wenst@chromium.org>
On Tue, Mar 24, 2026 at 01:30:28PM +0800, Chen-Yu Tsai wrote:
> diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
> index fa6743bb269d..ba99a0d02bc7 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
> @@ -29,6 +29,16 @@ properties:
> type: object
> description: List of regulators and its properties
>
> + properties:
> + pvdd1-supply:
> + description: Supply for vbuck1
> + pvdd2-supply:
> + description: Supply for vbuck2
> + pvdd3-supply:
> + description: Supply for vbuck3
> + pvdd4-supply:
> + description: Supply for vbuck4
These all look per-regulator supplies, so I think they should be in each
regulator node (see also regulator.yaml).
Or in top-level, but not in "regulators" node. The regulators is only
wrapping node for children.
I wonder what should be our preference - have supplies per regulator or
in top-level node. @Mark, any preference from your side?
> +
> patternProperties:
> "^vbuck[1-4]$":
> type: object
> @@ -51,6 +61,9 @@ examples:
> reg = <0x6 0>;
>
> regulators {
> + pvdd1-supply = <&pp4200_z2>;
> + pvdd3-supply = <&pp4200_z2>;
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/9] media: rockchip: rkcif: add support for rk3588 vicap mipi capture
From: Mehdi Djait @ 2026-03-25 9:00 UTC (permalink / raw)
To: Michael Riesch
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Sebastian Reichel, Nicolas Dufresne, Collabora Kernel Team,
Sakari Ailus, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <d97b05cb-396b-4189-8b96-88eab6f85f24@collabora.com>
Hi Michael,
On Wed, Mar 25, 2026 at 09:04:57AM +0100, Michael Riesch wrote:
> Hi Mehdi,
>
> On 3/17/26 14:28, Mehdi Djait wrote:
> > Hi Michael,
> >
> > On Tue, Mar 17, 2026 at 02:21:20PM +0100, Michael Riesch wrote:
> >> Hi Mehdi,
> >>
> >> On 3/17/26 14:08, Mehdi Djait wrote:
> >>> Hi Michael,
> >>>
> >>> Thank you for this nice patch!
> >>>
> >>> On Tue, Mar 17, 2026 at 10:32:21AM +0100, Michael Riesch via B4 Relay wrote:
> >>>> From: Michael Riesch <michael.riesch@collabora.com>
> >>>>
> >>>> The RK3588 Video Capture (VICAP) unit features a Digital Video Port
> >>>> (DVP) and six MIPI CSI-2 capture interfaces. Add initial support
> >>>> for this variant to the rkcif driver and enable the MIPI CSI-2
> >>>> capture interfaces.
> >>>>
> >>>> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
> >>>
> >>> [...]
> >>>
> >>>> static inline unsigned int rkcif_mipi_get_reg(struct rkcif_interface *interface,
> >>>> unsigned int index)
> >>>> {
> >>>> @@ -631,6 +765,8 @@ static int rkcif_mipi_start_streaming(struct rkcif_stream *stream)
> >>>> rkcif_mipi_stream_write(stream, RKCIF_MIPI_CTRL1, ctrl1);
> >>>> rkcif_mipi_stream_write(stream, RKCIF_MIPI_CTRL0, ctrl0);
> >>>>
> >>>> + rkcif_mipi_write(interface, RKCIF_MIPI_CTRL, RKCIF_MIPI_CTRL_CAP_EN);
> >>>> +
> >>>
> >>> while this is the correct solution for rk3588, for the rk3568 vicap this
> >>> will write 0x1 to the VICAP_MIPI_CTRL : 0x00A0 which will enable the water line.
> >>
> >> nice catch ;-) However, the TRM (at least my version) claims that this
> >> bit has a reset value of 0x1, so the bit in question should be already
> >> set in the first place. Thus I decided to *not* make variant specific
> >> code paths.
> >
> > Yes, the reset value is indeed 0x1
> >
> >>
> >> Do you see problems in your setup?
> >>
> >
> > No problems, it works as expected, I was just confused to see the
> > mipi capture enable added with this rk3588 patch and not before.
> >
> > I just find it a bit confusing but if a nicer solution is too much
> > hassle we can leave it like this.
>
> I agree that this is (while correct) not the nicest way. I am still
> bringing up the remaining features of the RK3588 VICAP (MUX + TOISP +
> SCALER) and it looks like I need to do some refactoring anyway to
> support them. When I do that, I shall rewrite this part. For the time
> being it would be great to have this merged in order to provide initial
> mainline support for this unit.
That sounds good.
How about adding a TODO comment ?
--
Kind Regards
Mehdi Djait
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: fsl: Add compatible for i.MX95 15x15 audio board (version 2)
From: Krzysztof Kozlowski @ 2026-03-25 9:01 UTC (permalink / raw)
To: Shengjiu Wang
Cc: robh, krzk+dt, conor+dt, shawnguo, Frank.Li, dario.binacchi,
alexander.stein, maudspierings, josua, Markus.Niebel,
matthias.schiffer, primoz.fiser, francesco.dolcini, devicetree,
linux-kernel, s.hauer, kernel, festevam, imx, linux-arm-kernel
In-Reply-To: <20260324061556.980621-2-shengjiu.wang@nxp.com>
On Tue, Mar 24, 2026 at 02:15:55PM +0800, Shengjiu Wang wrote:
> Introduce a new DT compatible string for the NXP i.MX95 15x15 audio board
> (version 2).
>
> i.MX Audio Board is a configurable and functional audio processing
> platform. Integrating a variety of audio input and output interfaces into
> the system, the i.MX Audio Board supports HDMI input, HDMI eARC,
> S/PDIF I/O, 2-ch ADC line-in, 24-ch DAC line-out and more. Based on these
> features, rich audio application cases can be realized.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] KVM: arm64: selftests: Add library functions for NV
From: Marc Zyngier @ 2026-03-25 9:03 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel,
Paolo Bonzini, Shuah Khan, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-2-weilin.chang@arm.com>
On Wed, 25 Mar 2026 00:36:18 +0000,
Wei-Lin Chang <weilin.chang@arm.com> wrote:
>
> The API is designed for userspace to first call prepare_{l2_stack,
> hyp_state, eret_destination, nested_sync_handler}, with a function
> supplied to prepare_eret_destination() to be run in L2. Then run_l2()
> can be called in L1 to run the given function in L2.
>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> tools/testing/selftests/kvm/Makefile.kvm | 2 +
> .../selftests/kvm/include/arm64/nested.h | 18 ++++++
> .../testing/selftests/kvm/lib/arm64/nested.c | 61 +++++++++++++++++++
> .../selftests/kvm/lib/arm64/nested_asm.S | 35 +++++++++++
> 4 files changed, 116 insertions(+)
> create mode 100644 tools/testing/selftests/kvm/include/arm64/nested.h
> create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested.c
> create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested_asm.S
>
> diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> index 98da9fa4b8b7..5e681e8e0cd7 100644
> --- a/tools/testing/selftests/kvm/Makefile.kvm
> +++ b/tools/testing/selftests/kvm/Makefile.kvm
> @@ -34,6 +34,8 @@ LIBKVM_arm64 += lib/arm64/gic.c
> LIBKVM_arm64 += lib/arm64/gic_v3.c
> LIBKVM_arm64 += lib/arm64/gic_v3_its.c
> LIBKVM_arm64 += lib/arm64/handlers.S
> +LIBKVM_arm64 += lib/arm64/nested.c
> +LIBKVM_arm64 += lib/arm64/nested_asm.S
> LIBKVM_arm64 += lib/arm64/processor.c
> LIBKVM_arm64 += lib/arm64/spinlock.c
> LIBKVM_arm64 += lib/arm64/ucall.c
> diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> new file mode 100644
> index 000000000000..739ff2ee0161
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * ARM64 Nested virtualization defines
> + */
> +
> +#ifndef SELFTEST_KVM_NESTED_H
> +#define SELFTEST_KVM_NESTED_H
> +
> +void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> +void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> +void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
> +void prepare_nested_sync_handler(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> +
> +void run_l2(void);
> +void after_hvc(void);
> +void do_hvc(void);
> +
> +#endif /* SELFTEST_KVM_NESTED_H */
> diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> new file mode 100644
> index 000000000000..111d02f44cfe
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> @@ -0,0 +1,61 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ARM64 Nested virtualization helpers
> + */
> +
> +#include "kvm_util.h"
> +#include "nested.h"
> +#include "processor.h"
> +#include "test_util.h"
> +
> +#include <asm/sysreg.h>
> +
> +static void hvc_handler(struct ex_regs *regs)
> +{
> + GUEST_ASSERT_EQ(get_current_el(), 2);
> + GUEST_PRINTF("hvc handler\n");
> + regs->pstate = PSR_MODE_EL2h | PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT;
> + regs->pc = (u64)after_hvc;
> +}
> +
> +void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> +{
> + size_t l2_stack_size;
> + uint64_t l2_stack_paddr;
> +
> + l2_stack_size = vm->page_size == 4096 ? DEFAULT_STACK_PGS * vm->page_size :
> + vm->page_size;
Please use symbolic constants. Also, this looks wrong if the default
stack size is 32k and the page size is 16k. You probably want to
express a stack size directly, rather than a number of pages.
> + l2_stack_paddr = __vm_phy_pages_alloc(vm, l2_stack_size / vm->page_size,
> + 0, 0, false);
> + vcpu_set_reg(vcpu, ARM64_CORE_REG(sp_el1), l2_stack_paddr + l2_stack_size);
> +}
> +
> +void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> +{
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW);
Surely the E2H value matters. Or are you planning to only run this on
configuration that hardcode E2H==0? That'd be pretty limiting.
> +}
> +
> +void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc)
> +{
> + vm_paddr_t do_hvc_paddr = addr_gva2gpa(vm, (vm_vaddr_t)do_hvc);
> + vm_paddr_t l2_pc_paddr = addr_gva2gpa(vm, (vm_vaddr_t)l2_pc);
> +
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_SPSR_EL2), PSR_MODE_EL1h |
> + PSR_D_BIT |
> + PSR_A_BIT |
> + PSR_I_BIT |
> + PSR_F_BIT);
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_ELR_EL2), l2_pc_paddr);
> + /* HACK: use TPIDR_EL2 to pass address, see run_l2() in nested_asm.S */
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_TPIDR_EL2), do_hvc_paddr);
> +}
> +
> +void prepare_nested_sync_handler(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
> +{
> + if (!vm->handlers) {
> + vm_init_descriptor_tables(vm);
> + vcpu_init_descriptor_tables(vcpu);
> + }
> + vm_install_sync_handler(vm, VECTOR_SYNC_LOWER_64,
> + ESR_ELx_EC_HVC64, hvc_handler);
> +}
> diff --git a/tools/testing/selftests/kvm/lib/arm64/nested_asm.S b/tools/testing/selftests/kvm/lib/arm64/nested_asm.S
> new file mode 100644
> index 000000000000..4ecf2d510a6f
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/lib/arm64/nested_asm.S
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * ARM64 Nested virtualization assembly helpers
> + */
> +
> +.globl run_l2
> +.globl after_hvc
> +.globl do_hvc
> +run_l2:
> + /*
> + * At this point TPIDR_EL2 will contain the gpa of do_hvc from
> + * prepare_eret_destination(). gpa of do_hvc have to be passed in
> + * because we want L2 to issue an hvc after it returns from the user
> + * passed function. In order for that to happen the lr must be
> + * controlled, which at this point holds the value of the address of
> + * the next instruction after this run_l2() call, which is not useful
> + * for L2. Additionally, L1 can't translate gva into gpa, so we can't
> + * calculate it here.
> + *
> + * So first save lr, then move TPIDR_EL2 to lr so when the user supplied
> + * L2 function returns, L2 jumps to do_hvc and let the L1 hvc handler
> + * take control. This implies we expect the L2 code to preserve lr and
> + * calls a regular ret in the end, which is true for normal C functions.
> + * The hvc handler will jump back to after_hvc when finished, and lr
> + * will be restored and we can return run_l2().
> + */
> + stp x29, lr, [sp, #-16]!
> + mrs x0, tpidr_el2
> + mov lr, x0
> + eret
> +after_hvc:
> + ldp x29, lr, [sp], #16
> + ret
> +do_hvc:
> + hvc #0
This probably works for a single instruction L2 guest, but not having
any save/restore of the L2 context makes it hard to build anything on
top of this.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 09/21] fs: afs: revert mmap_prepare() change
From: Vlastimil Babka (SUSE) @ 2026-03-25 9:06 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <08804c94e39d9102a3a8fbd12385e8aa079ba1d3.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Partially reverts commit 9d5403b1036c ("fs: convert most other
> generic_file_*mmap() users to .mmap_prepare()").
>
> This is because the .mmap invocation establishes a refcount, but
> .mmap_prepare is called at a point where a merge or an allocation failure
> might happen after the call, which would leak the refcount increment.
>
> Functionality is being added to permit the use of .mmap_prepare in this
> case, but in the interim, we need to fix this.
>
> Fixes: 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> fs/afs/file.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/afs/file.c b/fs/afs/file.c
> index f609366fd2ac..74d04af51ff4 100644
> --- a/fs/afs/file.c
> +++ b/fs/afs/file.c
> @@ -19,7 +19,7 @@
> #include <trace/events/netfs.h>
> #include "internal.h"
>
> -static int afs_file_mmap_prepare(struct vm_area_desc *desc);
> +static int afs_file_mmap(struct file *file, struct vm_area_struct *vma);
>
> static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter);
> static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
> @@ -35,7 +35,7 @@ const struct file_operations afs_file_operations = {
> .llseek = generic_file_llseek,
> .read_iter = afs_file_read_iter,
> .write_iter = netfs_file_write_iter,
> - .mmap_prepare = afs_file_mmap_prepare,
> + .mmap = afs_file_mmap,
> .splice_read = afs_file_splice_read,
> .splice_write = iter_file_splice_write,
> .fsync = afs_fsync,
> @@ -492,16 +492,16 @@ static void afs_drop_open_mmap(struct afs_vnode *vnode)
> /*
> * Handle setting up a memory mapping on an AFS file.
> */
> -static int afs_file_mmap_prepare(struct vm_area_desc *desc)
> +static int afs_file_mmap(struct file *file, struct vm_area_struct *vma)
> {
> - struct afs_vnode *vnode = AFS_FS_I(file_inode(desc->file));
> + struct afs_vnode *vnode = AFS_FS_I(file_inode(file));
> int ret;
>
> afs_add_open_mmap(vnode);
>
> - ret = generic_file_mmap_prepare(desc);
> + ret = generic_file_mmap(file, vma);
> if (ret == 0)
> - desc->vm_ops = &afs_vm_ops;
> + vma->vm_ops = &afs_vm_ops;
> else
> afs_drop_open_mmap(vnode);
> return ret;
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: mediatek,mt8173-rt5650-rt5514: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-25 9:07 UTC (permalink / raw)
To: Khushal Chitturi
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, koro.chen, linux-sound, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260324074618.145567-1-khushalchitturi@gmail.com>
On Tue, Mar 24, 2026 at 01:16:18PM +0530, Khushal Chitturi wrote:
> Convert the Mediatek MT8173 with RT5650 and RT5514 sound card
> bindings to YAML schema.
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
> ---
> .../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..05bb18006e08
> --- /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.
> +
> +additionalProperties: false
This goes after "required:" block.
> +
> +required:
> + - compatible
> + - mediatek,audio-codec
> + - mediatek,platform
> +
> +examples:
> + - |
> + sound {
> + compatible = "mediatek,mt8173-rt5650-rt5514";
> + mediatek,audio-codec = <&rt5650 &rt5514>;
Two phandles, so two <> (<>, <>).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/5] powervr: MT8173 GPU support
From: Icenowy Zheng @ 2026-03-25 9:11 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, linux-clk,
devicetree, linux-mediatek, dri-devel, linux-arm-kernel,
linux-kernel
In-Reply-To: <0739597b7a9c162525c10d82c3993e37af1c8a75.camel@icenowy.me>
在 2026-03-25三的 16:30 +0800，Icenowy Zheng写道：
> 在 2026-03-25三的 16:08 +0800，Chen-Yu Tsai写道：
> > On Wed, Mar 25, 2026 at 4:04 PM Icenowy Zheng <uwu@icenowy.me>
> > wrote:
> > >
> > > 在 2026-03-25三的 15:19 +0800，Chen-Yu Tsai写道：
> > > > Hi everyone,
> > > >
> > > > This is v2 of my MT8173 PowerVR GPU support series.
> > > >
> > > > Changes since v1:
> > > > - Adapted to changed DT bindings
> > > > - Dropped driver change
> > > > - Use same power domain for "a" and "b" GPU power domains
> > > >
> > > > This update was requested by Icenowy.
> > > >
> > > >
> > > > This series enables the PowerVR GPU found in the MT8173 SoC,
> > > > found in
> > > > some Chromebooks.
> > > >
> > > > This version is different from the initial powervr driver
> > > > submission
> > > > [1]
> > > > in that it splits out the GPU glue layer support out of the
> > > > powervr
> > > > driver and into a separate clock and power domain driver. The
> > > > glue
> > > > code
> > > > is otherwise the same, and also the same as found in the
> > > > ChromeOS
> > > > kernels, with some extra comments and macro names added where
> > > > possible.
> > > >
> > > > Patch 1 adds a binding for the glue layer, called mfgtop. The
> > > > glue
> > > > layer
> > > > contains clock and power controls for the GPU.
> > > >
> > > > Patch 2 adds a driver for the glue layer.
> > > >
> > > > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the
> > > > PowerVR
> > > > binding.
> > > >
> > > > Patch 4 adds an entry for the PowerVR 6XT series GPU to the
> > > > driver.
> > > >
> > > > Patch 5 corrects the clock for the GPU (called MFG) power
> > > > domain.
> > > >
> > > > Patch 6 adds device nodes for the GPU and glue layer to the
> > > > MT8173
> > > > dtsi
> > > > file.
> > > >
> > > > Patch 2 and 6 depend on patch 1 to build. I suppose some common
> > > > immutable tree would be needed from the MediaTek maintainers.
> > > >
> > > > The kernel driver successfully probes the hardware and loads
> > > > the
> > > > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination
> > > > Technologies
> > > > [2].
> > > > Userspace was tested with Mesa 24.0.8 from Debian Trixie
> > > > rebuilt
> > > > with
> > > > the powervr vulkan driver enabled. `vulkaninfo` gives some
> > > > information
> > > > about the GPU (attached at the end), but running the `triangle`
> > > > example
> > > > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as
> > > > recommended [4]
> > > > failed with:
> > > >
> > > > Can't find a display and a display mode!
> > >
> > > I think when using D2D the demos want width and height to be
> > > explicitly
> > > specified, otherwise it seems to hardcode 1280x720.
> > >
> > > If you're using an elm, could you try to add `-w 1920 -h 1080` or
> > > for
> > > hana `-w 1366 -h 768` ?
> >
> > I only did the basic `vulkaninfo` test this time around. To do
> > anything
> > interesting probably requires the Mesa 26.1 release.
> >
> > PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 \
> > vkmark --winsys kms -D b81f54f8568deb0fb70a6a1ed845b65d
> >
> > just reports "Error: Device specified by uuid is not available"
>
> I am very sorry to tell you that, when I run Sascha's demo with Mesa
> main, I got GPU lost immediately...
>
> ```
> [ 441.509433] powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> ```
However, Zink on PowerVR works, and on Lichee Pi 4A I also got
`VK_ERROR_DEVICE_LOST` when running Sascha's demos (although the kernel
does not report device lost).
I bet it's a regression on the VK_KHR_display code.
Thanks,
Icenowy
>
> Icenowy
>
> >
> > This is with Mesa 26.0.2 packages from Debian testing. At least now
> > have the powervr vulkan driver enabled by default, so I don't have
> > to rebuild the packages again.
> >
> >
> > ChenYu
> >
> > > Thanks
> > > Icenowy
> > >
> > > >
> > > > Same program worked correctly on a BeaglePlay and displayed a
> > > > color
> > > > gradient triangle. Not sure what went wrong here.
> > > >
> > > > Anyway, please have a look and test.
> > > >
> > > >
> > > > Thanks
> > > > ChenYu
> > > >
> > > > [1]
> > > > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
> > > > [2]
> > > > https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> > > > [3] https://github.com/SaschaWillems/Vulkan
> > > > [4]
> > > > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
> > > >
> > > > Chen-Yu Tsai (5):
> > > > dt-bindings: clock: mediatek: Add mt8173 mfgtop
> > > > clk: mediatek: Add mt8173-mfgtop driver
> > > > dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> > > > arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain
> > > > clock
> > > > arm64: dts: mediatek: mt8173: Add GPU device nodes
> > > >
> > > > .../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
> > > > .../bindings/gpu/img,powervr-rogue.yaml | 1 +
> > > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
> > > > drivers/clk/mediatek/Kconfig | 9 +
> > > > drivers/clk/mediatek/Makefile | 1 +
> > > > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243
> > > > ++++++++++++++++++
> > > > include/dt-bindings/clock/mt8173-clk.h | 7 +
> > > > 7 files changed, 363 insertions(+), 1 deletion(-)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/clock/mediatek,mt8173-
> > > > mfgtop.yaml
> > > > create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
^ permalink raw reply
* Re: [PATCH v27 3/4] i2c: ast2600: Add controller driver for AST2600 new register set
From: Jeremy Kerr @ 2026-03-25 9:15 UTC (permalink / raw)
To: Ryan Chen, andriy.shevchenko@linux.intel.com, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Benjamin Herrenschmidt, Philipp Zabel
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE6D451E8AFDBA03B81AFB4F249A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Hi Ryan,
> > I would suggest separating the string parsing from the "is the mode available"
> > logic, more on that below.
> >
> I will separate with following.
>
> static int ast2600_i2c_xfer_mode_parse(const char *buf, enum xfer_mode *mode)
> {
> if (sysfs_streq(buf, "byte")) { *mode = BYTE_MODE; return 0; }
> if (sysfs_streq(buf, "buffer")) { *mode = BUFF_MODE; return 0; }
> if (sysfs_streq(buf, "dma")) { *mode = DMA_MODE; return 0; }
> return -EINVAL;
> }
OK, but with kernel-style formatting.
>
> static int ast2600_i2c_xfer_mode_check(struct ast2600_i2c_bus *i2c_bus,
> enum xfer_mode mode)
> {
> if (mode == BUFF_MODE && !i2c_bus->buf_base)
> return -EINVAL;
> if (mode == DMA_MODE && !i2c_bus->dma_available)
> return -EINVAL;
> return 0;
> }
>
> > > +
> > > +static const char *ast2600_i2c_xfer_mode_name(enum xfer_mode mode) {
> > > + switch (mode) {
> > > + case BYTE_MODE:
> > > + return "byte";
> > > + case DMA_MODE:
> > > + return "dma";
> > > + case BUFF_MODE:
> > > + default:
> > > + return "buffer";
> > > + }
> > > +}
> > > +
> > > +static ssize_t xfer_mode_show(struct device *dev, struct
> > > +device_attribute *attr, char *buf) {
> > > + struct ast2600_i2c_bus *i2c_bus = dev_get_drvdata(dev);
> > > +
> > > + return sysfs_emit(buf, "%s\n",
> > > +ast2600_i2c_xfer_mode_name(i2c_bus->mode));
> > > +}
> > > +
> > > +static ssize_t xfer_mode_store(struct device *dev,
> > > + struct device_attribute *attr,
> > > + const char *buf, size_t count)
> > {
> > > + struct ast2600_i2c_bus *i2c_bus = dev_get_drvdata(dev);
> > > + enum xfer_mode mode;
> > > + int ret;
> > > +
> > > + ret = ast2600_i2c_xfer_mode_parse(i2c_bus, buf, &mode);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + i2c_lock_bus(&i2c_bus->adap, I2C_LOCK_ROOT_ADAPTER);
> > > + ast2600_i2c_set_xfer_mode(i2c_bus, mode);
> > > + i2c_unlock_bus(&i2c_bus->adap, I2C_LOCK_ROOT_ADAPTER);
> > > +
> > > + return count;
> > > +}
> > > +
> > > +static DEVICE_ATTR_RW(xfer_mode);
> >
> > This will need sysfs ABI documentation.
>
> Since it is in sysfs /sys/bus/platform/drivers/i2c_ast2600
> So I add Documentation/ABI/testing/sysfs-bus-platform-drivers-i2c-ast2600
> am I right?
I would suggest Documentation/ABI/testing/sysfs-driver-ast2600-i2c
>
> What: /sys/bus/platform/drivers/i2c-ast2600/.../xfer_mode
> Date: March 2026
> KernelVersion: 6.x
KernelVersion is optional, but if you include it, it would be 7.x.
> Contact: Ryan Chen <ryan_chen@aspeedtech.com>
> Description:
Keep the first line of the description on the same line.
> Shows or sets the transfer mode for the ASPEED AST2600 I2C
> controller. Valid values are:
>
> - "byte": Programmed I/O, one byte at a time.
> - "buffer": Programmed I/O using the hardware FIFO buffer.
> - "dma": DMA transfer (only available if aspeed,enable-dma
> is set in the device tree).
Decouple this from the device tree configuration mechanism:
- "dma": DMA transfer (if DMA is available for this
controller)
> i2c_bus->buf_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
> if (!IS_ERR(i2c_bus->buf_base))
> i2c_bus->buf_size = resource_size(res) / 2;
> else
> i2c_bus->buf_base = NULL;
I would suggest a temporary, so there's no chance that future changes
could see an ERR_PTR value in i2c_bus->buf_base:
buf_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
if (!IS_ERR(buf_base)) {
i2c_bus->buf_base = buf_base
i2c_bus->buf_size = resource_size(res) / 2;
}
and you have kzalloc()ed, so no need for the NULL init in the error path.
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH v2 0/5] powervr: MT8173 GPU support
From: Chen-Yu Tsai @ 2026-03-25 9:17 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, linux-clk,
devicetree, linux-mediatek, dri-devel, linux-arm-kernel,
linux-kernel
In-Reply-To: <cb75a09ecc88972503f5ade8e1807122c48d8ac8.camel@icenowy.me>
On Wed, Mar 25, 2026 at 4:42 PM Icenowy Zheng <uwu@icenowy.me> wrote:
>
> 在 2026-03-25三的 16:30 +0800，Icenowy Zheng写道：
> > 在 2026-03-25三的 16:08 +0800，Chen-Yu Tsai写道：
> > > On Wed, Mar 25, 2026 at 4:04 PM Icenowy Zheng <uwu@icenowy.me>
> > > wrote:
> > > >
> > > > 在 2026-03-25三的 15:19 +0800，Chen-Yu Tsai写道：
> > > > > Hi everyone,
> > > > >
> > > > > This is v2 of my MT8173 PowerVR GPU support series.
> > > > >
> > > > > Changes since v1:
> > > > > - Adapted to changed DT bindings
> > > > > - Dropped driver change
> > > > > - Use same power domain for "a" and "b" GPU power domains
> > > > >
> > > > > This update was requested by Icenowy.
> > > > >
> > > > >
> > > > > This series enables the PowerVR GPU found in the MT8173 SoC,
> > > > > found in
> > > > > some Chromebooks.
> > > > >
> > > > > This version is different from the initial powervr driver
> > > > > submission
> > > > > [1]
> > > > > in that it splits out the GPU glue layer support out of the
> > > > > powervr
> > > > > driver and into a separate clock and power domain driver. The
> > > > > glue
> > > > > code
> > > > > is otherwise the same, and also the same as found in the
> > > > > ChromeOS
> > > > > kernels, with some extra comments and macro names added where
> > > > > possible.
> > > > >
> > > > > Patch 1 adds a binding for the glue layer, called mfgtop. The
> > > > > glue
> > > > > layer
> > > > > contains clock and power controls for the GPU.
> > > > >
> > > > > Patch 2 adds a driver for the glue layer.
> > > > >
> > > > > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the
> > > > > PowerVR
> > > > > binding.
> > > > >
> > > > > Patch 4 adds an entry for the PowerVR 6XT series GPU to the
> > > > > driver.
> > > > >
> > > > > Patch 5 corrects the clock for the GPU (called MFG) power
> > > > > domain.
> > > > >
> > > > > Patch 6 adds device nodes for the GPU and glue layer to the
> > > > > MT8173
> > > > > dtsi
> > > > > file.
> > > > >
> > > > > Patch 2 and 6 depend on patch 1 to build. I suppose some common
> > > > > immutable tree would be needed from the MediaTek maintainers.
> > > > >
> > > > > The kernel driver successfully probes the hardware and loads
> > > > > the
> > > > > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination
> > > > > Technologies
> > > > > [2].
> > > > > Userspace was tested with Mesa 24.0.8 from Debian Trixie
> > > > > rebuilt
> > > > > with
> > > > > the powervr vulkan driver enabled. `vulkaninfo` gives some
> > > > > information
> > > > > about the GPU (attached at the end), but running the `triangle`
> > > > > example
> > > > > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as
> > > > > recommended [4]
> > > > > failed with:
> > > > >
> > > > > Can't find a display and a display mode!
> > > >
> > > > I think when using D2D the demos want width and height to be
> > > > explicitly
> > > > specified, otherwise it seems to hardcode 1280x720.
> > > >
> > > > If you're using an elm, could you try to add `-w 1920 -h 1080` or
> > > > for
> > > > hana `-w 1366 -h 768` ?
> > >
> > > I only did the basic `vulkaninfo` test this time around. To do
> > > anything
> > > interesting probably requires the Mesa 26.1 release.
> > >
> > > PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 \
> > > vkmark --winsys kms -D b81f54f8568deb0fb70a6a1ed845b65d
> > >
> > > just reports "Error: Device specified by uuid is not available"
> >
> > I am very sorry to tell you that, when I run Sascha's demo with Mesa
> > main, I got GPU lost immediately...
> >
> > ```
> > [ 441.509433] powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> > ```
>
> Sidenote: I think this is some power domain management issue, because I
> saw the kernel saying `vgpu: disabling` , which shouldn't happen if the
> GPU is active?
AFAICT "vgpu" is the vgpu output from the primary PMIC. This one is unused.
The actual regulator supplying the GPU is from the secondary PMIC. The
rail is called VBUCKB...
ChenYu
> >
> > Icenowy
> >
> > >
> > > This is with Mesa 26.0.2 packages from Debian testing. At least now
> > > have the powervr vulkan driver enabled by default, so I don't have
> > > to rebuild the packages again.
> > >
> > >
> > > ChenYu
> > >
> > > > Thanks
> > > > Icenowy
> > > >
> > > > >
> > > > > Same program worked correctly on a BeaglePlay and displayed a
> > > > > color
> > > > > gradient triangle. Not sure what went wrong here.
> > > > >
> > > > > Anyway, please have a look and test.
> > > > >
> > > > >
> > > > > Thanks
> > > > > ChenYu
> > > > >
> > > > > [1]
> > > > > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
> > > > > [2]
> > > > > https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> > > > > [3] https://github.com/SaschaWillems/Vulkan
> > > > > [4]
> > > > > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
> > > > >
> > > > > Chen-Yu Tsai (5):
> > > > > dt-bindings: clock: mediatek: Add mt8173 mfgtop
> > > > > clk: mediatek: Add mt8173-mfgtop driver
> > > > > dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> > > > > arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain
> > > > > clock
> > > > > arm64: dts: mediatek: mt8173: Add GPU device nodes
> > > > >
> > > > > .../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
> > > > > .../bindings/gpu/img,powervr-rogue.yaml | 1 +
> > > > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
> > > > > drivers/clk/mediatek/Kconfig | 9 +
> > > > > drivers/clk/mediatek/Makefile | 1 +
> > > > > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243
> > > > > ++++++++++++++++++
> > > > > include/dt-bindings/clock/mt8173-clk.h | 7 +
> > > > > 7 files changed, 363 insertions(+), 1 deletion(-)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/clock/mediatek,mt8173-
> > > > > mfgtop.yaml
> > > > > create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
^ permalink raw reply
* Re: [PATCH 3/3] KVM: arm64: selftests: Enable stage-2 in NV preparation functions
From: Marc Zyngier @ 2026-03-25 9:18 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel,
Paolo Bonzini, Shuah Khan, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-4-weilin.chang@arm.com>
On Wed, 25 Mar 2026 00:36:20 +0000,
Wei-Lin Chang <weilin.chang@arm.com> wrote:
>
> Introduce library functions for setting up guest stage-2 page tables,
> then use that to give L2 an identity mapped stage-2 and enable it.
>
> The translation and stage-2 page table built is simple, start level 0,
> 4 levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
That's a no go. The most common NV-capable out there can realistically
only do 16kB at S2, and is limited to 36bit IPA. We can't really
afford to say "too bad" and leave the main development platform behind.
>
> The nested page table code is adapted from lib/x86/vmx.c.
I guess this starting point is the main issue.
>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> .../selftests/kvm/include/arm64/nested.h | 7 ++
> .../selftests/kvm/include/arm64/processor.h | 9 ++
> .../testing/selftests/kvm/lib/arm64/nested.c | 97 ++++++++++++++++++-
> 3 files changed, 111 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
> index 739ff2ee0161..0be10a775e48 100644
> --- a/tools/testing/selftests/kvm/include/arm64/nested.h
> +++ b/tools/testing/selftests/kvm/include/arm64/nested.h
> @@ -6,6 +6,13 @@
> #ifndef SELFTEST_KVM_NESTED_H
> #define SELFTEST_KVM_NESTED_H
>
> +uint64_t get_l1_vtcr(void);
> +
> +void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> + uint64_t nested_paddr, uint64_t paddr, uint64_t size);
> +void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
> + uint32_t memslot);
> +
> void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
> void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
> diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
> index ac97a1c436fc..5de2e932d95a 100644
> --- a/tools/testing/selftests/kvm/include/arm64/processor.h
> +++ b/tools/testing/selftests/kvm/include/arm64/processor.h
> @@ -104,6 +104,15 @@
> #define TCR_HA (UL(1) << 39)
> #define TCR_DS (UL(1) << 59)
>
> +/* VTCR_EL2 specific flags */
> +#define VTCR_EL2_T0SZ_BITS(x) ((UL(64) - (x)) << VTCR_EL2_T0SZ_SHIFT)
> +
> +#define VTCR_EL2_SL0_LV0_4K (UL(2) << VTCR_EL2_SL0_SHIFT)
> +#define VTCR_EL2_SL0_LV1_4K (UL(1) << VTCR_EL2_SL0_SHIFT)
> +#define VTCR_EL2_SL0_LV2_4K (UL(0) << VTCR_EL2_SL0_SHIFT)
> +
> +#define VTCR_EL2_PS_40_BITS (UL(2) << VTCR_EL2_PS_SHIFT)
> +
> /*
> * AttrIndx[2:0] encoding (mapping attributes defined in the MAIR* registers).
> */
> diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
> index 111d02f44cfe..910f8cd30f96 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/nested.c
> +++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
> @@ -1,8 +1,11 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * ARM64 Nested virtualization helpers
> + * ARM64 Nested virtualization helpers, nested page table code adapted from
> + * ../x86/vmx.c.
> */
>
> +#include <linux/sizes.h>
> +
> #include "kvm_util.h"
> #include "nested.h"
> #include "processor.h"
> @@ -18,6 +21,87 @@ static void hvc_handler(struct ex_regs *regs)
> regs->pc = (u64)after_hvc;
> }
>
> +uint64_t get_l1_vtcr(void)
> +{
> + return VTCR_EL2_PS_40_BITS | VTCR_EL2_TG0_4K | VTCR_EL2_ORGN0_WBWA |
> + VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LV0_4K | VTCR_EL2_T0SZ_BITS(48);
Irk. See above.
> +}
> +
> +static void __nested_pg_map(struct kvm_vm *vm, uint64_t guest_pgd,
> + uint64_t nested_paddr, uint64_t paddr, uint64_t flags)
> +{
> + uint8_t attr_idx = flags & (PTE_ATTRINDX_MASK >> PTE_ATTRINDX_SHIFT);
> + uint64_t pg_attr;
> + uint64_t *ptep;
> +
> + TEST_ASSERT((nested_paddr % vm->page_size) == 0,
> + "L2 IPA not on page boundary,\n"
> + " nested_paddr: 0x%lx vm->page_size: 0x%x", nested_paddr, vm->page_size);
> + TEST_ASSERT((paddr % vm->page_size) == 0,
> + "Guest physical address not on page boundary,\n"
> + " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
> + TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
> + "Physical address beyond maximum supported,\n"
> + " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
> + paddr, vm->max_gfn, vm->page_size);
> +
> + ptep = addr_gpa2hva(vm, guest_pgd) + ((nested_paddr >> 39) & 0x1ffu) * 8;
> + if (!*ptep)
> + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PGD_TYPE_TABLE | PTE_VALID;
> + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 30) & 0x1ffu) * 8;
> + if (!*ptep)
> + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PUD_TYPE_TABLE | PTE_VALID;
> + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 21) & 0x1ffu) * 8;
> + if (!*ptep)
> + *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PMD_TYPE_TABLE | PTE_VALID;
> + ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 12) & 0x1ffu) * 8;
> +
> + pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
> + pg_attr |= PTE_SHARED;
> +
> + *ptep = (paddr & GENMASK(47, 12)) | pg_attr;
Please use named constants, and write a page table generator that is
independent of page, IA and OA sizes, as advertised to the guest.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v4 2/9] dt-bindings: mmc: amlogic: Add compatible for T7 mmc
From: Ronald Claveau @ 2026-03-25 9:15 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Ronald Claveau
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-0-44c7b4a5e459@aliel.fr>
Add amlogic,t7-mmc compatible string, falling back to amlogic,meson-axg-mmc
as the T7 MMC controller is compatible with the AXG implementation.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
index 57646575a13f8..976f36de2091c 100644
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
@@ -19,6 +19,10 @@ allOf:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-mmc
+ - const: amlogic,meson-axg-mmc
- const: amlogic,meson-axg-mmc
- items:
- const: amlogic,meson-gx-mmc
--
2.49.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