* Re: [PATCHv2] ARM: omap2: simplify allocation for omap_device
From: Kevin Hilman @ 2026-03-30 21:20 UTC (permalink / raw)
To: Rosen Penev, linux-omap
Cc: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Russell King, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM SUB-ARCHITECTURES, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260327191104.206512-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> Use a flexible array member to combine allocations.
>
> Add __counted_by for extra runtime analysis.
>
> Remove goto paths as they are not really needed anymore.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Could you please add a bit more explanation about the *why* behind this
patch. Your description tells us *what* you are doing, but is a bit
light on the *why*.
Thanks,
Kevin
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Martin Blumenstingl @ 2026-03-30 21:25 UTC (permalink / raw)
To: Jun Yan
Cc: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree, robh,
krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet
In-Reply-To: <20260330145111.115318-1-jerrysteve1101@gmail.com>
On Mon, Mar 30, 2026 at 4:53 PM Jun Yan <jerrysteve1101@gmail.com> wrote:
>
> Correct the interrupt number assigned to the Realtek PHY in the p230
>
> following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
> fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
> interrupt improvements [1].
>
> [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
>
> Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms")
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Thank you! I don't have a matching device to verify this myself.
However, it's in line with commit 3106507e1004d ("ARM64: dts:
meson-gxm: fix q200 interrupt number") as IRQ 29 is GPIOZ_15 on GXBB
(but no longer on GXL/GXM). So this gets my:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* [PATCHv3] ARM: omap2: simplify allocation for omap_device
From: Rosen Penev @ 2026-03-30 21:35 UTC (permalink / raw)
To: linux-omap
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM SUB-ARCHITECTURES, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member (FAM) to combine hwmods array allocation
with the omap_device structure. This reduces the number of allocations
from two separate calls (one for the device, one for the array) to a
single allocation, improving efficiency and reducing memory fragmentation.
The FAM approach also enables bounds checking through __counted_by(),
which provides runtime verification that array accesses stay within
the allocated size. This improves security and helps catch bugs during
development.
Simplify error handling by removing the unnecessary multi-label goto
pattern. The new code is more straightforward: allocate, verify, copy
data, and either return success or error immediately.
Also removes the now-redundant kfree(od->hwmods) in omap_device_delete()
since the hwmods array is now embedded in the structure rather than
separately allocated.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v3: add a verbose description explaining why. Powered by Claude Sonnet
4.5.
v2: remove kfree and fix compilation.
arch/arm/mach-omap2/omap_device.c | 29 ++++++++++-------------------
arch/arm/mach-omap2/omap_device.h | 4 ++--
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 79db4c49ffc9..77a75b0b9ae6 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -307,35 +307,27 @@ static struct omap_device *omap_device_alloc(struct platform_device *pdev,
int ret = -ENOMEM;
struct omap_device *od;
int i;
- struct omap_hwmod **hwmods;
+ struct omap_hwmod *hwmod;
- od = kzalloc_obj(struct omap_device);
- if (!od)
- goto oda_exit1;
+ od = kzalloc_flex(*od, hwmods, oh_cnt);
+ if (!od) {
+ dev_err(&pdev->dev, "omap_device: build failed (%d)\n", ret);
+ return ERR_PTR(ret);
+ }
od->hwmods_cnt = oh_cnt;
+ memcpy(od->hwmods, ohs, oh_cnt * sizeof(*od->hwmods));
- hwmods = kmemdup_array(ohs, oh_cnt, sizeof(*hwmods), GFP_KERNEL);
- if (!hwmods)
- goto oda_exit2;
-
- od->hwmods = hwmods;
od->pdev = pdev;
pdev->archdata.od = od;
for (i = 0; i < oh_cnt; i++) {
- hwmods[i]->od = od;
- _add_hwmod_clocks_clkdev(od, hwmods[i]);
+ hwmod = od->hwmods[i];
+ hwmod->od = od;
+ _add_hwmod_clocks_clkdev(od, hwmod);
}
return od;
-
-oda_exit2:
- kfree(od);
-oda_exit1:
- dev_err(&pdev->dev, "omap_device: build failed (%d)\n", ret);
-
- return ERR_PTR(ret);
}
static void omap_device_delete(struct omap_device *od)
@@ -344,7 +336,6 @@ static void omap_device_delete(struct omap_device *od)
return;
od->pdev->archdata.od = NULL;
- kfree(od->hwmods);
kfree(od);
}
diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h
index aa8096ecb23c..fae09cfce137 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -37,11 +37,11 @@
/**
* struct omap_device - omap_device wrapper for platform_devices
* @pdev: platform_device
- * @hwmods: (one .. many per omap_device)
* @hwmods_cnt: ARRAY_SIZE() of @hwmods
* @_state: one of OMAP_DEVICE_STATE_* (see above)
* @flags: device flags
* @_driver_status: one of BUS_NOTIFY_*_DRIVER from <linux/device.h>
+ * @hwmods: (one .. many per omap_device)
*
* Integrates omap_hwmod data into Linux platform_device.
*
@@ -51,11 +51,11 @@
*/
struct omap_device {
struct platform_device *pdev;
- struct omap_hwmod **hwmods;
unsigned long _driver_status;
u8 hwmods_cnt;
u8 _state;
u8 flags;
+ struct omap_hwmod *hwmods[] __counted_by(hwmods_cnt);
};
/* Device driver interface (call via platform_data fn ptrs) */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/2] pwm: meson: Add support for Amlogic S7
From: Martin Blumenstingl @ 2026-03-30 21:44 UTC (permalink / raw)
To: xianwei.zhao
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20260326-s6-s7-pwm-v1-2-67e2f72b98bc@amlogic.com>
Hi Xianwei Zhao,
On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Add support for Amlogic S7 PWM. Amlogic S7 different from the
> previous SoCs, a controller includes one pwm, at the same time,
> the controller has only one input clock source.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> drivers/pwm/pwm-meson.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index 8c6bf3d49753..3d16694e254e 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -113,6 +113,7 @@ struct meson_pwm_data {
> int (*channels_init)(struct pwm_chip *chip);
> bool has_constant;
> bool has_polarity;
> + bool single_pwm;
At first I wasn't sure about this and thought we should replace it
with a num_pwms (or similar) variable.
However, I think it will be hard to add a third (or even more)
channels to the PWM controller (not just from driver perspective but
also from hardware perspective). So I think this is good enough as the
choice will only be 1 or 2.
[...]
> +static const struct meson_pwm_data pwm_s7_data = {
> + .channels_init = meson_pwm_init_channels_s7,
I think you can use .channels_init = meson_pwm_init_channels_s4, if
you change the code inside that function from:
for (i = 0; i < MESON_NUM_PWMS; i++) {
to:
for (i = 0; i < chip->npwm; i++) {
[...]
> @@ -650,9 +674,13 @@ static int meson_pwm_probe(struct platform_device *pdev)
> {
> struct pwm_chip *chip;
> struct meson_pwm *meson;
> + const struct meson_pwm_data *pdata = of_device_get_match_data(&pdev->dev);
> int err;
>
> - chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
> + if (pdata->single_pwm)
> + chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*meson));
> + else
> + chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
I don't think this code is too bad for now.
However, I'm wondering if you want to make "channels" from struct
meson_pwm a flexible array member in a future patch. In that case it
will be helpful to have an "unsigned int npwm = pdata->single_pwm ? 1
: MESON_NUM_PWMS;" (or similar) variable to future-proof your code.
What do you think?
Best regards,
Martin
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Dmitry Torokhov @ 2026-03-30 21:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <acrcDTPpXZ_5A4D8@ashevche-desk.local>
On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
> > Software nodes are currently initialized in a function registered as
> > a postcore_initcall(). However, some devices may want to register
> > software nodes earlier than that (or also in a postcore_initcall() where
> > they're at the merci of the link order). Move the initialization to
> > driver_init() making swnode available much earlier as well as making
> > their initialization time deterministic.
>
> ...
>
> > -static void __exit software_node_exit(void)
> > -{
> > - ida_destroy(&swnode_root_ids);
> > - kset_unregister(swnode_kset);
> > }
> > -__exitcall(software_node_exit);
>
>
> Why? What's wrong with the __exitcall?
>
It's dead code. Always was, always will be.
Maybe split in a separate patch, but I sometimes feel the idea of "one
change" is taken to extreme and adds to both developer's and maintainers
burden by needing to keep track of extra patches.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Martin Blumenstingl @ 2026-03-30 21:47 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
linux-amlogic, devicetree, linux-kernel, kernel test robot,
Krzysztof Kozlowski
In-Reply-To: <20260330-fix-invalid-property-v2-1-228c51c8de93@aliel.fr>
On Mon, Mar 30, 2026 at 2:15 PM Ronald Claveau
<linux-kernel-dev@aliel.fr> wrote:
>
> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>
> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603290828.5gt393t6-lkp@intel.com/
> Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators")
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH] ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
From: Kevin Hilman @ 2026-03-30 21:53 UTC (permalink / raw)
To: Janusz Krzysztofik, Tony Lindgren, linux-omap, Aaro Koskinen
Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <aca7HnXZ-aCSJPW7@darkstar.musicnaut.iki.fi>
On Fri, 27 Mar 2026 19:15:10 +0200, Aaro Koskinen wrote:
> On OMAP16XX, the UART enable bit shifts are written instead of the actual
> bits. This breaks the boot when DEBUG_LL and earlyprintk is enabled;
> the UART gets disabled and some random bits get enabled. Fix that.
Applied, thanks!
[1/1] ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
commit: 7e74b606dd39c46d4378d6f6563f560a00ab8694
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH] ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
From: Kevin Hilman @ 2026-03-30 21:53 UTC (permalink / raw)
To: tony, Julian Braha
Cc: daniel.lezcano, linux, arnd, linux-kernel, linux-omap,
linux-arm-kernel, Thomas Gleixner
In-Reply-To: <20260329183018.519560-1-julianbraha@gmail.com>
On Sun, 29 Mar 2026 19:30:18 +0100, Julian Braha wrote:
> The same kconfig 'select OMAP_INTERCONNECT' appears twice for ARCH_OMAP4.
> I propose removing the second instance, as it is effectively dead code.
>
> This dead code was found by kconfirm, a static analysis tool for Kconfig.
Applied, thanks!
[1/1] ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
commit: 9ceb17ccd15ea32f19c9066f5f1b340d8340bd0b
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH] soc: brcmstb: consolidate initcall functions
From: Florian Fainelli @ 2026-03-30 21:54 UTC (permalink / raw)
To: bcm-kernel-feedback-list, justin.chen, linux-arm-kernel
Cc: Florian Fainelli, kees, florian.fainelli
In-Reply-To: <20260325174619.3761964-1-justin.chen@broadcom.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Wed, 25 Mar 2026 10:46:19 -0700, justin.chen@broadcom.com wrote:
> From: Justin Chen <justin.chen@broadcom.com>
>
> Merge the separate early_initcall and arch_initcall functions into a
> single early_initcall. This is possible thanks to commit 6e12db376b60
> ("base: soc: Allow early registration of a single SoC device"), which
> allows soc_device_register() to be called during early_initcall by
> deferring the actual registration until the soc_bus is ready.
>
> Replace static family_id/product_id variables with a dynamically
> allocated brcmstb_soc_info structure.
>
> Signed-off-by: Justin Chen <justin.chen@broadcom.com>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/drivers/next, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH 0/2] Add PWM support Amlogic S7 S7D S6
From: Martin Blumenstingl @ 2026-03-30 21:54 UTC (permalink / raw)
To: xianwei.zhao
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <20260326-s6-s7-pwm-v1-0-67e2f72b98bc@amlogic.com>
Hi Xianwei Zhao,
thanks for your contribution!
On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
There is an old report that got lost, stating that the current
pwm-meson driver has an off-by-one error with the hi and lo fields:
[0]
Since you are working on bringing up a new platform: is this something
you can verify in your lab?
To be clear: I'm not expecting you to work on this ad-hoc or bring a
patch into this series. However, it would be great if you could verify
if the findings from [0] are correct and send an updated patch in
future.
Thank you and best regards
Martin
[0] https://lore.kernel.org/all/20241225105639.1787237-3-gnstark@salutedevices.com/
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: amlogic: Add new bindings for S6 S7 S7D
From: Martin Blumenstingl @ 2026-03-30 21:58 UTC (permalink / raw)
To: xianwei.zhao
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <20260326-s6-s7-pwm-v1-1-67e2f72b98bc@amlogic.com>
On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Junyi Zhao <junyi.zhao@amlogic.com>
>
> Amlogic S7/S7D/S6 different from the previous SoCs, a controller
> includes one pwm, at the same time, the controller has only one
> input clock source.
>
> Signed-off-by: Junyi Zhao <junyi.zhao@amlogic.com>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
With the two suggestions from Krzysztof added:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH RESEND v4 4/4] drm/rockchip: dw_hdmi_qp: Do not send HPD events for all connectors
From: Cristian Ciocaltea @ 2026-03-30 22:24 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sandy Huang, Andy Yan
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
Diederik de Haas, Maud Spierings
In-Reply-To: <47972235.fMDQidcC6G@phil>
On 3/30/26 7:56 PM, Heiko Stuebner wrote:
> Am Montag, 23. März 2026, 18:45:30 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> In order to optimize the HPD event handling and run the detect cycle on
>> the affected connector only, make use of
>> drm_connector_helper_hpd_irq_event() instead of
>> drm_helper_hpd_irq_event().
>>
>> Additionally, move devm_request_threaded_irq() after bridge connector
>> initialization.
>
> nit: Using "and", "additionally", etc in commit messages, is a strong
> indicator, things should be separate commits.
>
> Especially as the sentence above just explains the "what" but not the
> why (interrupt firing, before the device is actually there probably).
>
> If there are no other changes requested, they can stay together though,
> the "why" is somewhat obvious here.
Ack, will split this up in case a new revision is needed.
>
>
> Both changes themself look fine, so
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Thanks for the review!
Regards,
Cristian
^ permalink raw reply
* [PATCH] arm64: dts: imx8mp-phyboard-pollux: Add HDMI support
From: Paul Kocialkowski @ 2026-03-30 22:37 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel, linux-kernel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Paul Kocialkowski
The PHYTEC phyBOARD Pollux comes with a HDMI port on the base board.
Add the required device-tree nodes to enable support for it.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
.../freescale/imx8mp-phyboard-pollux-rdk.dts | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
index 0fe52c73fc8f..0d52f29813f1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
@@ -38,6 +38,18 @@ fan0: fan {
#cooling-cells = <2>;
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
panel_lvds1: panel-lvds1 {
/* compatible panel in overlay */
backlight = <&backlight_lvds1>;
@@ -201,6 +213,28 @@ &flexcan2 {
status = "okay";
};
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
&i2c2 {
clock-frequency = <400000>;
pinctrl-names = "default", "gpio";
@@ -244,6 +278,10 @@ &i2c3 {
scl-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
};
+&lcdif3 {
+ status = "okay";
+};
+
&ldb_lvds_ch1 {
remote-endpoint = <&panel1_in>;
};
@@ -444,6 +482,15 @@ MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21 0x154
>;
};
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c3
+ MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c3
+ MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x19
+ MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x19
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 5/7] phy: ti: gmii-sel: add support for J722S SoC family
From: Vladimir Oltean @ 2026-03-30 22:37 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <5d00697f133cd33a1df62ac7ebf73e507e49ed2f.1774354734.git.nora.schiffer@ew.tq-group.com>
Hi Nora,
On Tue, Mar 24, 2026 at 01:29:41PM +0100, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
> index 6213c2b6005a5..4e242b1892334 100644
> --- a/drivers/phy/ti/phy-gmii-sel.c
> +++ b/drivers/phy/ti/phy-gmii-sel.c
> @@ -251,6 +251,13 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
> .regfields = phy_gmii_sel_fields_am654,
> };
>
> +static const
> +struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
> + .use_of_data = true,
> + .regfields = phy_gmii_sel_fields_am654,
> + .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
I'm not familiar with the hardware, but "mostly identical to AM64, but
additionally supports SGMII" does not explain why j722s does not inherit
the features that am654 has (PHY_GMII_SEL_RGMII_ID_MODE and
BIT(PHY_GMII_SEL_FIXED_TX_DELAY).
The phy-gmii-sel from j722s does support RGMII, right? Because in lack
of the PHY_GMII_SEL_RGMII_ID_MODE feature, phy_gmii_sel_mode() will just
silently skip the regmap_field_write(regfield, rgmii_id) call, and
return successfully despite an incomplete configuration.
We have the phy_validate() call and phy_ops::validate() through which
the PHY can report to the Ethernet controller which phy_interface_t it
supports and which it doesn't. If the j722s doesn't support RGMII, maybe
it should implement this method.
> +};
> +
^ permalink raw reply
* Re: [PATCH v2 0/2] regulator: mt6315: add regulator supplies
From: Mark Brown @ 2026-03-30 14:45 UTC (permalink / raw)
To: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Chen-Yu Tsai
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260326081050.1115201-1-wenst@chromium.org>
On Thu, 26 Mar 2026 16:10:47 +0800, Chen-Yu Tsai wrote:
> regulator: mt6315: add regulator supplies
>
> Hi,
>
> This is v2 of the "Add MT6315 regulator supplies" series.
>
> Changes since v1:
> - Link to v1: https://lore.kernel.org/all/20260324053030.4077453-1-wenst@chromium.org/
> - Move supplies to top level node, at the same level as the compatible
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/2] regulator: dt-bindings: mt6315: Add regulator supplies
https://git.kernel.org/broonie/regulator/c/d15d0f1a27b2
[2/2] regulator: mt6315: Add regulator supplies
https://git.kernel.org/broonie/regulator/c/292d64fb98a2
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] spi: stm32-ospi: Fix resource leak in remove() callback
From: Mark Brown @ 2026-03-30 12:22 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Patrice Chotard, Felix Gu
Cc: linux-spi, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260329-ospi-v1-1-cc8cf1c82c4a@gmail.com>
On Sun, 29 Mar 2026 19:14:05 +0800, Felix Gu wrote:
> spi: stm32-ospi: Fix resource leak in remove() callback
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.0
Thanks!
[1/1] spi: stm32-ospi: Fix resource leak in remove() callback
https://git.kernel.org/broonie/sound/c/73cd1f97946a
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
* [PATCH 0/3] drm: lcdif: FIFO underrun/solid color bug fix
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
This series brings a fix for the FIFO underrun/solid color bug (in the
last commit) and two other changes that may help with reliability.
Paul Kocialkowski (3):
drm: lcdif: Set undocumented bit to clear FIFO at vsync
drm: lcdif: Use dedicated set/clr registers for polarity/edge
drm: lcdif: Wait for vblank before disabling DMA
drivers/gpu/drm/mxsfb/lcdif_kms.c | 42 ++++++++++++++++++++++++------
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 35 insertions(+), 8 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 1/3] drm: lcdif: Set undocumented bit to clear FIFO at vsync
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
There is an undocumented bit used in the NXP BSP to clear the FIFO
systematically at vsync. In normal operation, the FIFO should already
be empty but it doesn't hurt to add it as an extra safety measure.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 3 ++-
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index ef3250a5c54f..a00c4f6d63f4 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -338,7 +338,8 @@ static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
* Downstream set it to 256B burst size to improve the memory
* efficiency so set it here too.
*/
- ctrl = CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
+ ctrl = CTRLDESCL0_3_STATE_CLEAR_VSYNC |
+ CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
CTRLDESCL0_3_PITCH(lcdif->crtc.primary->state->fb->pitches[0]);
writel(ctrl, lcdif->base + LCDC_V8_CTRLDESCL0_3);
}
diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h b/drivers/gpu/drm/mxsfb/lcdif_regs.h
index c55dfb236c1d..17882c593d27 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_regs.h
+++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h
@@ -190,6 +190,7 @@
#define CTRLDESCL0_1_WIDTH(n) ((n) & 0xffff)
#define CTRLDESCL0_1_WIDTH_MASK GENMASK(15, 0)
+#define CTRLDESCL0_3_STATE_CLEAR_VSYNC BIT(23)
#define CTRLDESCL0_3_P_SIZE(n) (((n) << 20) & CTRLDESCL0_3_P_SIZE_MASK)
#define CTRLDESCL0_3_P_SIZE_MASK GENMASK(22, 20)
#define CTRLDESCL0_3_T_SIZE(n) (((n) << 16) & CTRLDESCL0_3_T_SIZE_MASK)
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
The lcdif v3 hardware comes with dedicated registers to set and clear
polarity bits in the CTRL register. It is unclear if there is a
difference with writing to the CTRL register directly.
Follow the NXP BSP reference by using these registers, in case there is
a subtle difference caused by using them.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index a00c4f6d63f4..1aac354041c7 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -296,18 +296,27 @@ static void lcdif_set_formats(struct lcdif_drm_private *lcdif,
static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
{
struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
- u32 ctrl = 0;
+ u32 ctrl;
if (m->flags & DRM_MODE_FLAG_NHSYNC)
- ctrl |= CTRL_INV_HS;
+ writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
+
if (m->flags & DRM_MODE_FLAG_NVSYNC)
- ctrl |= CTRL_INV_VS;
+ writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
+
if (bus_flags & DRM_BUS_FLAG_DE_LOW)
- ctrl |= CTRL_INV_DE;
- if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
- ctrl |= CTRL_INV_PXCK;
+ writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_CLR);
- writel(ctrl, lcdif->base + LCDC_V8_CTRL);
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
+ writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_SET);
+ else
+ writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_CLR);
writel(DISP_SIZE_DELTA_Y(m->vdisplay) |
DISP_SIZE_DELTA_X(m->hdisplay),
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
It is necessary to wait for the full frame to finish streaming
through the DMA engine before we can safely disable it by removing
the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
hardware confused and unable to resume streaming for the next frame.
This causes the FIFO underrun and empty status bits to be set and
a single solid color to be shown on the display, coming from one of
the pixels of the previous frame. The issue occurs sporadically when
a new mode is set, which triggers the crtc disable and enable paths.
Setting the shadow load bit and waiting for it to be cleared by the
DMA engine allows waiting for completion.
The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 1aac354041c7..7dce7f48d938 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
if (ret)
drm_err(lcdif->drm, "Failed to disable controller!\n");
+ /*
+ * It is necessary to wait for the full frame to finish streaming
+ * through the DMA engine before we can safely disable it by removing
+ * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
+ * hardware confused and unable to resume streaming for the next frame.
+ */
+ reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
+ reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
+ writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
+
+ ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
+ reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
+ 0, 36000); /* Wait ~2 frame times max */
+ if (ret)
+ drm_err(lcdif->drm, "Failed to disable controller!\n");
+
reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
reg &= ~DISP_PARA_DISP_ON;
writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control
From: Cristian Ciocaltea @ 2026-03-30 22:56 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, kernel, linux-phy,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260330085723.4rewkbs76lz3scum@skbuf>
On 3/30/26 11:57 AM, Vladimir Oltean wrote:
> On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
>> During HDMI 2.1 Fixed Rate Link training, the source and sink may
>> negotiate a Transmitter Feed Forward Equalizer (TxFFE) level to
>> compensate for signal quality degradation on the physical channel. The
>> source starts at level 0 and may increment it up to a maximum agreed
>> upon during LTS3 in response to persistent link failures reported by the
>> sink. TxFFE adjustment is optional and entirely independent of the FRL
>> rate and lane count selection.
>>
>> Patch 1 extends the HDMI PHY configuration API with two new fields in
>> the frl sub-struct: ffe_level to carry the requested level, and a
>> set_ffe_level flag that switches the semantics of a phy_configure() call
>> to a pure equalizer update, leaving all other fields ignored.
>>
>> Patch 2 implements the new interface in the Rockchip Samsung HDPTX PHY
>> driver.
>>
>> The series depends on the "[PATCH 0/6] phy: rockchip: samsung-hdptx:
>> Clock fixes and API transition cleanups" patchset:
>>
>> https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> Cristian Ciocaltea (2):
>> phy: hdmi: Add optional FRL TxFFE config options
>> phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
>>
>> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
>> include/linux/phy/phy-hdmi.h | 6 ++
>> 2 files changed, 75 insertions(+), 5 deletions(-)
>> ---
>> base-commit: f7b64ed948718290209074a50bb0df17e5944873
>> change-id: 20260328-hdptx-ffe-a89c51e66904
>> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
>> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
>> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
>> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
>> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
>> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
>> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
>
> Sorry for my ignorance; who is supposed to act upon this git-format-patch
> base tree information and in what way?
>
> As things stand today, the build infrastructure we have in place will
> not be able to apply and test your series unless it applies directly
> onto the linux-phy/next branch.
Oh, I assumed that since b4 makes managing series dependencies straightforward
on the preparation/submission side, there would be similar tooling support on
the build/integration side as well.
^ permalink raw reply
* Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control
From: Vladimir Oltean @ 2026-03-30 23:35 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, kernel, linux-phy,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <f2827d9f-ddba-4fbd-8d1f-a1a2d1b94708@collabora.com>
On Tue, Mar 31, 2026 at 01:56:32AM +0300, Cristian Ciocaltea wrote:
> On 3/30/26 11:57 AM, Vladimir Oltean wrote:
> > On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
> >> ---
> >> base-commit: f7b64ed948718290209074a50bb0df17e5944873
> >> change-id: 20260328-hdptx-ffe-a89c51e66904
> >> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
> >> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
> >> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
> >> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
> >> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
> >> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
> >> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
> >
> > Sorry for my ignorance; who is supposed to act upon this git-format-patch
> > base tree information and in what way?
> >
> > As things stand today, the build infrastructure we have in place will
> > not be able to apply and test your series unless it applies directly
> > onto the linux-phy/next branch.
>
> Oh, I assumed that since b4 makes managing series dependencies straightforward
> on the preparation/submission side, there would be similar tooling support on
> the build/integration side as well.
Sorry to disappoint - linux-phy doesn't use b4 to build-test patches. It
gets them from Patchwork directly (as you'd get by clicking the 'diff' button),
then figures out whether to apply to the next or to the fixes branch
using the git-format-patch --subject-prefix string ('phy-next' or 'phy-fixes'),
then posts the checks back to Patchwork.
I can somehow imagine why no one rushed to improve this. While sometimes
somewhat useful, I can see the risk of such feature getting abused to
create a giant cobweb of dependencies that is suddenly no longer the
developer's problem, but passed on to somebody else.
In the future, please submit as RFC the patch sets that you know don't
directly apply, and mention that you're only posting them for early
feedback.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: stmmac: TSO fixes/cleanups
From: Jakub Kicinski @ 2026-03-30 23:42 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <acl0pTqJ97o0PRxY@shell.armlinux.org.uk>
On Sun, 29 Mar 2026 19:51:17 +0100 Russell King (Oracle) wrote:
> > While I have you - you have a significantly negative "reviewer score".
> > You post much more than you review. Which should earn you extra 24h
> > of delay in our system. I've been trying to ignore that and prioritize
> > applying your patches but it'd be great if you could review a bit more.
>
> Sorry, but given the effort that stmmac is taking, I don't have much
> capacity to extend mental cycles elsewhere.
>
> This two patch series wouldn't have exploded into ten (or maybe even
> more) patches had someone not pointed out the problem with
> suspend/resume interacting with disabling TSO... which prompted me to
> look deeper and discover a multitude of other problems. Should I
> instead ignore these bugs and not bother trying to fix this stuff?
>
> Honestly, I'm getting tired of stmmac with it sucking lots of my time,
> and I suspect you're getting tired of the constant stream of patches
> for it - but the reason there's a constant stream is because there's
> so much that's wrong or broken in this driver.
>
> So either we let the driver rot, or... what?
I was hoping to nudge you towards reviewing more rather than have you
slow down TBH :) Your patches are generally excellent so not a burden
for my PoV. And stmmac is a toilet, a very popular one at that, so
efforts to clean it up are most appreciated. If you could review a
couple of series every time you post - the balance should be restored
to our tooling universe.
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-30 23:56 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acclgID7lSVNten2@intel.com>
On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrjälä wrote:
> On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > > > + * semantics.
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > +
> > > > > > > > > > > > + /**
> > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > + */
> > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > >
> > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > should be for each format.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > by other properties.
> > > > > > > > > >
> > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > >
> > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > >
> > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > >
> > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > field of its own?
> > > > > > >
> > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > I think the assumption is limited range everywhere.
> > > > > > >
> > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > will want to know what the new property actually does so the
> > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > is no clear specification.
> > > > > >
> > > > > > Ack
> > > > > >
> > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > - YCbCr limited range
> > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > >
> > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > anything else full range?
> > > > >
> > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > those would always go hand in hand now.
> > > >
> > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > and uses the HDMI state helpers.
> > > >
> > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > drm_default_rgb_quant_range() which seems suspicious?
> > >
> > > If they want just manual full vs. limited then they should
> > > limit the property to not expose the "auto" option at all.
> > >
> > > amdgpu also ties this in with the "colorspace" property, which
> > > originally in i915 only controlled the infoframes/etc. But on
> > > amdgpu it now controls various aspects of output color
> > > transformation. The end result is that the property is a complete
> > > mess with most of the values making no sense. And for whatever
> > > reason everyone involved refused to remove/deprecate the
> > > nonsensical values :/
> > >
> > > Looks like this series should make sure the documentation for
> > > the "colorspace" property is in sync with the new property
> > > as well. Currently now it's giving conflicting information.
> > >
> >
> > I take it the problematic information is in
> >
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> >
> > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > that they "produce RGB content".
> >
> > I think we probably just have to change the statement "The variants
> > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > RGB and YCbCr on its own."
> >
> > The "on its own" here would get turned into "based on the color format
> > property".
> >
> > Speaking of i915, that patch is one of the very few (5) patches in
> > this series still lacking a review (hint hint nudge nudge). I'd like
> > to get some more feedback on the remaining patches before I send out
> > another revision, so that it's hopefully not just docs changes (I
> > know better than to think those patches must be perfect and won't
> > need revision.)
>
> The i915 code around this is already a big mess, and I don't really
> adding to that mess. So I think we'll need to do some refactoring before
> we add anything there. I already started typing something and so far
> it looks fairly straightforward, so I should have something soon.
OK, posted something
https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@linux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f
Are the wayland/compositor/color management folks on board with
these new properties? I don't think I see the usual suspects on
the cc list.
>
> While doing that several questions came to my mind though:
>
> * More interactions with the colorspace property, but I sent
> a separate mail already about that
>
> * Which conversion matrix to use, and the answer I suspect
> should be "ask the colorspace property", as mentioned in the
> other mail
>
> * Should we flat out reject color formats (and I suppose also
> colorspace prop values) the sink doesn't claim to support?
>
> If yes, then I think we'll have to forget about adding anything
> to i915 MST code. The way the MST stuff works is that if one
> stream needs a modeset then all the related streams get modeset
> as well. Thus if the user replaces a monitor getting fed with a
> YCbCr stream just as another stream is being modeset, then the
> entire atomic commit could fail due to the YCbCr stream getting
> rejected.
>
> I think eventually we might have to invent some mechanism where
> all the input into the modeset computation is cached somehow,
> and said cache updated only on explicit userspace modesets.
> Either that or we have to come up with a way to skip some of
> the calculations that depend on external factors. Either way
> it's going to be a pain.
>
> OTOH if we don't mind feeding the sink with stuff it can't
> understand, then I suppose we might add YCbCr 4:4:4 support
> for MST. It shouldn't be any different from RGB apart from
> the RGB->YCbCr conversion, which is handled elsewhere. But
> YCbCr 4:2:0 is definitely out either way, the MST code has
> no support for that currently.
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
^ permalink raw reply
* [PATCH] drm/mediatek: simplify mtk_crtc allocation
From: Rosen Penev @ 2026-03-31 0:23 UTC (permalink / raw)
To: dri-devel
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno,
moderated list:DRM DRIVERS FOR MEDIATEK,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use a flexible array member to combine allocations.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
index fcb16f3f7b23..914841d2396e 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -62,7 +62,6 @@ struct mtk_crtc {
struct device *dma_dev;
struct mtk_mutex *mutex;
unsigned int ddp_comp_nr;
- struct mtk_ddp_comp **ddp_comp;
unsigned int num_conn_routes;
const struct mtk_drm_route *conn_routes;
@@ -71,6 +70,8 @@ struct mtk_crtc {
bool config_updating;
/* lock for config_updating to cmd buffer */
spinlock_t config_lock;
+
+ struct mtk_ddp_comp *ddp_comp[];
};
struct mtk_crtc_state {
@@ -1048,18 +1049,12 @@ int mtk_crtc_create(struct drm_device *drm_dev, const unsigned int *path,
}
}
- mtk_crtc = devm_kzalloc(dev, sizeof(*mtk_crtc), GFP_KERNEL);
+ mtk_crtc = devm_kzalloc(dev, struct_size(mtk_crtc, ddp_comp, path_len + (conn_routes ? 1 : 0)), GFP_KERNEL);
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->ddp_comp_nr = path_len;
- mtk_crtc->ddp_comp = devm_kcalloc(dev,
- mtk_crtc->ddp_comp_nr + (conn_routes ? 1 : 0),
- sizeof(*mtk_crtc->ddp_comp),
- GFP_KERNEL);
- if (!mtk_crtc->ddp_comp)
- return -ENOMEM;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
mtk_crtc->mutex = mtk_mutex_get(priv->mutex_dev);
if (IS_ERR(mtk_crtc->mutex)) {
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox