* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Paul Kocialkowski @ 2026-05-18 11:52 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260510201644.4143710-4-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11951 bytes --]
Hi Alexander,
Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
Just in case you missed it, there was a previous submission for this
board which wasn't followed up on.
I also have one of this board and wanted to respin support, but it looks
like you beat me to it :)
Thanks for working on this!
Please change the naming to "Baijie HelperBoard A133" and "Baijie A133
HelperBoard Core" to align with the vendor terminology and rename the
files as:
- sun50i-a133-helperboard.dts
- sun50i-a133-helperboard-core.dtsi
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> Add initial support for both the Helper and Core boards, including UART,
> PMU, eMMC, USB, Ethernet.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
>
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
>
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-a133-baije-core.dtsi | 162 ++++++++++++++++++
> .../allwinner/sun50i-a133-baijie-helper.dts | 94 ++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index d116864b6c2b..926dfa851100 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h64-remix-mini-pc.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-baijie-helper.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a133-liontron-h-a133l.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> new file mode 100644
> index 000000000000..65b094f30bf5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2025 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +#include "sun50i-a100-cpu-opp.dtsi"
> +
> +/{
You could add a model here while at it, even though it would generally
be overwritten.
> + compatible = "baijie,helper-a133-core",
> + "allwinner,sun50i-a100";
> +
> + aliases {
> + serial1 = &uart1; /* BT module */
Not sure this is reallyt useful.
> + };
You should add:
chosen {
stdout-path = "serial0:115200n8";
};
As well as the incoming 5v regulator:
reg_vcc5v: vcc5v {
compatible = "regulator-fixed";
regulator-name = "vcc-5v";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
> +&pio {
> + vcc-pb-supply = <®_dcdc1>;
> + vcc-pc-supply = <®_eldo1>;
> + vcc-pd-supply = <®_dcdc1>;
> + vcc-pe-supply = <®_dldo2>;
> + vcc-pf-supply = <®_dcdc1>;
> + vcc-pg-supply = <®_dldo1>;
> + vcc-ph-supply = <®_dcdc1>;
> +};
> +
> +&mmc2 {
mmc2 goes before pio (alphanum sorting).
> + vmmc-supply = <®_dcdc1>;
> + vqmmc-supply = <®_eldo1>;
> + cap-mmc-hw-reset;
> + non-removable;
> + bus-width = <8>;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + status = "okay";
You can add:
max-frequency = <100000000>;
cap-mmc-highspeed;
> +};
> +
> +&r_i2c0 {
> + status = "okay";
> +
> + axp803: pmic@34 {
> + compatible = "x-powers,axp803";
> + reg = <0x34>;
> + interrupt-parent = <&r_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
You can also add:
x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
aldoin-supply = <®_vcc5v>;
dldoin-supply = <®_vcc5v>;
eldoin-supply = <®_vcc5v>;
fldoin-supply = <®_dcdc5>;
vin1-supply = <®_vcc5v>;
vin2-supply = <®_vcc5v>;
vin3-supply = <®_vcc5v>;
vin4-supply = <®_vcc5v>;
vin5-supply = <®_vcc5v>;
vin6-supply = <®_vcc5v>;
> + };
> +};
> +
> +#include "axp803.dtsi"
> +
> +&ac_power_supply {
> + status = "okay";
> +};
> +
> +®_aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pll-avcc";
> +};
> +
> +®_aldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-dram-lpddr";
> +};
> +
> +®_aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pl";
> +};
> +
> +®_dcdc1 {
> + regulator-always-on;
> + regulator-min-microvolt = <1600000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-name = "vcc-3v3";
Should be:
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-name = "vcc-io-usb-pd-nand-3v3";
> +};
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
Should be:
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-cpu";
> +};
> +
> +®_dcdc3 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
> +};
DCDC3 is polyphased with DCDC2, so remove this one and add:
/* DCDC3 is polyphased with DCDC2 */
> +
> +®_dcdc4 {
> + regulator-always-on;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-sys";
Should be:
regulator-min-microvolt = <810000>;
regulator-max-microvolt = <990000>;
regulator-name = "vcc-usb-sys";
> +};
> +
> +®_dcdc5 {
> + regulator-always-on;
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1840000>;
> + regulator-name = "vcc-dram";
Should be:
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-name = "vcc-dram-2";
ALDO2 is the main DRAM supply, this is the second one.
> +};
> +
> +/* DCDC6 unused */
> +
> +®_dldo1 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pg";
> +};
> +
> +®_dldo2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-csi-pe";
> +};
> +
> +®_dldo3 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-name = "avdd-csi";
Should be:
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-name = "ldo-avdd-csi";
> +};
> +
> +®_dldo4 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-name = "ldo-avdd-csi";
> +};
You can add:
®_drivevbus {
regulator-name = "usb0-vbus";
status = "okay";
};
> +
> +®_eldo1 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-enable-ramp-delay = <1000>;
Should be:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-name = "vcc-pc-efuse-lvds-cpvin-mcsi";
> +};
> +
> +®_eldo2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1900000>;
Should be:
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
> + regulator-enable-ramp-delay = <1000>;
> + regulator-name = "dvdd-csi";
> +};
> +
> +/* ELDO3 unused */
> +
> +®_fldo1 {
> + regulator-always-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vdd-cpus-usb";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> new file mode 100644
> index 000000000000..ccbca5d0a40c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2025 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a133-baije-core.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/{
> + model = "HelperBoard A133";
> + compatible = "baijie,helper-a133",
> + "baijie,helper-a133-core",
> + "allwinner,sun50i-a100";
> +
> + aliases {
> + serial0 = &uart0;
The is best added to the core dtsi.
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
Ditto.
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led {
> + function = LED_FUNCTION_INDICATOR;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 7 13 GPIO_ACTIVE_LOW>; /* PH13 */
> + };
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdc1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
You can add:
disable-wp;
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pb_pins>;
> + status = "okay";
> +};
> +
> +&rgmii0_pins {
> + drive-strength = <30>;
> +};
Sorting is also incorrect throughout the file, please use alphanum
sorting for phandle-based overwrites.
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii0_pins>;
> + phy-handle = <ð_phy>;
> + phy-mode = "rgmii-id";
> + allwinner,rx-delay-ps = <200>;
> + allwinner,tx-delay-ps = <200>;
> + status = "okay";
> +};
> +
> +&mdio0 {
> + reset-gpios = <&pio 7 11 GPIO_ACTIVE_LOW>; /* PH11 */
> + reset-delay-us = <10000>;
> + reset-post-delay-us = <150000>;
> +
> + eth_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> +&usbphy {
> + status = "okay";
You can add:
usb0_vbus-supply = <®_dcdc1>;
usb1_vbus-supply = <®_dcdc4>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
AFAIK there is no ID pin so ehci0/ohci0 will not be used.
It seems that version 1.7 of the board used PH0 as USB0 ID pin but
version 2.5 has reassigned PH8 to LCD reset.
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> --
> 2.54.0
>
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] media: s5p-jpeg: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 11:52 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, Jacek Anaszewski, Sylwester Nawrocki,
Mauro Carvalho Chehab, linux-arm-kernel, linux-media,
linux-kernel
Cc: Guangshuo Li
s5p_jpeg_probe() allocates encoder and decoder video_devices with
video_device_alloc() and releases them if video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
s5p_jpeg_probe()
-> video_device_release(jpeg->vfd_encoder)
The same issue exists for jpeg->vfd_decoder.
Use video_device_release_empty() while registering the devices so that
registration failure paths do not free them through vdev->release().
s5p_jpeg_probe() then releases the failed video_device exactly once.
Restore video_device_release() after successful registration so the
registered devices keep their normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 7a1d4e7c064c ("[media] s5p-jpeg: Eliminate double kfree()")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c b/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c
index fdc9d7e0be66..046ad555c5fc 100644
--- a/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/samsung/s5p-jpeg/jpeg-core.c
@@ -2915,7 +2915,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
jpeg->vfd_encoder->fops = &s5p_jpeg_fops;
jpeg->vfd_encoder->ioctl_ops = &s5p_jpeg_ioctl_ops;
jpeg->vfd_encoder->minor = -1;
- jpeg->vfd_encoder->release = video_device_release;
+ jpeg->vfd_encoder->release = video_device_release_empty;
jpeg->vfd_encoder->lock = &jpeg->lock;
jpeg->vfd_encoder->v4l2_dev = &jpeg->v4l2_dev;
jpeg->vfd_encoder->vfl_dir = VFL_DIR_M2M;
@@ -2927,6 +2927,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
video_device_release(jpeg->vfd_encoder);
goto m2m_init_rollback;
}
+ jpeg->vfd_encoder->release = video_device_release;
video_set_drvdata(jpeg->vfd_encoder, jpeg);
v4l2_info(&jpeg->v4l2_dev,
@@ -2945,7 +2946,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
jpeg->vfd_decoder->fops = &s5p_jpeg_fops;
jpeg->vfd_decoder->ioctl_ops = &s5p_jpeg_ioctl_ops;
jpeg->vfd_decoder->minor = -1;
- jpeg->vfd_decoder->release = video_device_release;
+ jpeg->vfd_decoder->release = video_device_release_empty;
jpeg->vfd_decoder->lock = &jpeg->lock;
jpeg->vfd_decoder->v4l2_dev = &jpeg->v4l2_dev;
jpeg->vfd_decoder->vfl_dir = VFL_DIR_M2M;
@@ -2957,6 +2958,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
video_device_release(jpeg->vfd_decoder);
goto enc_vdev_register_rollback;
}
+ jpeg->vfd_decoder->release = video_device_release;
video_set_drvdata(jpeg->vfd_decoder, jpeg);
v4l2_info(&jpeg->v4l2_dev,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: anacapa: add interrupt properties for PDB PCA9555
From: Andrew Jeffery @ 2026-05-18 11:48 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Rex Fu
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260417-anacapa-pca9555-irq-v1-1-9a6d28b1b656@amd.com>
On Fri, 17 Apr 2026 14:41:49 +0800, Rex Fu wrote:
> Add interrupt-parent and interrupts properties to the PDB PCA9555
> nodes in the anacapa DTS.
Thanks, I've applied this to the BMC tree.
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply
* Re: [PATCH v1 2/7] ARM: dts: aspeed: system1: Enable video engine
From: Andrew Jeffery @ 2026-05-18 11:38 UTC (permalink / raw)
To: Ninad Palsule, eajames, robh, krzk+dt, conor+dt, joel, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Manojkiran Eda
In-Reply-To: <20260421224551.1611818-3-ninad@linux.ibm.com>
On Tue, 2026-04-21 at 17:45 -0500, Ninad Palsule wrote:
> From: Manojkiran Eda <manojkiran.eda@gmail.com>
>
> This patch enables the aspeed video engine support in ASPEED BMC for
> IBM System1. It is crucial for facilitating the BMC's video capture
> and redirection capabilities, which are integral to remote management
> and KVM (Keyboard-Video-Mouse) over IP functionality.
This is a real nitpick, but: The commit message seems a bit too
grandiose for my tastes. Can you make it more succinct? Writing in
imperative mood to avoid "this patch" is generally recommended too:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
Andrew
>
> Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
> Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 488d0b3916a1..0ca799893791 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -531,6 +531,10 @@ &lpc_snoop {
> snoop-ports = <0x80>, <0x81>;
> };
>
> +&video {
> + status = "okay";
> +};
> +
> &i2c0 {
> status = "okay";
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
From: Paul Kocialkowski @ 2026-05-18 11:36 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel, Conor Dooley
In-Reply-To: <20260510201644.4143710-2-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
Hi,
Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Shenzhen Baijie Technology Co., Ltd. focuses on R&D and production of
> embedded products as well as customization of embedded solutions.
>
> Link: https://szbaijie.com/
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
All the best,
Paul
> ---
> 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 28784d66ae7b..095cf654787f 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -229,6 +229,8 @@ patternProperties:
> description: Azoteq (Pty) Ltd
> "^azw,.*":
> description: Shenzhen AZW Technology Co., Ltd.
> + "^baijie,.*":
> + description: Shenzhen Baijie Technology Co., Ltd.
> "^baikal,.*":
> description: BAIKAL ELECTRONICS, JSC
> "^bananapi,.*":
> --
> 2.54.0
>
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
From: Paul Kocialkowski @ 2026-05-18 11:35 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sunxi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Andre Przywara,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260510201644.4143710-3-alexander.sverdlin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
Hi Alexander,
Le Sun 10 May 26, 22:16, Alexander Sverdlin a écrit :
> Baijie HelperBoard A133 is a development board around their A133 Core
> board. Introduce a compatible for both the Core and the development
> boards.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
>
> Changelog:
> v2:
> - introduced baijie,helper-a133-core compatible for the Core (SoM) board
>
> Documentation/devicetree/bindings/arm/sunxi.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index e6443c266fa1..d7b9dec81165 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -96,6 +96,17 @@ properties:
> - const: allwinner,ba10-tvbox
> - const: allwinner,sun4i-a10
>
> + - description: Baijie Helper A133
Please use the correct naming from the vendor, which is: "Baijie
A133 HelperBoard"
> + items:
> + - const: baijie,helper-a133
Please make this: "baijie,helperboard-a133"
> + - const: baijie,helper-a133-core
Please make this: "baijie,helperboard-a133-core"
Thanks!
> + - const: allwinner,sun50i-a100
> +
> + - description: HelperBoardA133 Core
> + items:
> + - const: baijie,helper-a133-core
> + - const: allwinner,sun50i-a100
> +
> - description: BananaPi
> items:
> - const: lemaker,bananapi
> --
> 2.54.0
>
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 7/7] ARM: dts: aspeed: system1: DTS updates
From: Andrew Jeffery @ 2026-05-18 11:34 UTC (permalink / raw)
To: Ninad Palsule, eajames, robh, krzk+dt, conor+dt, joel, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260421224551.1611818-8-ninad@linux.ibm.com>
Hi Ninad,
On Tue, 2026-04-21 at 17:45 -0500, Ninad Palsule wrote:
> - Removed SGPIO node as not in use anymore.
> - Updated chassis power related pins as per the new hardware design
Can you please take a look at the discussion in the thread linked
below, and consider some of the approaches outlined there?
https://lore.kernel.org/all/d7794f74b26bbc1ee0a70e39c5671acc018f80eb.camel@codeconstruct.com.au/
I'd like to avoid a stream of backwards-incompatible changes due to
platform design changes where we can.
Andrew
>
> Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> index 91c317267d6b..d7a934fe5860 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
> @@ -424,7 +424,7 @@ &pinctrl_gpiol6_unbiased
> /*E0-E7*/ "","","","","","","","",
> /*F0-F7*/ "","","","","","","","",
> /*G0-G7*/ "","","","","","","","",
> - /*H0-H7*/ "","","","","","","","",
> + /*H0-H7*/ "power-chassis-good","power-chassis-reboot","","","","","","",
> /*I0-I7*/ "","","","","","","","",
> /*J0-J7*/ "","","","","","","","",
> /*K0-K7*/ "","","","","","","","",
> @@ -440,7 +440,7 @@ &pinctrl_gpiol6_unbiased
> /*U0-U7*/ "","","","","","","","",
> /*V0-V7*/ "","rtc-battery-voltage-read-enable","","power-chassis-control","","","","",
> /*W0-W7*/ "","","","","","","","",
> - /*X0-X7*/ "fpga-pgood","power-chassis-good","pch-pgood","","","","","",
> + /*X0-X7*/ "fpga-pgood","","pch-pgood","","","","","",
> /*Y0-Y7*/ "","","","","","","","",
> /*Z0-Z7*/ "","","","","","","","";
>
> @@ -486,12 +486,6 @@ &emmc {
> clk-phase-mmc-hs200 = <180>, <180>;
> };
>
> -&sgpiom0 {
> - status = "okay";
> - ngpios = <128>;
> - bus-frequency = <500000>;
> -};
> -
> &ibt {
> status = "okay";
> };
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: rockchip: inno-hdmi: Add configure() and validate() ops
From: Jonas Karlman @ 2026-05-18 11:19 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Heiko Stuebner, linux-phy, linux-rockchip,
linux-arm-kernel, linux-kernel
In-Reply-To: <agny1ER5j6om9hIT@vaman>
On 5/17/2026 6:54 PM, Vinod Koul wrote:
> On 15-05-26, 23:04, Jonas Karlman wrote:
>> Hi,
>>
>> On 5/15/2026 9:55 PM, Jonas Karlman wrote:
>>> The commit 10ed34d6eaaf ("phy: Add HDMI configuration options")
>>> introduced a way for HDMI PHYs to be configured through the generic
>>> phy_configure() function.
>>>
>>> This driver derives the TMDS character rate from the pixel clock and the
>>> PHY bus width setting. However, no in-tree consumer of this PHY has ever
>>> called phy_set_bus_width() to change the TMDS character rate as only
>>> 8-bit RGB output is supported by the HDMI display driver.
>>>
>>> Add configure() and validate() ops to allow consumers to configure the
>>> TMDS character rate using phy_configure(). Fallback to the deprecated
>>> way of using the PHY bus width to configure the TMDS character rate.
>>>
>>> A typical call chain during DRM modeset on a RK3328 device:
>>>
>>> dw_hdmi_rockchip_encoder_atomic_check():
>>> - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000
>>>
>>> dw_hdmi_rockchip_encoder_atomic_mode_set():
>>> - inno_hdmi_phy_configure(): pixclock 148500000
>>> - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000
>>>
>>> vop_crtc_atomic_enable():
>>> - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000
>>> - inno_hdmi_phy_rk3328_clk_set_rate(): pixclock 594000000 tmdsclock 594000000
>>> - inno_hdmi_phy_rk3328_clk_recalc_rate(): pixclock 594000000 vco 594000000
>>>
>>> dw_hdmi_rockchip_encoder_enable():
>>> - inno_hdmi_phy_power_on(): Inno HDMI PHY Power On
>>> - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000
>>>
>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>>> ---
>>> Changes in v3:
>>> - Change validate() ops to only validate tmdsclock
>>> - Add comments about expected consumer usage
>>> - Update commit message with a typical call chain
>>> Changes in v2:
>>> - Add validate() ops to validate that the TMDS rate is supported
>>> - Split out parts that remove the old workaround into a separate patch
>>>
>>> Patch "drm/rockchip: dw_hdmi: Configure HDMI PHY in atomic_mode_set()"
>>> at [1] adds phy_validate() and phy_configure() calls for this HDMI PHY.
>>>
>>> [1] https://lore.kernel.org/dri-devel/20260510183114.1248840-10-jonas@kwiboo.se/
>>> ---
>>> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 60 ++++++++++++++++++-
>>> 1 file changed, 59 insertions(+), 1 deletion(-)
>>
>> [snip]
>>
>>> +static int inno_hdmi_phy_validate(struct phy *phy, enum phy_mode mode,
>>> + int submode, union phy_configure_opts *opts)
>>> +{
>>> + const struct pre_pll_config *cfg = pre_pll_cfg_table;
>>> + unsigned long tmdsclock;
>>> +
>>> + if (!(mode == PHY_MODE_HDMI && submode == PHY_HDMI_MODE_TMDS))
>>> + return -EINVAL;
>>> +
>>> + if (!opts->hdmi.tmds_char_rate || opts->hdmi.tmds_char_rate > 594000000)
>>> + return -EINVAL;
>>
>> Sashiko reasoning log pointed out that a consumer of phy_validate() or
>> phy_configure() can make a call with opts=NULL, so I may likely send a
>> v4 of this series to fix such possible NULL pointer dereference here.
>
> Yes please
I will send a v4 that includes a NULL check, thanks.
>
>>
>> Or is that something that possible should be checked before phy core
>> calls the .validate()/.configure() ops?
>
> The opts is an optional argument depending upon the mode to be valid. So
> we cant do that in the core...
>
>>
>> Multiple other phy .configure() ops seem to dereference opts members
>> without any type of opts NULL check. (next-20260508)
>
> We should fix these
>
>
> PS: Any reason why you are sending encypted emails?
Hopefully you find a way to read this :-)
My email provider tries to be smart and encrypts any outgoing mail when
there is a PGP key published for a recipient in a Web Key Directory,
something that kernel.org has [2].
I raised an issue with the provider and was hoping that the change they
made [3] would fix the issue, and it looks like your published PGP key
is not sign-only and is in fact encryption-capable.
Will open a new issue and ask them to add some way to fully disable use
of automatic encryption on outgoing mails.
[2] https://www.kernel.org/category/signatures.html
[3] https://github.com/forwardemail/forwardemail.net/commit/88def5438a8da678252c234e876d3cdd469a8202
Regards,
Jonas
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: firmware: google,gs101-acpm-ipc: document Exynos850 compatible
From: Alexey Klimov @ 2026-05-18 11:30 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <e91496f2-3b7a-4982-992a-91e8326367be@linaro.org>
On Thu May 14, 2026 at 3:46 PM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> Please check sashiko's review from:
> https://sashiko.dev/#/patchset/20260513-exynos850-acpm-firmware-support-v1-0-3858d097e433%40linaro.org
>
> does the gs101 pmic constraints apply to e850?
Thanks for the heads-up! Yes, sashiko-bot@kernel.org sends reports and
I received it. The "To:" field there includes lesser email addresses and
only device tree mail list.
I need to check pmic thingy for e850 but probably yes. Obviously, it
needs updating.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Alexander Sverdlin @ 2026-05-18 11:29 UTC (permalink / raw)
To: Andre Przywara, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <256b1cd8-b143-4f71-91cc-8513be04ce4c@arm.com>
Hi Andre,
On Mon, 2026-05-18 at 13:16 +0200, Andre Przywara wrote:
> > > And anyway, I see a *dual* USB-A socket on the pictures online, in
> > > addition to the USB-OTG port. So where does the third USB come from? The
> > > A133 only supports one host USB port plus the one OTG port. So is there
> > > an USB hub chip on the board?
> >
> > There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
>
> What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
> does this work, then?
the upstream port of this hub is wired to the USB-C connector, one port has
CH340E USB-UART on it for the console, the other port goes to the SoC usbphy 0.
So it would be "peripheral" only, I suppose.
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-18 11:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Matthew Wilcox, surenb, akpm, linux-mm, david, liam, vbabka, rppt,
mhocko, jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <agrWuDNGddNmvMFD@lucifer>
On Mon, May 18, 2026 at 5:47 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Sun, May 17, 2026 at 04:45:15PM +0800, Barry Song wrote:
> > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > >
> > > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > > > both the hardware and the software stack (bio/request queues and the
> > > > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > > > be quite long. In such cases, a high-priority thread performing operations
> > > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > > > for an unpredictable amount of time.
> > > > >
> > > > > But does that actually happen? I find it hard to believe that thread A
> > > > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > > > it still seems really unlikely to me.
> > > >
> > > > It doesn’t have to involve unmapping or applying mprotect to
> > > > the entire VMA—just a portion of it is sufficient.
> > >
> > > Yes, but that still fails to answer "does this actually happen". How much
> > > performance is all this complexity in the page fault handler buying us?
> > > If you don't answer this question, I'm just going to go in and rip it
> > > all out.
> > >
> >
> > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > waiting for answers),
> >
> > As promised during LSF/MM/BPF, we conducted thorough
> > testing on Android phones to determine whether performing
> > I/O in `filemap_fault()` can block `vma_start_write()`.
> > I wanted to give a quick update on this question.
> >
> > Nanzhe at Xiaomi created tracing scripts and ran various
> > applications on Android devices with I/O performed under
> > the VMA lock in `filemap_fault()`. We found that:
> >
> > 1. There are very few cases where unmap() is blocked by
> > page faults. I assume this is due to buggy user code
> > or poor synchronization between reads and unmap().
> > So I assume it is not a problem.
> >
> > 2. We observed many cases where `vma_start_write()`
> > is blocked by page-fault I/O in some applications.
> > The blocking occurs in the `dup_mmap()` path during
> > fork().
> >
> > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > the parent process when forking"), we now always hold
> > `vma_write_lock()` for each VMA. Note that the
> > `mmap_lock` write lock is also held, which could lead to
> > chained waiting if page-fault I/O is performed without
> > releasing the VMA lock.
>
> Hm but did you observe this 'chained waiting'? And what were the latencies?
We have clearly observed that the `fork()` operations of many
popular Android apps, such as iQiyi, Baidu Tieba, and 10086,
end up waiting on page-fault (PF) I/O when the VMA lock is
held during I/O operations. This has already become a
practical issue. I also believe this can lead to chained
waiting, since the global `mmap_lock` blocks all threads that
need to acquire it.
>
> >
> > My gut feeling is that Suren's commit may be overshooting,
> > so my rough idea is that we might want to do something like
> > the following (we haven't tested it yet and it might be
> > wrong):
>
> Yeah I'm really not sure about that.
>
> Prior to the VMA locks, the mmap write lock would have guaranteed no concurrent
> page faults, which is really what fb49c455323ff is about.
>
> So Suren's patch was essentially restoring the _existing_ forking behaviour, and
> now you're saying 'let's change the forking behaviour that's been like that for
> forever'.
I am afraid not. Before we introduced the per-VMA lock, we
were not performing I/O while holding `mmap_lock`. A page fault
that needed I/O would drop the `mmap_lock` read lock and allow
`fork()` to proceed.
Now, you are suggesting performing I/O while holding the VMA
lock, which changes the requirements and introduces this
problem.
>
> I think you would _really_ have to be sure that's safe. And forking is a very
> dangerous time in terms of complexity and sensitivity and 'weird stuff'
> happening so I'd tread _very_ carefully here.
Yep. I think my original proposal did not require any changes
to `fork()`, since it simply preserved the current behavior of
dropping the VMA lock before performing I/O. In that model,
`fork()` would not end up waiting on I/O at all.
What you are suggesting now appears to be performing I/O while
holding the VMA lock, which in turn introduces the need to
change `fork()`.
>
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 2311ae7c2ff4..5ddaf297f31a 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > *mm, struct mm_struct *oldmm)
> > for_each_vma(vmi, mpnt) {
> > struct file *file;
> >
> > - retval = vma_start_write_killable(mpnt);
> > + /*
> > + * For anonymous or writable private VMAs, prevent
> > + * concurrent CoW faults.
> > + */
>
> To nit pick I think the comment's confusing but also tells you you don't need to
> specific anon check - writable private is sufficient. And it's not really just
> CoW that's the issue, it's anon_vma population _at all_ as well as CoW.
>
> > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > + (mpnt->vm_flags & VM_WRITE)))
> > + retval = vma_start_write_killable(mpnt);
>
> I think this has to be VM_MAYWRITE, because somebody could otherwise mprotect()
> it R/W.
>
> I also don't understand why !mpnt->vm_file for a read-only anon mapping (more
> likely PROT_NONE) is here, just do the second check?
>
> (Also please use the new interface, so !vma_test(mpnt, VMA_SHARED_BIT) &&
> vma_test(mpnt, VMA_MAYWRITE_BIT))
Yep, I can definitely refine the check further. But before
doing that, I'd first like to confirm that we are aligned on
the direction.
If you still intend to hold the VMA lock while performing I/O,
then I think we should fix `fork()` to avoid taking
`vma_start_write()`.
>
> > if (retval < 0)
> > goto loop_out;
> > if (mpnt->vm_flags & VM_DONTCOPY) {
> >
> > Based on the above, we may want to re-check whether fork()
> > can be blocked by page faults. At the same time, if Suren,
> > you, or anyone else has any comments, please feel free to
> > share them.
> >
> > Best Regards
> > Barry
>
> Technical commentary above is sort of 'just cos' :) because I really question
> doing this honestly.
I think we either need to fix `fork()`, or keep the current
behavior of dropping the VMA lock before performing I/O.
>
> I'd also like to get Suren's input, however.
Yes. of course.
>
> Thanks, Lorenzo
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Alexey Klimov @ 2026-05-18 11:24 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <a55690fc-7727-401d-9b3c-06bf3c2852d0@linaro.org>
On Fri May 15, 2026 at 8:56 AM BST, Tudor Ambarus wrote:
>
>
> On 5/11/26 4:17 PM, Alexey Klimov wrote:
>> On Thu May 7, 2026 at 9:31 AM BST, Tudor Ambarus wrote:
>>> On 5/6/26 6:13 PM, Alexey Klimov wrote:
>>>> On Wed May 6, 2026 at 12:39 PM BST, Tudor Ambarus wrote:
>>
>> [..]
>>
>>>>> new file mode 100644
>>>>> index 000000000000..c68d60b4c0b3
>>>>> --- /dev/null
>>>>> +++ b/drivers/firmware/samsung/exynos-acpm-tmu.c
>>>>
>>>> [..]
>>>>
>>>>> +static int acpm_tmu_to_linux_err(s8 fw_err)
>>>>> +{
>>>>> + /*
>>>>> + * ACPM_TMU_INIT uses BIT(0) and BIT(1) of msg.rx.ret to flag APM
>>>>> + * capabilities. Treat zero and all positive values as success.
>>>>
>>>> ACPM_TMU_INIT returns capabilities inside designated error field?
>>>
>>> yes
>>
>> Heh. Okay.
>>
>>>> What about other messages/commands? They just return error code there?
>>>
>>> all the other commands either return -1 for errors, regardless of the error
>>> type, or 0 for success.
>>>>
>>>>> + */
>>>>> + if (fw_err >= 0)
>>>>> + return 0;
>>>>> +
>>>>> + if (fw_err == -1)
>>>>> + return -EACCES;
>>>>> +
>>>>> + return -EIO;
>>>>> +}
>>>>
>>>> Could we map these return values with better granularity instead of
>>>> returning -EIO for everything else that is not minus one?
>>>
>>> I think we're good as we are now. The firmware returns either -1 for errors,
>>> zero for success, or BIT(0) and BIT(1) for TMU_INIT to flag some capabilities.
>>> I can't tell if there are other commands that return capabilities as well,
>>> or if there are other capabilities for TMU_INIT, I don't have access to the
>>> firmware code.
>>
>> On Exynos850 I see more than just one returned error codes. I definitely
>> see 0xfe and 0xfd at least. I don't have any data to confirm that ff
>> maps to -1 and fd-s, fe-s to -2,-3 though and what they mean. From my
>
> for these error codes we will return -EIO which is alright. We can have
> a more granular approach depending on the SoC if you want.
>
> For GS101 above is alright, it matches the info I got from the firmware guys.
*sigh*
>> experiments I suspect that 0xfe means that call/msg type is not
>> implemented or not accessible and 0xfd means that passed parameter is
>> wrong or incorrect or not found.
>>
>> I am also not sure that I saw 0xff-s but, well, maybe that needs more
>> experimenting.
>>
> fe and ff will be covered as well by -EIO.
Of course. But it is about propagating the correct error (meaning
exactly "what went wrong") to the other levels and to a user.
My debugging of tmu for e850 would be a bit easier when sending messages
to acpm if I knew that:
-- something went completely bad;
-- specific acpm call is not implemented/not allowed
(but acpm machinery is working);
-- passed argument for acpm call is not correct/not found
(but acpm machinery is working);
Instead all of that I get only -EIO. Couldn't say if it will be helpful
for any other platforms.
> Let's keep this as it is for now, and if you need a more granular approach
> we can differentiate that for e850.
It's quite sad that even on that level ACPM on gs101 differs from ACPM
on E850.
Thinking further about this I'd humbly suggest that even
if (fw_err >= 0)
return 0;
pr_debug_ratelimited("ACPM tmu call returned: %x\n", fw_err);
or pr_debug(...);
if (fw_err == -1)
return -EACCES;
some debug message would do.
Perhaps we need some convertation, for instance as it is done in scmi
code (scmi_to_linux_errno(), scmi_linux_errmap[]). But I don't have any
data for mapping acpm errors to some human meanings.
Up to you.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH v2 1/1] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs
From: Andrew Jeffery @ 2026-05-18 11:22 UTC (permalink / raw)
To: Fred Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260421130344.2751662-2-fredchen.openbmc@gmail.com>
Hi Fred,
On Tue, 2026-04-21 at 21:03 +0800, Fred Chen wrote:
> Add several GPIO expanders to the Santabarbara platform, with ioexp0
> (0x20) configured to aggregate interrupt signals from downstream
> expanders to optimize sideband pin usage.
Can you provide a bit more context? Is this the result of a broader
design change? Or is it a case of adding descriptions of hardware that
was already present in the design?
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
From: Andre Przywara @ 2026-05-18 11:16 UTC (permalink / raw)
To: Alexander Sverdlin, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <14a7e289ff5ffed8fcd6dcb9b2e8455a1b2c9420.camel@gmail.com>
Hi Alexander,
On 5/17/26 22:38, Alexander Sverdlin wrote:
> Hi Andre,
>
> thanks for the quick feedback!
>
> On Mon, 2026-05-11 at 13:44 +0200, Andre Przywara wrote:
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baije-core.dtsi
>>> @@ -0,0 +1,162 @@
>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> +/*
>>> + * Copyright (c) 2025 Arm Ltd.
>>
>> Please put your own copyright here, even if that has been largely copied
>> from an existing file.
>>
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "sun50i-a100.dtsi"
>>> +#include "sun50i-a100-cpu-opp.dtsi"
>>> +
>>> +/{
>>> + compatible = "baijie,helper-a133-core",
>>> + "allwinner,sun50i-a100";
>>> +
>>> + aliases {
>>> + serial1 = &uart1; /* BT module */
>>
>> Do we really need an alias for the BT UART? And is the BT module
>> supported already? Then please add a child node to the UART node.
>
> That's the only thing I can do currently regarding BT: stabilize the
> serial enumeration, because UART1 cannot be used for anything else
> except BT module, because this is soldered inside "core" module.
> We can avoid different tty enumeration, should the support for
> BT be implemented in the future...
>
>> Isn't the WiFi/BT module on the SoM? Then please mention and enable MMC1
>> here. Provide the child node for the WiFi chip, even if there is no
>> upstream support in the kernel for it yet.
>
> So both the above BT and the WiFi is AW869A/AIC8800 combo chip, which
> has neither upstream driver, nor [upstream] DT bindings. Even github
> driver for AIC8800 doesn't seem to use DT, therefore it looks quite
> pointless to me at this point to specify anything in the DT for the
> chip which doesn't have the bindings idea even theoretically.
>
> Nothing in the current DT shall block any future work on the AW869A
> support though and the above "aliases" entry shall even guarantee
> unchanged serial enumeration shall such support arise.
Fair enough for not providing DT nodes for those unsupported chips, but
why do we need to force enumeration? For the eventual Bluetooth usage,
the driver will find the respective serial interface by just looking at
its parent interface. IIUC there is nothing referring to ttyS1
explicitly. So we wouldn't really need an alias, would we?
I see that some boards do define an alias, but others with Bluetooth
don't, which I think is the right thing to do. Which name the kernel
comes up with for UART1 shouldn't matter in any way.
>>> +®_aldo1 {
>>
>> What is aldo1 used for, actually? I don't see this referenced anywhere.
>> I guess the kernel turns that off after booting?
>> If you have access to the schematic, please check that. If that's for
>> some peripheral not yet supported, please note the user anyway, ideally
>> by an explaining regulator-name, or by a comment. Also if it's used for
>> any of the required SoC VDD pins. See the Liontron .dts for comparison.
>>
>>> + regulator-always-on;
> ^^^^^^^^^^^^^^^^^^^
> I suppose it's not being switcdhed of because of the above.
> It's used for both PLL supply for the whole SoC + as analog voltage reference
> for LRADC (the buttons you've noticed on the board are connected to
> this ADC via a resistor ladder).
Ah, yeah, somehow missed that line. So as stated below, please use a
descriptive regulator name.
Look at sun55i-a527-cubie-a5e.dts, I think is a more modern example of
how to handle regulators best.
>
>>
>>> +®_aldo2 {
>>> + regulator-always-on;
>>
>> For always-on regulators we definitely need an explanation. Does the
>> board stop booting if you remove this line?
>> Maybe it's for DRAM? Can you say what voltage it is, either from the
>> reset default, or set by the bootloader?
>
> Thanks for the hint! I'll put proper voltages into all regulators +
> comment all the always-on regulators.
Thanks!
>
>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>>> new file mode 100644
>>> index 000000000000..ccbca5d0a40c
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-baijie-helper.dts
>
>> And you should provide a top level 5V regulator here, to be the root of
>> the regulator tree. Look at reg_vcc5v in the Liontron .dts.
>
> It doesn't look to me as if Liontron had reg_vcc5v as its 5V "root" regulator.
> It seems to be only used for reg_usb1_vbus, while HelperBoard A133 doesn't
> have USB power control. The second issue with Helper/Core split is that
> all PMIC story is inside Core board which has 5V input rail, while HelperBoard
> around it has indeed 12V->5V DCDC regulator (similar to Liontron), but
> putting it in the DT would introduce wierd dependency of the core to the
> HelperBoard which carries it. Do you think it would make sense?
Ah yeah, the Liontron is not the best example, we don't have the full
description there, because this board misses schematics.
So look at sun55i-a527-cubie-a5e.dts instead, which uses the top level
regulator correctly. We didn't traditionally do this with the A64 boards
using the AXP803, and just learned to live with those dummy supplies
created by the kernel, but for new boards we should do better.
Regarding the board/SoM split: You should have a fixed regulator in the
SoM .dtsi reflecting the 5V input pin(s), and then using that as the VIN
supply for the various PMIC rails, as the Cubie A5E does. This would
mimic some barrel connector on a standard board: the voltage is applied
"by the user", externally.
So in this SoM .dtsi node, there is no vin-supply property, but you add
that in the board .dts:
®_vcc5v {
vin-supply = <®_vcc12v5v>;
};
Please come up with some better names than I just did ;-) Maybe
something like reg_vcc5v_som to make this clearer.
And then you have that 12V->5V regulator described in the board .dts,
along with a parent-less 12V regulator, check sun55i-t527-avaota-a1.dts
for an example.
That should work cleanly, I think.
>> So from the pictures I found online it looks like there is an USB-C port
>> labelled "OTG", so can you please add an &usbotg reference here and
>> describe that port.
>
> Nice catch! I've missed the fact usbphy 0 has to be in peripheral mode,
> not host mode. Will rework!
I guess that's the same situation as in the other recent boards using
USB-C: they hardwired it to peripheral mode, although you can use this
as a host port with some tricks, check sun50i-h616-orangepi-zero.dtsi,
and copy this comment, should it apply.
>>> +&usbphy {
>>
>> Are the two USB ports always powered?
>>
>> And anyway, I see a *dual* USB-A socket on the pictures online, in
>> addition to the USB-OTG port. So where does the third USB come from? The
>> A133 only supports one host USB port plus the one OTG port. So is there
>> an USB hub chip on the board?
>
> There are two hubs, one on each usbphy. OTG side hub is even bus-powered,
What do you mean with OTG side hub, exactly? Is there a hub on USB0? How
does this work, then?
Cheers,
Andre
> two USB-A ports are always powered from the board's 12V->5V DCDC, no USB
> load switches.
>>
>
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Niyas Sait @ 2026-05-18 11:14 UTC (permalink / raw)
To: andre.przywara
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260429141339.3171205-6-andre.przywara@arm.com>
Hi Andre,
On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
> + msc->pcc_chan = pcc_mbox_request_channel(&msc->pcc_cl,
> + pcc_subspace_id);
> + if (IS_ERR(msc->pcc_chan)) {
> + pr_err("Failed to request MSC PCC channel\n");
> + return (void *)msc->pcc_chan;
> + }
> +
> + if (msc->pcc_chan->shmem_size < MPAM_FB_MAX_MSG_SIZE) {
> + pr_err("MPAM-Fb PCC channel size too small.\n");
> + pcc_mbox_free_channel(msc->pcc_chan);
> + return ERR_PTR(-ENOMEM);
> + }
I think this allocates one PCC channel per MSC instance.
MPAM-Fb spec. allows MPAM manager to support multiple MSCs and does not
require seperate channels per MSC. Each MSC is targeted via its msc_id
in the MPAM_MSC_READ/WRITE commands.
So for systems where multiple MSC nodes point to the same PCC subspace,
should we share one pcc_mbox_chan and serialize requests through it?
Thanks,
Niyas
^ permalink raw reply
* Re: [PATCH 2/2] firmware: samsung: acpm: add Exynos850 support
From: Tudor Ambarus @ 2026-05-18 11:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexey Klimov, Sam Protsenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <b1631f32-aafb-46fc-86c8-daff0d6dc2f7@kernel.org>
On 5/18/26 1:46 PM, Krzysztof Kozlowski wrote:
> On 18/05/2026 12:27, Tudor Ambarus wrote:
>>
>>
>> On 5/13/26 2:12 AM, Alexey Klimov wrote:
>>> The Exynos850 SoC contains an APM co-processor. Communication
>>> with this hardware block is established using the ACPM protocol,
>>> which handles IPC messages for clocks, power, thermal management,
>>> and PMIC control.
>>>
>>> Add the "samsung,exynos850-acpm-ipc" compatible string along with
>>> its associated match data. This includes the specific initialisation
>>
>> s/initialisation/initialization
>
> Hoho, careful, that's a quite hot topic :)
:)
> I think we do not have kernel-wide preference here and even if there
> was, no need to resend just for that.
I wasn't aware of the British term (thanks Alexey!) and I already gave
my R-b. No hot topic for me, thought that it's just a typo.
Cheers,
ta
^ permalink raw reply
* [PATCH] usb: typec: Use named initializers for arrays of i2c_device_data
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-18 11:01 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman
Cc: Hans de Goede, Badhri Jagan Sridharan, Maxime Coquelin,
Alexandre Torgue, Sebastian Reichel, Yongbo Zhang,
Thomas Gleixner, Alexey Charkov, Sebastian Andrzej Siewior,
André Draszik, Amit Sunil Dhamne, Yuanshen Cao, Sven Peter,
Neal Gompa, Hector Martin, Ethan Tidmore, Peter Korsgaard,
Andrew Morton, Johan Hovold, Randy Dunlap, Pooja Katiyar,
Dmitry Baryshkov, Thorsten Blum, linux-usb, linux-kernel,
linux-stm32, linux-arm-kernel
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify usage of whitespace in the list
terminator.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
the mentioned change to i2c_device_id is the following:
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 23ff24080dfd..aebd3a5e90af 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -477,7 +477,11 @@ struct rpmsg_device_id {
struct i2c_device_id {
char name[I2C_NAME_SIZE];
- kernel_ulong_t driver_data; /* Data private to the driver */
+ union {
+ /* Data private to the driver */
+ kernel_ulong_t driver_data;
+ const void *driver_data_ptr;
+ };
};
/* pci_epf */
and this requires that .driver_data is assigned via a named initializer
for static data. This requirement isn't a bad one because named
initializers are also much better readable than list initializers.
The union added to struct i2c_device_id enables further cleanups like:
diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
index 0123ca8157a8..dfb0b07500a7 100644
--- a/drivers/regulator/ad5398.c
+++ b/drivers/regulator/ad5398.c
@@ -207,8 +207,8 @@ struct ad5398_current_data_format {
static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
static const struct i2c_device_id ad5398_id[] = {
- { .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
- { .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
+ { .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
+ { .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ad5398_id);
@@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
struct regulator_config config = { };
struct ad5398_chip_info *chip;
- const struct ad5398_current_data_format *df =
- (struct ad5398_current_data_format *)id->driver_data;
+ const struct ad5398_current_data_format *df = id->driver_data;
chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
that are an improvement for readability (again!) and it keeps some
properties of the pointers (here: being const) without having to pay
attention for that. (I didn't find a usb driver that benefits, so this
is "only" a regulator driver example.)
My additional motivation for this effort is CHERI[1]. This is a hardware
extension that uses 128 bit pointers but unsigned long is still 64 bit.
So with CHERI you cannot store pointers in unsigned long variables.
Best regards
Uwe
[1] https://cheri-alliance.org/discover-cheri/
https://lwn.net/Articles/1037974/
drivers/usb/typec/anx7411.c | 4 ++--
drivers/usb/typec/mux/fsa4480.c | 2 +-
drivers/usb/typec/mux/it5205.c | 2 +-
drivers/usb/typec/mux/nb7vpq904m.c | 2 +-
drivers/usb/typec/mux/pi3usb30532.c | 2 +-
drivers/usb/typec/mux/ptn36502.c | 2 +-
drivers/usb/typec/mux/wcd939x-usbss.c | 2 +-
drivers/usb/typec/tcpm/fusb302.c | 4 ++--
drivers/usb/typec/tcpm/tcpci.c | 2 +-
drivers/usb/typec/tcpm/tcpci_maxim_core.c | 2 +-
drivers/usb/typec/tcpm/tcpci_rt1711h.c | 8 ++++----
drivers/usb/typec/tipd/core.c | 2 +-
drivers/usb/typec/ucsi/ucsi_ccg.c | 4 ++--
drivers/usb/typec/ucsi/ucsi_stm32g0.c | 4 ++--
14 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/typec/anx7411.c b/drivers/usb/typec/anx7411.c
index 2e8ae1d2faf9..604868ebf422 100644
--- a/drivers/usb/typec/anx7411.c
+++ b/drivers/usb/typec/anx7411.c
@@ -1577,8 +1577,8 @@ static void anx7411_i2c_remove(struct i2c_client *client)
}
static const struct i2c_device_id anx7411_id[] = {
- { "anx7411" },
- {}
+ { .name = "anx7411" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, anx7411_id);
diff --git a/drivers/usb/typec/mux/fsa4480.c b/drivers/usb/typec/mux/fsa4480.c
index c54e42c7e6a1..bea0c1deec94 100644
--- a/drivers/usb/typec/mux/fsa4480.c
+++ b/drivers/usb/typec/mux/fsa4480.c
@@ -336,7 +336,7 @@ static void fsa4480_remove(struct i2c_client *client)
}
static const struct i2c_device_id fsa4480_table[] = {
- { "fsa4480" },
+ { .name = "fsa4480" },
{ }
};
MODULE_DEVICE_TABLE(i2c, fsa4480_table);
diff --git a/drivers/usb/typec/mux/it5205.c b/drivers/usb/typec/mux/it5205.c
index 4357cc67a867..5e1a120b2e3b 100644
--- a/drivers/usb/typec/mux/it5205.c
+++ b/drivers/usb/typec/mux/it5205.c
@@ -266,7 +266,7 @@ static void it5205_remove(struct i2c_client *client)
}
static const struct i2c_device_id it5205_table[] = {
- { "it5205" },
+ { .name = "it5205" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, it5205_table);
diff --git a/drivers/usb/typec/mux/nb7vpq904m.c b/drivers/usb/typec/mux/nb7vpq904m.c
index b57b6c9c40fe..d1fa26ff442c 100644
--- a/drivers/usb/typec/mux/nb7vpq904m.c
+++ b/drivers/usb/typec/mux/nb7vpq904m.c
@@ -499,7 +499,7 @@ static void nb7vpq904m_remove(struct i2c_client *client)
}
static const struct i2c_device_id nb7vpq904m_table[] = {
- { "nb7vpq904m" },
+ { .name = "nb7vpq904m" },
{ }
};
MODULE_DEVICE_TABLE(i2c, nb7vpq904m_table);
diff --git a/drivers/usb/typec/mux/pi3usb30532.c b/drivers/usb/typec/mux/pi3usb30532.c
index 8eeec135dcdb..985683fe49e9 100644
--- a/drivers/usb/typec/mux/pi3usb30532.c
+++ b/drivers/usb/typec/mux/pi3usb30532.c
@@ -169,7 +169,7 @@ static void pi3usb30532_remove(struct i2c_client *client)
}
static const struct i2c_device_id pi3usb30532_table[] = {
- { "pi3usb30532" },
+ { .name = "pi3usb30532" },
{ }
};
MODULE_DEVICE_TABLE(i2c, pi3usb30532_table);
diff --git a/drivers/usb/typec/mux/ptn36502.c b/drivers/usb/typec/mux/ptn36502.c
index 129d9d24b932..afd16775dbaf 100644
--- a/drivers/usb/typec/mux/ptn36502.c
+++ b/drivers/usb/typec/mux/ptn36502.c
@@ -404,7 +404,7 @@ static void ptn36502_remove(struct i2c_client *client)
}
static const struct i2c_device_id ptn36502_table[] = {
- { "ptn36502" },
+ { .name = "ptn36502" },
{ }
};
MODULE_DEVICE_TABLE(i2c, ptn36502_table);
diff --git a/drivers/usb/typec/mux/wcd939x-usbss.c b/drivers/usb/typec/mux/wcd939x-usbss.c
index d46c353dfaf2..73db3aa3cec4 100644
--- a/drivers/usb/typec/mux/wcd939x-usbss.c
+++ b/drivers/usb/typec/mux/wcd939x-usbss.c
@@ -753,7 +753,7 @@ static void wcd939x_usbss_remove(struct i2c_client *client)
}
static const struct i2c_device_id wcd939x_usbss_table[] = {
- { "wcd9390-usbss" },
+ { .name = "wcd9390-usbss" },
{ }
};
MODULE_DEVICE_TABLE(i2c, wcd939x_usbss_table);
diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
index 889c4c29c1b8..6560da0c523b 100644
--- a/drivers/usb/typec/tcpm/fusb302.c
+++ b/drivers/usb/typec/tcpm/fusb302.c
@@ -1841,8 +1841,8 @@ static const struct of_device_id fusb302_dt_match[] __maybe_unused = {
MODULE_DEVICE_TABLE(of, fusb302_dt_match);
static const struct i2c_device_id fusb302_i2c_device_id[] = {
- { "typec_fusb302" },
- {}
+ { .name = "typec_fusb302" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, fusb302_i2c_device_id);
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index 0148b8f50412..8841a94df153 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -1020,7 +1020,7 @@ static int tcpci_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(tcpci_pm_ops, tcpci_suspend, tcpci_resume);
static const struct i2c_device_id tcpci_id[] = {
- { "tcpci" },
+ { .name = "tcpci" },
{ }
};
MODULE_DEVICE_TABLE(i2c, tcpci_id);
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim_core.c b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
index c0ee7e6959ed..6ceb25e5bdd0 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim_core.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
@@ -570,7 +570,7 @@ static int max_tcpci_suspend(struct device *dev)
static SIMPLE_DEV_PM_OPS(max_tcpci_pm_ops, max_tcpci_suspend, max_tcpci_resume);
static const struct i2c_device_id max_tcpci_id[] = {
- { "maxtcpc" },
+ { .name = "maxtcpc" },
{ }
};
MODULE_DEVICE_TABLE(i2c, max_tcpci_id);
diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
index 4b3e4e22a82e..a8726da6fc71 100644
--- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
+++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
@@ -373,10 +373,10 @@ static const struct rt1711h_chip_info rt1715 = {
};
static const struct i2c_device_id rt1711h_id[] = {
- { "et7304", (kernel_ulong_t)&rt1715 },
- { "rt1711h", (kernel_ulong_t)&rt1711h },
- { "rt1715", (kernel_ulong_t)&rt1715 },
- {}
+ { .name = "et7304", .driver_data = (kernel_ulong_t)&rt1715 },
+ { .name = "rt1711h", .driver_data = (kernel_ulong_t)&rt1711h },
+ { .name = "rt1715", .driver_data = (kernel_ulong_t)&rt1715 },
+ { }
};
MODULE_DEVICE_TABLE(i2c, rt1711h_id);
diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
index 43faec794b95..f560606c588c 100644
--- a/drivers/usb/typec/tipd/core.c
+++ b/drivers/usb/typec/tipd/core.c
@@ -2027,7 +2027,7 @@ static const struct of_device_id tps6598x_of_match[] = {
MODULE_DEVICE_TABLE(of, tps6598x_of_match);
static const struct i2c_device_id tps6598x_id[] = {
- { "tps6598x", (kernel_ulong_t)&tps6598x_data },
+ { .name = "tps6598x", .driver_data = (kernel_ulong_t)&tps6598x_data },
{ }
};
MODULE_DEVICE_TABLE(i2c, tps6598x_id);
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c b/drivers/usb/typec/ucsi/ucsi_ccg.c
index 199799b319c2..ddde0a7702f0 100644
--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
+++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
@@ -1525,8 +1525,8 @@ static const struct of_device_id ucsi_ccg_of_match_table[] = {
MODULE_DEVICE_TABLE(of, ucsi_ccg_of_match_table);
static const struct i2c_device_id ucsi_ccg_device_id[] = {
- { "ccgx-ucsi" },
- {}
+ { .name = "ccgx-ucsi" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, ucsi_ccg_device_id);
diff --git a/drivers/usb/typec/ucsi/ucsi_stm32g0.c b/drivers/usb/typec/ucsi/ucsi_stm32g0.c
index 838ac0185082..848ed459a6de 100644
--- a/drivers/usb/typec/ucsi/ucsi_stm32g0.c
+++ b/drivers/usb/typec/ucsi/ucsi_stm32g0.c
@@ -737,8 +737,8 @@ static const struct of_device_id __maybe_unused ucsi_stm32g0_typec_of_match[] =
MODULE_DEVICE_TABLE(of, ucsi_stm32g0_typec_of_match);
static const struct i2c_device_id ucsi_stm32g0_typec_i2c_devid[] = {
- { "stm32g0-typec" },
- {}
+ { .name = "stm32g0-typec" },
+ { }
};
MODULE_DEVICE_TABLE(i2c, ucsi_stm32g0_typec_i2c_devid);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 4/5] arm_mpam: prevent MPAM-Fb accesses inside IRQ handler
From: Niyas Sait @ 2026-05-18 10:57 UTC (permalink / raw)
To: andre.przywara
Cc: ben.horgan, catalin.marinas, fenghuay, guohanjun, james.morse,
jic23, lenb, linux-acpi, linux-arm-kernel, linux-kernel,
lpieralisi, rafael, reinette.chatre, sudeep.holla, will
In-Reply-To: <20260429141339.3171205-5-andre.przywara@arm.com>
Hi Andre,
On Wed, Apr 29, 2026 at 04:13:38PM +0200, Andre Przywara wrote:
> This error report relies on reading the MSC's error status register
> (ESR) in the IRQ handler, which is not possible for MPAM-Fb based
> MSC accesses, since they involve mailbox routines that might sleep.
I think there are a few other places where we may still end up invoking
the MPAM-Fb path from atomic/IRQ context.
For example, _msmon_read() uses smp_call_function_any(), which runs
__ris_msmon_read() in callback/atomic context
static int _msmon_read(struct mpam_component *comp, struct mon_read *arg)
{
...
err = smp_call_function_any(&msc->accessibility,
__ris_msmon_read, arg,
true);
...
}
For MPAM-Fb, I think we could potentially avoid the smp_call_function_any() path entirely
and invoke directly from the current CPU. Since PCC accesses are effectively CPU agnostic,
I think that should be fine for the MPAM-Fb case.
Thanks,
Niyas
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Krzysztof Kozlowski @ 2026-05-18 10:57 UTC (permalink / raw)
To: Prasanth Kumar Padarthi
Cc: joel, andrew, robh, krzk+dt, conor+dt, andrew+netdev, devicetree,
linux-aspeed, linux-arm-kernel
In-Reply-To: <20260518033440.17569-2-prasanth.padarthi10@gmail.com>
On Mon, May 18, 2026 at 09:04:39AM +0530, Prasanth Kumar Padarthi wrote:
> Add the compatible string for the ASRock Rack B650D4U BMC,
> which is an AST2600-based server motherboard.
>
> Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
> ---
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] media: rkvdec: fix PM runtime teardown ordering in remove
From: Francesco Saverio Pavone @ 2026-05-18 10:54 UTC (permalink / raw)
To: jonas, detlev.casanova, nicolas.dufresne, hverkuil, mchehab
Cc: ezequiel, heiko, linux-media, linux-rockchip, linux-arm-kernel,
linux-kernel
From: Jonas Karlman <jonas@kwiboo.se>
The current remove() path calls rkvdec_v4l2_cleanup() and
pm_runtime_disable() before pm_runtime_dont_use_autosuspend(), and
frees the empty IOMMU domain after that. With autosuspend still
armed when the domain goes away, the VDPU381 can be left in a dirty
state across module reload and suspend/resume cycles.
On RK3588 this surfaces as a VP9 inter-prediction bug: from the
second ALTREF frame onward, motion blocks decode with U=V=0 (BT.709
green), while intra and static blocks stay correct. Reordering the
teardown to dont_use_autosuspend() -> iommu_domain_free() ->
pm_runtime_disable() -> v4l2_cleanup() makes the symptom go away.
Tested on a Radxa Rock 5B+ (RK3588, 8 GB LPDDR5) with both the
libva-v4l2-request mpv pipeline and Chromium's V4L2 stateless
decoder. With the fix, 300 random pixel samples on VP9 Profile 0
clips at 1080p and 1440p match a libvpx software reference exactly
(worst delta 0). Without it, the same 1080p sample at frame 4,
pixel (960, 270) reads HW=(0,112,0) vs SW=(204,147,116). HEVC and
H.264 stateless decoding via mpv keep running on hardware with no
fallback.
Fixes: ff8c5622f9f7 ("media: rkvdec: Restore iommu addresses on errors")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
Signed-off-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
---
drivers/media/platform/rockchip/rkvdec/rkvdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
index 6f5f0422d317..bb95b090a25b 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
@@ -2066,12 +2066,13 @@ static void rkvdec_remove(struct platform_device *pdev)
cancel_delayed_work_sync(&rkvdec->watchdog_work);
- rkvdec_v4l2_cleanup(rkvdec);
- pm_runtime_disable(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
if (rkvdec->empty_domain)
iommu_domain_free(rkvdec->empty_domain);
+
+ pm_runtime_disable(&pdev->dev);
+ rkvdec_v4l2_cleanup(rkvdec);
}
#ifdef CONFIG_PM
--
2.45.0
^ permalink raw reply related
* Re: [PATCH] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table
From: Luca Ceresoli @ 2026-05-18 10:50 UTC (permalink / raw)
To: Simon Wright, Cristian Ciocaltea
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Heiko Stuebner, Andy Yan, Sebastian Reichel, Dmitry Baryshkov,
Algea Cao, dri-devel, linux-rockchip, linux-arm-kernel,
linux-kernel
In-Reply-To: <92aa4191-2a2a-41e3-badb-c0a5b1fbb957@symple.nz>
Hello Simon,
On Sat May 9, 2026 at 9:09 AM CEST, Simon Wright wrote:
> dw_hdmi_qp_find_cts() returns 0 for any TMDS character rate not
> present in common_tmds_cts_table[] (which terminates at 148.5 MHz).
> In that case dw_hdmi_qp_set_sample_rate() calls dw_hdmi_qp_set_cts_n()
> with cts == 0, which leaves AUDPKT_ACR_CTS_OVR_EN clear and falls
> back to the controller's internal CTS auto-measurement.
> On at least the RK3576 hdptx integration, strict HDMI sinks mute
> audio in this configuration. The behaviour reproduces at any rate
> not present in the table -- it is not specific to HDMI 2.x:
> 1920x1080@60 with 10-bit deep colour (185.625 MHz, HDMI 1.4) is
> affected, as is 3840x2160@60 8-bit (594 MHz, HDMI 2.0). Supplying
> explicit CTS via the standard set_cts_n() override path resolves
> the mute.
> The driver already has the symmetric machinery for the N-table-miss
> case: dw_hdmi_qp_compute_n() falls back to a dynamic search using
> dw_hdmi_qp_audio_math_diff() ((pixel_clk * n) / (128 * freq)) when
> no table entry matches. The CTS path lacks the equivalent fallback.
> Compute CTS inline in dw_hdmi_qp_set_sample_rate() from N per the
> HDMI spec (CTS = TMDS * N / (128 * Fs)) when find_cts() returns 0.
> The same formula appears in the legacy DesignWare HDMI driver
> (drivers/gpu/drm/bridge/synopsys/dw-hdmi.c, hdmi_set_clk_regenerator())
> under its AHB / GP audio paths.
> Tested on R76S (RK3576) on Armbian-edge mainline 7.0.1 with Cristian
> Ciocaltea's hdptx-clk-fixes v1 series applied:
> TMDS Mode In table? Audio with fix
> 148.5 MHz 1080p60 8-bit yes plays (regression check)
> 185.625 MHz 1080p60 10-bit no plays
> 297 MHz 3840p30 8-bit no plays
> 594 MHz 3840p60 8-bit no plays
> Sinks tested: LG G3 OLED, LG C4 OLED, TCL 75P7K QLED, Kogan
> KALED43XU9210STA (Changhong-OEM 4K LED). Without the fix, the LG
> G3 mutes audio -- this is the originally reported bug
> (linux-rockchip 070633). The LG C4 was verified during this cycle
> to mute at 185.625 MHz (1080p60 10-bit) with the unpatched module.
> The Kogan TV plays audio with or without the fix; it is a
> permissive HDMI 2.0 implementation that does not strictly cross-
> check ACR timing. The TCL 75P7K was tested with the fix loaded
> only.
> Audio plays at every supported sample rate (32 / 44.1 / 48 / 96 /
> 192 kHz) verified on the TCL at the 185.625 MHz out-of-table TMDS
> rate -- the fallback's CTS = (TMDS * N) / (128 * Fs) computation is
> independent of sample rate, as expected.
> The LG C4's CTA-861 SVDs do not advertise 3840x2160@60 over TMDS
> (it is signalled FRL-only on that model), so that one row is N/A
> on the C4. The same audio-path code is exercised at 297 MHz on
> that sink and behaves identically to the G3.
> Reported-by: Simon Wright <simon@symple.nz>
> Closes:
> https://lists.infradead.org/pipermail/linux-rockchip/2026-May/070633.html
> Suggested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> Tested-by: Simon Wright <simon@symple.nz>
> Signed-off-by: Simon Wright <simon@symple.nz>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> index 0dbb1274360..25ac8d3cfc8 100644
> ---a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> +++b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> @@-461,6 +461,21 @@static void dw_hdmi_qp_set_sample_rate(struct
> dw_hdmi_qp *hdmi, unsigned long lo
> n = dw_hdmi_qp_find_n(hdmi, tmds_char_rate, sample_rate);
> cts = dw_hdmi_qp_find_cts(hdmi, tmds_char_rate, sample_rate);
> + /*
> + * dw_hdmi_qp_find_cts() returns 0 for any TMDS rate not in
> + * common_tmds_cts_table[]. Falling through to the controller's
> + * auto-measure path mutes audio on strict HDMI sinks at out-of-
> + * table rates (e.g. 185.625 MHz, 297 MHz, 594 MHz). Compute CTS
> + * from N per HDMI spec instead, so the standard override path
> + * supplies it on the wire.
> + */
> + if (!cts && n) {
> + u64 computed = (u64)tmds_char_rate * n;
> +
> + do_div(computed, 128ULL * sample_rate);
> + cts = (unsigned int)computed;
> + }
> +
> dw_hdmi_qp_set_cts_n(hdmi, cts, n);
> }
Thanks for your patch. I cannot comment on the content but I can point for
formal issues with your submission.
Your patch got mangled by your mailer and cannot be applied. Please don't
try to convince your mailer to send patches the right way: save your time
and use "git-format patch + git send-email", or even better use b4.
Also your commit message is very detailed, and think it would be more
readable if split in paragraphs. You can have a look at various commits in
the kernel log for inspiration.
There's plenty of suggestions on how to send patches in [0], ensure you
read them all.
[0] https://docs.kernel.org/process/submitting-patches.html
Thanks!
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 4/4] driver core: platform: set mod_name in driver registration
From: Greg Kroah-Hartman @ 2026-05-18 10:49 UTC (permalink / raw)
To: Shashank Balaji
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Thierry Reding,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <agrqvIiNWrYtGvTk@JPC00244420>
On Mon, May 18, 2026 at 07:32:28PM +0900, Shashank Balaji wrote:
> On Mon, May 18, 2026 at 12:27:13PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, May 18, 2026 at 07:20:00PM +0900, Shashank Balaji wrote:
> > > Pass KBUILD_MODNAME through the driver registration macro so that
> > > the driver core can create the module symlink in sysfs for built-in
> > > drivers, and fixup all callers.
> > >
> > > The Rust platform adapter is updated to pass the module name through to the new
> > > parameter.
> > >
> > > Tested on qemu with:
> > > - x86 defconfig + CONFIG_RUST
> > > - arm64 defconfig + CONFIG_RUST + CONFIG_CORESIGHT stuff
> > >
> > > Examples after this patch:
> > >
> > > /sys/bus/platform/drivers/...
> > > coresight-itnoc/module -> coresight_tnoc
> > > coresight-static-tpdm/module -> coresight_tpdm
> > > coresight-catu-platform/module -> coresight_catu
> > > serial8250/module -> 8250
> > > acpi-ged/module -> acpi
> > > vmclock/module -> ptp_vmclock
> > >
> > > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > > ---
> > > This patch depends on patches 1, 2, 3
> > > ---
> > > Documentation/driver-api/driver-model/platform.rst | 3 ++-
> > > drivers/base/platform.c | 21 ++++++++++++++-------
> > > drivers/hwtracing/coresight/coresight-core.c | 5 +++--
> > > include/linux/coresight.h | 5 +++--
> > > include/linux/platform_device.h | 17 +++++++++--------
> > > rust/kernel/platform.rs | 4 +++-
> > > 6 files changed, 34 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/Documentation/driver-api/driver-model/platform.rst b/Documentation/driver-api/driver-model/platform.rst
> > > index cf5ff48d3115..9673470bded2 100644
> > > --- a/Documentation/driver-api/driver-model/platform.rst
> > > +++ b/Documentation/driver-api/driver-model/platform.rst
> > > @@ -70,7 +70,8 @@ Kernel modules can be composed of several platform drivers. The platform core
> > > provides helpers to register and unregister an array of drivers::
> > >
> > > int __platform_register_drivers(struct platform_driver * const *drivers,
> > > - unsigned int count, struct module *owner);
> > > + unsigned int count, struct module *owner,
> > > + const char *mod_name);
> >
> > Why can't you just use the owner->name value instead? They are always
> > the same here, right?
>
> owner is NULL for built-in modules.
Ah, sorry, forgot about that.
^ permalink raw reply
* Re: [PATCH 2/2] firmware: samsung: acpm: add Exynos850 support
From: Alexey Klimov @ 2026-05-18 10:46 UTC (permalink / raw)
To: Tudor Ambarus, Sam Protsenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <6802a856-76dc-4bd0-a026-59b0249646af@linaro.org>
On Mon May 18, 2026 at 11:27 AM BST, Tudor Ambarus wrote:
>
>
> On 5/13/26 2:12 AM, Alexey Klimov wrote:
>> The Exynos850 SoC contains an APM co-processor. Communication
>> with this hardware block is established using the ACPM protocol,
>> which handles IPC messages for clocks, power, thermal management,
>> and PMIC control.
>>
>> Add the "samsung,exynos850-acpm-ipc" compatible string along with
>> its associated match data. This includes the specific initialisation
>
> s/initialisation/initialization
Why? Where is the error here?
Also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/doc-guide/contributing.rst?h=v7.1-rc4#n176
"Both American and British English spellings are allowed within the
kernel documentation. There is no need to fix one by replacing it with
the other."
Also looking at git log, plenty of _s_ spellings.
>> data base offset (which differs from the GS101 offset) and the
>> "exynos850-acpm-clk" device name required to properly instantiate
>> the clock provider.
>
> The patch looks alright. With what client did you test it, cpufreq?
>
> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Thanks. As you might be aware this was tested with acpm-based tmu
and with dvfs/cpufreq both on e850-96. They are local changes here but I
can't send all of them in one go -- I need dependencies first.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH 2/2] firmware: samsung: acpm: add Exynos850 support
From: Krzysztof Kozlowski @ 2026-05-18 10:46 UTC (permalink / raw)
To: Tudor Ambarus, Alexey Klimov, Sam Protsenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: Peter Griffin, linux-samsung-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <6802a856-76dc-4bd0-a026-59b0249646af@linaro.org>
On 18/05/2026 12:27, Tudor Ambarus wrote:
>
>
> On 5/13/26 2:12 AM, Alexey Klimov wrote:
>> The Exynos850 SoC contains an APM co-processor. Communication
>> with this hardware block is established using the ACPM protocol,
>> which handles IPC messages for clocks, power, thermal management,
>> and PMIC control.
>>
>> Add the "samsung,exynos850-acpm-ipc" compatible string along with
>> its associated match data. This includes the specific initialisation
>
> s/initialisation/initialization
Hoho, careful, that's a quite hot topic :)
I think we do not have kernel-wide preference here and even if there
was, no need to resend just for that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: arm: aspeed: add Anacapa EVT1 EVT2 board
From: Colin Huang @ 2026-05-18 10:43 UTC (permalink / raw)
To: Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <20260420-garnet-goal-4a284a8818fc@spud>
Conor Dooley <conor@kernel.org> 於 2026年4月20日週一 下午11:36寫道：
>
> On Mon, Apr 20, 2026 at 01:41:30PM +0800, Colin Huang wrote:
> > Conor Dooley <conor@kernel.org> 於 2026年4月9日週四 下午11:36寫道：
> > >
> > > On Thu, Apr 09, 2026 at 07:40:26PM +0800, Colin Huang wrote:
> > > > Document Anacapa BMC EVT1 and EVT2 compatibles.
> > > >
> > > > Signed-off-by: Colin Huang <u8813345@gmail.com>
> > >
> > > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > > pw-bot: not-applicable
> >
> > Hi
> > Could anyone let me know, what is my next step which I need to do?
> > I can't find the changed in for-next branch of
> > https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git .
> > Thanks.
>
> You wait for the merge window to end and the maintainer to apply your
> patches.
Hi
soft-remind for these patches merge.
^ 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