* Re: [RESEND v2 1/1] dt-bindings: arm: lpc: add missed lpc43xx board
From: Vladimir Zapolskiy @ 2026-03-24 21:44 UTC (permalink / raw)
To: Frank Li, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Piotr Wojtaszczyk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/LPC32XX SOC SUPPORT, open list, imx
In-Reply-To: <acL_cAQ99B2VliJU@lizhi-Precision-Tower-5810>
Hi Frank,
On 3/24/26 23:17, Frank Li wrote:
> On Wed, Jan 28, 2026 at 10:24:50PM +0200, Vladimir Zapolskiy wrote:
>> Hi Frank,
>>
>> On 1/28/26 21:54, Frank Li wrote:
>>> On Wed, Oct 15, 2025 at 10:48:47PM +0300, Vladimir Zapolskiy wrote:
>>>> Hi Frank,
>>>>
>>>> On 10/15/25 21:48, Frank Li wrote:
>>>>> Add missed legancy lpc43xx board compatible string to fix below CHECK_DTB
>>>>> warnings:
>>>>> arch/arm/boot/dts/nxp/lpc/lpc4337-ciaa.dtb: /: failed to match any schema with compatible: ['ciaa,lpc4337', 'nxp,lpc4337', 'nxp,lpc4350']
>>>>>
>>>>> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>> Signed-off-by: Frank Li <Frank.Li@nxp.com>
>>>>
>>>> I'll take it for v6.19, thank you.
>>>>
>>>> If you have any other changes in the queue, please feel free to send them also.
>>>
>>> Vladimir Zapolskiy:
>>>
>>> look like you missed this patch.
>>>
>>
>> You are right about it. I consider it's pretty late to send another PR
>> including this change, and thus it will be postponed, I'm sorry for it.
>
> Can I include this patch my imx's PR?
>
you've already got my RB, and there is no objections from my side, if
the change goes through imx dt PR, otherwise I have to postpone pushing
it upwards, there is no plan to send an ARM LPCxxxx dt PR for v7.1.
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [RESEND v2 1/1] dt-bindings: arm: lpc: add missed lpc43xx board
From: Frank Li @ 2026-03-24 21:17 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Piotr Wojtaszczyk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/LPC32XX SOC SUPPORT, open list, imx
In-Reply-To: <f213bdb9-7104-495f-97fe-8190af3ec577@mleia.com>
On Wed, Jan 28, 2026 at 10:24:50PM +0200, Vladimir Zapolskiy wrote:
> Hi Frank,
>
> On 1/28/26 21:54, Frank Li wrote:
> > On Wed, Oct 15, 2025 at 10:48:47PM +0300, Vladimir Zapolskiy wrote:
> > > Hi Frank,
> > >
> > > On 10/15/25 21:48, Frank Li wrote:
> > > > Add missed legancy lpc43xx board compatible string to fix below CHECK_DTB
> > > > warnings:
> > > > arch/arm/boot/dts/nxp/lpc/lpc4337-ciaa.dtb: /: failed to match any schema with compatible: ['ciaa,lpc4337', 'nxp,lpc4337', 'nxp,lpc4350']
> > > >
> > > > Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > >
> > > I'll take it for v6.19, thank you.
> > >
> > > If you have any other changes in the queue, please feel free to send them also.
> >
> > Vladimir Zapolskiy:
> >
> > look like you missed this patch.
> >
>
> You are right about it. I consider it's pretty late to send another PR
> including this change, and thus it will be postponed, I'm sorry for it.
Can I include this patch my imx's PR?
Frank
>
^ permalink raw reply
* Re: [PATCH 02/10] i2c: tegra: Replace dev_err() with dev_err_probe() in probe function
From: Jon Hunter @ 2026-03-24 21:04 UTC (permalink / raw)
To: Atharv Dubey, Till Harbaum, Andi Shyti, Laxman Dewangan,
Dmitry Osipenko, Thierry Reding, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Pierre-Yves MORDRET, Alain Volmat,
Maxime Coquelin, Alexandre Torgue, Patrice Chotard, Orson Zhai,
Baolin Wang, Chunyan Zhang, Jean Delvare
Cc: linux-i2c, linux-kernel, linux-tegra, linux-arm-kernel,
linux-sunxi, linux-stm32, Enrico Zanda
In-Reply-To: <20260324-deverr-v1-2-7e591cce33a3@gmail.com>
On 24/03/2026 18:26, Atharv Dubey wrote:
> From: Enrico Zanda <e.zanda1@gmail.com>
>
> This simplifies the code while improving log.
>
> Signed-off-by: Enrico Zanda <e.zanda1@gmail.com>
> Signed-off-by: Atharv Dubey <atharvd440@gmail.com>
> ---
> drivers/i2c/busses/i2c-tegra.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index bec619b9af4e..51d15fca82fc 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -575,8 +575,8 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
> dma_buf = dma_alloc_coherent(i2c_dev->dma_dev, i2c_dev->dma_buf_size,
> &dma_phys, GFP_KERNEL | __GFP_NOWARN);
> if (!dma_buf) {
> - dev_err(i2c_dev->dev, "failed to allocate DMA buffer\n");
> - err = -ENOMEM;
> + err = dev_err_probe(i2c_dev->dev, -ENOMEM,
> + "failed to allocate DMA buffer\n");
So this will never be a probe defer, so why bother?
> goto err_out;
> }
>
> @@ -588,8 +588,8 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
> err_out:
> tegra_i2c_release_dma(i2c_dev);
> if (err != -EPROBE_DEFER) {
> - dev_err(i2c_dev->dev, "cannot use DMA: %d\n", err);
> - dev_err(i2c_dev->dev, "falling back to PIO\n");
> + dev_err_probe(i2c_dev->dev, err,
> + "cannot use DMA, falling back to PIO\n");
This is not right.
> return 0;
> }
>
> @@ -1953,7 +1953,7 @@ static int tegra_i2c_init_clocks(struct tegra_i2c_dev *i2c_dev)
>
> err = clk_enable(i2c_dev->div_clk);
> if (err) {
> - dev_err(i2c_dev->dev, "failed to enable div-clk: %d\n", err);
> + dev_err_probe(i2c_dev->dev, err, "failed to enable div-clk\n");
We have already got the clock and so I don't think that this is needed
either.
> goto unprepare_clocks;
> }
>
> @@ -1979,7 +1979,7 @@ static int tegra_i2c_init_hardware(struct tegra_i2c_dev *i2c_dev)
>
> ret = pm_runtime_get_sync(i2c_dev->dev);
> if (ret < 0)
> - dev_err(i2c_dev->dev, "runtime resume failed: %d\n", ret);
> + dev_err_probe(i2c_dev->dev, ret, "runtime resume failed\n");
I don't think that this is needed either.
> else
> ret = tegra_i2c_init(i2c_dev);
>
>
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 3/7] pinctrl: pinctrl-generic: add __pinctrl_generic_pins_function_dt_node_to_map()
From: Frank Li @ 2026-03-24 20:16 UTC (permalink / raw)
To: Linus Walleij
Cc: Peter Rosin, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen
In-Reply-To: <ab1Rpf2zS8Bn1-HV@lizhi-Precision-Tower-5810>
On Fri, Mar 20, 2026 at 09:54:45AM -0400, Frank Li wrote:
> On Fri, Mar 20, 2026 at 02:27:21PM +0100, Linus Walleij wrote:
> > On Thu, Mar 19, 2026 at 12:04 AM Frank Li <Frank.li@nxp.com> wrote:
> > > On Mon, Mar 16, 2026 at 10:37:28AM +0100, Linus Walleij wrote:
> >
> > > > That said: in this case you're just adding a parameter, just add
> > > > the parameter and change all of the in-tree users to pass false
> > > > or whatever you need, these is just one (1) in-tree user anyway.
> > >
> > > pinctrl_generic_pins_function_dt_node_to_map() directly feed to
> > > .dt_node_to_map() callback, add parameter will impact too much.
> >
> > Why do you say that. It already has many parameters, one more
> > or less doesn't matter. It's not like this call is performance-critical.
> > Just change the users.
>
> In only user drivers/pinctrl/microchip/pinctrl-mpfs-mssio.c,
> .dt_node_to_map = pinctrl_generic_pins_function_dt_node_to_map;
>
> pinctrl_generic_pins_function_dt_node_to_map() need match .dt_node_to_map()'s
> declear.
>
> So it can't direct add two parameters in pinctrl_generic_pins_function_dt_node_to_map()
> Need simple wrap function, which other in pinctrl-mpfs-mssio.c or in
> pinconf.h.
>
> If add two parameter in .dt_node_to_map(), need change all functions, which
> .dt_node_to_map = xxx_to_map(). and OF core part.
Linus Walleij:
Is my explain clear enough? I am preparing respin it?
is okay use wrap function
pinctrl_generic_pins_function_dt_node_to_map_ext()?
Frank
>
> Frank
>
> >
> > Yours,
> > Linus Walleij
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Frank Li @ 2026-03-24 20:00 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Christoph Niedermaier, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, devicetree, imx, kernel, linux-kernel
In-Reply-To: <e5d7ca6a-fdd3-4aca-aa1f-1d35bc9c0119@nabladev.com>
On Tue, Mar 24, 2026 at 06:39:10PM +0100, Marek Vasut wrote:
> On 3/24/26 5:01 PM, Frank Li wrote:
> > On Fri, Mar 13, 2026 at 12:24:04AM +0100, Marek Vasut wrote:
> > ...
> >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
> > > new file mode 100644
> > > index 0000000000000..534737363c9f0
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
> > > @@ -0,0 +1,42 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +/*
> > > + * Copyright (C) 2022 Marek Vasut
> >
> > 2026?
>
> That was the original copyright year when this was implemented, but I can
> update it to 2022-2026 ?
Okay, you upstream this year.
>
> > > + */
> > > +
> > > +&display_bl {
> > > + pwms = <&pwm1 0 5000000 0>;
> > > +};
> > > +
> > > +&DH_OVERLAY_PANEL_I2C_BUS {
> >
> > why upcase for label, generally it should be lower case
>
> Because this label is really a macro , please read on.
>
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + touchscreen@41 {
> > > + compatible = "ilitek,ili251x";
> > > + pinctrl-0 = <DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_PINCTRL>;
> > > + pinctrl-names = "default";
> > > + reg = <0x41>;
> >
> > reg should second property, please dt-format for new dts files.
> > check others
> What is "dt-format" ? Linux kernel source tree, even current next, does not
> mention such a tool . I did run schema check and checkpatch on these
> patches. obv.
I send out at many place, https://github.com/lznuaa/dt-format
I write small tools to detect and fix node and property order problem,
it may be buggy.
These node order problem is easy to detected and fix by tools to save
review cycle and focus on the important stuff.
Frank
>
> > > + interrupt-parent = <&DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_IRQ_PARENT>;
> > ...
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@1 {
> > > + reg = <1>;
> >
> > need empty line between child node and property.
>
> Fixed in V2
>
> > > + #size-cells = <0>;
> > > +
> > > + eeprom@56 {
> > > + compatible = "atmel,24c04";
> > > + reg = <0x56>;
> > > + pagesize = <16>;
> > > + };
> > > +};
> > > +
> > > +&ecspi2 {
> > > + status = "okay";
> >
> > status should be last property. I stop here because these
> > should be identify by tools/script
> Neither checkpatch nor schema validation complained about these.
>
> I moved the status=okay to the end. Anything else I should update ?
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: rockchip: Enable PCIe CLKREQ# for RK3588 on Rock 5b-5bp-5t series
From: Heiko Stuebner @ 2026-03-24 19:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, FUKAUMI Naoki,
Nicolas Frattaroli, Sebastian Reichel, Diederik de Haas,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Anand Moon
Cc: Heiko Stuebner, Shawn Lin
In-Reply-To: <20260316073621.39027-1-linux.amoon@gmail.com>
On Mon, 16 Mar 2026 13:03:55 +0530, Anand Moon wrote:
> Add supports-clkreq and the corresponding pinmux configurations for PCIe
> ASPM L1 substates on the Rock 5B, 5B+ and 5T.
> The supports-clkreq flag informs the PCIe controller that the hardware
> routing for the CLKREQ# sideband signal is present. This enables support
> for PCIe ASPM (Active State Power Management) L1 substates, allowing for
> better power efficiency.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: Enable PCIe CLKREQ# for RK3588 on Rock 5b-5bp-5t series
commit: 0f36806da4834cbdfe790de6b88347348cdad32a
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/4] Rework BPI-R2-Pro PCIe clock topology
From: Heiko Stuebner @ 2026-03-24 19:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Wunderlich,
David Heidelberg
Cc: Heiko Stuebner, Martin Filla, Charalampos Mitrodimas, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260304-rk3568-bri-r2-pro-fix-pcie-v4-0-37abd7ba29d0@ixit.cz>
On Wed, 04 Mar 2026 12:05:26 +0100, David Heidelberg wrote:
>
Applied, thanks!
[1/4] arm64: dts: rockchip: assign pipe clock to rk356x PCIe lanes
commit: 27472814ac0bb465da1981788aad2463bc862848
The clock generator itself can use some rework, as suggested
in the review.
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: dts: rockchip: Add initial support for Khadas Edge 2L
From: Heiko Stuebner @ 2026-03-24 19:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Gray Huang
Cc: Heiko Stuebner, linux-rockchip, devicetree, linux-arm-kernel,
linux-kernel, naoki, jonas, chaoyi.chen, i, michael.opdenacker,
inindev, quentin.schulz, andrew, alchark, pbrobinson, nick
In-Reply-To: <20260317090731.600787-1-gray.huang@wesion.com>
On Tue, 17 Mar 2026 17:07:29 +0800, Gray Huang wrote:
> This patch series adds initial basic support for the Khadas Edge 2L board,
> which is based on the Rockchip RK3576 SoC.
>
> To keep the initial review process simple and easy, this series only
> enables the bare minimum peripherals required to boot the board to a shell:
> - UART (for serial console)
> - eMMC (for root filesystem)
>
> [...]
Applied, thanks!
[1/2] dt-bindings: arm: rockchip: Add Khadas Edge 2L board
commit: b1a9b33cff4f58f2507e930d2c5805877928c6f7
[2/2] arm64: dts: rockchip: Add Khadas Edge 2L board
commit: 254c6ae9c5014497e840a6fb8520f70caef31097
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: add SD/eMMC aliases for ArmSom Sige5
From: Heiko Stuebner @ 2026-03-24 19:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Heiko Stuebner, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, kernel
In-Reply-To: <20260317-sige5-mmc-aliases-v1-1-ee93a1571802@collabora.com>
On Tue, 17 Mar 2026 15:39:30 +0100, Sebastian Reichel wrote:
> Provide aliases for the SD and eMMC interfaces, so that the operating
> system can assign stable interface names.
>
> On Linux this is only relevant when booting without partition UUID
> based root device identification, e.g. when booting without an
> initramfs. In that case booting with e.g. root=/dev/mmcblk0p2 is
> unreliable without this patch as the device numbers changed based
> on device probe order.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: add SD/eMMC aliases for ArmSom Sige5
commit: 6f7f44169bdef6e10b8d174079a155d02b87d2dc
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH 0/2] Add SPDIF support to RK3576
From: Heiko Stuebner @ 2026-03-24 19:53 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel
Cc: Heiko Stuebner, Alexey Charkov, linux-sound, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel
In-Reply-To: <20260316-rk3576-spdif-v1-0-acb75088b560@collabora.com>
On Mon, 16 Mar 2026 19:22:59 +0100, Sebastian Reichel wrote:
> Add SPDIF support on RK3576 in preparation for Displayport audio
> support. My expectation is that Mark picks up the DT binding via
> his audio tree and Heiko picks up the DTS via the Rockchip tree.
>
>
Applied, thanks!
[2/2] arm64: dts: rockchip: Add SPDIF nodes to RK3576 device tree
commit: edd3173f3d4424861c1e036b76f0f30b581bb4bc
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v2 0/3] Add devicetree nodes for RK3528, RK3562 and RK356x
From: Heiko Stuebner @ 2026-03-24 19:53 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-arm-kernel, linux-rockchip, linux-kernel, kever.yang,
finley.xiao, w, jonas
In-Reply-To: <20260312213019.13965-1-heiko@sntech.de>
On Thu, 12 Mar 2026 22:30:16 +0100, Heiko Stuebner wrote:
> This is a companion series to the binding+driver changes [0], that adds
> the relevant OTP controller nodes to the core SoC devicetrees.
>
> [0] https://lore.kernel.org/linux-rockchip/20260205211901.490181-1-heiko@sntech.de/T/#t
>
> changes in v2:
> - rename node-names to be efuse@... following the dt-specfication
> 2.2.2. Generic Names Recommendation
>
> [...]
Applied, thanks!
[1/3] arm64: dts: rockchip: Enable OTP controller for RK3562
commit: d7a73e63b9c4c1e31bf7898d45418eaa69790057
[2/3] arm64: dts: rockchip: Enable OTP controller for RK356x
commit: 2d7b5e1c962158833ef778a09d9293ed710fcc84
[3/3] arm64: dts: rockchip: Enable OTP controller for RK3528
commit: a956b54f33de96e0d879e679c22a717d390e1afa
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-24 19:53 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <23910073.EfDdHjke4D@workhorse>
On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > +enum drm_connector_color_format {
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > + * helpers should pick a suitable color format. All implementations of a
> > > + * specific display protocol must behave the same way with "AUTO", but
> > > + * different display protocols do not necessarily have the same "AUTO"
> > > + * semantics.
> > > + *
> > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > + * YCbCr 4:2:0.
> > > + *
> > > + * For display protocols other than HDMI, the recursive bridge chain
> > > + * format selection picks the first chain of bridge formats that works,
> > > + * as has already been the case before the introduction of the "color
> > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > + * bus output formats by preference, or agree on a unified auto format
> > > + * selection logic that's implemented in a common state helper (like
> > > + * how HDMI does it).
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > + * not subsampled)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > + * with horizontal subsampling)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > +
> > > + /**
> > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > + * with horizontal and vertical subsampling)
> > > + */
> > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> >
> > Seems like this should document what the quantization range
> > should be for each format.
> >
>
> I don't think so? If you want per-component bit depth values,
> DRM_FORMAT_* defines would be the appropriate values to use. This
> enum is more abstract than that, and is there to communicate
> YUV vs. RGB and chroma subsampling, with bit depth being handled
> by other properties.
>
> If you mean the factor used for subsampling, then that'd only be
> relevant if YCBCR410 was supported where one chroma plane isn't
> halved but quartered in resolution. I suspect 4:1:0 will never
> be added; no digital display protocol standard supports it to my
> knowledge, and hopefully none ever will.
No, I mean the quantization range (16-235 vs. 0-255 etc).
The i915 behaviour is that YCbCr is always limited range,
RGB can either be full or limited range depending on the
"Broadcast RGB" property and other related factors.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v7 0/2] Add support for Variscite DART-MX95 and Sonata board
From: Frank Li @ 2026-03-24 19:48 UTC (permalink / raw)
To: Stefano Radaelli
Cc: devicetree, linux-kernel, pierluigi.p, Stefano Radaelli,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, imx,
linux-arm-kernel
In-Reply-To: <abRdwy_AS046QVRI@lizhi-Precision-Tower-5810>
On Fri, Mar 13, 2026 at 02:56:03PM -0400, Frank Li wrote:
> On Fri, Mar 13, 2026 at 06:47:01PM +0100, Stefano Radaelli wrote:
> > This patch series adds support for the Variscite DART-MX95 system on
> > module and the Sonata carrier board.
> >
> > The series includes:
> > - Device tree bindings documentation for both SOM and carrier board
> > - SOM device tree with on-module peripherals
> > - Sonata carrier board device tree with board-specific features
> >
> > The implementation follows the standard SOM + carrier board pattern
> > where the SOM dtsi contains only peripherals mounted on the module,
> > while carrier-specific interfaces are enabled in the board dts.
> >
> > v7:
> > - Order nodes in symphony dts
>
> Can you run https://github.com/lznuaa/dt-format for new file to easy
> track and check by script later.
I applied with below change
- update copywrite to 2026
- move reg after compatible at ethernet phy node
- order button-n,
Next time, run dt-format, keep node orders, just adjust some property.
I will enhance script check graduatelly.
Frank
>
> Frank
>
> > v6:
> > - Order by node name instead of by label
> > v5:
> > - Fix newlines and nodes order
> > v4:
> > - Fix typo in spacing
> > - Remove vpu and cm7 reserved memory
> > - Add GPIO_OPEN_DRAIN to i2c gpios
> > - Move pinmux to eof
> > v3:
> > - Fix specific node names with generic ones
> > - Remove fixed-link property for SFP
> > - Audio regulator cleanup
> > v2:
> > - Add SFP cage node for enetc_port2 following sff,sfp.yaml binding
> >
> > Stefano Radaelli (2):
> > arm64: dts: freescale: Add support for Variscite DART-MX95
> > arm64: dts: imx95-var-dart: Add support for Variscite Sonata board
> >
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > .../dts/freescale/imx95-var-dart-sonata.dts | 591 ++++++++++++++++++
> > .../boot/dts/freescale/imx95-var-dart.dtsi | 425 +++++++++++++
> > 3 files changed, 1017 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/imx95-var-dart-sonata.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx95-var-dart.dtsi
> >
> >
> > base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb
> > prerequisite-patch-id: 7ed0e453f554c70d0fafd5147d4d9b62cac6c10f
> > --
> > 2.47.3
> >
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Mark Brown @ 2026-03-24 15:00 UTC (permalink / raw)
To: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, Alex Williamson,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Christophe Leroy (CS GROUP), Danilo Krummrich
Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260324005919.2408620-1-dakr@kernel.org>
On Tue, 24 Mar 2026 01:59:04 +0100, Danilo Krummrich wrote:
> treewide: Convert buses to use generic driver_override
>
> This is the follow-up of the driver_override generalization in [1], converting
> the remaining 11 busses and removing the now-unused driver_set_override()
> helper.
>
> All of them (except AP, which has a different race condition) are prone to the
> potential UAF described in [2], caused by accessing the driver_override field
> from their corresponding match() callback.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.0
Thanks!
[11/12] spi: use generic driver_override infrastructure
https://git.kernel.org/broonie/spi/c/cc34d77dd487
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: stm32: Fix incorrect compatible string in stm32h7-sai match
From: Mark Brown @ 2026-03-24 12:58 UTC (permalink / raw)
To: olivier.moysan, arnaud.pouliquen, mcoquelin.stm32,
alexandre.torgue, Jihed Chaibi
Cc: lgirdwood, krzk+dt, robh, conor+dt, devicetree, linux-sound,
linux-stm32, linux-kernel, linux-arm-kernel
In-Reply-To: <20260321012011.125791-1-jihed.chaibi.dev@gmail.com>
On Sat, 21 Mar 2026 02:20:11 +0100, Jihed Chaibi wrote:
> ASoC: dt-bindings: stm32: Fix incorrect compatible string in stm32h7-sai match
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.0
Thanks!
[1/1] ASoC: dt-bindings: stm32: Fix incorrect compatible string in stm32h7-sai match
https://git.kernel.org/broonie/sound/c/91049ec2e183
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-debix-model-a: Correct PAD settings for pmicirqgrp
From: Laurent Pinchart @ 2026-03-24 19:43 UTC (permalink / raw)
To: Kieran Bingham
Cc: Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Marco Felsch, Daniel Scally, devicetree, imx, linux-arm-kernel,
linux-kernel, Peng Fan, Stefan Klug
In-Reply-To: <177437389415.1230693.16040948368071205395@ping.linuxembedded.co.uk>
On Tue, Mar 24, 2026 at 05:38:14PM +0000, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2026-03-24 09:38:50)
> > On Tue, Mar 24, 2026 at 11:16:13AM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
> > > there is interrupt storm for i.MX8MP DEBIX Model A. Per schematic, there
> > > is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD
> > > PUE and PU together to make pull up work properly.
> > >
> > > Fixes: c86d350aae68e ("arm64: dts: Add device tree for the Debix Model A Board")
> > > Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > Frank, would you be able to handle this as a v7.0 regression fix ?
> >
> > I think the same is needed for imx8mp-debix-som-a.dtsi, but I can't
> > confirm it as I don't have the schematics for the SoM, neither do I have
> > access to the board.
> >
> > Dan, Kieran, Stefan, could one of you check if you get an interrupt
> > storm from the PMIC on v7.0 ?
>
> Confirmed:
> 35: 83626 0 0 0 gpio-mxc 3 Level pca9450-irq
>
> and
>
> 200: 270180 0 0 0 GICv3 67 Level 30a20000.i2c
> ...
> 200: 400925 0 0 0 GICv3 67 Level 30a20000.i2c
> ...
>
> increasing rapidly on the debix-som.
>
> I started out on the linux-media branches which were 7.0-rc2 based, and
> this didn't happen but cherry-picking in 5d0efaf47ee90 certainly causes
> this issue to occur on my board.
Could you confirm that setting MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 to
0x000001c0 fixes the issue ?
> > > ---
> > > arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > > index 9422beee30b29c5a551b08476c80fbff96af3439..df7489587e48ed0c678f11291f6f2b77082ade95 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > > @@ -440,7 +440,7 @@ MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c3
> > >
> > > pinctrl_pmic: pmicirqgrp {
> > > fsl,pins = <
> > > - MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
> > > + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x000001c0
> > > >;
> > > };
> > >
> > >
> > > ---
> > > base-commit: 09c0f7f1bcdbc3c37a5a760cbec76bf18f278406
> > > change-id: 20260324-imx8mp-dts-fix-512530fe4dcd
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 06/12] platform/wmi: use generic driver_override infrastructure
From: Armin Wolf @ 2026-03-24 19:41 UTC (permalink / raw)
To: Danilo Krummrich, Russell King, Greg Kroah-Hartman,
Rafael J. Wysocki, Ioana Ciornei, Nipun Gupta, Nikhil Agarwal,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Bjorn Helgaas, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
Gui-Dong Han
In-Reply-To: <20260324005919.2408620-7-dakr@kernel.org>
Am 24.03.26 um 01:59 schrieb Danilo Krummrich:
> When a driver is probed through __driver_attach(), the bus' match()
> callback is called without the device lock held, thus accessing the
> driver_override field without a lock, which can cause a UAF.
>
> Fix this by using the driver-core driver_override infrastructure taking
> care of proper locking internally.
>
> Note that calling match() from __driver_attach() without the device lock
> held is intentional. [1]
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
> Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> Fixes: 12046f8c77e0 ("platform/x86: wmi: Add driver_override support")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
> drivers/platform/wmi/core.c | 36 +++++-------------------------------
> include/linux/wmi.h | 4 ----
> 2 files changed, 5 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/platform/wmi/core.c b/drivers/platform/wmi/core.c
> index b8e6b9a421c6..750e3619724e 100644
> --- a/drivers/platform/wmi/core.c
> +++ b/drivers/platform/wmi/core.c
> @@ -842,39 +842,11 @@ static ssize_t expensive_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(expensive);
>
> -static ssize_t driver_override_show(struct device *dev, struct device_attribute *attr,
> - char *buf)
> -{
> - struct wmi_device *wdev = to_wmi_device(dev);
> - ssize_t ret;
> -
> - device_lock(dev);
> - ret = sysfs_emit(buf, "%s\n", wdev->driver_override);
> - device_unlock(dev);
> -
> - return ret;
> -}
> -
> -static ssize_t driver_override_store(struct device *dev, struct device_attribute *attr,
> - const char *buf, size_t count)
> -{
> - struct wmi_device *wdev = to_wmi_device(dev);
> - int ret;
> -
> - ret = driver_set_override(dev, &wdev->driver_override, buf, count);
> - if (ret < 0)
> - return ret;
> -
> - return count;
> -}
> -static DEVICE_ATTR_RW(driver_override);
> -
> static struct attribute *wmi_attrs[] = {
> &dev_attr_modalias.attr,
> &dev_attr_guid.attr,
> &dev_attr_instance_count.attr,
> &dev_attr_expensive.attr,
> - &dev_attr_driver_override.attr,
> NULL
> };
> ATTRIBUTE_GROUPS(wmi);
> @@ -943,7 +915,6 @@ static void wmi_dev_release(struct device *dev)
> {
> struct wmi_block *wblock = dev_to_wblock(dev);
>
> - kfree(wblock->dev.driver_override);
> kfree(wblock);
> }
>
> @@ -952,10 +923,12 @@ static int wmi_dev_match(struct device *dev, const struct device_driver *driver)
> const struct wmi_driver *wmi_driver = to_wmi_driver(driver);
> struct wmi_block *wblock = dev_to_wblock(dev);
> const struct wmi_device_id *id = wmi_driver->id_table;
> + int ret;
>
> /* When driver_override is set, only bind to the matching driver */
> - if (wblock->dev.driver_override)
> - return !strcmp(wblock->dev.driver_override, driver->name);
> + ret = device_match_driver_override(dev, driver);
> + if (ret >= 0)
> + return ret;
>
> if (id == NULL)
> return 0;
> @@ -1076,6 +1049,7 @@ static struct class wmi_bus_class = {
> static const struct bus_type wmi_bus_type = {
> .name = "wmi",
> .dev_groups = wmi_groups,
> + .driver_override = true,
> .match = wmi_dev_match,
> .uevent = wmi_dev_uevent,
> .probe = wmi_dev_probe,
> diff --git a/include/linux/wmi.h b/include/linux/wmi.h
> index 75cb0c7cfe57..14fb644e1701 100644
> --- a/include/linux/wmi.h
> +++ b/include/linux/wmi.h
> @@ -18,16 +18,12 @@
> * struct wmi_device - WMI device structure
> * @dev: Device associated with this WMI device
> * @setable: True for devices implementing the Set Control Method
> - * @driver_override: Driver name to force a match; do not set directly,
> - * because core frees it; use driver_set_override() to
> - * set or clear it.
> *
> * This represents WMI devices discovered by the WMI driver core.
> */
> struct wmi_device {
> struct device dev;
> bool setable;
> - const char *driver_override;
> };
>
> /**
^ permalink raw reply
* [PATCH v4 5/5] watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
From: Thomas Perrot (Schneider Electric) @ 2026-03-24 19:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric)
In-Reply-To: <20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com>
Add watchdog driver for the Aaeon SRG-IMX8P embedded controller.
This driver provides system monitoring and recovery capabilities
through the MCU's watchdog timer.
The watchdog supports start, stop, and ping operations with a maximum
hardware heartbeat of 25 seconds and a default timeout of 240 seconds.
Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
MAINTAINERS | 1 +
drivers/watchdog/Kconfig | 10 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/aaeon_mcu_wdt.c | 134 +++++++++++++++++++++++++++++++++++++++
4 files changed, 146 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2538f8c4bc1482b139e18243a68f0a21b9be3704..7b92af42c9fdc17a69a4e7a2fe50f9e199c8b144 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -193,6 +193,7 @@ S: Maintained
F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
F: drivers/gpio/gpio-aaeon-mcu.c
F: drivers/mfd/aaeon-mcu.c
+F: drivers/watchdog/aaeon_mcu_wdt.c
F: include/linux/mfd/aaeon-mcu.h
AAEON UPBOARD FPGA MFD DRIVER
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d3b9df7d466b0b7215ee87b3040811d44ee53d2a..da54e6a641d7af343e4f0ae84f96f150979f8348 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -168,6 +168,16 @@ config SOFT_WATCHDOG_PRETIMEOUT
watchdog. Be aware that governors might affect the watchdog because it
is purely software, e.g. the panic governor will stall it!
+config AAEON_MCU_WATCHDOG
+ tristate "Aaeon MCU Watchdog"
+ depends on MFD_AAEON_MCU
+ select WATCHDOG_CORE
+ help
+ Select this option to enable watchdog timer support for the Aaeon
+ SRG-IMX8P onboard microcontroller (MCU). This driver provides
+ watchdog functionality through the MCU, allowing system monitoring
+ and automatic recovery from system hangs.
+
config BD957XMUF_WATCHDOG
tristate "ROHM BD9576MUF and BD9573MUF PMIC Watchdog"
depends on MFD_ROHM_BD957XMUF
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index ba52099b125398a32f80dad23317e223cc4af028..2deec425d3eafb6b208e061fda9f216f4baa8ecc 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
# ALPHA Architecture
# ARM Architecture
+obj-$(CONFIG_AAEON_MCU_WATCHDOG) += aaeon_mcu_wdt.o
obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
obj-$(CONFIG_ARMADA_37XX_WATCHDOG) += armada_37xx_wdt.o
diff --git a/drivers/watchdog/aaeon_mcu_wdt.c b/drivers/watchdog/aaeon_mcu_wdt.c
new file mode 100644
index 0000000000000000000000000000000000000000..f01571cf0036d252f9bebd3a9d6a1c2e7a83e42c
--- /dev/null
+++ b/drivers/watchdog/aaeon_mcu_wdt.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Aaeon MCU Watchdog driver
+ *
+ * Copyright (C) 2025 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#include <linux/mfd/aaeon-mcu.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/watchdog.h>
+
+#define AAEON_MCU_CONTROL_WDT 0x63
+#define AAEON_MCU_PING_WDT 0x73
+
+#define AAEON_MCU_WDT_TIMEOUT 240
+#define AAEON_MCU_WDT_HEARTBEAT_MS 25000
+
+struct aaeon_mcu_wdt {
+ struct watchdog_device wdt;
+ struct regmap *regmap;
+};
+
+static int aaeon_mcu_wdt_cmd(struct aaeon_mcu_wdt *data, u8 opcode, u8 arg)
+{
+ /* The MCU always sends a response byte after each command; discard it. */
+ return regmap_write(data->regmap, AAEON_MCU_REG(opcode, arg), 0);
+}
+
+static int aaeon_mcu_wdt_start(struct watchdog_device *wdt)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+
+ return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT, 0x01);
+}
+
+static int aaeon_mcu_wdt_status(struct watchdog_device *wdt, bool *enabled)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+ unsigned int rsp;
+ int ret;
+
+ ret = regmap_read(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT, 0x02),
+ &rsp);
+ if (ret)
+ return ret;
+
+ *enabled = rsp == 0x01;
+ return 0;
+}
+
+static int aaeon_mcu_wdt_stop(struct watchdog_device *wdt)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+
+ return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT, 0x00);
+}
+
+static int aaeon_mcu_wdt_ping(struct watchdog_device *wdt)
+{
+ struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
+
+ return aaeon_mcu_wdt_cmd(data, AAEON_MCU_PING_WDT, 0x00);
+}
+
+static const struct watchdog_info aaeon_mcu_wdt_info = {
+ .identity = "Aaeon MCU Watchdog",
+ .options = WDIOF_KEEPALIVEPING
+};
+
+static const struct watchdog_ops aaeon_mcu_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = aaeon_mcu_wdt_start,
+ .stop = aaeon_mcu_wdt_stop,
+ .ping = aaeon_mcu_wdt_ping,
+};
+
+static int aaeon_mcu_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct watchdog_device *wdt;
+ struct aaeon_mcu_wdt *data;
+ bool enabled;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->regmap = dev_get_regmap(dev->parent, NULL);
+ if (!data->regmap)
+ return -ENODEV;
+
+ wdt = &data->wdt;
+ wdt->parent = dev;
+ wdt->info = &aaeon_mcu_wdt_info;
+ wdt->ops = &aaeon_mcu_wdt_ops;
+ /*
+ * The MCU firmware has a fixed hardware timeout of 25 seconds that
+ * cannot be changed. The watchdog core will handle automatic pinging
+ * to support longer timeouts. The software timeout of 240 seconds is
+ * chosen arbitrarily as a reasonable value and is not user-configurable.
+ */
+ wdt->timeout = AAEON_MCU_WDT_TIMEOUT;
+ wdt->max_hw_heartbeat_ms = AAEON_MCU_WDT_HEARTBEAT_MS;
+
+ watchdog_set_drvdata(wdt, data);
+
+ ret = aaeon_mcu_wdt_status(wdt, &enabled);
+ if (ret)
+ return ret;
+
+ if (enabled)
+ set_bit(WDOG_HW_RUNNING, &wdt->status);
+
+ return devm_watchdog_register_device(dev, wdt);
+}
+
+static struct platform_driver aaeon_mcu_wdt_driver = {
+ .driver = {
+ .name = "aaeon-mcu-wdt",
+ },
+ .probe = aaeon_mcu_wdt_probe,
+};
+
+module_platform_driver(aaeon_mcu_wdt_driver);
+
+MODULE_DESCRIPTION("Aaeon MCU Watchdog Driver");
+MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 05/13] wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
From: Sean Wang @ 2026-03-24 19:24 UTC (permalink / raw)
To: Javier Tia
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno, Deren Wu,
Ming Yen Hsieh, linux-wireless, linux-kernel, linux-arm-kernel,
linux-mediatek, Marcin FM, Cristian-Florin Radoi,
George Salukvadze, Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld,
Chapuis Dario, Thibaut François, 张旭涵
In-Reply-To: <20260319-mt7927-wifi-support-v2-v2-5-d627a7fad70d@jetm.me>
Hi,
On Thu, Mar 19, 2026 at 5:26 PM Javier Tia <floss@jetm.me> wrote:
>
> mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80
> and BW = 160, but never sets BW = 320. This means iw phy shows no
> 320MHz MCS map entries even though the hardware supports 320MHz
> operation in the 6GHz band.
>
> Add the missing 320MHz capability bits for 6GHz, following the same
> pattern as mt7996:
> - PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ
> - PHY_CAP1: beamformee SS for 320MHz
> - PHY_CAP2: sounding dimensions for 320MHz
> - PHY_CAP6: MCS15 support for 320MHz width
> - PHY_CAP7: non-OFDMA UL MU-MIMO and MU beamformer for 320MHz
> - MCS/NSS: populate bw._320 maps for 6GHz band
>
> Introduce is_320mhz_supported() as a generic capability check using the
> mt7925 family ID. This avoids chip-specific references in common code,
> and automatically extends to new chips once they join the
> is_mt7925() family via chip ID helpers.
>
> Tested-by: Marcin FM <marcin@lgic.pl>
> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
> Tested-by: George Salukvadze <giosal90@gmail.com>
> Tested-by: Evgeny Kapusta <3193631@gmail.com>
> Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
> Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
> Tested-by: Thibaut François <tibo@humeurlibre.fr>
> Tested-by: 张旭涵 <Loong.0x00@gmail.com>
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> drivers/net/wireless/mediatek/mt76/mt76_connac.h | 5 +++++
> drivers/net/wireless/mediatek/mt76/mt7925/main.c | 28 +++++++++++++++++++++++-
> 2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
> index 813d61bffc2c..554716e01ee6 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
> @@ -177,6 +177,11 @@ static inline bool is_mt7925(struct mt76_dev *dev)
> return mt76_chip(dev) == 0x7925;
> }
>
> +static inline bool is_320mhz_supported(struct mt76_dev *dev)
> +{
> + return is_mt7925(dev);
I don't think this is correct for mt7925, and it will cause a
regression there. Was this tested on actual mt7925 hardware?
> +}
> +
> static inline bool is_mt7920(struct mt76_dev *dev)
> {
> return mt76_chip(dev) == 0x7920;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> index f128a198f81d..cd043ac266fb 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> @@ -183,6 +183,10 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMER |
> IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMEE;
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[0] |=
> + IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
> +
> eht_cap_elem->phy_cap_info[0] |=
> u8_encode_bits(u8_get_bits(sts - 1, BIT(0)),
> IEEE80211_EHT_PHY_CAP0_BEAMFORMEE_SS_80MHZ_MASK);
> @@ -193,10 +197,20 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> u8_encode_bits(sts - 1,
> IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_160MHZ_MASK);
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[1] |=
> + u8_encode_bits(sts - 1,
> + IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK);
> +
> eht_cap_elem->phy_cap_info[2] =
> u8_encode_bits(sts - 1, IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_80MHZ_MASK) |
> u8_encode_bits(sts - 1, IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_160MHZ_MASK);
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[2] |=
> + u8_encode_bits(sts - 1,
> + IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK);
> +
> eht_cap_elem->phy_cap_info[3] =
> IEEE80211_EHT_PHY_CAP3_NG_16_SU_FEEDBACK |
> IEEE80211_EHT_PHY_CAP3_NG_16_MU_FEEDBACK |
> @@ -217,7 +231,8 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> u8_encode_bits(u8_get_bits(0x11, GENMASK(1, 0)),
> IEEE80211_EHT_PHY_CAP5_MAX_NUM_SUPP_EHT_LTF_MASK);
>
> - val = width == NL80211_CHAN_WIDTH_160 ? 0x7 :
> + val = width == NL80211_CHAN_WIDTH_320 ? 0xf :
> + width == NL80211_CHAN_WIDTH_160 ? 0x7 :
> width == NL80211_CHAN_WIDTH_80 ? 0x3 : 0x1;
> eht_cap_elem->phy_cap_info[6] =
> u8_encode_bits(u8_get_bits(0x11, GENMASK(4, 2)),
> @@ -230,6 +245,11 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_80MHZ |
> IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_160MHZ;
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[7] |=
> + IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ |
> + IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ;
> +
I don't think this should be copied from mt7996 as-is for mt7927. I'd
suggest dropping the eht_cap_elem->phy_cap_info[7] change and keeping
it conservative for now.
> val = u8_encode_bits(nss, IEEE80211_EHT_MCS_NSS_RX) |
> u8_encode_bits(nss, IEEE80211_EHT_MCS_NSS_TX);
>
> @@ -239,6 +259,12 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> eht_nss->bw._160.rx_tx_mcs9_max_nss = val;
> eht_nss->bw._160.rx_tx_mcs11_max_nss = val;
> eht_nss->bw._160.rx_tx_mcs13_max_nss = val;
> +
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76)) {
> + eht_nss->bw._320.rx_tx_mcs9_max_nss = val;
> + eht_nss->bw._320.rx_tx_mcs11_max_nss = val;
> + eht_nss->bw._320.rx_tx_mcs13_max_nss = val;
> + }
> }
>
> int mt7925_init_mlo_caps(struct mt792x_phy *phy)
>
> --
> 2.53.0
>
>
^ permalink raw reply
* [PATCH v4 4/5] gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU
From: Thomas Perrot (Schneider Electric) @ 2026-03-24 19:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Bartosz Golaszewski
In-Reply-To: <20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com>
Add GPIO driver for the Aaeon SRG-IMX8P embedded controller. This
driver supports 7 GPO (General Purpose Output) pins and 12 GPIO pins
that can be configured as inputs or outputs.
The driver implements proper state management for GPO pins (which are
output-only) and full direction control for GPIO pins. During probe,
all pins are reset to a known state (GPOs low, GPIOs as inputs) to
prevent undefined behavior across system reboots, as the MCU does not
reset GPIO states on soft reboot.
Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
MAINTAINERS | 1 +
drivers/gpio/Kconfig | 10 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-aaeon-mcu.c | 221 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 233 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f91b6a1826d04bef8a0f88221f6c8e8a3652cd77..2538f8c4bc1482b139e18243a68f0a21b9be3704 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -191,6 +191,7 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
S: Maintained
F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
+F: drivers/gpio/gpio-aaeon-mcu.c
F: drivers/mfd/aaeon-mcu.c
F: include/linux/mfd/aaeon-mcu.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c74da29253e810b51540684b1186e8f274066b69..04285dc77430a5dbdb2d6e03e51bca64a432bf1a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -157,6 +157,16 @@ config GPIO_74XX_MMIO
8 bits: 74244 (Input), 74273 (Output)
16 bits: 741624 (Input), 7416374 (Output)
+config GPIO_AAEON_MCU
+ tristate "Aaeon MCU GPIO support"
+ depends on MFD_AAEON_MCU
+ select GPIO_GENERIC
+ help
+ Select this option to enable GPIO support for the Aaeon SRG-IMX8P
+ onboard MCU. This driver provides access to GPIO pins and GPO
+ (General Purpose Output) pins controlled by the microcontroller.
+ The driver handles both input and output configuration.
+
config GPIO_ALTERA
tristate "Altera GPIO"
select GPIOLIB_IRQCHIP
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 2421a8fd3733e0b06c2581262aaa9cd629f66c7d..1ba6318bc558743fbe5910966c2c8fc3f792efe9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_GPIO_104_IDI_48) += gpio-104-idi-48.o
obj-$(CONFIG_GPIO_104_IDIO_16) += gpio-104-idio-16.o
obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
obj-$(CONFIG_GPIO_74XX_MMIO) += gpio-74xx-mmio.o
+obj-$(CONFIG_GPIO_AAEON_MCU) += gpio-aaeon-mcu.o
obj-$(CONFIG_GPIO_ADNP) += gpio-adnp.o
obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
obj-$(CONFIG_GPIO_ADP5585) += gpio-adp5585.o
diff --git a/drivers/gpio/gpio-aaeon-mcu.c b/drivers/gpio/gpio-aaeon-mcu.c
new file mode 100644
index 0000000000000000000000000000000000000000..3b679259a6c66e3113cadc083dc7b4152d070ed5
--- /dev/null
+++ b/drivers/gpio/gpio-aaeon-mcu.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Aaeon MCU GPIO driver
+ *
+ * Copyright (C) 2025 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/gpio/driver.h>
+#include <linux/mfd/aaeon-mcu.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define AAEON_MCU_CONFIG_GPIO_INPUT 0x69
+#define AAEON_MCU_CONFIG_GPIO_OUTPUT 0x6F
+#define AAEON_MCU_READ_GPIO 0x72
+#define AAEON_MCU_WRITE_GPIO 0x77
+
+#define AAEON_MCU_CONTROL_GPO 0x6C
+
+#define MAX_GPIOS 12
+#define MAX_GPOS 7
+
+struct aaeon_mcu_gpio {
+ struct gpio_chip gc;
+ struct regmap *regmap;
+ DECLARE_BITMAP(dir_in, MAX_GPOS + MAX_GPIOS);
+ DECLARE_BITMAP(gpo_state, MAX_GPOS);
+};
+
+static int aaeon_mcu_gpio_config_input_cmd(struct aaeon_mcu_gpio *data,
+ unsigned int offset)
+{
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONFIG_GPIO_INPUT, offset - 7),
+ 0);
+}
+
+static int aaeon_mcu_gpio_direction_input(struct gpio_chip *gc, unsigned int offset)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ int ret;
+
+ if (offset < MAX_GPOS) {
+ dev_err(gc->parent, "GPIO offset (%d) must be an output GPO\n", offset);
+ return -EOPNOTSUPP;
+ }
+
+ ret = aaeon_mcu_gpio_config_input_cmd(data, offset);
+ if (ret < 0)
+ return ret;
+
+ __set_bit(offset, data->dir_in);
+
+ return 0;
+}
+
+static int aaeon_mcu_gpio_config_output_cmd(struct aaeon_mcu_gpio *data,
+ unsigned int offset,
+ int value)
+{
+ int ret;
+
+ ret = regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONFIG_GPIO_OUTPUT, offset - 7),
+ 0);
+ if (ret < 0)
+ return ret;
+
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_WRITE_GPIO, offset - 7),
+ !!value);
+}
+
+static int aaeon_mcu_gpio_direction_output(struct gpio_chip *gc, unsigned int offset, int value)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ int ret;
+
+ if (offset < MAX_GPOS)
+ return 0;
+
+ ret = aaeon_mcu_gpio_config_output_cmd(data, offset, value);
+ if (ret < 0)
+ return ret;
+
+ __clear_bit(offset, data->dir_in);
+
+ return 0;
+}
+
+static int aaeon_mcu_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+
+ return test_bit(offset, data->dir_in) ?
+ GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
+}
+
+static int aaeon_mcu_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+ unsigned int rsp;
+ int ret;
+
+ if (offset < MAX_GPOS)
+ return test_bit(offset, data->gpo_state);
+
+ ret = regmap_read(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_READ_GPIO, offset - 7),
+ &rsp);
+ if (ret < 0)
+ return ret;
+
+ return rsp;
+}
+
+static int aaeon_mcu_gpo_set_cmd(struct aaeon_mcu_gpio *data, unsigned int offset, int value)
+{
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_CONTROL_GPO, offset + 1),
+ !!value);
+}
+
+static int aaeon_mcu_gpio_set_cmd(struct aaeon_mcu_gpio *data, unsigned int offset, int value)
+{
+ return regmap_write(data->regmap,
+ AAEON_MCU_REG(AAEON_MCU_WRITE_GPIO, offset - 7),
+ !!value);
+}
+
+static int aaeon_mcu_gpio_set(struct gpio_chip *gc, unsigned int offset,
+ int value)
+{
+ struct aaeon_mcu_gpio *data = gpiochip_get_data(gc);
+
+ if (offset >= MAX_GPOS)
+ return aaeon_mcu_gpio_set_cmd(data, offset, value);
+
+ if (aaeon_mcu_gpo_set_cmd(data, offset, value) == 0)
+ __assign_bit(offset, data->gpo_state, value);
+
+ return 0;
+}
+
+static const struct gpio_chip aaeon_mcu_chip = {
+ .label = "gpio-aaeon-mcu",
+ .owner = THIS_MODULE,
+ .get_direction = aaeon_mcu_gpio_get_direction,
+ .direction_input = aaeon_mcu_gpio_direction_input,
+ .direction_output = aaeon_mcu_gpio_direction_output,
+ .get = aaeon_mcu_gpio_get,
+ .set = aaeon_mcu_gpio_set,
+ .base = -1,
+ .ngpio = MAX_GPOS + MAX_GPIOS,
+ .can_sleep = true,
+};
+
+static void aaeon_mcu_gpio_reset(struct aaeon_mcu_gpio *data, struct device *dev)
+{
+ unsigned int i;
+ int ret;
+
+ /* Reset all GPOs */
+ for (i = 0; i < MAX_GPOS; i++) {
+ ret = aaeon_mcu_gpo_set_cmd(data, i, 0);
+ if (ret < 0)
+ dev_warn(dev, "Failed to reset GPO %u state: %d\n", i, ret);
+ __clear_bit(i, data->dir_in);
+ }
+
+ /* Reset all GPIOs */
+ for (i = MAX_GPOS; i < MAX_GPOS + MAX_GPIOS; i++) {
+ ret = aaeon_mcu_gpio_config_input_cmd(data, i);
+ if (ret < 0)
+ dev_warn(dev, "Failed to reset GPIO %u state: %d\n", i, ret);
+ __set_bit(i, data->dir_in);
+ }
+}
+
+static int aaeon_mcu_gpio_probe(struct platform_device *pdev)
+{
+ struct aaeon_mcu_gpio *data;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!data->regmap)
+ return -ENODEV;
+
+ data->gc = aaeon_mcu_chip;
+ data->gc.parent = pdev->dev.parent;
+
+ /*
+ * Reset all GPIO states to a known configuration. The MCU does not
+ * reset GPIO state on soft reboot, only on power cycle (hard reboot).
+ * Without this reset, GPIOs would retain their previous state across
+ * reboots, which could lead to unexpected behavior.
+ */
+ aaeon_mcu_gpio_reset(data, &pdev->dev);
+
+ return devm_gpiochip_add_data(&pdev->dev, &data->gc, data);
+}
+
+static struct platform_driver aaeon_mcu_gpio_driver = {
+ .driver = {
+ .name = "aaeon-mcu-gpio",
+ },
+ .probe = aaeon_mcu_gpio_probe,
+};
+module_platform_driver(aaeon_mcu_gpio_driver);
+
+MODULE_DESCRIPTION("GPIO interface for Aaeon MCU");
+MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/5] mfd: aaeon: Add SRG-IMX8P MCU driver
From: Thomas Perrot (Schneider Electric) @ 2026-03-24 19:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric)
In-Reply-To: <20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com>
Add Multi-Function Device (MFD) driver for the Aaeon SRG-IMX8P
embedded controller. This driver provides the core I2C communication
interface and registers child devices (GPIO and watchdog controllers).
The driver implements a custom regmap bus over I2C to match the MCU's
fixed 3-byte command format [opcode, arg, value]. Register addresses
are encoded as 16-bit values (opcode << 8 | arg) using the
AAEON_MCU_REG() macro defined in the shared header. The regmap
instance is shared with child drivers via dev_get_regmap(). Concurrent
I2C accesses from child drivers are serialized by regmap's built-in
locking.
Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
MAINTAINERS | 2 +
drivers/mfd/Kconfig | 10 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/aaeon-mcu.c | 155 ++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/aaeon-mcu.h | 20 ++++++
5 files changed, 188 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea9d55f76f3509c7f6ba6d1bc86ca2e2e71aa954..f91b6a1826d04bef8a0f88221f6c8e8a3652cd77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -191,6 +191,8 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
S: Maintained
F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
+F: drivers/mfd/aaeon-mcu.c
+F: include/linux/mfd/aaeon-mcu.h
AAEON UPBOARD FPGA MFD DRIVER
M: Thomas Richard <thomas.richard@bootlin.com>
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index aace5766b38aa5e46e32a8a7b42eea238159fbcf..7a1ceedece899faad7a03a1fe7b1c91b72253c05 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1574,6 +1574,16 @@ config AB8500_CORE
the irq_chip parts for handling the Mixed Signal chip events.
This chip embeds various other multimedia functionalities as well.
+config MFD_AAEON_MCU
+ tristate "Aaeon SRG-IMX8P MCU Driver"
+ depends on I2C || COMPILE_TEST
+ select MFD_CORE
+ help
+ Select this option to enable support for the Aaeon SRG-IMX8P
+ onboard microcontroller (MCU). This driver provides the core
+ functionality to communicate with the MCU over I2C. The MCU
+ provides GPIO and watchdog functionality.
+
config MFD_DB8500_PRCMU
bool "ST-Ericsson DB8500 Power Reset Control Management Unit"
depends on UX500_SOC_DB8500
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e75e8045c28afae975ac61d282b3b85af5440119..34db5b033584368b7a269b1eef12528a74baf8f5 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
+obj-$(CONFIG_MFD_AAEON_MCU) += aaeon-mcu.o
obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
obj-$(CONFIG_MFD_SM501) += sm501.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
diff --git a/drivers/mfd/aaeon-mcu.c b/drivers/mfd/aaeon-mcu.c
new file mode 100644
index 0000000000000000000000000000000000000000..5a969890d201c027eb25c324b4d4d89b1f8c563e
--- /dev/null
+++ b/drivers/mfd/aaeon-mcu.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Aaeon MCU driver
+ *
+ * Copyright (C) 2025 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+static const struct mfd_cell aaeon_mcu_devs[] = {
+ {
+ .name = "aaeon-mcu-wdt",
+ },
+ {
+ .name = "aaeon-mcu-gpio",
+ },
+};
+
+/*
+ * Custom regmap bus for the Aaeon MCU I2C protocol.
+ *
+ * The MCU uses a fixed 3-byte command format [opcode, arg, value] followed
+ * by a 1-byte response. It requires a STOP condition between the command
+ * write and the response read, so two separate i2c_transfer() calls are
+ * issued. The regmap lock serialises concurrent accesses from the GPIO
+ * and watchdog child drivers.
+ *
+ * Register addresses are encoded as a 16-bit big-endian value where the
+ * high byte is the opcode and the low byte is the argument, matching the
+ * wire layout produced by regmap for reg_bits=16.
+ */
+
+static int aaeon_mcu_regmap_write(void *context, const void *data, size_t count)
+{
+ struct i2c_client *client = context;
+ /* data = [opcode, arg, value] as formatted by regmap */
+ struct i2c_msg write_msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .buf = (u8 *)data,
+ .len = count,
+ };
+ u8 rsp;
+ /* The MCU always sends a response byte after each command; discard it. */
+ struct i2c_msg rsp_msg = {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .buf = &rsp,
+ .len = 1,
+ };
+ int ret;
+
+ ret = i2c_transfer(client->adapter, &write_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ ret = i2c_transfer(client->adapter, &rsp_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return 0;
+}
+
+static int aaeon_mcu_regmap_read(void *context, const void *reg_buf,
+ size_t reg_size, void *val_buf, size_t val_size)
+{
+ struct i2c_client *client = context;
+ /*
+ * reg_buf holds the 2-byte big-endian register address [opcode, arg].
+ * Append a trailing 0x00 to form the full 3-byte MCU command.
+ */
+ u8 cmd[3] = { ((u8 *)reg_buf)[0], ((u8 *)reg_buf)[1], 0x00 };
+ struct i2c_msg write_msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .buf = cmd,
+ .len = sizeof(cmd),
+ };
+ struct i2c_msg read_msg = {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .buf = val_buf,
+ .len = val_size,
+ };
+ int ret;
+
+ ret = i2c_transfer(client->adapter, &write_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ ret = i2c_transfer(client->adapter, &read_msg, 1);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return 0;
+}
+
+static const struct regmap_bus aaeon_mcu_regmap_bus = {
+ .write = aaeon_mcu_regmap_write,
+ .read = aaeon_mcu_regmap_read,
+};
+
+static const struct regmap_config aaeon_mcu_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+ .cache_type = REGCACHE_NONE,
+};
+
+static int aaeon_mcu_probe(struct i2c_client *client)
+{
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init(&client->dev, &aaeon_mcu_regmap_bus,
+ client, &aaeon_mcu_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
+ aaeon_mcu_devs, ARRAY_SIZE(aaeon_mcu_devs),
+ NULL, 0, NULL);
+}
+
+static const struct of_device_id aaeon_mcu_of_match[] = {
+ { .compatible = "aaeon,srg-imx8p-mcu" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, aaeon_mcu_of_match);
+
+static struct i2c_driver aaeon_mcu_driver = {
+ .driver = {
+ .name = "aaeon_mcu",
+ .of_match_table = aaeon_mcu_of_match,
+ },
+ .probe = aaeon_mcu_probe,
+};
+module_i2c_driver(aaeon_mcu_driver);
+
+MODULE_DESCRIPTION("Aaeon MCU Driver");
+MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/aaeon-mcu.h b/include/linux/mfd/aaeon-mcu.h
new file mode 100644
index 0000000000000000000000000000000000000000..861003f6dfd20424c3785008bd2cf89aaa1715b9
--- /dev/null
+++ b/include/linux/mfd/aaeon-mcu.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Aaeon MCU driver definitions
+ *
+ * Copyright (C) 2025 Bootlin
+ * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ * Author: Thomas Perrot <thomas.perrot@bootlin.com>
+ */
+
+#ifndef __LINUX_MFD_AAEON_MCU_H
+#define __LINUX_MFD_AAEON_MCU_H
+
+/*
+ * MCU register address: the high byte is the command opcode, the low
+ * byte is the argument. This matches the 3-byte wire format
+ * [opcode, arg, value] used by the MCU I2C protocol.
+ */
+#define AAEON_MCU_REG(op, arg) (((op) << 8) | (arg))
+
+#endif /* __LINUX_MFD_AAEON_MCU_H */
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: vendor-prefixes: Add AAEON vendor prefix
From: Thomas Perrot (Schneider Electric) @ 2026-03-24 19:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Krzysztof Kozlowski
In-Reply-To: <20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com>
Add the AAEON vendor prefix to support the AAEON SRG-IMX8P MCU driver
devicetree bindings.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index c7591b2aec2a74560a4f687fe7a2070ca21b0752..0f84ee93b3a8473719ee92f8c046e350c4a20825 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -32,6 +32,8 @@ patternProperties:
description: 8devices, UAB
"^9tripod,.*":
description: Shenzhen 9Tripod Innovation and Development CO., LTD.
+ "^aaeon,.*":
+ description: AAEON
"^abb,.*":
description: ABB
"^abilis,.*":
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: mfd: Add AAEON embedded controller
From: Thomas Perrot (Schneider Electric) @ 2026-03-24 19:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Conor Dooley
In-Reply-To: <20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com>
Add device tree binding documentation for the AAEON embedded controller
(MCU). This microcontroller is found on AAEON embedded boards, it is
connected via I2C and and provides a GPIO control and watchdog timer.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
.../bindings/mfd/aaeon,srg-imx8p-mcu.yaml | 67 ++++++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 73 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml b/Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..4895028e72eb3ac2376b61ed9c06549b42da66d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/aaeon,srg-imx8p-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AAEON Embedded Controller
+
+maintainers:
+ - Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+ - Thomas Perrot <thomas.perrot@bootlin.com>
+
+description:
+ AAEON embeds a microcontroller on Standard RISC Gateway with ARM i.MX8M Plus
+ Quad-Core boards providing GPIO control and watchdog timer.
+
+ This MCU is connected via I2C bus.
+
+ Its GPIO controller provides 7 GPOs and 12 GPIOs.
+
+ Its watchdog has a fixed maximum hardware heartbeat of 25 seconds and supports
+ a timeout of 240 seconds through automatic pinging.
+ The timeout is not programmable and cannot be changed via device tree properties.
+
+properties:
+ compatible:
+ const: aaeon,srg-imx8p-mcu
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 19
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@62 {
+ compatible = "aaeon,srg-imx8p-mcu";
+ reg = <0x62>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "gpo-1", "gpo-2", "gpo-3", "gpo-4",
+ "gpo-5", "gpo-6", "gpo-7",
+ "gpio-1", "gpio-2", "gpio-3", "gpio-4",
+ "gpio-5", "gpio-6", "gpio-7", "gpio-8",
+ "gpio-9", "gpio-10", "gpio-11", "gpio-12";
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c9e416ba74c64e90629c0b7d7941f879c9ac589e..ea9d55f76f3509c7f6ba6d1bc86ca2e2e71aa954 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -186,6 +186,12 @@ W: http://www.adaptec.com/
F: Documentation/scsi/aacraid.rst
F: drivers/scsi/aacraid/
+AAEON SRG-IMX8P CONTROLLER MFD DRIVER
+M: Thomas Perrot <thomas.perrot@bootlin.com>
+R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
+
AAEON UPBOARD FPGA MFD DRIVER
M: Thomas Richard <thomas.richard@bootlin.com>
S: Maintained
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/5] Add support for AAEON SRG-IMX8P MCU
From: Thomas Perrot (Schneider Electric) @ 2026-03-24 19:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Thomas Perrot (Schneider Electric), Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski
This patch series introduces support for the AAEON SRG-IMX8P embedded
controller (MCU). The MCU is connected via I2C and provides GPIO and
watchdog functionality for the SRG-IMX8P board.
The series includes:
- Device tree binding for the MFD driver
- MFD driver that serves as the core driver for the MCU
- GPIO driver implementing the GPIO functionality
- Watchdog driver for system monitoring
- MAINTAINERS entry for the new drivers
The drivers follow the standard Linux kernel subsystem patterns, with
the MFD driver registering the sub-devices (GPIO and watchdog) which
are then handled by their respective subsystem drivers.
Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
---
Changes in v4:
- mfd: switch to a custom regmap bus; remove aaeon_mcu_i2c_xfer() and the aaeon_mcu_dev struct
- mfd: locking delegated to regmap's built-in mutex; drop explicit mutex
- mfd: remove firmware version reading at probe time
- gpio, watchdog: use regmap_read()/regmap_write() via dev_get_regmap()
- include: replace aaeon_mcu_i2c_xfer() declaration with AAEON_MCU_REG() macro
- dt-bindings: remove unused label from example node
- Link to v3: https://lore.kernel.org/r/20260203-dev-b4-aaeon-mcu-driver-v3-0-0a19432076ac@bootlin.com
Changes in v3:
- Renamed SRG-IMX8PL to SRG-IMX8P
- dt-bindings: add gpio-controller properties as required
- mfd: move struct aaeon_mcu_dev from header to .c file (private)
- mfd: use guard(mutex) and devm_mutex_init() for cleanup
- mfd: firmware version log changed to dev_dbg()
- mfd: add select MFD_CORE to Kconfig
- Kconfig: add || COMPILE_TEST to all three drivers
- watchdog: add comments explaining hardware timeout and WDOG_HW_RUNNING
- watchdog: remove unused platform_set_drvdata()
- watchdog: add a function to query the status
- Link to v2: https://lore.kernel.org/r/20260123-dev-b4-aaeon-mcu-driver-v2-0-9f4c00bfb5cb@bootlin.com
Changes in v2:
- Fold GPIO and watchdog bindings into MFD binding
- Drop OF_GPIO dependency in GPIO Kconfig
- Use __set_bit/__clear_bit/__assign_bit instead of atomic variants
- Various driver cleanups and improvements
- Link to v1: https://lore.kernel.org/r/20251212-dev-b4-aaeon-mcu-driver-v1-0-6bd65bc8ef12@bootlin.com
---
Thomas Perrot (Schneider Electric) (5):
dt-bindings: vendor-prefixes: Add AAEON vendor prefix
dt-bindings: mfd: Add AAEON embedded controller
mfd: aaeon: Add SRG-IMX8P MCU driver
gpio: aaeon: Add GPIO driver for SRG-IMX8P MCU
watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
.../bindings/mfd/aaeon,srg-imx8p-mcu.yaml | 67 +++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 10 +
drivers/gpio/Kconfig | 10 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-aaeon-mcu.c | 221 +++++++++++++++++++++
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/aaeon-mcu.c | 155 +++++++++++++++
drivers/watchdog/Kconfig | 10 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/aaeon_mcu_wdt.c | 134 +++++++++++++
include/linux/mfd/aaeon-mcu.h | 20 ++
13 files changed, 642 insertions(+)
---
base-commit: d358e5254674b70f34c847715ca509e46eb81e6f
change-id: 20251211-dev-b4-aaeon-mcu-driver-e0e89ebf4afb
Best regards,
--
Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
^ permalink raw reply
* Re: [PATCH v4 0/2] Allow non-coherent video capture buffers on Rockchip ISP V1
From: Mikhail Rudenko @ 2026-03-24 19:12 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Dafna Hirschfeld, Laurent Pinchart, Mauro Carvalho Chehab,
Heiko Stuebner, Tomasz Figa, Marek Szyprowski, Hans Verkuil,
Sergey Senozhatsky, linux-media, linux-rockchip, linux-arm-kernel,
linux-kernel, Mauro Carvalho Chehab, stable
In-Reply-To: <acFkAPreOFBvoHid@zed>
Hi, Jacopo!
On 2026-03-23 at 17:03 +01, Jacopo Mondi <jacopo.mondi@ideasonboard.com> wrote:
> Hello
>
> On Mon, Mar 03, 2025 at 02:40:08PM +0300, Mikhail Rudenko wrote:
>> This small series adds support for non-coherent video capture buffers
>> on Rockchip ISP V1. Patch 1 fixes cache management for dmabuf's
>> allocated by dma-contig allocator. Patch 2 allows non-coherent
>> allocations on the rkisp1 capture queue. Some timing measurements are
>> provided in the commit message of patch 2.
>>
>> Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>
>
> I regularly get back to this series everytime I have to reason about
> the caching policies in vb2..
>
> Is there any reason why it didn't get in ?
My impression is that all the review comments were addressed, but these
patches somehow fell through the cracks. I can rebase and post v5 if any
maintainer is interested in picking it up.
>> ---
>> Changes in v4:
>> - rebase to media/next
>> - use `direction` instead of `buf->dma_dir` in dma_sync_sgtable_*
>> - Link to v3: https://lore.kernel.org/r/20250128-b4-rkisp-noncoherent-v3-0-baf39c997d2a@gmail.com
>>
>> Changes in v3:
>> - ignore skip_cache_sync_* flags in vb2_dc_dmabuf_ops_{begin,end}_cpu_access
>> - invalidate/flush kernel mappings as appropriate if they exist
>> - use dma_sync_sgtable_* instead of dma_sync_sg_*
>> - Link to v2: https://lore.kernel.org/r/20250115-b4-rkisp-noncoherent-v2-0-0853e1a24012@gmail.com
>>
>> Changes in v2:
>> - Fix vb2_dc_dmabuf_ops_{begin,end}_cpu_access() for non-coherent buffers.
>> - Add cache management timing information to patch 2 commit message.
>> - Link to v1: https://lore.kernel.org/r/20250102-b4-rkisp-noncoherent-v1-1-bba164f7132c@gmail.com
>>
>> ---
>> Mikhail Rudenko (2):
>> media: videobuf2: Fix dmabuf cache sync/flush in dma-contig
>> media: rkisp1: Allow non-coherent video capture buffers
>>
>> .../media/common/videobuf2/videobuf2-dma-contig.c | 22 ++++++++++++++++++++++
>> .../platform/rockchip/rkisp1/rkisp1-capture.c | 1 +
>> 2 files changed, 23 insertions(+)
>> ---
>> base-commit: b2c4bf0c102084e77ed1b12090d77a76469a6814
>> change-id: 20241231-b4-rkisp-noncoherent-ad6e7c7a68ba
>>
>> Best regards,
>> --
>> Mikhail Rudenko <mike.rudenko@gmail.com>
>>
>>
--
Best regards,
Mikhail Rudenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox