* [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-07 9:15 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, Liu Ying
Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
The panel connects with the QSB board through an adapter board[1]
designed by NXP.
Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi | 110 +++++++++++++++++++++
.../imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso | 106 +-------------------
.../freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso | 14 +++
4 files changed, 127 insertions(+), 105 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c99..6315fb8390ff 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -455,9 +455,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb.dtb
imx93-9x9-qsb-can1-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-can1.dtbo
imx93-9x9-qsb-i3c-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-i3c.dtbo
imx93-9x9-qsb-ontat-kd50g21-40nt-a1-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo
+imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-tianma-tm050rdh03.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-can1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-i3c.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
new file mode 100644
index 000000000000..d167c9fc3b8f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx93-pinfunc.h"
+
+&{/} {
+ backlight: backlight {
+ compatible = "gpio-backlight";
+ gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel {
+ compatible = "ontat,kd50g21-40nt-a1";
+ backlight = <&backlight>;
+ power-supply = <®_rpi_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+};
+
+&dpi_bridge {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dpi_to_panel: endpoint {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x31e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x31e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x31e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x31e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x31e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x31e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x31e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x31e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x31e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x31e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x31e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x31e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x31e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x31e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x31e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x31e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x31e
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x31e
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x31e
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x31e
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x31e
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x31e
+ >;
+ };
+};
+
+&lcdif {
+ status = "okay";
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&pcal6524 {
+ /*
+ * exp-sel-hog has property 'output-low' while DT overlay doesn't
+ * support /delete-property/. Both 'output-low' and 'output-high'
+ * will exist under hog nodes if DT overlay file sets 'output-high'.
+ * Workaround is to disable this hog and create new hog with
+ * 'output-high'.
+ */
+ exp-sel-hog {
+ status = "disabled";
+ };
+
+ exp-high-sel-hog {
+ gpio-hog;
+ gpios = <22 GPIO_ACTIVE_HIGH>;
+ output-high;
+ };
+};
+
+&sai3 {
+ /* disable due to GPIO12 and GPIO17~20 pin conflicts with LCDIF */
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
index d167c9fc3b8f..356533a7b513 100644
--- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso
@@ -3,108 +3,4 @@
* Copyright 2026 NXP
*/
-/dts-v1/;
-/plugin/;
-
-#include <dt-bindings/gpio/gpio.h>
-#include "imx93-pinfunc.h"
-
-&{/} {
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>;
- };
-
- panel {
- compatible = "ontat,kd50g21-40nt-a1";
- backlight = <&backlight>;
- power-supply = <®_rpi_3v3>;
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&dpi_to_panel>;
- };
- };
- };
-};
-
-&dpi_bridge {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcdif>;
- status = "okay";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dpi_to_panel: endpoint {
- remote-endpoint = <&panel_in>;
- bus-width = <18>;
- };
- };
- };
-};
-
-&iomuxc {
- pinctrl_lcdif: lcdifgrp {
- fsl,pins = <
- MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x31e
- MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x31e
- MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x31e
- MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x31e
- MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x31e
- MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x31e
- MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x31e
- MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x31e
- MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x31e
- MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x31e
- MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x31e
- MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x31e
- MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x31e
- MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x31e
- MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x31e
- MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x31e
- MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x31e
- MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x31e
- MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x31e
- MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x31e
- MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x31e
- MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x31e
- >;
- };
-};
-
-&lcdif {
- status = "okay";
-};
-
-&media_blk_ctrl {
- status = "okay";
-};
-
-&pcal6524 {
- /*
- * exp-sel-hog has property 'output-low' while DT overlay doesn't
- * support /delete-property/. Both 'output-low' and 'output-high'
- * will exist under hog nodes if DT overlay file sets 'output-high'.
- * Workaround is to disable this hog and create new hog with
- * 'output-high'.
- */
- exp-sel-hog {
- status = "disabled";
- };
-
- exp-high-sel-hog {
- gpio-hog;
- gpios = <22 GPIO_ACTIVE_HIGH>;
- output-high;
- };
-};
-
-&sai3 {
- /* disable due to GPIO12 and GPIO17~20 pin conflicts with LCDIF */
- status = "disabled";
-};
+#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
new file mode 100644
index 000000000000..c233797ec28c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb-tianma-tm050rdh03.dtso
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi"
+
+&{/} {
+ panel {
+ compatible = "tianma,tm050rdh03";
+ enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
+ };
+};
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
Best regards,
--
Liu Ying <victor.liu@nxp.com>
^ permalink raw reply related
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Johan Hovold @ 2026-04-07 9:07 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Mark Brown, alexander.stein, andrew, andrew,
andriy.shevchenko, astewart, bhelgaas, brgl, davem, devicetree,
driver-core, hkallweit1, jirislaby, joel, kees, kuba, lgirdwood,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pci,
linux-serial, linux-usb, linux, mani, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Doug Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
This flag is only set before registering a device with driver core so
there is no issue using the existing bitfield here (with the caveat that
PCI pwrctrl may have gotten that wrong). I haven't checked the other
flags, but I assume most of them work the same way.
But apart from the commit message being misleading, switching to using
atomic ops and accessors for consistency is fine.
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
These two uses are broken currently though and should be using
device_set_of_node_from_dev() so that an extra reference is taken to
balance the one dropped by the platform bus code.
I'll send two fixes to Mark, any merge conflict should be trivial to
fixup.
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: PK Lee @ 2026-04-07 9:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <258747f4-9da5-44da-8eb9-24f8a8cbff3a@lunn.ch>
> > +&mac3 {
> > + status = "okay";
> > + phy-mode = "rmii";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_rmii4_default>;
> > + fixed-link {
> > + speed = <100>;
> > + full-duplex;
> > + };
>
> What is on the other end of this fixed link?
The other end of this fixed link is the CPU port of a Marvell 88E6393X
switch. We are using this switch in unmanaged mode rather than using
the DSA subsystem. Therefore, we use a fixed-link to force the mac3 to
100Mbps full-duplex RMII to match the CPU port configuration.
>
> > +};
> > +
> > +&mdio0 {
> > + status = "okay";
> > +};
>
> If there are no devices on the bus, why enable it?
We intentionally enable it so user-space tools can access the switch
registers. I have added a comment in v13 to clarify this.
>
> Andrew
P.K. Lee
^ permalink raw reply
* Re: [PATCH v2] dmaengine: imx-sdma: Refine spba bus searching in probe
From: Shengjiu Wang @ 2026-04-07 8:59 UTC (permalink / raw)
To: Marco Felsch
Cc: Shengjiu Wang, vkoul, Frank.Li, s.hauer, kernel, festevam,
dmaengine, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <6r7ih7wz7xn44c7c2ukohy3fgp3tpo222jh7ocxacccrvywz3i@mddoznil6way>
On Tue, Apr 7, 2026 at 4:31 PM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> On 26-04-07, Shengjiu Wang wrote:
> > There are multi spba-busses for i.MX8M* platforms, if only search for
> > the first spba-bus in DT, the found spba-bus may not the real bus of
> > audio devices, which cause issue for sdma p2p case, as the sdma p2p
> > script presently does not deal with the transactions involving two devices
> > connected to the AIPS bus.
> >
> > Search the SDMA parent node first, which should be the AIPS bus, then
> > search the child node whose compatible string is spba-bus under that AIPS
> > bus for the above multi spba-busses case.
>
> Sorry but I've to NACK this, I already fixed it in a more robust way by
> checking the consumer sdma node.
>
I think you refer to this one:
https://lists.infradead.org/pipermail/linux-arm-kernel/2025-September/1061824.html
I tested it, but there is an issue. I replied to that thread, not
sure you received my message.
> +static int sdma_config_spba_slave(struct dma_chan *chan)
> +{
> + struct sdma_channel *sdmac = to_sdma_chan(chan);
> + struct device_node *spba_bus;
> + struct resource spba_res;
> + int ret;
> +
> + spba_bus = of_get_parent(chan->slave->of_node);
With asrc p2p case, the chan is requested by __dma_request_channel(),
that the chan->slave = NULL, Then there will be a kernel dump here.
That's the reason I sent this fix. But if you can fix the above
issue, I am ok to drop
my fix. or could you review my fix?, which is simpler.
Best regards
Shengjiu Wang
> Regards,
> Marco
>
>
> > Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support")
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > changes in v2:
> > - add fixes tag
> > - use __free(device_node) for auto release.
> >
> > drivers/dma/imx-sdma.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > index 3d527883776b..36368835a845 100644
> > --- a/drivers/dma/imx-sdma.c
> > +++ b/drivers/dma/imx-sdma.c
> > @@ -2364,7 +2364,9 @@ static int sdma_probe(struct platform_device *pdev)
> > return dev_err_probe(&pdev->dev, ret,
> > "failed to register controller\n");
> >
> > - spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
> > + struct device_node *sdma_parent_np __free(device_node) = of_get_parent(np);
> > +
> > + spba_bus = of_get_compatible_child(sdma_parent_np, "fsl,spba-bus");
> > ret = of_address_to_resource(spba_bus, 0, &spba_res);
> > if (!ret) {
> > sdma->spba_start_addr = spba_res.start;
> > --
> > 2.34.1
> >
> >
> >
>
> --
> #gernperDu
> #CallMeByMyFirstName
>
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
>
^ permalink raw reply
* Re: [PATCH v5 0/9] driver core: Fix some race conditions
From: Marek Szyprowski @ 2026-04-07 8:57 UTC (permalink / raw)
To: Douglas Anderson, Greg Kroah-Hartman, Rafael J . Wysocki,
Danilo Krummrich, Alan Stern
Cc: Leon Romanovsky, Christoph Hellwig, Robin Murphy, driver-core,
iommu, linux-acpi, linux-arm-kernel, linux-kernel, linux-mm,
linux-pci, linux-usb, linux
In-Reply-To: <20260406232444.3117516-1-dianders@chromium.org>
On 07.04.2026 01:22, Douglas Anderson wrote:
> The main goal of this series is to fix the observed bug talked about
> in the first patch ("driver core: Don't let a device probe until it's
> ready"). That patch fixes a problem that has been observed in the real
> world and could land even if the rest of the patches are found
> unacceptable or need to be spun.
>
> That said, during patch review Danilo correctly pointed out that many
> of the bitfield accesses in "struct device" are unsafe. I added a
> bunch of patches in the series to address each one.
>
> Danilo said he's most worried about "can_match", so I put that one
> first. After that, I tried to transition bitfields to flags in reverse
> order to when the bitfield was added.
>
> Even if transitioning from bitfields to flags isn't truly needed for
> correctness, it seems silly (and wasteful of space in struct device)
> to have some in bitfields and some as flags. Thus I didn't spend time
> for each bitfield showing that it's truly needed for correctness.
>
> Transition was done semi manually. Presumably someone skilled at
> coccinelle could do a better job, but I just used sed in a heavy-
> handed manner and then reviewed/fixed the results, undoing anything my
> script got wrong. My terrible/ugly script was:
>
> var=can_match
> caps="${var^^}"
> for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
> echo $f
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
> done
>
> From v3 to v4, I transitioned to accessor functions with another ugly
> sed script. I had git format the old patches, then transformed them
> with:
>
> for f in *.patch; do
> echo $f
> sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> done
>
> ...and then did a few manual touchups for spacing.
>
> I only marked the first patch as a "Fix" since it is the only one
> fixing observed problems. Other patches could be considered fixes too
> if folks want.
>
> I tested the first patch in the series backported to kernel 6.6 on the
> Pixel phone that was experiencing the race. I added extra printouts to
> make sure that the problem was hitting / addressed. The rest of the
> patches are tested with allmodconfig with arm32, arm64, ppc, and
> x86. I boot tested on an arm64 Chromebook running mainline.
The dma-mapping related bits are probably not race prone, but if you plan
to refactor that part I won't object.
Acked-by: Marek Szyprowski
> Changes in v5:
> - ready_to_prove => ready_to_probe typo
> - device_lock() while calling dev_set_ready_to_probe()
> - Add comment before "can_match = true" from Danilo.
> - undef __create_dev_flag_accessors
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - Use a new "flags" bitfield
> - Add missing \n in probe error message
>
> Changes in v2:
> - Instead of adjusting the ordering, use "ready_to_probe" flag
>
> Douglas Anderson (9):
> driver core: Don't let a device probe until it's ready
> driver core: Replace dev->can_match with dev_can_match()
> driver core: Replace dev->dma_iommu with dev_dma_iommu()
> driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
> driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
> driver core: Replace dev->state_synced with dev_state_synced()
> driver core: Replace dev->dma_coherent with dev_dma_coherent()
> driver core: Replace dev->of_node_reused with dev_of_node_reused()
> driver core: Replace dev->offline + ->offline_disabled with accessors
>
> arch/arc/mm/dma.c | 4 +-
> arch/arm/mach-highbank/highbank.c | 2 +-
> arch/arm/mach-mvebu/coherency.c | 2 +-
> arch/arm/mm/dma-mapping-nommu.c | 4 +-
> arch/arm/mm/dma-mapping.c | 28 ++--
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/mm/dma-mapping.c | 2 +-
> arch/mips/mm/dma-noncoherent.c | 2 +-
> arch/powerpc/kernel/dma-iommu.c | 8 +-
> .../platforms/pseries/hotplug-memory.c | 4 +-
> arch/riscv/mm/dma-noncoherent.c | 2 +-
> drivers/acpi/scan.c | 2 +-
> drivers/base/core.c | 55 +++++---
> drivers/base/cpu.c | 4 +-
> drivers/base/dd.c | 36 ++++--
> drivers/base/memory.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/dma/ti/k3-udma-glue.c | 6 +-
> drivers/dma/ti/k3-udma.c | 6 +-
> drivers/iommu/dma-iommu.c | 9 +-
> drivers/iommu/iommu.c | 5 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +-
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 122 ++++++++++++------
> include/linux/dma-map-ops.h | 6 +-
> include/linux/dma-mapping.h | 2 +-
> include/linux/iommu-dma.h | 3 +-
> kernel/cpu.c | 4 +-
> kernel/dma/mapping.c | 12 +-
> mm/hmm.c | 2 +-
> 37 files changed, 218 insertions(+), 142 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Ryan Roberts @ 2026-04-07 8:43 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <ac-W9oNM_O5RTtaf@arm.com>
On 03/04/2026 11:31, Catalin Marinas wrote:
> On Thu, Apr 02, 2026 at 09:43:59PM +0100, Catalin Marinas wrote:
>> Another thing I couldn't get my head around - IIUC is_realm_world()
>> won't return true for map_mem() yet (if in a realm). Can we have realms
>> on hardware that does not support BBML2_NOABORT? We may not have
>> configuration with rodata_full set (it should be complementary to realm
>> support).
>
> With rodata_full==false, can_set_direct_map() returns false initially
> but after arm64_rsi_init() it starts returning true if is_realm_world().
> The side-effect is that map_mem() goes for block mappings and
> linear_map_requires_bbml2 set to false. Later on,
> linear_map_maybe_split_to_ptes() will skip the splitting.
>
> Unless I'm missing something, is_realm_world() calls in
> force_pte_mapping() and can_set_direct_map() are useless. I'd remove
> them and either require BBML2_NOABORT with CCA or get the user to force
> rodata_full when running in realms. Or move arm64_rsi_init() even
> earlier?
I'd need Suzuki to comment on this. As I said in the other mail, I was treating
this like a pre-existing bug. But I guess linear_map_requires_bbml2 ending up
wrong is a problem here. I'm not sure it's quite as simple as requiring
BBML2_NOABORT with CCA as we still need can_set_direct_map() to return true if
we are in a realm.
I don't know what it would take to run arm64_rsi_init() even earlier, but that
would be the best option from my point of view.
Thanks,
Ryan
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Ryan Roberts @ 2026-04-07 8:33 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <ac7VD4Z85nS30GCp@arm.com>
On 02/04/2026 21:43, Catalin Marinas wrote:
> On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
>> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
>> {
>> int ret;
>>
>> - /*
>> - * !BBML2_NOABORT systems should not be trying to change permissions on
>> - * anything that is not pte-mapped in the first place. Just return early
>> - * and let the permission change code raise a warning if not already
>> - * pte-mapped.
>> - */
>> - if (!system_supports_bbml2_noabort())
>> - return 0;
>> -
>> /*
>> * If the region is within a pte-mapped area, there is no need to try to
>> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
>> * change permissions from atomic context so for those cases (which are
>> * always pte-mapped), we must not go any further because taking the
>> - * mutex below may sleep.
>> + * mutex below may sleep. Do not call force_pte_mapping() here because
>> + * it could return a confusing result if called from a secondary cpu
>> + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
>> + * what we need.
>> */
>> - if (force_pte_mapping() || is_kfence_address((void *)start))
>> + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
>> return 0;
>>
>> + if (!system_supports_bbml2_noabort()) {
>> + /*
>> + * !BBML2_NOABORT systems should not be trying to change
>> + * permissions on anything that is not pte-mapped in the first
>> + * place. Just return early and let the permission change code
>> + * raise a warning if not already pte-mapped.
>> + */
>> + if (system_capabilities_finalized())
>> + return 0;
>> +
>> + /*
>> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
>> + * page allocator. Can't split until it's available.
>> + */
>> + if (WARN_ON(!page_alloc_available))
>> + return -EBUSY;
>> +
>> + /*
>> + * Boot-time: Started secondary cpus but don't know if they
>> + * support BBML2_NOABORT yet. Can't allow splitting in this
>> + * window in case they don't.
>> + */
>> + if (WARN_ON(num_online_cpus() > 1))
>> + return -EBUSY;
>> + }
>
> I think sashiko is over cautions here
> (https://sashiko.dev/#/patchset/20260330161705.3349825-1-ryan.roberts@arm.com)
> but it has a somewhat valid point from the perspective of
> num_online_cpus() semantics. We have have num_online_cpus() == 1 while
> having a secondary CPU just booted and with its MMU enabled. I don't
> think we can have any asynchronous tasks running at that point to
> trigger a spit though. Even async_init() is called after smp_init().
Yes I saw the Sashiko report, but we had previously had a (private) discussion
where I thought we had already concluded that this approach is safe in practice
due to the way that the boot cpu brings the secondaries online.
>
> An option may be to attempt cpus_read_trylock() as this lock is taken by
> _cpu_up(). If it fails, return -EBUSY, otherwise check num_online_cpus()
> and unlock (and return -EBUSY if secondaries already started).
That sounds neat; I could dig deeper and have a go at something like this if you
want?
>
> Another thing I couldn't get my head around - IIUC is_realm_world()
> won't return true for map_mem() yet (if in a realm). Can we have realms
> on hardware that does not support BBML2_NOABORT? We may not have
> configuration with rodata_full set (it should be complementary to realm
> support).
My understanding is that this is a pre-existing (and known) bug. It's not
related to the "map linear map by large leaves and split dynamically" feature so
wasn't attempting to fix it.
I had heard that in practice all FEAT_RME systems should support FEAT_BBML3
which would solve the problem. Not sure how true that is though.
>
> I'll add the patches to for-next/core to give them a bit of time in
> -next but let's see next week if we ignore this (with an updated
> comment) or we try to avoid the issue altogether.
>
Thanks,
Ryan
^ permalink raw reply
* Re: [PATCH] coresight: tpdm: fix invalid MMIO access issue
From: Jie Gan @ 2026-04-07 8:33 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Tingwei Zhang, coresight, linux-arm-kernel, linux-kernel
In-Reply-To: <20260407081048.GJ356832@e132581.arm.com>
Hi Leo
On 4/7/2026 4:10 PM, Leo Yan wrote:
> On Tue, Apr 07, 2026 at 12:47:11PM +0800, Jie Gan wrote:
>> Create the csdev_access struct only when a valid MMIO resource is
>> available. In tpdm_probe(), base is uninitialized for static TPDM
>> instances that lack an MMIO resource, causing csdev_access to be
>> created with a garbage address and potentially leading to
>> unexpected issues.
>
> This patch itself is fine for me. However, I am wandering if this
> is sufficient.
>
> As mentioned "potentially leading to unexpected issues", can I
> understand some code pieces access register with uninitialized base?
> If so, you would also explictly add coresight_is_static_tpdm() to
> prevent register access.
>
Actually, we havent MMIO access for the static TPDM device, So no issues
are observed. The commit message here may be misleading. do I need
rephrase the commit message?
Thanks,
Jie
> Thanks,
> Leo
>
>> Fixes: 14ae052f7947 ("coresight: tpdm: add static tpdm support")
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-tpdm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
>> index 9b16f368a58b..eaf7210af648 100644
>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>> @@ -1430,6 +1430,7 @@ static int tpdm_probe(struct device *dev, struct resource *res)
>> if (ret)
>> return ret;
>>
>> + desc.access = CSDEV_ACCESS_IOMEM(base);
>> if (tpdm_has_dsb_dataset(drvdata))
>> of_property_read_u32(drvdata->dev->of_node,
>> "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
>> @@ -1452,7 +1453,6 @@ static int tpdm_probe(struct device *dev, struct resource *res)
>> desc.ops = &tpdm_cs_ops;
>> desc.pdata = dev->platform_data;
>> desc.dev = dev;
>> - desc.access = CSDEV_ACCESS_IOMEM(base);
>> if (res)
>> desc.groups = tpdm_attr_grps;
>> else
>>
>> ---
>> base-commit: 816f193dd0d95246f208590924dd962b192def78
>> change-id: 20260407-fix-potential-issue-in-tpdm-b07b44416051
>>
>> Best regards,
>> --
>> Jie Gan <jie.gan@oss.qualcomm.com>
>>
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Michal Simek @ 2026-04-07 8:30 UTC (permalink / raw)
To: Pei Xiao, linux-spi, linux-arm-kernel, linux-kernel, broonie
In-Reply-To: <80a108ac-c100-4077-b51e-8139f9ec277b@kylinos.cn>
On 4/7/26 10:14, Pei Xiao wrote:
> 在 2026/4/7 16:01, Michal Simek 写道:
>>
>>
>> On 4/7/26 09:32, Pei Xiao wrote:
>>>
>>> Replace devm_clk_get() followed by clk_prepare_enable() with
>>> devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
>>> the need for explicit clock enable and disable calls, as the managed
>>> API automatically disables the clocks on device removal or probe
>>> failure.
>>>
>>> Remove the now-unnecessary clk_disable_unprepare() calls from the
>>> probe error paths and the remove callback. Simplify error handling
>>> by jumping directly to the remove_ctlr label.
>>>
>>> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
>>> ---
>>> drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
>>> 1 file changed, 6 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
>>> index 5232483c4a3a..8c3975030d0a 100644
>>> --- a/drivers/spi/spi-zynq-qspi.c
>>> +++ b/drivers/spi/spi-zynq-qspi.c
>>> @@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>>> goto remove_ctlr;
>>> }
>>>
>>> - xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
>>> + xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
>>> if (IS_ERR(xqspi->pclk)) {
>>> dev_err(&pdev->dev, "pclk clock not found.\n");
>>> ret = PTR_ERR(xqspi->pclk);
>>> @@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>>>
>>> init_completion(&xqspi->data_completion);
>>>
>>> - xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
>>> + xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
>>> if (IS_ERR(xqspi->refclk)) {
>>> dev_err(&pdev->dev, "ref_clk clock not found.\n");
>>> ret = PTR_ERR(xqspi->refclk);
>>> goto remove_ctlr;
>>> }
>>>
>>> - ret = clk_prepare_enable(xqspi->pclk);
>>> - if (ret) {
>>> - dev_err(&pdev->dev, "Unable to enable APB clock.\n");
>>> - goto remove_ctlr;
>>> - }
>>> -
>>> - ret = clk_prepare_enable(xqspi->refclk);
>>> - if (ret) {
>>> - dev_err(&pdev->dev, "Unable to enable device clock.\n");
>>> - goto clk_dis_pclk;
>>> - }
>>> -
>>> xqspi->irq = platform_get_irq(pdev, 0);
>>> if (xqspi->irq < 0) {
>>> ret = xqspi->irq;
>>> - goto clk_dis_all;
>>> + goto remove_ctlr;
>>> }
>>> ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
>>> 0, pdev->name, xqspi);
>>> if (ret != 0) {
>>> ret = -ENXIO;
>>> dev_err(&pdev->dev, "request_irq failed\n");
>>> - goto clk_dis_all;
>>> + goto remove_ctlr;
>>> }
>>>
>>> ret = of_property_read_u32(np, "num-cs",
>>> @@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>>> } else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
>>> ret = -EINVAL;
>>> dev_err(&pdev->dev, "only 2 chip selects are available\n");
>>> - goto clk_dis_all;
>>> + goto remove_ctlr;
>>> } else {
>>> ctlr->num_chipselect = num_cs;
>>> }
>>> @@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>>> ret = devm_spi_register_controller(&pdev->dev, ctlr);
>>> if (ret) {
>>> dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
>>> - goto clk_dis_all;
>>> + goto remove_ctlr;
>>> }
>>>
>>> return ret;
>>>
>>> -clk_dis_all:
>>> - clk_disable_unprepare(xqspi->refclk);
>>> -clk_dis_pclk:
>>> - clk_disable_unprepare(xqspi->pclk);
>>> remove_ctlr:
>>> spi_controller_put(ctlr);
>>>
>>> @@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
>>> struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
>>>
>>> zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
>>> -
>>> - clk_disable_unprepare(xqspi->refclk);
>>> - clk_disable_unprepare(xqspi->pclk);
>>> }
>>>
>>> static const struct of_device_id zynq_qspi_of_match[] = {
>>> --
>>> 2.25.1
>>>
>>
>> There is also clock manipulation in zynq_qspi_setup_op() which needs to be handled.
>>
> Can I remove this code? If not, please ignore this patch, and I apologize for the noise.
>
> In zynq_qspi_setup_op:
> ~~~~remove this clk enable code
> ret = clk_enable(qspi->refclk);
> if (ret)
> return ret;
>
> ret = clk_enable(qspi->pclk);
> if (ret) {
> clk_disable(qspi->refclk);
> return ret;
> }
> ~~~
Yes, remove it completely.
M
^ permalink raw reply
* Re: [PATCH v2 2/2] drm: lcdif: Wait for vblank before disabling DMA
From: Lucas Stach @ 2026-04-07 8:28 UTC (permalink / raw)
To: Paul Kocialkowski, dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Krzysztof Hałasa, Marco Felsch, Liu Ying
In-Reply-To: <20260402183351.3281123-3-paulk@sys-base.io>
Am Donnerstag, dem 02.04.2026 um 20:33 +0200 schrieb Paul Kocialkowski:
> It is necessary to wait for the full frame to finish streaming
> through the DMA engine before we can safely disable it by removing
> the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> hardware confused and unable to resume streaming for the next frame.
>
> This causes the FIFO underrun and empty status bits to be set and
> a single solid color to be shown on the display, coming from one of
> the pixels of the previous frame. The issue occurs sporadically when
> a new mode is set, which triggers the crtc disable and enable paths.
>
> Setting the shadow load bit and waiting for it to be cleared by the
> DMA engine allows waiting for completion.
>
> The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
>
> Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
Looks good to me. Since the co-developed tag requires a sign-off from
me, I'll add that instead of a review tag. And you might want to move
your sign-off down, as you are the one submitting the patch.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index a00c4f6d63f4..0d04a0028671 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -375,14 +375,23 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> int ret;
>
> reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> + /* Disable the layer for DMA. */
> reg &= ~CTRLDESCL0_5_EN;
> + /*
> + * It is necessary to wait for the full frame to finish streaming
> + * through the DMA engine before we can safely disable it by removing
> + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> + * hardware confused and unable to resume streaming for the next frame.
> + */
> + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
>
> + /* Wait for the frame to finish or timeout after 50 ms. */
> ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> - reg, !(reg & CTRLDESCL0_5_EN),
> - 0, 36000); /* Wait ~2 frame times max */
> + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> + 200, 50000);
> if (ret)
> - drm_err(lcdif->drm, "Failed to disable controller!\n");
> + drm_err(lcdif->drm, "Timed out waiting for final vblank!\n");
>
> reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
> reg &= ~DISP_PARA_DISP_ON;
^ permalink raw reply
* Re: [PATCH v2] dmaengine: imx-sdma: Refine spba bus searching in probe
From: Marco Felsch @ 2026-04-07 8:26 UTC (permalink / raw)
To: Shengjiu Wang
Cc: vkoul, Frank.Li, s.hauer, kernel, festevam, dmaengine, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260407032755.2758049-1-shengjiu.wang@nxp.com>
On 26-04-07, Shengjiu Wang wrote:
> There are multi spba-busses for i.MX8M* platforms, if only search for
> the first spba-bus in DT, the found spba-bus may not the real bus of
> audio devices, which cause issue for sdma p2p case, as the sdma p2p
> script presently does not deal with the transactions involving two devices
> connected to the AIPS bus.
>
> Search the SDMA parent node first, which should be the AIPS bus, then
> search the child node whose compatible string is spba-bus under that AIPS
> bus for the above multi spba-busses case.
Sorry but I've to NACK this, I already fixed it in a more robust way by
checking the consumer sdma node.
Regards,
Marco
> Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changes in v2:
> - add fixes tag
> - use __free(device_node) for auto release.
>
> drivers/dma/imx-sdma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 3d527883776b..36368835a845 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -2364,7 +2364,9 @@ static int sdma_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, ret,
> "failed to register controller\n");
>
> - spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
> + struct device_node *sdma_parent_np __free(device_node) = of_get_parent(np);
> +
> + spba_bus = of_get_compatible_child(sdma_parent_np, "fsl,spba-bus");
> ret = of_address_to_resource(spba_bus, 0, &spba_res);
> if (!ret) {
> sdma->spba_start_addr = spba_res.start;
> --
> 2.34.1
>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-04-07 8:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrea della Porta, Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <20260405-enormous-glittering-avocet-285f82@quoll>
Hi Krzysztof,
On 09:52 Sun 05 Apr , Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 04:31:54PM +0200, Andrea della Porta wrote:
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > +
>
> Missing ref to pwm.yaml.
The reference to pwm.yaml is at line 13, as follows:
allOf:
- $ref: pwm.yaml#
currently right after the maintainers: block. Are you
suggesting to move it after the required: block?
>
> > +additionalProperties: false
>
> and this should be unevaluatedProperties. See other files.
Ack.
Many thanks,
Andrea
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 0/4] perf arm_spe: Dump IMPDEF events
From: James Clark @ 2026-04-07 8:18 UTC (permalink / raw)
To: Namhyung Kim
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <adP44THdD-HBB8cY@google.com>
On 06/04/2026 7:18 pm, Namhyung Kim wrote:
> Hi James,
>
> On Wed, Apr 01, 2026 at 03:25:48PM +0100, James Clark wrote:
>> In the Arm SPE raw data dump, IMPDEF events aren't printed. Add the
>> ability to add names for some known events or print the raw event number
>> for unknown events.
>>
>> For example:
>>
>> $ perf report -D
>>
>> ... ARM SPE data: size 0xd000 bytes
>> 00000000: b0 18 c6 32 80 00 80 ff a0 PC 0xff80008032c618 el1 ns=1
>> 00000009: 64 e7 42 00 00 CONTEXT 0x42e7 el1
>> 0000000e: 00 00 00 00 00 PAD
>> 00000013: 49 00 LD GP-REG
>> 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS
>>
>> On N1 the event line becomes:
>>
>> 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS LATE-PREFETCH
>>
>> Or on other cores it becomes:
>>
>> 00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS IMPDEF:12
>>
>> Signed-off-by: James Clark <james.clark@linaro.org>
>> ---
>> James Clark (4):
>> perf arm_spe: Make a function to get the MIDR
>> perf arm_spe: Turn event name mappings into an array
>> perf arm_spe: Decode Arm N1 IMPDEF events
>> perf arm_spe: Print remaining IMPDEF event numbers
>
> Will you send v2 or do you think it's ok to merge v1?
>
> Thanks,
> Namhyung
>
I'll send a v2, thanks.
>>
>> tools/perf/util/arm-spe-decoder/Build | 2 +
>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 147 ++++++++++++++-------
>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 +-
>> tools/perf/util/arm-spe.c | 49 ++++---
>> 4 files changed, 135 insertions(+), 68 deletions(-)
>> ---
>> base-commit: 74e2dbe7be5037a5e5eed6bc1ad562747ac88566
>> change-id: 20260331-james-spe-impdef-decode-d944f4fdcff7
>>
>> Best regards,
>> --
>> James Clark <james.clark@linaro.org>
>>
^ permalink raw reply
* [PATCH v13 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: P.K. Lee @ 2026-04-07 8:17 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
In-Reply-To: <20260407081700.2658011-1-pkleequanta@gmail.com>
Add Linux device tree related to Meta (Facebook) Ventura specific
devices connected to the BMC (AST2600) SoC. The purpose of Ventura is to
detect liquid leakage from all compute trays, switch trays and rack
sensors within the rack, log the events, and take necessary actions
accordingly.
Signed-off-by: P.K. Lee <pkleequanta@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-ventura.dts | 1636 +++++++++++++++++
2 files changed, 1637 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 0f0b5b707654..f5ac72d5933c 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-santabarbara.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+ aspeed-bmc-facebook-ventura.dtb \
aspeed-bmc-facebook-wedge40.dtb \
aspeed-bmc-facebook-wedge100.dtb \
aspeed-bmc-facebook-wedge400-data64.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
new file mode 100644
index 000000000000..6ce6201f7755
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
@@ -0,0 +1,1636 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2023 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/gpio/aspeed-gpio.h>
+
+/ {
+ model = "Facebook ventura RMC";
+ compatible = "facebook,ventura-rmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ i2c16 = &i2c3mux0ch3;
+ i2c17 = &i2c3mux0ch4;
+ i2c18 = &i2c3mux0ch5;
+ i2c19 = &i2c3mux0ch6;
+ i2c20 = &i2c3mux0ch0;
+ i2c21 = &i2c3mux0ch1;
+ i2c22 = &i2c3mux0ch2;
+ i2c23 = &i2c3mux0ch7;
+ i2c24 = &i2c0mux0ch0;
+ i2c25 = &i2c0mux0ch1;
+ i2c26 = &i2c0mux0ch2;
+ i2c27 = &i2c0mux0ch3;
+ i2c28 = &i2c0mux0ch4;
+ i2c29 = &i2c0mux0ch5;
+ i2c30 = &i2c0mux0ch6;
+ i2c31 = &i2c0mux0ch7;
+ i2c32 = &i2c1mux0ch0;
+ i2c33 = &i2c1mux0ch1;
+ i2c34 = &i2c1mux0ch2;
+ i2c35 = &i2c1mux0ch3;
+ i2c36 = &i2c1mux0ch4;
+ i2c37 = &i2c1mux0ch5;
+ i2c38 = &i2c1mux0ch6;
+ i2c39 = &i2c1mux0ch7;
+ i2c40 = &i2c2mux0ch0;
+ i2c41 = &i2c2mux0ch1;
+ i2c42 = &i2c2mux0ch2;
+ i2c43 = &i2c2mux0ch3;
+ i2c44 = &i2c2mux0ch4;
+ i2c45 = &i2c2mux0ch5;
+ i2c46 = &i2c2mux0ch6;
+ i2c47 = &i2c2mux0ch7;
+ };
+
+ chosen {
+ stdout-path = "serial4:57600n8";
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+ <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+ <&adc1 2>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "bmc_heartbeat_amber";
+ gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-1 {
+ label = "fp_id_amber";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-2 {
+ label = "bmc_ready_noled";
+ default-state = "on";
+ gpios = <&gpio0 ASPEED_GPIO(B, 3) (GPIO_ACTIVE_HIGH|GPIO_TRANSITORY)>;
+ };
+
+ led-3 {
+ label = "power_blue";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(P, 4) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-4 {
+ label = "compute1_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g5_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-5 {
+ label = "compute1_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-6 {
+ label = "compute1_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-7 {
+ label = "compute2_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-8 {
+ label = "compute2_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-9 {
+ label = "compute2_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-10 {
+ label = "compute3_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-11 {
+ label = "compute3_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-12 {
+ label = "compute3_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-13 {
+ label = "compute4_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-14 {
+ label = "compute4_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-15 {
+ label = "compute4_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-16 {
+ label = "compute5_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-17 {
+ label = "compute5_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-18 {
+ label = "compute5_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-19 {
+ label = "compute6_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-20 {
+ label = "compute6_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-21 {
+ label = "compute6_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-22 {
+ label = "compute7_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-23 {
+ label = "compute7_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-24 {
+ label = "compute7_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-25 {
+ label = "compute8_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-26 {
+ label = "compute8_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-27 {
+ label = "compute8_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-28 {
+ label = "nvs1_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-29 {
+ label = "nvs1_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-30 {
+ label = "nvs1_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-31 {
+ label = "nvs2_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-32 {
+ label = "nvs2_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-33 {
+ label = "nvs2_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-34 {
+ label = "nvs3_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-35 {
+ label = "nvs3_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-36 {
+ label = "nvs3_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-37 {
+ label = "nvs4_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-38 {
+ label = "nvs4_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-39 {
+ label = "nvs4_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-40 {
+ label = "nvs5_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-41 {
+ label = "nvs5_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-42 {
+ label = "nvs5_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-43 {
+ label = "nvs6_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-44 {
+ label = "nvs6_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-45 {
+ label = "nvs6_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-46 {
+ label = "nvs7_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-47 {
+ label = "nvs7_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-48 {
+ label = "nvs7_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-49 {
+ label = "nvs8_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-50 {
+ label = "nvs8_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-51 {
+ label = "nvs8_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-52 {
+ label = "nvs9_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-53 {
+ label = "nvs9_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-54 {
+ label = "nvs9_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-55 {
+ label = "compute9_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-56 {
+ label = "compute9_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-57 {
+ label = "compute9_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-58 {
+ label = "compute10_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-59 {
+ label = "compute10_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-60 {
+ label = "compute10_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-61 {
+ label = "compute11_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-62 {
+ label = "compute11_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-63 {
+ label = "compute11_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-64 {
+ label = "compute12_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-65 {
+ label = "compute12_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-66 {
+ label = "compute12_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-67 {
+ label = "compute13_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-68 {
+ label = "compute13_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-69 {
+ label = "compute13_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-70 {
+ label = "compute14_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-71 {
+ label = "compute14_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-72 {
+ label = "compute14_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-73 {
+ label = "compute15_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-74 {
+ label = "compute15_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-75 {
+ label = "compute15_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-76 {
+ label = "compute16_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-77 {
+ label = "compute16_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-78 {
+ label = "compute16_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-79 {
+ label = "compute17_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-80 {
+ label = "compute17_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-81 {
+ label = "compute17_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-82 {
+ label = "compute18_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-83 {
+ label = "compute18_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-84 {
+ label = "compute18_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-85 {
+ label = "fan0_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-86 {
+ label = "fan0_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-87 {
+ label = "fan0_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-88 {
+ label = "fan0_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-89 {
+ label = "fan1_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-90 {
+ label = "fan1_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-91 {
+ label = "fan1_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-92 {
+ label = "fan1_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+
+ p1v8_bmc_aux: regulator-p1v8-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p1v8_bmc_aux";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ p2v5_bmc_aux: regulator-p2v5-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p2v5_bmc_aux";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ spi1_gpio: spi {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sck-gpios = <&gpio0 ASPEED_GPIO(Z, 3) GPIO_ACTIVE_HIGH>;
+ mosi-gpios = <&gpio0 ASPEED_GPIO(Z, 4) GPIO_ACTIVE_HIGH>;
+ miso-gpios = <&gpio0 ASPEED_GPIO(Z, 5) GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio0 ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+ num-chipselects = <1>;
+
+ tpm@0 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+ };
+};
+
+&adc0 {
+ vref-supply = <&p1v8_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+ &pinctrl_adc2_default &pinctrl_adc3_default
+ &pinctrl_adc4_default &pinctrl_adc5_default
+ &pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+ vref-supply = <&p2v5_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+ };
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "alt-bmc";
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&gpio0 {
+ gpio-line-names =
+ /*A0-A7*/ "","","","","","","","",
+ /*B0-B7*/ "BATTERY_DETECT","","","BMC_READY","","","","",
+ /*C0-C7*/ "","","","","","","","",
+ /*D0-D7*/ "","","","","","","","",
+ /*E0-E7*/ "","","","","","","","",
+ /*F0-F7*/ "","","","","","","","",
+ /*G0-G7*/ "","","","","","","","",
+ /*H0-H7*/ "","","","","","","","",
+ /*I0-I7*/ "","","","","","","","",
+ /*J0-J7*/ "","","","","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "","","","","","","","",
+ /*M0-M7*/ "","","","","","","","",
+ /*N0-N7*/ "","","","","","","","",
+ /*O0-O7*/ "","","","","","","","USBDBG_IPMI_EN_L",
+ /*P0-P7*/ "","","","","","","","",
+ /*Q0-Q7*/ "","","","","","FM_MDIO_SW_SEL","","",
+ /*R0-R7*/ "","","","","","","","",
+ /*S0-S7*/ "","","","","","","","",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "","","","","","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","","","","",
+ /*Y0-Y7*/ "","","","","","","","",
+ /*Z0-Z7*/ "","","","","","","","";
+};
+
+&i2c0 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c0mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c0mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c0mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c0mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c0mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c0mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c0mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c0mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c1mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c1mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c1mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c1mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c1mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c1mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c1mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c1mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c2mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c2mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c2mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c2mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c2mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c2mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c2mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c2mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c3 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c3mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c3mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c3mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c3mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ fan_leds_g1_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "FAN0_PRSNT", "FAN1_PRSNT",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ // Fan Board 0 FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ fan_leds_g2_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "FAN2_PRSNT", "FAN3_PRSNT",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ // Fan Board 1 FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ pwm@20 {
+ compatible = "maxim,max31790";
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@2 {
+ reg = <2>;
+ sensor-type = "TACH";
+ };
+ channel@5 {
+ reg = <5>;
+ sensor-type = "TACH";
+ };
+ };
+
+ hwmon: hwmon@23 {
+ compatible = "nuvoton,nct7363";
+ reg = <0x23>;
+ #pwm-cells = <2>;
+
+ //fan 0 IL
+ fan-0 {
+ pwms = <&hwmon 0 20000>;
+ tach-ch = /bits/ 8 <0x09>;
+ };
+
+ //fan 0 OL
+ fan-1 {
+ pwms = <&hwmon 0 20000>;
+ tach-ch = /bits/ 8 <0x0B>;
+ };
+
+ //fan 1 IL
+ fan-2 {
+ pwms = <&hwmon 4 20000>;
+ tach-ch = /bits/ 8 <0x0A>;
+ };
+
+ //fan 1 OL
+ fan-3 {
+ pwms = <&hwmon 4 20000>;
+ tach-ch = /bits/ 8 <0x0D>;
+ };
+
+ //fan 2 IL
+ fan-4 {
+ pwms = <&hwmon 6 20000>;
+ tach-ch = /bits/ 8 <0x0F>;
+ };
+
+ //fan 2 OL
+ fan-5 {
+ pwms = <&hwmon 6 20000>;
+ tach-ch = /bits/ 8 <0x01>;
+ };
+
+ //fan 3 IL
+ fan-6 {
+ pwms = <&hwmon 10 20000>;
+ tach-ch = /bits/ 8 <0x00>;
+ };
+
+ //fan 3 OL
+ fan-7 {
+ pwms = <&hwmon 10 20000>;
+ tach-ch = /bits/ 8 <0x03>;
+ };
+ };
+ };
+
+ i2c3mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ // REAR-IO Board FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+
+ // VR TEMP U399
+ temperature-sensor@4c {
+ compatible = "ti,tmp75";
+ reg = <0x4c>;
+ };
+
+ // VR TEMP U397
+ temperature-sensor@4d {
+ compatible = "ti,tmp75";
+ reg = <0x4d>;
+ };
+
+ // BRICK TEMP U398
+ temperature-sensor@4e {
+ compatible = "ti,tmp75";
+ reg = <0x4e>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp75";
+ reg = <0x4f>;
+ };
+
+ // RMC FRU
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+};
+
+&i2c6 {
+ status = "okay";
+
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+ bus-frequency = <100000>;
+ multi-master;
+ i2c-scl-clk-low-timeout-us = <31744>;
+
+ //USB Debug Connector
+ ipmb@10 {
+ compatible = "ipmb-dev";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ i2c-protocol;
+ };
+};
+
+&i2c9 {
+ status = "okay";
+
+ // SCM TEMP SENSOR
+ temperature-sensor@4b {
+ compatible = "ti,tmp75";
+ reg = <0x4b>;
+ };
+
+ // SCM FRU EEPROM
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ // BSM FRU EEPROM
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ reg = <0x56>;
+ };
+};
+
+&i2c10 {
+ status = "okay";
+
+ gpio@10 {
+ compatible = "nxp,pca9555";
+ reg = <0x10>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "IT_STOP_PUMP_SPARE_2", "IT_STOP_PUMP_2",
+ "IT_STOP_PUMP_SPARE", "IT_STOP_PUMP",
+ "", "RPU_2_READY_PLD_R",
+ "RPU_READY_SPARE_PLD_R", "",
+ "wPWRGD_P12V_SCM_R", "wPWRGD_P12V_AUX_R",
+ "wPWRGD_P24V_AUX_R", "wPWRGD_P52V_HSC_PWROK_R",
+ "wSMB_TMC75_TEMP_ALERT_N_R", "wP48V_HSC_ALERT_N",
+ "wP24V_AUX_INA230_ALERT_N_R", "wP24V_SM_INA230_ALERT_N_R";
+ };
+
+ gpio@11 {
+ compatible = "nxp,pca9555";
+ reg = <0x11>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "wPWRGD_P24V_SMPWROK",
+ "wPWRGD_P1V05_AUX_R", "wPWRGD_P1V5_AUX_R",
+ "wPWRGD_P3V3_AUX_R", "wPWRGD_P5V_AUX_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ power-monitor@14 {
+ compatible = "infineon,xdp710";
+ reg = <0x14>;
+ };
+
+ gpio@16 {
+ compatible = "nxp,pca9555";
+ reg = <0x16>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWREN_COMPUTE_BLADE2_EN_R", "PWREN_COMPUTE_BLADE1_EN_R",
+ "", "",
+ "", "",
+ "", "",
+ "PWREN_NVS_BLADE2_EN_L_R", "PWREN_NVS_BLADE1_EN_L_R",
+ "PWREN_COMPUTE_BLADE8_EN_R", "PWREN_COMPUTE_BLADE7_EN_R",
+ "PWREN_COMPUTE_BLADE6_EN_R", "PWREN_COMPUTE_BLADE5_EN_R",
+ "PWREN_COMPUTE_BLADE4_EN_R", "PWREN_COMPUTE_BLADE3_EN_R";
+ };
+
+ gpio@17 {
+ compatible = "nxp,pca9555";
+ reg = <0x17>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWREN_COMPUTE_BLADE18_EN_R", "PWREN_COMPUTE_BLADE17_EN_R",
+ "PWREN_COMPUTE_BLADE16_EN_R", "PWREN_COMPUTE_BLADE15_EN_R",
+ "PWREN_COMPUTE_BLADE14_EN_R", "PWREN_COMPUTE_BLADE13_EN_R",
+ "PWREN_COMPUTE_BLADE12_EN_R", "PWREN_COMPUTE_BLADE11_EN_R",
+ "PWREN_COMPUTE_BLADE9_EN_R", "PWREN_NVS_BLADE9_EN_L_R",
+ "PWREN_NVS_BLADE8_EN_L_R", "PWREN_NVS_BLADE7_EN_L_R",
+ "PWREN_NVS_BLADE6_EN_L_R", "PWREN_NVS_BLADE5_EN_L_R",
+ "PWREN_NVS_BLADE4_EN_L_R", "PWREN_NVS_BLADE3_EN_L_R";
+ };
+
+ gpio@19 {
+ compatible = "nxp,pca9555";
+ reg = <0x19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "wIT_GEAR_RPU_2_LINK_PRSNT_SPARE_N_R", "wIT_GEAR_RPU_2_LINK_PRSNT_N_R",
+ "wIT_GEAR_RPU_LINK_PRSNT_SPARE_N_R", "wIT_GEAR_RPU_LINK_PRSNT_N_R",
+ "", "",
+ "", "";
+ };
+
+ gpio@1a {
+ compatible = "nxp,pca9555";
+ reg = <0x1a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "wPRSNT_LEAK1_SENSOR_R_PLD_N", "wPRSNT_LEAK0_SENSOR_R_PLD_N",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "wPRSNT_LEAK2_SENSOR_R_PLD_N";
+ };
+
+ gpio@1b {
+ compatible = "nxp,pca9555";
+ reg = <0x1b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <18 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "wPRSNT_LEAK4_SENSOR_R_PLD_N",
+ "wPRSNT_LEAK3_SENSOR_R_PLD_N", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "PWREN_COMPUTE_BLADE10_EN_R";
+ };
+
+ power-monitor@44 {
+ compatible = "lltc,ltc4286";
+ reg = <0x44>;
+ };
+};
+
+&i2c14 {
+ status = "okay";
+};
+
+&i2c15 {
+ status = "okay";
+
+ tray_leds_g1_gpio: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g2_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g3_gpio: gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g4_gpio: gpio@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g5_gpio: gpio@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g6_gpio: gpio@26 {
+ compatible = "nxp,pca9555";
+ reg = <0x26>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ // LED Board FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+};
+
+&mac3 {
+ status = "okay";
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii4_default>;
+
+ /* Connected to Marvell 88E6393X CPU port in unmanaged mode */
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&mdio0 {
+ status = "okay";
+ /* * Intentionally left empty.
+ * Enabled to allow user-space tools (e.g., mdio)
+ * to access the unmanaged Marvell switch registers.
+ */
+};
+
+&sgpiom0 {
+ status = "okay";
+ ngpios = <128>;
+ bus-frequency = <2000000>;
+
+ gpio-line-names =
+ /*"input pin","output pin"*/
+ /*A0 - A7*/
+ "power-chassis-good","power-chassis-control",
+ "IOEXP1_INT_N","WATER_VALVE_CLOSED_N",
+ "wPRSNT_RETURN_PLD_R_N","FM_MDIO_SW_SEL_PLD",
+ "wPRSNT_SUPPLY_PLD_R_N","FM_88E6393X_BIN_UPDATE_EN_N",
+ "LEAK3_DETECT","",
+ "LEAK4_DETECT","",
+ "RETURN_CNTL_FB_D_R","",
+ "SUPPLY_CNTL_FB_D_R","",
+ /*B0 - B7*/
+ "IOEXP0_INT_N","",
+ "IOEXP11_INT_N","",
+ "IOEXP10_INT_N","",
+ "IOEXP9_INT_N","",
+ "RPU_2_READY_SPARE_PLD_R","",
+ "IOEXP7_INT_N","",
+ "IOEXP6_INT_N","",
+ "RPU_READY_PLD_R","",
+ /*C0 - C7*/
+ "wAALC_RPU_READY","",
+ "LEAK0_DETECT","",
+ "LEAK1_DETECT","",
+ "LEAK2_DETECT","",
+ "PRSNT_COMPUTE_TRAY1_N","",
+ "PRSNT_COMPUTE_TRAY2_N","",
+ "PRSNT_COMPUTE_TRAY3_N","",
+ "PRSNT_COMPUTE_TRAY4_N","",
+ /*D0 - D7*/
+ "PRSNT_COMPUTE_TRAY5_N","",
+ "PRSNT_COMPUTE_TRAY6_N","",
+ "PRSNT_COMPUTE_TRAY7_N","",
+ "PRSNT_COMPUTE_TRAY8_N","",
+ "PRSNT_NVS_TRAY1_N","",
+ "PRSNT_NVS_TRAY2_N","",
+ "PRSNT_COMPUTE_TRAY11_N","",
+ "PRSNT_COMPUTE_TRAY12_N","",
+ /*E0 - E7*/
+ "PRSNT_COMPUTE_TRAY13_N","",
+ "PRSNT_COMPUTE_TRAY14_N","",
+ "PRSNT_COMPUTE_TRAY15_N","",
+ "PRSNT_COMPUTE_TRAY16_N","",
+ "PRSNT_COMPUTE_TRAY17_N","",
+ "PRSNT_COMPUTE_TRAY18_N","",
+ "PRSNT_NVS_TRAY3_N","",
+ "PRSNT_NVS_TRAY4_N","",
+ /*F0 - F7*/
+ "PRSNT_NVS_TRAY5_N","",
+ "PRSNT_NVS_TRAY6_N","",
+ "PRSNT_NVS_TRAY7_N","",
+ "PRSNT_NVS_TRAY8_N","",
+ "PRSNT_NVS_TRAY9_N","",
+ "PRSNT_COMPUTE_TRAY9_N","",
+ "PRSNT_COMPUTE_TRAY10_N","",
+ "SMALL_LEAK_COMPUTE_TRAY1_N","",
+ /*G0 - G7*/
+ "SMALL_LEAK_COMPUTE_TRAY2_N","",
+ "SMALL_LEAK_COMPUTE_TRAY3_N","",
+ "SMALL_LEAK_COMPUTE_TRAY4_N","",
+ "SMALL_LEAK_COMPUTE_TRAY5_N","",
+ "SMALL_LEAK_COMPUTE_TRAY6_N","",
+ "SMALL_LEAK_COMPUTE_TRAY7_N","",
+ "SMALL_LEAK_COMPUTE_TRAY8_N","",
+ "SMALL_LEAK_NVS_TRAY1_N","",
+ /*H0 - H7*/
+ "SMALL_LEAK_NVS_TRAY2_N","",
+ "SMALL_LEAK_COMPUTE_TRAY11_N","",
+ "SMALL_LEAK_COMPUTE_TRAY12_N","",
+ "SMALL_LEAK_COMPUTE_TRAY13_N","",
+ "SMALL_LEAK_COMPUTE_TRAY14_N","",
+ "SMALL_LEAK_COMPUTE_TRAY15_N","",
+ "SMALL_LEAK_COMPUTE_TRAY16_N","",
+ "SMALL_LEAK_COMPUTE_TRAY17_N","",
+ /*I0 - I7*/
+ "SMALL_LEAK_COMPUTE_TRAY18_N","",
+ "SMALL_LEAK_NVS_TRAY3_N","",
+ "SMALL_LEAK_NVS_TRAY4_N","",
+ "SMALL_LEAK_NVS_TRAY5_N","",
+ "SMALL_LEAK_NVS_TRAY6_N","",
+ "SMALL_LEAK_NVS_TRAY7_N","",
+ "SMALL_LEAK_NVS_TRAY8_N","",
+ "SMALL_LEAK_NVS_TRAY9_N","",
+ /*J0 - J7*/
+ "SMALL_LEAK_COMPUTE_TRAY9_N","",
+ "SMALL_LEAK_COMPUTE_TRAY10_N","",
+ "PWRGD_COMPUTE_TRAY1_N","",
+ "PWRGD_COMPUTE_TRAY2_N","",
+ "PWRGD_COMPUTE_TRAY3_N","",
+ "PWRGD_COMPUTE_TRAY4_N","",
+ "PWRGD_COMPUTE_TRAY5_N","",
+ "PWRGD_COMPUTE_TRAY6_N","",
+ /*K0 - K7*/
+ "PWRGD_COMPUTE_TRAY7_N","",
+ "PWRGD_COMPUTE_TRAY8_N","",
+ "PWRGD_NVS_TRAY1_PWROK_N","",
+ "PWRGD_NVS_TRAY2_PWROK_N","",
+ "PWRGD_COMPUTE_TRAY11_N","",
+ "PWRGD_COMPUTE_TRAY12_N","",
+ "PWRGD_COMPUTE_TRAY13_N","",
+ "PWRGD_COMPUTE_TRAY14_N","",
+ /*L0 - L7*/
+ "PWRGD_COMPUTE_TRAY15_N","",
+ "PWRGD_COMPUTE_TRAY16_N","",
+ "PWRGD_COMPUTE_TRAY17_N","",
+ "PWRGD_COMPUTE_TRAY18_N","",
+ "PWRGD_NVS_TRAY3_PWROK_N","",
+ "PWRGD_NVS_TRAY4_PWROK_N","",
+ "PWRGD_NVS_TRAY5_PWROK_N","",
+ "PWRGD_NVS_TRAY6_PWROK_N","",
+ /*M0 - M7*/
+ "PWRGD_NVS_TRAY7_PWROK_N","",
+ "PWRGD_NVS_TRAY8_PWROK_N","",
+ "PWRGD_NVS_TRAY9_PWROK_N","",
+ "PWRGD_COMPUTE_TRAY9_N","",
+ "PWRGD_COMPUTE_TRAY10_N","",
+ "LEAK_DETECT_COMPUTE_TRAY1_N","",
+ "LEAK_DETECT_COMPUTE_TRAY2_N","",
+ "LEAK_DETECT_COMPUTE_TRAY3_N","",
+ /*N0 - N7*/
+ "LEAK_DETECT_COMPUTE_TRAY4_N","",
+ "LEAK_DETECT_COMPUTE_TRAY5_N","",
+ "LEAK_DETECT_COMPUTE_TRAY6_N","",
+ "LEAK_DETECT_COMPUTE_TRAY7_N","",
+ "LEAK_DETECT_COMPUTE_TRAY8_N","",
+ "LEAK_DETECT_NVS_TRAY1_N","",
+ "LEAK_DETECT_NVS_TRAY2_N","",
+ "LEAK_DETECT_COMPUTE_TRAY11_N","",
+ /*O0 - O7*/
+ "LEAK_DETECT_COMPUTE_TRAY12_N","",
+ "LEAK_DETECT_COMPUTE_TRAY13_N","",
+ "LEAK_DETECT_COMPUTE_TRAY14_N","",
+ "LEAK_DETECT_COMPUTE_TRAY15_N","",
+ "LEAK_DETECT_COMPUTE_TRAY16_N","",
+ "LEAK_DETECT_COMPUTE_TRAY17_N","",
+ "LEAK_DETECT_COMPUTE_TRAY18_N","",
+ "LEAK_DETECT_NVS_TRAY3_N","",
+ /*P0 - P7*/
+ "LEAK_DETECT_NVS_TRAY4_N","",
+ "LEAK_DETECT_NVS_TRAY5_N","",
+ "LEAK_DETECT_NVS_TRAY6_N","",
+ "LEAK_DETECT_NVS_TRAY7_N","",
+ "LEAK_DETECT_NVS_TRAY8_N","",
+ "LEAK_DETECT_NVS_TRAY9_N","",
+ "LEAK_DETECT_COMPUTE_TRAY9_N","",
+ "LEAK_DETECT_COMPUTE_TRAY10_N","";
+};
+
+&uhci {
+ status = "okay";
+};
+
+&wdt1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdtrst1_default>;
+ aspeed,reset-type = "soc";
+ aspeed,external-signal;
+ aspeed,ext-push-pull;
+ aspeed,ext-active-high;
+ aspeed,ext-pulse-duration = <256>;
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v13 1/2] dt-bindings: arm: aspeed: add Meta Ventura board
From: P.K. Lee @ 2026-04-07 8:16 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
In-Reply-To: <20260407081700.2658011-1-pkleequanta@gmail.com>
Document the new compatibles used on Meta Ventura.
Signed-off-by: P.K. Lee <pkleequanta@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index aedefca7cf4a..afabfe22c8f3 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -92,6 +92,7 @@ properties:
- facebook,harma-bmc
- facebook,minerva-cmc
- facebook,santabarbara-bmc
+ - facebook,ventura-rmc
- facebook,yosemite4-bmc
- ibm,blueridge-bmc
- ibm,everest-bmc
--
2.43.0
^ permalink raw reply related
* [PATCH v13 0/2] Add Meta (Facebook) Ventura BMC (AST2600)
From: P.K. Lee @ 2026-04-07 8:16 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
Add Linux device tree entry related to Meta (Facebook) Ventura specific
devices connected to the BMC (AST2600) SoC. The purpose of Ventura is to
detect liquid leakage from all compute trays, switch trays and rack
sensors within the rack, log the events, and take necessary actions
accordingly.
---
v1:
1. Create ventura dts file.
2. Add commit msg.
3. Use format-patch to generate patch.
4. Add subject prefixes matching the subsystem.
---
v2:
1. Modify email content.
---
v3:
1. Add mail list.
---
v4:
1. Apply git send-email --thread option.
2. Sort nodes in the dts alphanumerically.
---
v5:
1. Run scripts/checkpatch.pl and fix reported warnings.
2. Remove unnecessary 88E6393X CONFIG FRU.
---
v6:
1. Add a new stage for the DTS change.
2. Run scripts/checkpatch.pl and fix reported error.
3. Fix the issue in a separate patch.
---
v7:
1. Fix broken indentation in the device tree file.
2. Sort nodes alphabetically, then by address if equal.
3. Rename fan sensor nodes from 'hwmon' to 'fan-controller'.
---
v8:
1. This patch series has significant changes compared to
previous versions, and quite some time has passed since the last
submission.Therefore, previously received Acked-by/Reviewed-by/Tested-by
tags are not included in this version.
If needed, tags can be added again after review of thisnew version.
---
v9:
1. Reordered the node sequence under i2c5.
2. Added a description of the platform's intended use to the commit
messages.
3. Added 3 GPIO expanders to i2c10 and defined the necessary GPIO
line names.
---
v10:
1. Added IRQ support in GPIO expanders under i2c10 to handle edge-triggered
events.
2. Reordered the nodes.
---
v11:
1. Modified the position for i2c3mux0ch6 and i2c3mux0ch7.
---
v12:
1. Added a GPIO expander at address 0x11 on i2c10, and assign an SGPIO pin
as the IRQ for it.
2. Fixed the "failed to match any schema with compatible" issues.
3. Reorder the nodes in alphabetically.
---
v13:
1. Add two GPIO expanders (0x16 and 0x17) to i2c10 and assign two SGPIO
pins as IRQs.
2. Move the RPU_READY_SPARE_PLD_R and RPU_2_READY_PLD_R pins from
SGPIO to the GPIO expander (0x10).
3. Add all tray PWREN pins to the GPIO expanders (0x16, 0x17 and 0x1b).
4. Add explanatory comments for "unmanaged mode" under &mac3 and
"intentionally left empty" under &mdio.
P.K. Lee (2):
dt-bindings: arm: aspeed: add Meta Ventura board
arm: dts: aspeed: ventura: add Meta Ventura BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-ventura.dts | 1636 +++++++++++++++++
3 files changed, 1638 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
base-commit: e11fa6b1ff6c27c808d17e479bd7d5582e772062
branch: dev-6.6
--
2.43.0
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Pei Xiao @ 2026-04-07 8:14 UTC (permalink / raw)
To: Michal Simek, linux-spi, linux-arm-kernel, linux-kernel, broonie
In-Reply-To: <827a6fdf-b119-4aea-9442-7f27f1383c78@amd.com>
在 2026/4/7 16:01, Michal Simek 写道:
>
>
> On 4/7/26 09:32, Pei Xiao wrote:
>> [You don't often get email from xiaopei01@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Replace devm_clk_get() followed by clk_prepare_enable() with
>> devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
>> the need for explicit clock enable and disable calls, as the managed
>> API automatically disables the clocks on device removal or probe
>> failure.
>>
>> Remove the now-unnecessary clk_disable_unprepare() calls from the
>> probe error paths and the remove callback. Simplify error handling
>> by jumping directly to the remove_ctlr label.
>>
>> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
>> ---
>> drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
>> 1 file changed, 6 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
>> index 5232483c4a3a..8c3975030d0a 100644
>> --- a/drivers/spi/spi-zynq-qspi.c
>> +++ b/drivers/spi/spi-zynq-qspi.c
>> @@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>> goto remove_ctlr;
>> }
>>
>> - xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
>> + xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
>> if (IS_ERR(xqspi->pclk)) {
>> dev_err(&pdev->dev, "pclk clock not found.\n");
>> ret = PTR_ERR(xqspi->pclk);
>> @@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>>
>> init_completion(&xqspi->data_completion);
>>
>> - xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
>> + xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
>> if (IS_ERR(xqspi->refclk)) {
>> dev_err(&pdev->dev, "ref_clk clock not found.\n");
>> ret = PTR_ERR(xqspi->refclk);
>> goto remove_ctlr;
>> }
>>
>> - ret = clk_prepare_enable(xqspi->pclk);
>> - if (ret) {
>> - dev_err(&pdev->dev, "Unable to enable APB clock.\n");
>> - goto remove_ctlr;
>> - }
>> -
>> - ret = clk_prepare_enable(xqspi->refclk);
>> - if (ret) {
>> - dev_err(&pdev->dev, "Unable to enable device clock.\n");
>> - goto clk_dis_pclk;
>> - }
>> -
>> xqspi->irq = platform_get_irq(pdev, 0);
>> if (xqspi->irq < 0) {
>> ret = xqspi->irq;
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> }
>> ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
>> 0, pdev->name, xqspi);
>> if (ret != 0) {
>> ret = -ENXIO;
>> dev_err(&pdev->dev, "request_irq failed\n");
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> }
>>
>> ret = of_property_read_u32(np, "num-cs",
>> @@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>> } else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
>> ret = -EINVAL;
>> dev_err(&pdev->dev, "only 2 chip selects are available\n");
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> } else {
>> ctlr->num_chipselect = num_cs;
>> }
>> @@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>> ret = devm_spi_register_controller(&pdev->dev, ctlr);
>> if (ret) {
>> dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> }
>>
>> return ret;
>>
>> -clk_dis_all:
>> - clk_disable_unprepare(xqspi->refclk);
>> -clk_dis_pclk:
>> - clk_disable_unprepare(xqspi->pclk);
>> remove_ctlr:
>> spi_controller_put(ctlr);
>>
>> @@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
>> struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
>>
>> zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
>> -
>> - clk_disable_unprepare(xqspi->refclk);
>> - clk_disable_unprepare(xqspi->pclk);
>> }
>>
>> static const struct of_device_id zynq_qspi_of_match[] = {
>> --
>> 2.25.1
>>
>
> There is also clock manipulation in zynq_qspi_setup_op() which needs to be handled.
>
Can I remove this code? If not, please ignore this patch, and I apologize for the noise.
In zynq_qspi_setup_op:
~~~~remove this clk enable code
ret = clk_enable(qspi->refclk);
if (ret)
return ret;
ret = clk_enable(qspi->pclk);
if (ret) {
clk_disable(qspi->refclk);
return ret;
}
~~~
Thanks!
Pei.
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH] coresight: tpdm: fix invalid MMIO access issue
From: Leo Yan @ 2026-04-07 8:10 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Tingwei Zhang, coresight, linux-arm-kernel, linux-kernel
In-Reply-To: <20260407-fix-potential-issue-in-tpdm-v1-1-42090d27c0a8@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 12:47:11PM +0800, Jie Gan wrote:
> Create the csdev_access struct only when a valid MMIO resource is
> available. In tpdm_probe(), base is uninitialized for static TPDM
> instances that lack an MMIO resource, causing csdev_access to be
> created with a garbage address and potentially leading to
> unexpected issues.
This patch itself is fine for me. However, I am wandering if this
is sufficient.
As mentioned "potentially leading to unexpected issues", can I
understand some code pieces access register with uninitialized base?
If so, you would also explictly add coresight_is_static_tpdm() to
prevent register access.
Thanks,
Leo
> Fixes: 14ae052f7947 ("coresight: tpdm: add static tpdm support")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-tpdm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index 9b16f368a58b..eaf7210af648 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -1430,6 +1430,7 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> if (ret)
> return ret;
>
> + desc.access = CSDEV_ACCESS_IOMEM(base);
> if (tpdm_has_dsb_dataset(drvdata))
> of_property_read_u32(drvdata->dev->of_node,
> "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
> @@ -1452,7 +1453,6 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> desc.ops = &tpdm_cs_ops;
> desc.pdata = dev->platform_data;
> desc.dev = dev;
> - desc.access = CSDEV_ACCESS_IOMEM(base);
> if (res)
> desc.groups = tpdm_attr_grps;
> else
>
> ---
> base-commit: 816f193dd0d95246f208590924dd962b192def78
> change-id: 20260407-fix-potential-issue-in-tpdm-b07b44416051
>
> Best regards,
> --
> Jie Gan <jie.gan@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v3 3/4] soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
From: Nicolas Frattaroli @ 2026-04-07 8:10 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Daniele Briguglio
Cc: linux-clk, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Daniele Briguglio
In-Reply-To: <20260320-rk3588-mclk-gate-grf-v3-3-980338eacd2c@superkali.me>
On Friday, 20 March 2026 11:34:15 Central European Summer Time Daniele Briguglio wrote:
> Add the RK3588_SYSGRF_SOC_CON6 register offset to the RK3588 GRF
> header. This register contains the I2S MCLK output to IO gate bits,
> needed by the clock driver.
>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
> include/soc/rockchip/rk3588_grf.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/soc/rockchip/rk3588_grf.h b/include/soc/rockchip/rk3588_grf.h
> index 02a7b2432d99..db0092fc66ad 100644
> --- a/include/soc/rockchip/rk3588_grf.h
> +++ b/include/soc/rockchip/rk3588_grf.h
> @@ -19,4 +19,6 @@
> /* Whether the LPDDR5 is in 2:1 (= 0) or 4:1 (= 1) CKR a.k.a. DQS mode */
> #define RK3588_PMUGRF_OS_REG6_LP5_CKR BIT(0)
>
> +#define RK3588_SYSGRF_SOC_CON6 0x0318
> +
> #endif /* __SOC_RK3588_GRF_H */
>
>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Verified the definition by comparing it to hardware documentation,
it checks out.
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Michal Simek @ 2026-04-07 8:01 UTC (permalink / raw)
To: Pei Xiao, linux-spi, linux-arm-kernel, linux-kernel, broonie
In-Reply-To: <0c851587c90ae51d1498d18955aefc83fa41f17d.1775547057.git.xiaopei01@kylinos.cn>
On 4/7/26 09:32, Pei Xiao wrote:
> [You don't often get email from xiaopei01@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Replace devm_clk_get() followed by clk_prepare_enable() with
> devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
> the need for explicit clock enable and disable calls, as the managed
> API automatically disables the clocks on device removal or probe
> failure.
>
> Remove the now-unnecessary clk_disable_unprepare() calls from the
> probe error paths and the remove callback. Simplify error handling
> by jumping directly to the remove_ctlr label.
>
> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
> ---
> drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
> 1 file changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
> index 5232483c4a3a..8c3975030d0a 100644
> --- a/drivers/spi/spi-zynq-qspi.c
> +++ b/drivers/spi/spi-zynq-qspi.c
> @@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> goto remove_ctlr;
> }
>
> - xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
> + xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
> if (IS_ERR(xqspi->pclk)) {
> dev_err(&pdev->dev, "pclk clock not found.\n");
> ret = PTR_ERR(xqspi->pclk);
> @@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>
> init_completion(&xqspi->data_completion);
>
> - xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
> + xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
> if (IS_ERR(xqspi->refclk)) {
> dev_err(&pdev->dev, "ref_clk clock not found.\n");
> ret = PTR_ERR(xqspi->refclk);
> goto remove_ctlr;
> }
>
> - ret = clk_prepare_enable(xqspi->pclk);
> - if (ret) {
> - dev_err(&pdev->dev, "Unable to enable APB clock.\n");
> - goto remove_ctlr;
> - }
> -
> - ret = clk_prepare_enable(xqspi->refclk);
> - if (ret) {
> - dev_err(&pdev->dev, "Unable to enable device clock.\n");
> - goto clk_dis_pclk;
> - }
> -
> xqspi->irq = platform_get_irq(pdev, 0);
> if (xqspi->irq < 0) {
> ret = xqspi->irq;
> - goto clk_dis_all;
> + goto remove_ctlr;
> }
> ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
> 0, pdev->name, xqspi);
> if (ret != 0) {
> ret = -ENXIO;
> dev_err(&pdev->dev, "request_irq failed\n");
> - goto clk_dis_all;
> + goto remove_ctlr;
> }
>
> ret = of_property_read_u32(np, "num-cs",
> @@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> } else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
> ret = -EINVAL;
> dev_err(&pdev->dev, "only 2 chip selects are available\n");
> - goto clk_dis_all;
> + goto remove_ctlr;
> } else {
> ctlr->num_chipselect = num_cs;
> }
> @@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> ret = devm_spi_register_controller(&pdev->dev, ctlr);
> if (ret) {
> dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
> - goto clk_dis_all;
> + goto remove_ctlr;
> }
>
> return ret;
>
> -clk_dis_all:
> - clk_disable_unprepare(xqspi->refclk);
> -clk_dis_pclk:
> - clk_disable_unprepare(xqspi->pclk);
> remove_ctlr:
> spi_controller_put(ctlr);
>
> @@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
> struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
>
> zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
> -
> - clk_disable_unprepare(xqspi->refclk);
> - clk_disable_unprepare(xqspi->pclk);
> }
>
> static const struct of_device_id zynq_qspi_of_match[] = {
> --
> 2.25.1
>
There is also clock manipulation in zynq_qspi_setup_op() which needs to be handled.
Thanks,
Michal
^ permalink raw reply
* Re: [Upstream] Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Primoz Fiser @ 2026-04-07 6:14 UTC (permalink / raw)
To: Frank Li, Florijan Plohl
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <adMg762HH4gcuWyq@lizhi-Precision-Tower-5810>
Hi Frank, Florijan,
On 4/6/26 04:56, Frank Li wrote:
> On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
>> Hello,
>>
>> On 4/2/26 15:50, Frank Li wrote:
>>> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
>>>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
>>> what's means PEB-AV-18? Is it random board name?
>> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
>> be used to connect displays on their boards.
>>
>> I will improve commit message to add more such information in v2.
>>
>>>
>>>
>>>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>>>>
>>>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
>>>> ---
>>>> arch/arm64/boot/dts/freescale/Makefile | 4 +
>>>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>>>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>>> Any difference between 91 and 93, can use one overlay file?
>>>
>>> Frank
>>
>> Can you suggest how to do so?
>>
>> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
>> between imx91 and imx93.
>
> I suggest move pinmux setting to mainboard's dts files, which provide
> plug adaptor header, signal should be descripted in mainboard's dts file,
> which provide an unified label to overlay file.
Yeah, that would be one way of doing it.
However, the phycore dtsi and phyboard dts are kept simple by design
choice. This way, all optional pinctrls and peripherals are kept
separate from the board device-tree to maintain clutter low.
For v2 I would prefer to keep as is (current downstream implementation)
or at least use this approach:
imx91-93-phyboard-segin-peb-av-18.dtsi
|
-> imx91-phyboard-segin-peb-av-18.dtso
|
-> imx93-phyboard-segin-peb-av-18.dtso
BR,
Primoz
>
> Frank
>
>>
>> So we can only create common dtsi like so:
>>
>> imx91-93-phyboard-segin-peb-av-18.dtsi
>>
>> and still use separate dtsos:
>>
>> imx91-phyboard-segin-peb-av-18.dtso
>> imx93-phyboard-segin-peb-av-18.dtso
>>
>> Is that your idea?
>>
>> BR,
>>
>> Florijan Plohl
>>
>>>> --
>>>> 2.43.0
>>>>
> _______________________________________________
> upstream mailing list -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de
--
Primoz Fiser
phone: +386-41-390-545
email: primoz.fiser@norik.com
--
Norik systems d.o.o.
Your embedded software partner
Slovenia, EU
phone: +386-41-540-545
email: info@norik.com
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Thomas Zimmermann @ 2026-04-07 7:39 UTC (permalink / raw)
To: Arnd Bergmann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <295a43ce-92fb-435d-a82f-d1cfa8f4f28d@app.fastmail.com>
Hi
Am 02.04.26 um 18:47 schrieb Arnd Bergmann:
> On Thu, Apr 2, 2026, at 17:27, Thomas Zimmermann wrote:
>> Am 02.04.26 um 16:59 schrieb Arnd Bergmann:
>>> On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
>>>> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>>> I don't really like this part of the series and would prefer
>>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>>>>> (and EFI) specific implementation detail, with the hope
>>>>> of eventually seperating out the x86 bits from the EFI ones.
>>>> You mean, you want to use the EFI-provided framebuffers without the
>>>> intermediate step of going through sysfb_primary_display?
>>>>
>>>> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
>>> The part that is still needed from sysfb is the arbitration
>>> between DRM_EFI and the PCI device driver for the same hardware,
>>> so I think some part of sysfb is clearly needed, in particular
>>> the sysfb_disable() function that removes the EFI framebuffer
>>> when there is a conflicting simpledrm or hardware specific
>>> driver.
>> We do most of that in the aperture-helper module. (see
>> <linux/aperture.h>). Calling sysfb_disable() from there is a workaround
>> for some corner cases. We can have an EFI-specific function that does
>> the same.
> That sounds good, yes. The same change would need to go into
> of_platform_default_populate_init() then.
The call to sysfb_disable() is a workaround for certain cases that
aperture helpers don't handle well. In the longer term, I'd want
aperture helpers to be more clever about aperture ownership. But as an
intermediate step, adding other _disable() function would be an option.
But there's no hurry.
>
>> BTW, simpledrm-on-EFI/VESA is considered obsolete and should preferably
>> be removed from that driver. Simpledrm should become a driver for
>> Devicetree nodes of type simple-framebuffer (as it originally has been
>> intended).
> Sure, I was only thinking of the case where there are both
> sysfb (from Arm/riscv UEFI) and simpledrm (from devicetree)
> objects referring to the same one, not the simpledrm
> device created by sysfb_simplefb.
>
>>> The parts that I want to keep out of that is anything
>>> related to the x86 boot protocol, non-EFI framebuffers,
>>> text console, and kexec handoff, which we don't need on
>>> non-x86 UEFI systems.
>>>
>>> I don't mind the idea of having a sysfb_primary_display
>>> in the EFI code if that helps keep EFI sane on x86,
>>> but it would be good to make that local to
>>> drivers/firmware/efi and (eventually) detached from
>>> include/uapi/linux/screen_info.h.
>> Efidrm retrieves the framebuffer settings from the contained struct
>> screen_info. Disconnecting from screen_info would require separate
>> graphics drivers for x86 and non-x86. If we split off EFI from sysfb,
>> we'd likely need a sysfbdrm driver of some sort. Just saying.
> Yes, I saw that as well and don't have an immediate idea for how
> to best do it. I saw that you already abstracted the access to
> the screen_info members in drm_sysfb_screen_info.c, which I think
> is a step in that direction.
>
> I also noticed that efidrm is mostly a subset of vesadrm, so
> in theory they could be merged back into an x86 drm driver
> along with the drm_sysfb_screen_info helpers, and have a non-x86
> driver that constructs a drm_sysfb_device directly from the
> EFI structures.
I would not want to have a unifed driver for all-things-screen_info. The
code that can easily be shared is already in the sysfb helpers. But I
don't mind adding a separate driver for EFI's Graphics Output Protocol.
Then there would be current efidrm for EFI-from-screen_info and
efigopdrm for EFI via the GOP interfaces. If EFI ever specifies another
graphics interface, we could add another driver. The maintenance
overhead is small on the DRM side.
What is the future of x86's boot_param and the related screen_info on
x86-64? Is it obsolete? Will boot loaders run the EFI stub instead?
>
>> I think we'd also have to duplicate the framebuffer-relocation code that
>> currently works on anything using struct screen_info (see patch 5).
> You mean the code from include/linux/screen_info.h? I think
> it would make sense to have an x86 specific version of that
> to operate on the x86 screen_info, and a simpler version
> that just updates the resource for the efirdrm driver, but
> that could also be done one level higher or lower.
Makes me wonder if the relocation code could be integrated into the
aperture helpers. It would have to track the relocation of all PCI
graphics devices and probing DRM drivers would query the relocation
offset for their given framebuffer.
>
>>>>> In general, I am always in favor of properly using Kconfig
>>>>> dependencies over 'select' statements, for the same reasons
>>>>> you describe, but I don't want the the x86 logic for
>>>>> the legacy VESA and VGA console handling to leak into more
>>>>> architectures than necessary.
>>>>>
>>>>> Do you think we could instead move the sysfb_init()
>>>>> function into the same two places that contain the
>>>>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>>>>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>>>>> to take out the x86 bits? That would reduce the rest
>>>>> of sysfb-primary.c to the logic to unregister the device,
>>>>> and that could then be selected by both x86 and EFI.
>>>> No, I'm more than happy that sysfb finally consolidates all the
>>>> init-framebuffer setup and detection that floated around in the kernel.
>>>> I would not want it to be duplicated again.
>>>>
>>>> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
>>>> Although I think this will require soem sort of solution at a later point.
>>> Can you clarify which problem you are trying to solve
>>> with that?
>> One thing is that some users simply what control over their kernel build.
>>
>> I also think that there might be systems that want to use
>> sysfb_primary_display (plus the relocation feature), but not create the
>> framebuffer device. Say for efi-earlycon. It needs user-control over the
>> SYSFB option to do that.
> I'm still not following, sorry. efi-earlycon doesn't require
> CONFIG_SYSFB today, and I don't see why that would need to change,
> or why it couldn't just 'select SYSFB' if it it does change.
>
>> As a side-effect, user-configurable SYSFB gives us a nice place to put
>> SYSFB_SIMPLEFB and FIRMWARE_EDID; two options that currently float
>> around in the config somewhat arbitrarily.
> You said that SYSFB_SIMPLEFB should get phased out in the future,
> right?
Yes. Better sooner than later.
>
> I'm also missing your plan for CONFIG_FIRMWARE_EDID. I only
> see three legacy drivers using the old fb_firmware_edid()
> interface, so I assume this is not what you are interested in.
>
> For the global copy that is filled by x86 and efi, and
> consumed by vesadrm and efidrm, does that even need to
> be a configuration option rather than get always enabled?
There is code in x86's old 16-bit boot/init code that reads the EDID via
VESA. The help text on CONFIG_FIRMWARE_EDID sounds like it needs to be
configurable because some systems can't do the VESA calls. Hence, the
logical step seems to be to make this consistent for all systems by
adopting the option for all EDID retrieval.
If we can remove CONFIG_FIRMWARE_EDID and make EDID support
unconditional, I'm all for it.
Best regards
Thomas
>
> Arnd
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [RFC v1 01/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Antoine Bouyer @ 2026-04-07 7:37 UTC (permalink / raw)
To: Jacopo Mondi
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, laurent.pinchart, mchehab, robh, krzk+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-kernel, linux-media,
devicetree, linux-arm-kernel, Jai Luthra, paul elder
In-Reply-To: <ac93m33MhldSpYDj@zed>
Hi Jacopo
On 4/3/26 10:19 AM, Jacopo Mondi wrote:
>
>
> Hello Antoine
>
> in cc Jai and Paul
>
> Jai and Paul are working on upstreaming new ISP formats which would
> benefit from usage of extensible stats.
>
> No pressure of course, just wanted to check how things are progressing
> on your side. Do you have an updated version of this patch which can
> be taken in ? Should we sync and work on an updated version ?
I'm still on it. Things are progressing well, but little bit delayed
because of neoisp rework. I hope to submit patchset (v4l2-isp + neo) by
end of this week.
BR
Antoine
>
> Thanks!
> j
>
> On Fri, Jan 23, 2026 at 09:09:28AM +0100, Antoine Bouyer wrote:
>> Extend the v4l2-isp extensible format introduced for isp parameters buffer
>> to the statistics buffer as well.
>>
>> Like for ISP configuration purpose, that will help supporting various ISP
>> hardware versions reporting different statistics data with less impact on
>> userspace.
>>
>> The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
>> definitions, with similar header, versions and flags. V0 and V1 versions
>> are provided to match with params versions. On the other side, ENABLE and
>> DISABLE flags are not really meaningfull for statistics purpose. So VALID
>> and INVALID flags are introduced. Purpose is to force ISP driver to
>> validate a statistics buffer, before it is consumed by userspace.
>>
>> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
>> ---
>> include/uapi/linux/media/v4l2-isp.h | 85 +++++++++++++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
>> index 779168f9058e..ed1279b86694 100644
>> --- a/include/uapi/linux/media/v4l2-isp.h
>> +++ b/include/uapi/linux/media/v4l2-isp.h
>> @@ -99,4 +99,89 @@ struct v4l2_isp_params_buffer {
>> __u8 data[] __counted_by(data_size);
>> };
>>
>> +/**
>> + * enum v4l2_isp_stats_version - V4L2 ISP statistics versioning
>> + *
>> + * @V4L2_ISP_STATS_VERSION_V0: First version of the V4L2 ISP statistics format
>> + * (for compatibility)
>> + * @V4L2_ISP_STATS_VERSION_V1: First version of the V4L2 ISP statistics format
>> + *
>> + * V0 and V1 are identical, and comply with V4l2 ISP parameters versions. So
>> + * both V0 and V1 refers to the first version of the V4L2 ISP statistics
>> + * format.
>> + *
>> + * Future revisions of the V4L2 ISP statistics format should start from the
>> + * value of 2.
>> + */
>> +enum v4l2_isp_stats_version {
>> + V4L2_ISP_STATS_VERSION_V0 = 0,
>> + V4L2_ISP_STATS_VERSION_V1,
>> +};
>> +
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_VALID (1U << 0)
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_INVALID (1U << 1)
>> +
>> +/*
>> + * Reserve the first 8 bits for V4L2_ISP_STATS_FL_* flag.
>> + *
>> + * Driver-specific flags should be defined as:
>> + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(0))
>> + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(1))
>> + */
>> +#define V4L2_ISP_STATS_FL_DRIVER_FLAGS(n) ((n) + 8)
>> +
>> +/**
>> + * struct v4l2_isp_stats_block_header - V4L2 extensible statistics block header
>> + * @type: The statistics block type (driver-specific)
>> + * @flags: A bitmask of block flags (driver-specific)
>> + * @size: Size (in bytes) of the statistics block, including this header
>> + *
>> + * This structure represents the common part of all the ISP statistics blocks.
>> + * Each statistics block shall embed an instance of this structure type as its
>> + * first member, followed by the block-specific statistics data.
>> + *
>> + * The @type field is an ISP driver-specific value that identifies the block
>> + * type. The @size field specifies the size of the parameters block.
>> + *
>> + * The @flags field is a bitmask of per-block flags V4L2_STATS_ISP_FL_* and
>> + * driver-specific flags specified by the driver header.
>> + */
>> +struct v4l2_isp_stats_block_header {
>> + __u16 type;
>> + __u16 flags;
>> + __u32 size;
>> +} __attribute__((aligned(8)));
>> +
>> +/**
>> + * struct v4l2_isp_stats_buffer - V4L2 extensible statistics data
>> + * @version: The statistics buffer version (driver-specific)
>> + * @data_size: The statistics data effective size, excluding this header
>> + * @data: The statistics data
>> + *
>> + * This structure contains the statistics information of the ISP hardware,
>> + * serialized for userspace into a data buffer. Each statistics block is
>> + * represented by a block-specific structure which contains a
>> + * :c:type:`v4l2_isp_stats_block_header` entry as first member. Driver
>> + * populates the @data buffer with statistics information of the ISP blocks it
>> + * intends to share to userspace. As a consequence, the data buffer effective
>> + * size changes according to the number of ISP blocks that driver intends to
>> + * provide and is set by the driver in the @data_size field.
>> + *
>> + * The statistics buffer is versioned by the @version field to allow modifying
>> + * and extending its definition. Driver shall populate the @version field to
>> + * inform the userpsace about the version it intends to use. The userspace will
>> + * parse and handle the @data buffer according to the data layout specific to
>> + * the indicated version.
>> + *
>> + * For each ISP block that driver wants to report, a block-specific structure
>> + * is appended to the @data buffer, one after the other without gaps in
>> + * between. Driver shall populate the @data_size field with the effective
>> + * size, in bytes, of the @data buffer.
>> + */
>> +struct v4l2_isp_stats_buffer {
>> + __u32 version;
>> + __u32 data_size;
>> + __u8 data[] __counted_by(data_size);
>> +};
>> +
>> #endif /* _UAPI_V4L2_ISP_H_ */
>> --
>> 2.52.0
>>
^ permalink raw reply
* [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Pei Xiao @ 2026-04-07 7:32 UTC (permalink / raw)
To: michal.simek, linux-spi, linux-arm-kernel, linux-kernel, broonie; +Cc: Pei Xiao
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
the need for explicit clock enable and disable calls, as the managed
API automatically disables the clocks on device removal or probe
failure.
Remove the now-unnecessary clk_disable_unprepare() calls from the
probe error paths and the remove callback. Simplify error handling
by jumping directly to the remove_ctlr label.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index 5232483c4a3a..8c3975030d0a 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
goto remove_ctlr;
}
- xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
+ xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
if (IS_ERR(xqspi->pclk)) {
dev_err(&pdev->dev, "pclk clock not found.\n");
ret = PTR_ERR(xqspi->pclk);
@@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
init_completion(&xqspi->data_completion);
- xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
+ xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
if (IS_ERR(xqspi->refclk)) {
dev_err(&pdev->dev, "ref_clk clock not found.\n");
ret = PTR_ERR(xqspi->refclk);
goto remove_ctlr;
}
- ret = clk_prepare_enable(xqspi->pclk);
- if (ret) {
- dev_err(&pdev->dev, "Unable to enable APB clock.\n");
- goto remove_ctlr;
- }
-
- ret = clk_prepare_enable(xqspi->refclk);
- if (ret) {
- dev_err(&pdev->dev, "Unable to enable device clock.\n");
- goto clk_dis_pclk;
- }
-
xqspi->irq = platform_get_irq(pdev, 0);
if (xqspi->irq < 0) {
ret = xqspi->irq;
- goto clk_dis_all;
+ goto remove_ctlr;
}
ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
0, pdev->name, xqspi);
if (ret != 0) {
ret = -ENXIO;
dev_err(&pdev->dev, "request_irq failed\n");
- goto clk_dis_all;
+ goto remove_ctlr;
}
ret = of_property_read_u32(np, "num-cs",
@@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
} else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
ret = -EINVAL;
dev_err(&pdev->dev, "only 2 chip selects are available\n");
- goto clk_dis_all;
+ goto remove_ctlr;
} else {
ctlr->num_chipselect = num_cs;
}
@@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
ret = devm_spi_register_controller(&pdev->dev, ctlr);
if (ret) {
dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
- goto clk_dis_all;
+ goto remove_ctlr;
}
return ret;
-clk_dis_all:
- clk_disable_unprepare(xqspi->refclk);
-clk_dis_pclk:
- clk_disable_unprepare(xqspi->pclk);
remove_ctlr:
spi_controller_put(ctlr);
@@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
-
- clk_disable_unprepare(xqspi->refclk);
- clk_disable_unprepare(xqspi->pclk);
}
static const struct of_device_id zynq_qspi_of_match[] = {
--
2.25.1
^ permalink raw reply related
* [PATCH] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
From: Pei Xiao @ 2026-04-07 7:30 UTC (permalink / raw)
To: hayashi.kunihiko, mhiramat, linux-spi, linux-arm-kernel,
linux-kernel
Cc: broonie, Pei Xiao
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for the clock. This removes the need for
explicit clock enable and disable calls, as the managed API automatically
handles clock disabling on device removal or probe failure.
Remove the now-unnecessary clk_disable_unprepare() calls from the probe
error path and the remove callback. Adjust error labels accordingly.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/spi/spi-uniphier.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index 9e1d364a6198..1b815ee2ed1b 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -666,28 +666,24 @@ static int uniphier_spi_probe(struct platform_device *pdev)
}
priv->base_dma_addr = res->start;
- priv->clk = devm_clk_get(&pdev->dev, NULL);
+ priv->clk = devm_clk_get_enabled(&pdev->dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(priv->clk);
goto out_host_put;
}
- ret = clk_prepare_enable(priv->clk);
- if (ret)
- goto out_host_put;
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
- goto out_disable_clk;
+ goto out_host_put;
}
ret = devm_request_irq(&pdev->dev, irq, uniphier_spi_handler,
0, "uniphier-spi", priv);
if (ret) {
dev_err(&pdev->dev, "failed to request IRQ\n");
- goto out_disable_clk;
+ goto out_host_put;
}
init_completion(&priv->xfer_done);
@@ -716,7 +712,7 @@ static int uniphier_spi_probe(struct platform_device *pdev)
if (IS_ERR_OR_NULL(host->dma_tx)) {
if (PTR_ERR(host->dma_tx) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
- goto out_disable_clk;
+ goto out_host_put;
}
host->dma_tx = NULL;
dma_tx_burst = INT_MAX;
@@ -766,9 +762,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
host->dma_tx = NULL;
}
-out_disable_clk:
- clk_disable_unprepare(priv->clk);
-
out_host_put:
spi_controller_put(host);
return ret;
@@ -777,14 +770,11 @@ static int uniphier_spi_probe(struct platform_device *pdev)
static void uniphier_spi_remove(struct platform_device *pdev)
{
struct spi_controller *host = platform_get_drvdata(pdev);
- struct uniphier_spi_priv *priv = spi_controller_get_devdata(host);
if (host->dma_tx)
dma_release_channel(host->dma_tx);
if (host->dma_rx)
dma_release_channel(host->dma_rx);
-
- clk_disable_unprepare(priv->clk);
}
static const struct of_device_id uniphier_spi_match[] = {
--
2.25.1
^ 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