* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Krzysztof Hałasa @ 2026-03-31 10:11 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, 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, Marco Felsch,
Liu Ying
In-Reply-To: <20260330224619.2620782-4-paulk@sys-base.io>
Hi Paul,
Paul Kocialkowski writes:
> 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.
...or "addressed" in the previous version :-)
Test results: it works for me: at 1080p60 and 2160p30. I.e. it fixed the
underrun problem. It's interesting how a CRTC shutdown can affect it's
subsequent start following an SW_RESET.
Or... perhaps it has something to do with the clocks? Also see below.
If somehow the DMA engine was "running" with it's clock disabled, it
would result in an underrun, or worse.
BTW apparently something converted your tab characters into spaces.
> --- 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 */
I guess this comment is not necessarily correct - at 2160p30 one frame =
ca. 33 ms. Still works, though (I guess anything more than one frame is
enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
Also, found an issue. Perhaps unrelated? Powered the board without HDMI
connected. Then connected 1080p60 display. It came in 1024x768, console
64x24 :-)
Run weston. Pressed ctrl-alt-backspace. It deadlocked. Sysrq (serial
console, show blocked state) showed (with *lcdif* in it):
task:systemd-logind state:D stack:0 pid:253 tgid:253 ppid:1 task_flags:0x400100 flags:0x00000800
Call trace:
...
schedule+0x34/0x118
rpm_resume+0x188/0x678
__pm_runtime_resume+0x4c/0x98
clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
clk_core_set_rate_nolock+0xd0/0x2fc
clk_set_rate+0x38/0x158
lcdif_crtc_atomic_enable+0x74/0x8d0
drm_atomic_helper_commit_crtc_enable+0xac/0x104
drm_atomic_helper_commit_tail_rpm+0x68/0xd8
commit_tail+0xa4/0x1a4
drm_atomic_helper_commit+0x178/0x1a0
drm_atomic_commit+0x8c/0xcc
drm_client_modeset_commit_atomic+0x1f8/0x25c
drm_client_modeset_commit_locked+0x60/0x17c
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x2c/0x8c
drm_fb_helper_set_par+0x5c/0x78
fb_set_var+0x190/0x35c
fbcon_blank+0x178/0x24c
do_unblank_screen+0xa8/0x19c
vt_ioctl+0x4fc/0x14c0
tty_ioctl+0x228/0xb88
__arm64_sys_ioctl+0x90/0xe4
...
This is reproducible, though not always.
It seems it locks on some mutex - the shell works until I do 'cat
log.txt' or similar. Now (with std output/error redirection?), weston
doesn't even start.
dmesg doesn't show anything of interest.
weston: 14.0.2
using /dev/dri/card1
DRM: supports atomic modesetting
DRM: supports GBM modifiers
DRM: does not support Atomic async page flip
DRM: supports picture aspect ratio
Loading module '/usr/lib64/libweston-14/gl-renderer.so'
Using rendering device: /dev/dri/renderD128
EGL version: 1.5
EGL vendor: Mesa Project
EGL client APIs: OpenGL OpenGL_ES
...
Registered plugin API 'weston_drm_output_api_v1' of size 40
Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
Color manager: no-op
protocol support: no
Output 'HDMI-A-1' attempts EOTF mode SDR and colorimetry mode default.
Output 'HDMI-A-1' using color profile: stock sRGB color profile
Chosen EGL config details: id: 17 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8
)
Output HDMI-A-1 (crtc 37) video modes:
1920x1080@60.0, preferred, current, 148.5 MHz
Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
Loading module '/usr/lib64/weston/desktop-shell.so'
launching '/usr/libexec/weston-keyboard'
launching '/usr/libexec/weston-desktop-shell'
Warning: computed repaint delay for output [HDMI-A-1] is abnormal: -69164 msec (happens always)
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
Why all these clk* mutexes? Perhaps something didn't work out as it
should there? clk_set_rate isn't supposed to take much time, is it?
$ grep clk /tmp/minicom.cap -C1
[ 728.310054] __pm_runtime_resume+0x4c/0x98
[ 728.310059] clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
[ 728.310065] clk_core_set_rate_nolock+0xd0/0x2fc
[ 728.310071] clk_set_rate+0x38/0x158
[ 728.310076] lcdif_crtc_atomic_enable+0x74/0x8d0
--
[ 728.310210] mutex_lock+0x48/0x58
[ 728.310216] clk_prepare_lock+0x80/0xc0
[ 728.310223] clk_unprepare+0x28/0x44
[ 728.310227] fsl_samsung_hdmi_phy_suspend+0x24/0x40
--
[ 728.310344] mutex_lock+0x48/0x58
[ 728.310350] clk_prepare_lock+0x80/0xc0
[ 728.310359] clk_unprepare+0x28/0x44
[ 728.310364] etnaviv_gpu_clk_disable.isra.0+0x28/0x80
[ 728.310372] etnaviv_gpu_rpm_suspend+0x78/0x1dc
--
[ 728.310494] mutex_lock+0x48/0x58
[ 728.310499] clk_prepare_lock+0x80/0xc0
[ 728.310506] clk_unprepare+0x28/0x44
[ 728.310512] sdhci_esdhc_runtime_suspend+0x7c/0x198
--
[ 728.310627] mutex_lock+0x48/0x58
[ 728.310632] clk_prepare_lock+0x80/0xc0
[ 728.310639] clk_round_rate+0x38/0x1d8
[ 728.310646] dev_pm_opp_set_rate+0xe4/0x2e0
--
[ 728.310760] mutex_lock+0x48/0x58
[ 728.310765] clk_prepare_lock+0x80/0xc0
[ 728.310771] clk_prepare+0x1c/0x50
[ 728.310778] sdhci_esdhc_runtime_resume+0x34/0x180
--
[ 728.311286] mutex_lock+0x48/0x58
[ 728.311292] clk_prepare_lock+0x80/0xc0
[ 728.311298] clk_prepare+0x1c/0x50
[ 728.311303] sdhci_esdhc_runtime_resume+0x34/0x180
Something fishy here.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Lee Jones @ 2026-03-31 10:12 UTC (permalink / raw)
To: Akashdeep Kaur
Cc: praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy, vishalm,
sebin.francis, d-gole, k-willis
In-Reply-To: <20260324101419.95616-3-a-kaur@ti.com>
---
On Tue, 24 Mar 2026, Akashdeep Kaur wrote:
> Currently, the TPS65219 driver unconditionally registers a poweroff
> handler. This causes issues on systems where a different component
> (such as TF-A firmware) should handle system poweroff instead.
>
> Make the poweroff handler registration conditional based on the
> "system-power-controller" device tree property. This follows the
> standard kernel pattern where only the designated power controller
> registers for system poweroff operations.
>
> On systems where the property is absent, the PMIC will not register
> a poweroff handler, allowing other poweroff mechanisms to function.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> drivers/mfd/tps65219.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
> index 7275dcdb7c44..6fa202339a0c 100644
> --- a/drivers/mfd/tps65219.c
> +++ b/drivers/mfd/tps65219.c
> @@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
> return ret;
> }
>
> - ret = devm_register_power_off_handler(tps->dev,
> - tps65219_power_off_handler,
> - tps);
> - if (ret) {
> - dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
> - return ret;
> + if (of_device_is_system_power_controller(tps->dev->of_node)) {
> + ret = devm_register_power_off_handler(tps->dev,
> + tps65219_power_off_handler,
> + tps);
> + if (ret)
> + return dev_err_probe(tps->dev, ret,
> + "failed to register power-off handler\n");
Couple of nits to fix.
The `"` should be aligned with the `(` and the `failed` should be capitalised.
> }
> +
> return 0;
> }
>
> --
> 2.34.1
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Arnd Bergmann @ 2026-03-31 10:11 UTC (permalink / raw)
To: Khristine Andreea Barbulescu, Krzysztof Kozlowski,
Ghennadi Procopciuc
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot, Rob Herring
In-Reply-To: <4c46909d-641b-4389-bc4a-29394cb1d46d@oss.nxp.com>
On Tue, Mar 31, 2026, at 09:48, Khristine Andreea Barbulescu wrote:
>
> With the current layout, the SIUL2 node itself now contains the two
> MMIO ranges directly, while the remaining child node is only the
> pinctrl/GPIO function.
The thread started by saying this is an MFD "It can export information
about the SoC, configure the pinmux&pinconf for pins and it is also
a GPIO controller with interrupt capability." Having a combined
pinctrl/gpio/irqchip driver is normal, but can you clarify what
you plan to do with the "information about the SoC" part?
Was this a "soc_device" driver, or something else? Have you
concluded now that this is not going to be needed at all?
In that case, I guess having a monolithic driver is
indeed simpler than an MFD.
What I wonder about then is whether the binding needs to be changed
at all. With the current nxp,s32g2-siul2-pinctrl.yaml binding
and pinctrl-s32g2.c implementation, you seem to have a monolithic
device already, though missing the gpio functionality. Rather
than completely replacing this, I assume the easiest way then
would be to add the PGPD registers into this device node, right?
It is still a bit weird to list the individual register areas
inside of the larger device here, but that still seems better
than an incompatible binding change.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:13 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <51a05279-1759-4c03-8bba-835a9e972ccb@oss.qualcomm.com>
On 31/03/2026 12:10, Konrad Dybcio wrote:
> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>> and is not modified: neither by the driver defining it nor by common.c
>>>> code using it.
>>>>
>>>> Make it const for code safety and code readability.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> --- a/drivers/clk/qcom/common.h
>>>> +++ b/drivers/clk/qcom/common.h
>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>> size_t num_icc_hws;
>>>> unsigned int icc_first_node_id;
>>>> bool use_rpm;
>>>> - struct qcom_cc_driver_data *driver_data;
>>>> + const struct qcom_cc_driver_data *driver_data;
>>>
>>> This can be a const ptr to const data, even
>>
>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>> they also could. If doing this change, let's make it consistent - so
>> shall all of them be const?
>
> I thought about it, but then it turns out that videocc-sm8550.c has:
>
> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>
> So we'd have to duplicate the entire struct
No, that's not a problem. Pointer is not modified and we speak here
about const pointer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <445a53e3-f467-40fc-9b01-dc776555c3fb@oss.qualcomm.com>
On 3/31/26 12:13 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:10, Konrad Dybcio wrote:
>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>> code using it.
>>>>>
>>>>> Make it const for code safety and code readability.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> --- a/drivers/clk/qcom/common.h
>>>>> +++ b/drivers/clk/qcom/common.h
>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>> size_t num_icc_hws;
>>>>> unsigned int icc_first_node_id;
>>>>> bool use_rpm;
>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>
>>>> This can be a const ptr to const data, even
>>>
>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>> they also could. If doing this change, let's make it consistent - so
>>> shall all of them be const?
>>
>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>
>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>
>> So we'd have to duplicate the entire struct
>
> No, that's not a problem. Pointer is not modified and we speak here
> about const pointer.
Right, I already had constifying the various struct members in mind
Konrad
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Mark Rutland @ 2026-03-31 10:18 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Oliver Upton, Marc Zyngier,
Catalin Marinas
In-Reply-To: <20260330152927.26300-1-will@kernel.org>
On Mon, Mar 30, 2026 at 04:29:26PM +0100, Will Deacon wrote:
> When running with VHE, TPIDR_EL2 is only used for the percpu offset once
> the ARM64_HAS_VIRT_HOST_EXTN capability has been detected, at which
> point cpu_copy_el2regs() will populate its contents from TPIDR_EL1.
>
> Remove the redundant initialisation of TPIDR_EL2 from finalise_el2().
It wasn't clear to me how this worked for both the boot CPU and
secondaries, since they both call finalise_el2(). How about a slightly
more elaborate commit message, e.g.
| Currently, it is not necessary for __finalise_el2() to configure
| TPIDR_EL2:
|
| * The hyp stub code does not consume the value of TPIDR_EL2.
|
| * On the boot cpu, TPIDR_EL1 is used for the percpu offset until the
| ARM64_HAS_VIRT_HOST_EXTN cpucap is detected and boot alternatives
| are patched. Before boot alternatives are patched,
| cpu_copy_el2regs() will copy TPIDR_EL1 into TPIDR_EL2. It is not
| necessary for __finalise_el2() to initialise TPIDR_EL2 before this.
|
| * Secondary CPUs are brought up after boot alternatives have been
| patched, and __secondary_switched() will initialize TPIDR_EL2 in
| 'init_cpu_task', after finalise_el2() calls __finalise_el2()
|
| * KVM hyp code which may consume TPIDR_EL2 is brought up after all
| secondaries have been booted, once TPIDR_El2 has been configured on
| all CPUs.
|
| Remove the redundant initialisation from __finalise_el2().
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
>
> I spotted this by inspection as part of an ill-fated (abandoned) attempt
> at repurposing tpidr_elx for something else.
>
> arch/arm64/kernel/hyp-stub.S | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
> index 085bc9972f6b..8b8614c0b9a5 100644
> --- a/arch/arm64/kernel/hyp-stub.S
> +++ b/arch/arm64/kernel/hyp-stub.S
> @@ -105,11 +105,9 @@ SYM_CODE_START_LOCAL(__finalise_el2)
> msr_hcr_el2 x0
> isb
>
> - // Use the EL1 allocated stack, per-cpu offset
> + // Use the EL1 allocated stack
> mrs x0, sp_el1
> mov sp, x0
> - mrs x0, tpidr_el1
> - msr tpidr_el2, x0
>
> // FP configuration, vectors
> mrs_s x0, SYS_CPACR_EL12
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: patchwork-bot+netdevbpf @ 2026-03-31 10:20 UTC (permalink / raw)
To: Suraj Gupta
Cc: radhey.shyam.pandey, andrew+netdev, davem, edumazet, kuba, pabeni,
michal.simek, sean.anderson, daniel, ariane.keller, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-1-suraj.gupta2@amd.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Mar 2026 13:02:36 +0530 you wrote:
> This patch series fixes two issues in the Xilinx AXI Ethernet driver:
> 1. Corrects the BD length masks to match the AXIDMA IP spec.
> 2. Fixes BQL accounting for multi-BD TX packets.
>
> ---
> Changes in V2:
> - Define BD length masks with GENMASK(25, 0) per PG021.
> - Credit BQL using skb->len on packet completion instead of summing
> per-BD actual lengths from descriptor status.
>
> [...]
Here is the summary with links:
- [net,V2,1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
https://git.kernel.org/netdev/net/c/393e0b4f178e
- [net,V2,2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
https://git.kernel.org/netdev/net/c/d1978d03e867
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:20 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <445a53e3-f467-40fc-9b01-dc776555c3fb@oss.qualcomm.com>
On 31/03/2026 12:13, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:10, Konrad Dybcio wrote:
>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>> code using it.
>>>>>
>>>>> Make it const for code safety and code readability.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> --- a/drivers/clk/qcom/common.h
>>>>> +++ b/drivers/clk/qcom/common.h
>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>> size_t num_icc_hws;
>>>>> unsigned int icc_first_node_id;
>>>>> bool use_rpm;
>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>
>>>> This can be a const ptr to const data, even
>>>
>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>> they also could. If doing this change, let's make it consistent - so
>>> shall all of them be const?
>>
>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>
>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>
>> So we'd have to duplicate the entire struct
>
> No, that's not a problem. Pointer is not modified and we speak here
> about const pointer.
>
So to clarify what the code is doing now: I constified the pointed data.
Not the pointer. If you ask me to constify the pointer itself, it's
fine, it will compile/work as well, but do you want it?
It allows only definition with initialization, no further changes later.
All existing drivers would be fine with it, so just confirm that's your
preferred expression.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] dt-bindings: reset: imx8mq: Add _N suffix to IMX8MQ_RESET_MIPI_CSI*_RESET
From: Robby Cai @ 2026-03-31 10:13 UTC (permalink / raw)
To: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
In-Reply-To: <20260331101331.1405588-1-robby.cai@nxp.com>
The assert logic of the MIPI CSI reset signals is active-low on i.MX8MQ,
but the existing names do not indicate this explicitly. To improve
consistency and clarity, append the _N suffix to all
IMX8MQ_RESET_MIPI_CSI*_RESET definitions. The deprecated
IMX8MQ_RESET_MIPI_CSI*_RESET versions remain temporarily for DT ABI
compatibility and will be removed at an appropriate time in the future.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
include/dt-bindings/reset/imx8mq-reset.h | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/dt-bindings/reset/imx8mq-reset.h b/include/dt-bindings/reset/imx8mq-reset.h
index 705870693ec2..83a155dbbd4a 100644
--- a/include/dt-bindings/reset/imx8mq-reset.h
+++ b/include/dt-bindings/reset/imx8mq-reset.h
@@ -46,12 +46,18 @@
#define IMX8MQ_RESET_PCIEPHY2_PERST 35 /* i.MX8MM/i.MX8MN does NOT support */
#define IMX8MQ_RESET_PCIE2_CTRL_APPS_EN 36 /* i.MX8MM/i.MX8MN does NOT support */
#define IMX8MQ_RESET_PCIE2_CTRL_APPS_TURNOFF 37 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET 39 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET 40 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET 41 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET 42 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET 43 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N 38 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET 39 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET_N 39 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET 40 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET_N 40 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET 41 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET_N 41 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET 42 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET_N 42 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET 43 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET_N 43 /* i.MX8MM/i.MX8MN does NOT support */
#define IMX8MQ_RESET_DDRC1_PRST 44 /* i.MX8MN does NOT support */
#define IMX8MQ_RESET_DDRC1_CORE_RESET 45 /* i.MX8MN does NOT support */
#define IMX8MQ_RESET_DDRC1_PHY_RESET 46 /* i.MX8MN does NOT support */
--
2.37.1
^ permalink raw reply related
* [PATCH 2/2] reset: imx7: Fix handling of MIPI CSI resets on i.MX8MQ
From: Robby Cai @ 2026-03-31 10:13 UTC (permalink / raw)
To: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
In-Reply-To: <20260331101331.1405588-1-robby.cai@nxp.com>
The MIPI CSI reset signals on i.MX8MQ are active-low, but the reset
controller driver previously treated them as active-high, resulting in
incorrect assert/deassert behavior. Update the reset handling logic to
correctly process these active-low reset lines.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
drivers/reset/reset-imx7.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index dd01fe11c5cb..b7048e1f10df 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -202,12 +202,12 @@ static const struct imx7_src_signal imx8mq_src_signals[IMX8MQ_RESET_NUM] = {
[IMX8MQ_RESET_PCIEPHY2_PERST] = { SRC_PCIE2_RCR, BIT(3) },
[IMX8MQ_RESET_PCIE2_CTRL_APPS_EN] = { SRC_PCIE2_RCR, BIT(6) },
[IMX8MQ_RESET_PCIE2_CTRL_APPS_TURNOFF] = { SRC_PCIE2_RCR, BIT(11) },
- [IMX8MQ_RESET_MIPI_CSI1_CORE_RESET] = { SRC_MIPIPHY1_RCR, BIT(0) },
- [IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET] = { SRC_MIPIPHY1_RCR, BIT(1) },
- [IMX8MQ_RESET_MIPI_CSI1_ESC_RESET] = { SRC_MIPIPHY1_RCR, BIT(2) },
- [IMX8MQ_RESET_MIPI_CSI2_CORE_RESET] = { SRC_MIPIPHY2_RCR, BIT(0) },
- [IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET] = { SRC_MIPIPHY2_RCR, BIT(1) },
- [IMX8MQ_RESET_MIPI_CSI2_ESC_RESET] = { SRC_MIPIPHY2_RCR, BIT(2) },
+ [IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N] = { SRC_MIPIPHY1_RCR, BIT(0) },
+ [IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET_N] = { SRC_MIPIPHY1_RCR, BIT(1) },
+ [IMX8MQ_RESET_MIPI_CSI1_ESC_RESET_N] = { SRC_MIPIPHY1_RCR, BIT(2) },
+ [IMX8MQ_RESET_MIPI_CSI2_CORE_RESET_N] = { SRC_MIPIPHY2_RCR, BIT(0) },
+ [IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET_N] = { SRC_MIPIPHY2_RCR, BIT(1) },
+ [IMX8MQ_RESET_MIPI_CSI2_ESC_RESET_N] = { SRC_MIPIPHY2_RCR, BIT(2) },
[IMX8MQ_RESET_DDRC1_PRST] = { SRC_DDRC_RCR, BIT(0) },
[IMX8MQ_RESET_DDRC1_CORE_RESET] = { SRC_DDRC_RCR, BIT(1) },
[IMX8MQ_RESET_DDRC1_PHY_RESET] = { SRC_DDRC_RCR, BIT(2) },
@@ -236,6 +236,12 @@ static int imx8mq_reset_set(struct reset_controller_dev *rcdev,
case IMX8MQ_RESET_PCIE_CTRL_APPS_EN:
case IMX8MQ_RESET_PCIE2_CTRL_APPS_EN:
+ case IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI1_ESC_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI2_CORE_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI2_ESC_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N:
--
2.37.1
^ permalink raw reply related
* [PATCH 0/2] Fix active-low handling of MIPI CSI resets on i.MX8MQ
From: Robby Cai @ 2026-03-31 10:13 UTC (permalink / raw)
To: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
Hi all,
This series updates the Device Tree bindings and reset controller driver
to correctly reflect the active-low polarity of the MIPI CSI reset lines
on i.MX8MQ.
The MIPI CSI reset signals are active-low, but the original reset
identifiers and driver implementation did not clearly indicate or handle
this polarity. Patch 1 updates the DT binding header to add *_RESET_N
variants for the MIPI CSI reset definitions, while keeping the old names
temporarily for DT ABI compatibility. Patch 2 updates the imx7 reset
controller driver to correctly treat these resets as active-low.
Thanks,
Robby
Robby Cai (2):
dt-bindings: reset: imx8mq: Add _N suffix to
IMX8MQ_RESET_MIPI_CSI*_RESET
reset: imx7: Fix handling of MIPI CSI resets on i.MX8MQ
drivers/reset/reset-imx7.c | 18 ++++++++++++------
include/dt-bindings/reset/imx8mq-reset.h | 18 ++++++++++++------
2 files changed, 24 insertions(+), 12 deletions(-)
--
2.37.1
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <7fece0e7-31b0-4b92-855e-bd9e210cc651@oss.qualcomm.com>
On 3/31/26 12:20 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:13, Krzysztof Kozlowski wrote:
>> On 31/03/2026 12:10, Konrad Dybcio wrote:
>>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>>> code using it.
>>>>>>
>>>>>> Make it const for code safety and code readability.
>>>>>>
>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> --- a/drivers/clk/qcom/common.h
>>>>>> +++ b/drivers/clk/qcom/common.h
>>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>>> size_t num_icc_hws;
>>>>>> unsigned int icc_first_node_id;
>>>>>> bool use_rpm;
>>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>>
>>>>> This can be a const ptr to const data, even
>>>>
>>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>>> they also could. If doing this change, let's make it consistent - so
>>>> shall all of them be const?
>>>
>>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>>
>>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>>
>>> So we'd have to duplicate the entire struct
>>
>> No, that's not a problem. Pointer is not modified and we speak here
>> about const pointer.
>>
>
> So to clarify what the code is doing now: I constified the pointed data.
> Not the pointer. If you ask me to constify the pointer itself, it's
> fine, it will compile/work as well, but do you want it?
>
> It allows only definition with initialization, no further changes later.
> All existing drivers would be fine with it, so just confirm that's your
> preferred expression.
I'm actually a little on the verge. Maybe let's keep the current
iteration of this patch after all, as it'd be a mess to undo if it turned
out to be useful
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] clk: qcom: Constify list of critical CBCR registers
From: Konrad Dybcio @ 2026-03-31 10:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-4-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
> The static array 'xxx_critical_cbcrs' contains probe match-like data and
> is not modified: neither by the driver defining it nor by common.c code
> using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH net-next] net: airoha: Set REG_RX_CPU_IDX() once in airoha_qdma_fill_rx_queue()
From: Lorenzo Bianconi @ 2026-03-31 10:33 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev
It is not necessary to update REG_RX_CPU_IDX register for each iteration
of the descriptor loop in airoha_qdma_fill_rx_queue routine.
Move REG_RX_CPU_IDX configuration out of the descriptor loop and rely on
the last queue head value updated in the descriptor loop.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..e09442580f376b6810b6e4023794e93f63dac209 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -572,11 +572,12 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
WRITE_ONCE(desc->msg1, 0);
WRITE_ONCE(desc->msg2, 0);
WRITE_ONCE(desc->msg3, 0);
+ }
+ if (nframes)
airoha_qdma_rmw(qdma, REG_RX_CPU_IDX(qid),
RX_RING_CPU_IDX_MASK,
FIELD_PREP(RX_RING_CPU_IDX_MASK, q->head));
- }
return nframes;
}
---
base-commit: 93d04e76bcf1e81f36f5ea7ad620a07747f1527c
change-id: 20260331-airoha-cpu-idx-out-off-loop-41ea4b99404c
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-31 10:33 UTC (permalink / raw)
To: Ville Syrjälä
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: <acsNoCDsPtEhtkRn@intel.com>
On Tuesday, 31 March 2026 01:56:16 Central European Summer Time Ville Syrjälä wrote:
> 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
Thanks! I'll take a look at this today to get a more solid idea of
where the pain points you highlighted are.
I'll also rebase/reimplement my i915 color format implementation
(sans the DP-MST part, as discussed) on top of this on the next
revision. I was never fully happy with the current one due to the
logic being shoehorned into the already existing i915 fallback
format logic, so I'm quite happy to have another opportunity to
implement it with less historic baggage.
> 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.
I don't know which precise group of people you refer to, but at
least from the Collabora side of things, the userspace Wayland
people are on board with these new properties. In Weston, we use
it to implement the Weston frontend's "color-format" option in a
WIP branch at
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1859
I've also been made aware that LibreELEC is aware, and will look
into making use of it rather than their own kernel patches.
Kind regards,
Nicolas Frattaroli
> >
> > 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.
> >
>
>
^ permalink raw reply
* Re: [PATCH v2 5/7] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-31 10:35 UTC (permalink / raw)
To: Vladimir Oltean
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: <20260330223741.pmrx25cslrlpbcea@skbuf>
On Tue, 2026-03-31 at 01:37 +0300, Vladimir Oltean wrote:
> 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.
Thanks for noticing this, PHY_GMII_SEL_RGMII_ID_MODE and
PHY_GMII_SEL_FIXED_TX_DELAY are missing indeed - will fix in v3. I made the
mistake to rebase from an older kernel version where these flags didn't exist
yet and neglected to double check when the rebase went through without
conflicts. I assume I didn't notice any issues because our bootloader left the
controller in the correct state.
Best,
Nora
>
> > +};
> > +
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Vladimir Zapolskiy @ 2026-03-31 10:43 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-3-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 12:17, Krzysztof Kozlowski wrote:
> The static 'struct qcom_cc_driver_data' contains probe match-like data
> and is not modified: neither by the driver defining it nor by common.c
> code using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 2/2] clk: qcom: Constify list of critical CBCR registers
From: Vladimir Zapolskiy @ 2026-03-31 10:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-4-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 12:17, Krzysztof Kozlowski wrote:
> The static array 'xxx_critical_cbcrs' contains probe match-like data and
> is not modified: neither by the driver defining it nor by common.c code
> using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Arnd Bergmann @ 2026-03-31 10:45 UTC (permalink / raw)
To: Andy Shevchenko, Dmitry Torokhov
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, Bartosz Golaszewski, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, Linux-OMAP
In-Reply-To: <acuMD7Oly4XWW4n8@ashevche-desk.local>
On Tue, Mar 31, 2026, at 10:55, Andy Shevchenko wrote:
> On Mon, Mar 30, 2026 at 11:52:34PM -0700, Dmitry Torokhov wrote:
>> On March 30, 2026 11:25:33 PM PDT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>> >On Mon, Mar 30, 2026 at 02:46:45PM -0700, Dmitry Torokhov wrote:
>>
>> The code section will be discarded when the kernel finishes booting so it
>> only increases image size on disk.
>
> Almost true. Interesting microblaze case, where it's not discarded.
> But I can't find where it's actually used on any architecture.
I'm pretty sure that is just mistake
>> >A bit of archaeology:
>> >
>> >The first time it appeared was in the bcc2152647b8 ("Import 2.4.0-test3pre3").
>> >Then somehow spread a bit (but not much).
>>
>> And it shows how useful it is. Maybe it had some purpose a long time ago, but
>> at present time this code will never be executed since it cannot be built as
>> a module.
>
> Are you sure about definition of __exitcall? As I read init.h the macro
> is defined when it's not a MODULE.
I also tried to trace this back now, and from what I found, both
the __init_call and __exit_call annotations gained __attribute_used__
back in lniux-2.6.0 as a way to prevent both gcc-3.3 and gcc-3.4
from warning about unused functions or discarding initcalls that
are actually required.
My best guess is that __exit_call should just use
__attribute__((unused)) instead of __attribute__((used)) and
have the compiler drop it from built-in code instead of the linker:
diff --git a/include/linux/init.h b/include/linux/init.h
index 5db55c660124..ad5c19763034 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -47,7 +47,7 @@
#define __initdata __section(".init.data")
#define __initconst __section(".init.rodata")
#define __exitdata __section(".exit.data")
-#define __exit_call __used __section(".exitcall.exit")
+#define __exit_call __maybe_unused __section(".exitcall.exit")
/*
* modpost check for section mismatches during the kernel build.
Arnd
^ permalink raw reply related
* Patch "media: nxp: imx8-isi: Fix streaming cleanup on release" has been added to the 6.12-stable tree
From: gregkh @ 2026-03-31 10:55 UTC (permalink / raw)
To: festevam, gregkh, hverkuil+cisco, imx, kernel, laurent.pinchart,
linux-arm-kernel, mchehab, richard.leitner, rob_garcia, s.hauer,
shawnguo
Cc: stable-commits
In-Reply-To: <20260324070507.2554507-1-rob_garcia@163.com>
This is a note to let you know that I've just added the patch titled
media: nxp: imx8-isi: Fix streaming cleanup on release
to the 6.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
media-nxp-imx8-isi-fix-streaming-cleanup-on-release.patch
and it can be found in the queue-6.12 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From stable+bounces-230063-greg=kroah.com@vger.kernel.org Tue Mar 24 08:08:16 2026
From: Robert Garcia <rob_garcia@163.com>
Date: Tue, 24 Mar 2026 15:05:07 +0800
Subject: media: nxp: imx8-isi: Fix streaming cleanup on release
To: stable@vger.kernel.org, Richard Leitner <richard.leitner@linux.dev>
Cc: Hans Verkuil <hverkuil+cisco@kernel.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, linux-media@vger.kernel.org, Robert Garcia <rob_garcia@163.com>, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Message-ID: <20260324070507.2554507-1-rob_garcia@163.com>
From: Richard Leitner <richard.leitner@linux.dev>
[ Upstream commit 47773031a148ad7973b809cc7723cba77eda2b42 ]
The current implementation unconditionally calls
mxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This can
lead to situations where any release call (like from a simple
"v4l2-ctl -l") may release a currently streaming queue when called on
such a device.
This is reproducible on an i.MX8MP board by streaming from an ISI
capture device using gstreamer:
gst-launch-1.0 -v v4l2src device=/dev/videoX ! \
video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \
fakesink
While this stream is running, querying the caps of the same device
provokes the error state:
v4l2-ctl -l -d /dev/videoX
This results in the following trace:
[ 155.452152] ------------[ cut here ]------------
[ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]
[ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6
[ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT
[ 157.064369] Hardware name: imx8mp_board_01 (DT)
[ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]
[ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi]
[ 157.087126] sp : ffff800080003ee0
[ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000
[ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50
[ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000
[ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000
[ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000
[ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38
[ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000
[ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000
[ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200
[ 157.161850] Call trace:
[ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)
[ 157.170319] __handle_irq_event_percpu+0x58/0x218
[ 157.175029] handle_irq_event+0x54/0xb8
[ 157.178867] handle_fasteoi_irq+0xac/0x248
[ 157.182968] handle_irq_desc+0x48/0x68
[ 157.186723] generic_handle_domain_irq+0x24/0x38
[ 157.191346] gic_handle_irq+0x54/0x120
[ 157.195098] call_on_irq_stack+0x24/0x30
[ 157.199027] do_interrupt_handler+0x88/0x98
[ 157.203212] el0_interrupt+0x44/0xc0
[ 157.206792] __el0_irq_handler_common+0x18/0x28
[ 157.211328] el0t_64_irq_handler+0x10/0x20
[ 157.215429] el0t_64_irq+0x198/0x1a0
[ 157.219009] ---[ end trace 0000000000000000 ]---
Address this issue by moving the streaming preparation and cleanup to
the vb2 .prepare_streaming() and .unprepare_streaming() operations. This
also simplifies the driver by allowing direct usage of the
vb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal of
the manual cleanup from mxc_isi_video_release().
Link: https://lore.kernel.org/r/20250813212451.22140-2-laurent.pinchart@ideasonboard.com
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Richard Leitner <richard.leitner@linux.dev> # i.MX8MP
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
[ Minor context change fixed. ]
Signed-off-by: Robert Garcia <rob_garcia@163.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c | 156 +++++++------------
1 file changed, 58 insertions(+), 98 deletions(-)
--- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c
+++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c
@@ -937,6 +937,49 @@ static void mxc_isi_video_init_channel(s
mxc_isi_channel_set_output_format(pipe, video->fmtinfo, &video->pix);
}
+static int mxc_isi_vb2_prepare_streaming(struct vb2_queue *q)
+{
+ struct mxc_isi_video *video = vb2_get_drv_priv(q);
+ struct media_device *mdev = &video->pipe->isi->media_dev;
+ struct media_pipeline *pipe;
+ int ret;
+
+ /* Get a pipeline for the video node and start it. */
+ scoped_guard(mutex, &mdev->graph_mutex) {
+ ret = mxc_isi_pipe_acquire(video->pipe,
+ &mxc_isi_video_frame_write_done);
+ if (ret)
+ return ret;
+
+ pipe = media_entity_pipeline(&video->vdev.entity)
+ ? : &video->pipe->pipe;
+
+ ret = __video_device_pipeline_start(&video->vdev, pipe);
+ if (ret)
+ goto err_release;
+ }
+
+ /* Verify that the video format matches the output of the subdev. */
+ ret = mxc_isi_video_validate_format(video);
+ if (ret)
+ goto err_stop;
+
+ /* Allocate buffers for discard operation. */
+ ret = mxc_isi_video_alloc_discard_buffers(video);
+ if (ret)
+ goto err_stop;
+
+ video->is_streaming = true;
+
+ return 0;
+
+err_stop:
+ video_device_pipeline_stop(&video->vdev);
+err_release:
+ mxc_isi_pipe_release(video->pipe);
+ return ret;
+}
+
static int mxc_isi_vb2_start_streaming(struct vb2_queue *q, unsigned int count)
{
struct mxc_isi_video *video = vb2_get_drv_priv(q);
@@ -985,6 +1028,17 @@ static void mxc_isi_vb2_stop_streaming(s
mxc_isi_video_return_buffers(video, VB2_BUF_STATE_ERROR);
}
+static void mxc_isi_vb2_unprepare_streaming(struct vb2_queue *q)
+{
+ struct mxc_isi_video *video = vb2_get_drv_priv(q);
+
+ mxc_isi_video_free_discard_buffers(video);
+ video_device_pipeline_stop(&video->vdev);
+ mxc_isi_pipe_release(video->pipe);
+
+ video->is_streaming = false;
+}
+
static const struct vb2_ops mxc_isi_vb2_qops = {
.queue_setup = mxc_isi_vb2_queue_setup,
.buf_init = mxc_isi_vb2_buffer_init,
@@ -992,8 +1046,10 @@ static const struct vb2_ops mxc_isi_vb2_
.buf_queue = mxc_isi_vb2_buffer_queue,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
+ .prepare_streaming = mxc_isi_vb2_prepare_streaming,
.start_streaming = mxc_isi_vb2_start_streaming,
.stop_streaming = mxc_isi_vb2_stop_streaming,
+ .unprepare_streaming = mxc_isi_vb2_unprepare_streaming,
};
/* -----------------------------------------------------------------------------
@@ -1147,97 +1203,6 @@ static int mxc_isi_video_s_fmt(struct fi
return 0;
}
-static int mxc_isi_video_streamon(struct file *file, void *priv,
- enum v4l2_buf_type type)
-{
- struct mxc_isi_video *video = video_drvdata(file);
- struct media_device *mdev = &video->pipe->isi->media_dev;
- struct media_pipeline *pipe;
- int ret;
-
- if (vb2_queue_is_busy(&video->vb2_q, file))
- return -EBUSY;
-
- /*
- * Get a pipeline for the video node and start it. This must be done
- * here and not in the queue .start_streaming() handler, so that
- * pipeline start errors can be reported from VIDIOC_STREAMON and not
- * delayed until subsequent VIDIOC_QBUF calls.
- */
- mutex_lock(&mdev->graph_mutex);
-
- ret = mxc_isi_pipe_acquire(video->pipe, &mxc_isi_video_frame_write_done);
- if (ret) {
- mutex_unlock(&mdev->graph_mutex);
- return ret;
- }
-
- pipe = media_entity_pipeline(&video->vdev.entity) ? : &video->pipe->pipe;
-
- ret = __video_device_pipeline_start(&video->vdev, pipe);
- if (ret) {
- mutex_unlock(&mdev->graph_mutex);
- goto err_release;
- }
-
- mutex_unlock(&mdev->graph_mutex);
-
- /* Verify that the video format matches the output of the subdev. */
- ret = mxc_isi_video_validate_format(video);
- if (ret)
- goto err_stop;
-
- /* Allocate buffers for discard operation. */
- ret = mxc_isi_video_alloc_discard_buffers(video);
- if (ret)
- goto err_stop;
-
- ret = vb2_streamon(&video->vb2_q, type);
- if (ret)
- goto err_free;
-
- video->is_streaming = true;
-
- return 0;
-
-err_free:
- mxc_isi_video_free_discard_buffers(video);
-err_stop:
- video_device_pipeline_stop(&video->vdev);
-err_release:
- mxc_isi_pipe_release(video->pipe);
- return ret;
-}
-
-static void mxc_isi_video_cleanup_streaming(struct mxc_isi_video *video)
-{
- lockdep_assert_held(&video->lock);
-
- if (!video->is_streaming)
- return;
-
- mxc_isi_video_free_discard_buffers(video);
- video_device_pipeline_stop(&video->vdev);
- mxc_isi_pipe_release(video->pipe);
-
- video->is_streaming = false;
-}
-
-static int mxc_isi_video_streamoff(struct file *file, void *priv,
- enum v4l2_buf_type type)
-{
- struct mxc_isi_video *video = video_drvdata(file);
- int ret;
-
- ret = vb2_ioctl_streamoff(file, priv, type);
- if (ret)
- return ret;
-
- mxc_isi_video_cleanup_streaming(video);
-
- return 0;
-}
-
static int mxc_isi_video_enum_framesizes(struct file *file, void *priv,
struct v4l2_frmsizeenum *fsize)
{
@@ -1293,9 +1258,8 @@ static const struct v4l2_ioctl_ops mxc_i
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_prepare_buf = vb2_ioctl_prepare_buf,
.vidioc_create_bufs = vb2_ioctl_create_bufs,
-
- .vidioc_streamon = mxc_isi_video_streamon,
- .vidioc_streamoff = mxc_isi_video_streamoff,
+ .vidioc_streamon = vb2_ioctl_streamon,
+ .vidioc_streamoff = vb2_ioctl_streamoff,
.vidioc_enum_framesizes = mxc_isi_video_enum_framesizes,
@@ -1334,10 +1298,6 @@ static int mxc_isi_video_release(struct
if (ret)
dev_err(video->pipe->isi->dev, "%s fail\n", __func__);
- mutex_lock(&video->lock);
- mxc_isi_video_cleanup_streaming(video);
- mutex_unlock(&video->lock);
-
pm_runtime_put(video->pipe->isi->dev);
return ret;
}
Patches currently in stable-queue which might be from rob_garcia@163.com are
queue-6.12/media-nxp-imx8-isi-fix-streaming-cleanup-on-release.patch
^ permalink raw reply
* Re: [PATCH v4] coresight: tpdm: add traceid_show for checking traceid
From: Suzuki K Poulose @ 2026-03-31 10:57 UTC (permalink / raw)
To: Mike Leach, James Clark, Leo Yan, Alexander Shishkin,
Tingwei Zhang, Jie Gan
Cc: Suzuki K Poulose, coresight, linux-arm-kernel, linux-kernel,
Mao Jinlong
In-Reply-To: <20260331-add-traceid-show-for-tpdm-v4-1-ed3dda24a562@oss.qualcomm.com>
On Tue, 31 Mar 2026 18:05:22 +0800, Jie Gan wrote:
> Save the trace ID in drvdata during TPDM enablement and expose it
> to userspace to support trace data parsing.
>
> The TPDM device’s trace ID corresponds to the trace ID allocated
> to the connected TPDA device.
>
>
> [...]
Applied, thanks!
[1/1] coresight: tpdm: add traceid_show for checking traceid
commit: ec687ba84000d7d50cf243558041f6729d1d8119
Best regards,
--
Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()
From: Lorenzo Bianconi @ 2026-03-31 11:01 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260330172857.0c94685d@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4147 bytes --]
> On Fri, 27 Mar 2026 10:48:21 +0100 Lorenzo Bianconi wrote:
> > In order to properly cleanup hw rx QDMA queues and bring the device to
> > the initial state, reset rx DMA queue head/tail index. Moreover, reset
> > queued DMA descriptor fields.
> >
> > Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> > Tested-by: Madhur Agrawal <Madhur.Agrawal@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Take a look at sashiko, please:
> https://sashiko.dev/#/patchset/20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org
>
> Looks somewhat orthogonal to the current patch but probably worth
> fixing.
Hi Jakub,
thx for pointing me to the sashiko's issues.
1- Could this code execute while the interface is still administratively up and
the hardware DMA engines are actively receiving packets?
Looking at the teardown paths, airoha_hw_cleanup() is called before
unregister_netdev(). Unmapping buffers and zeroing descriptor addresses
while the hardware might still be actively writing to them could cause
physical memory corruption and IOMMU faults.
Should unregister_netdev() (which quiesces the DMA via ndo_stop) be called
before airoha_hw_cleanup() to avoid this?
I think the issue described above is already fixed in the following commit
available in net-next:
commit b1c803d5c8167026791abfaed96fd3e6a1fcd750
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Sat Mar 21 15:41:44 2026 +0100
net: airoha: Rework the code flow in airoha_remove() and in airoha_probe() error path
As suggested by Simon in [0], rework the code flow in airoha_remove()
and in the airoha_probe() error path in order to rely on a more common
approach un-registering configured net-devices first and destroying the
hw resources at the end of the code.
Introduce airoha_qdma_cleanup routine to release QDMA resources.
[0] https://lore.kernel.org/netdev/20251214-airoha-fix-dev-registration-v1-1-860e027ad4c6@kernel.org/
Suggested-by: Simon Horman <horms@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260321-airoha-remove-rework-v2-1-16c7bade5fe5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
How can we go ahead on this?
2- This is a pre-existing issue, but while reviewing this cleanup path, I
noticed a potential NULL pointer dereference if initialization fails earlier.
If devm_kzalloc() or dmam_alloc_coherent() fails in airoha_qdma_init_rx_queue(),
it returns an error before netif_napi_add() is called, leaving the embedded
q->napi struct zero-filled.
However, q->ndesc is set earlier in that function. Since q->ndesc is now
non-zero, the error cleanup path will try to disable and delete this
uninitialized NAPI structure, leading to a crash in napi_disable() when it
calls hrtimer_cancel() on the uninitialized timer.
Could we defer setting q->ndesc until after the allocations succeed?
I think it is fine to set 'q->ndesc' at the end of airoha_qdma_init_rx_queue()
routine but, considering net codebase, it seems the issue can't occur since if
airoha_qdma_init_rx_queue() fails as described above, airoha_probe() will jump
to error_hw_cleanup and netif_napi_del() in airoha_hw_cleanup() will return if
NAPI_STATE_LISTED is not set in __netif_napi_del_locked().
Am I missing something?
3- Is there a missing reset for the CPU producer index (REG_RX_CPU_IDX) here?
The hardware DMA relies on the gap between the CPU and DMA indices to
identify valid descriptors. By rewinding the DMA consumer index (REG_RX_DMA_IDX)
to q->tail while leaving the CPU index at its old, advanced value, could
this create a phantom gap of descriptors?
If the DMA engine fetches these zeroed descriptors (with addr = 0), it might
attempt to write incoming packets to physical address 0x0. Both indices might
need to be synchronized.
I will post a fix for it.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v8] arm64: Use static call trampolines when kCFI is enabled
From: Ard Biesheuvel @ 2026-03-31 11:04 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-hardening, will, mark.rutland, Ard Biesheuvel,
Carlos Llamas, Sami Tolvanen, Sean Christopherson, Kees Cook,
Peter Zijlstra, Will McVicker
From: Ard Biesheuvel <ardb@kernel.org>
Implement arm64 support for the 'unoptimized' static call variety, which
routes all calls through a trampoline that performs a tail call to the
chosen function, and wire it up for use when kCFI is enabled. This works
around an issue with kCFI and generic static calls, where the prototypes
of default handlers such as __static_call_nop() and __static_call_ret0()
don't match the expected prototype of the call site, resulting in kCFI
false positives [0].
Since static call targets may be located in modules loaded out of direct
branching range, this needs a ADRP/ADD pair to load the branch target
into R16 and a branch-to-register (BR) instruction to perform an
indirect call. This is the exact code sequence that is used by modules
when the call target is out of direct branching range.
Unlike on x86, there is no pressing need on arm64 to avoid indirect
calls at all cost, but hiding it from the compiler as is done here does
have some benefits:
- the literal is located in .rodata, which gives us the same robustness
advantage that code patching does;
- no D-cache pollution from fetching hash values from .text sections.
From an execution speed PoV, this is unlikely to make any difference at
all.
[0] https://lore.kernel.org/all/20260311225822.1565895-1-cmllamas@google.com/
Cc: Carlos Llamas <cmllamas@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will McVicker <willmcvicker@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
v8: Simplify the trampoline by combining the NULL and RET0 cases, and
dropping the conditional branch and return
v7: https://lore.kernel.org/all/20260313061852.4025964-1-cmllamas@google.com/
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/static_call.h | 31 ++++++++++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/static_call.c | 23 +++++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 1 +
5 files changed, 57 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 38dba5f7e4d2..9ea19b74b6c3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -252,6 +252,7 @@ config ARM64
select HAVE_RSEQ
select HAVE_RUST if RUSTC_SUPPORTS_ARM64
select HAVE_STACKPROTECTOR
+ select HAVE_STATIC_CALL if CFI
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
select HAVE_KRETPROBES
diff --git a/arch/arm64/include/asm/static_call.h b/arch/arm64/include/asm/static_call.h
new file mode 100644
index 000000000000..b73960c949e4
--- /dev/null
+++ b/arch/arm64/include/asm/static_call.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_STATIC_CALL_H
+#define _ASM_STATIC_CALL_H
+
+#define __ARCH_DEFINE_STATIC_CALL_TRAMP(name, target) \
+ asm(" .pushsection .static_call.text, \"ax\" \n" \
+ " .align 4 \n" \
+ " .globl " name " \n" \
+ name ": \n" \
+ " hint 34 /* BTI C */ \n" \
+ " adrp x16, 1f \n" \
+ " ldr x16, [x16, :lo12:1f] \n" \
+ " br x16 \n" \
+ " .type " name ", %function \n" \
+ " .size " name ", . - " name " \n" \
+ " .popsection \n" \
+ " .pushsection .rodata, \"a\" \n" \
+ " .align 3 \n" \
+ "1: .quad " #target " \n" \
+ " .popsection \n")
+
+#define ARCH_DEFINE_STATIC_CALL_TRAMP(name, func) \
+ __ARCH_DEFINE_STATIC_CALL_TRAMP(STATIC_CALL_TRAMP_STR(name), #func)
+
+#define ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) \
+ ARCH_DEFINE_STATIC_CALL_TRAMP(name, __static_call_return0)
+
+#define ARCH_DEFINE_STATIC_CALL_RET0_TRAMP(name) \
+ ARCH_DEFINE_STATIC_CALL_TRAMP(name, __static_call_return0)
+
+#endif /* _ASM_STATIC_CALL_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 76f32e424065..fe627100d199 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_MODULES) += module.o module-plts.o
obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
obj-$(CONFIG_HARDLOCKUP_DETECTOR_PERF) += watchdog_hld.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_HAVE_STATIC_CALL) += static_call.o
obj-$(CONFIG_CPU_PM) += sleep.o suspend.o
obj-$(CONFIG_KGDB) += kgdb.o
obj-$(CONFIG_EFI) += efi.o efi-rt-wrapper.o
diff --git a/arch/arm64/kernel/static_call.c b/arch/arm64/kernel/static_call.c
new file mode 100644
index 000000000000..8b3a19e10871
--- /dev/null
+++ b/arch/arm64/kernel/static_call.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/static_call.h>
+#include <linux/memory.h>
+#include <asm/text-patching.h>
+
+void arch_static_call_transform(void *site, void *tramp, void *func, bool tail)
+{
+ u64 literal;
+ int ret;
+
+ if (!func)
+ func = __static_call_return0;
+
+ /* decode the instructions to discover the literal address */
+ literal = ALIGN_DOWN((u64)tramp + 4, SZ_4K) +
+ aarch64_insn_adrp_get_offset(le32_to_cpup(tramp + 4)) +
+ 8 * aarch64_insn_decode_immediate(AARCH64_INSN_IMM_12,
+ le32_to_cpup(tramp + 8));
+
+ ret = aarch64_insn_write_literal_u64((void *)literal, (u64)func);
+ WARN_ON_ONCE(ret);
+}
+EXPORT_SYMBOL_GPL(arch_static_call_transform);
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 2964aad0362e..2d1e75263f03 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -191,6 +191,7 @@ SECTIONS
LOCK_TEXT
KPROBES_TEXT
HYPERVISOR_TEXT
+ STATIC_CALL_TEXT
*(.gnu.warning)
}
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Suzuki K Poulose @ 2026-03-31 11:05 UTC (permalink / raw)
To: Mathieu Poirier, Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve
In-Reply-To: <acrj-cKphy4hJsEG@p14s>
Hi Mathieu,
On 30/03/2026 21:58, Mathieu Poirier wrote:
> Hi,
>
> On Wed, Mar 18, 2026 at 03:53:34PM +0000, Steven Price wrote:
>> The RMM may not be tracking all the memory of the system at boot. Create
>> the necessary tracking state and GPTs within the RMM so that all boot
>> memory can be delegated to the RMM as needed during runtime.
>>
>> Note: support is currently missing for SROs which means that if the RMM
>> needs memory donating this will fail (and render CCA unusable in Linux).
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> New patch for v13
>> ---
>> arch/arm64/kvm/rmi.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 89 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>> index 9590dff9a2c1..80aedc85e94a 100644
>> --- a/arch/arm64/kvm/rmi.c
>> +++ b/arch/arm64/kvm/rmi.c
>> @@ -4,6 +4,7 @@
>> */
>>
>> #include <linux/kvm_host.h>
>> +#include <linux/memblock.h>
>>
>> #include <asm/kvm_pgtable.h>
>> #include <asm/rmi_cmds.h>
>> @@ -56,6 +57,18 @@ static int rmi_check_version(void)
>> return 0;
>> }
>>
>> +/*
>> + * These are the 'default' sizes when passing 0 as the tracking_region_size.
>> + * TODO: Support other granule sizes
>> + */
>> +#ifdef CONFIG_PAGE_SIZE_4KB
>> +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
>> +#elif defined(CONFIG_PAGE_SIZE_16KB)
>> +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
>> +#elif defined(CONFIG_PAGE_SIZE_64KB)
>> +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
>> +#endif
>> +
>> static int rmi_configure(void)
>> {
>> struct rmm_config *config __free(free_page) = NULL;
>> @@ -95,6 +108,80 @@ static int rmi_configure(void)
>> return 0;
>> }
>>
>> +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
>> +{
>> + start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
>
> This will produce an error on systems where the start of system memory is not
> aligned to RMM_GRANULE_TRACKING_SIZE. For instance, on QEMU-SBSA the system
> memory starts at 0x100_4300_0000. With the above and RMM_GRANULE_TRACKING_SIZE
> set to SZ_1G, @start becomes 0x100_4000_0000, which falls outside the memory map
> known to the TF-A. I fixed it with these modifications:
Thanks for raising this. This would need to be addressed in the RMM
spec, I have raised it with the team and will be addressed soon.
>
> LINUX:
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 10ff1c3bddaf..21bfbbe2f047 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -424,7 +424,9 @@ static int rmi_configure(void)
>
> static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> {
> - start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> + phys_addr_t offset;
> +
> + offset = start - ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
>
> while (start < end) {
> @@ -439,7 +441,13 @@ static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> start);
> return -ENODEV;
> }
> - start += RMM_GRANULE_TRACKING_SIZE;
> +
> + if (offset) {
> + start += (RMM_GRANULE_TRACKING_SIZE - offset);
> + offset = 0;
> + } else {
> + start += RMM_GRANULE_TRACKING_SIZE;
> + }
> }
>
> return 0;
>
> RMM:
>
> diff --git a/runtime/rmi/granule.c b/runtime/rmi/granule.c
> index cef521fc0869..60358d9ee81e 100644
> --- a/runtime/rmi/granule.c
> +++ b/runtime/rmi/granule.c
> @@ -209,9 +209,11 @@ void smc_granule_tracking_get(unsigned long addr,
> return;
> }
>
> +#if 0
> if (!ALIGNED(addr, RMM_INTERNAL_TRACKING_REGION_SIZE)) {
> return;
> }
> +#endif
>
> g = find_granule(addr);
> if (g != NULL) {
>
> This is likely not the right fix but hopefully provides some guidance. Send me
> your patches when you have an idea and I'll test them.
We will send you the update once it is fixed in the RMM spec. The rough
idea is to remove the ALIGNMENT restrictions and return a Range that
the host can iterate over to find "regions" with the same type of
memory.
Cheers
Suzuki
>
> Thanks,
> Mathieu
>
>
>> + end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
>> +
>> + while (start < end) {
>> + unsigned long ret, category, state;
>> +
>> + ret = rmi_granule_tracking_get(start, &category, &state);
>> + if (ret != RMI_SUCCESS ||
>> + state != RMI_TRACKING_FINE ||
>> + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
>> + /* TODO: Set granule tracking in this case */
>> + kvm_err("Granule tracking for region isn't fine/conventional: %llx",
>> + start);
>> + return -ENODEV;
>> + }
>> + start += RMM_GRANULE_TRACKING_SIZE;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static unsigned long rmi_l0gpt_size(void)
>> +{
>> + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
>> + rmm_feat_reg1));
>> +}
>> +
>> +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
>> +{
>> + unsigned long l0gpt_sz = rmi_l0gpt_size();
>> +
>> + start = ALIGN_DOWN(start, l0gpt_sz);
>> + end = ALIGN(end, l0gpt_sz);
>> +
>> + while (start < end) {
>> + int ret = rmi_gpt_l1_create(start);
>> +
>> + if (ret && ret != RMI_ERROR_GPT) {
>> + /*
>> + * FIXME: Handle SRO so that memory can be donated for
>> + * the tables.
>> + */
>> + kvm_err("GPT Level1 table missing for %llx\n", start);
>> + return -ENOMEM;
>> + }
>> + start += l0gpt_sz;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int rmi_init_metadata(void)
>> +{
>> + phys_addr_t start, end;
>> + const struct memblock_region *r;
>> +
>> + for_each_mem_region(r) {
>> + int ret;
>> +
>> + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
>> + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
>> + ret = rmi_verify_memory_tracking(start, end);
>> + if (ret)
>> + return ret;
>> + ret = rmi_create_gpts(start, end);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int rmm_check_features(void)
>> {
>> if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
>> @@ -120,6 +207,8 @@ void kvm_init_rmi(void)
>> return;
>> if (rmi_configure())
>> return;
>> + if (rmi_init_metadata())
>> + return;
>>
>> /* Future patch will enable static branch kvm_rmi_is_available */
>> }
>> --
>> 2.43.0
>>
>>
^ 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