* [PATCH v3] arm: multi_v7_defconfig: Enable BRIDGE and DP83848_PHY for TI AM57xx, AM437x and AM335x
From: Parvathi Pudi @ 2026-03-31 14:10 UTC (permalink / raw)
To: nm, vigneshr, linux, ardb, ebiggers, krzysztof.kozlowski, khilman,
arnd, geert+renesas, parvathi, tiwai, kory.maincent, andreas,
dmitry.baryshkov, prabhakar.mahadev-lad.rj, twoerner
Cc: linux-arm-kernel, linux-kernel, pratheesh, j-rameshbabu, praneeth,
srk, rogerq, danishanwar, m-malladi, krishna, mohan, pmohan,
basharath
This patch enables BRIDGE and DP83848_PHY as kernel modules for AM57xx,
AM437x and AM335x SoCs. BRIDGE is to support STP/RSTP Switch mode using
PRU-ICSS which got recently merged and DP83848 PHY driver to support
TI TLK10X PHY.
Signed-off-by: Parvathi Pudi <parvathi@couthit.com>
---
Changes from v2 to v3 :
*) No changes were made, only the version was updated.
*) Rebased the series on latest linux-next.
Changes from v1 to v2 :
*) Addressed Krzysztof's comments on this patch.
*) Rebased the series on latest linux-next.
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc1202..13362286b111 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -149,6 +149,7 @@ CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_BRIDGE=m
CONFIG_NET_DSA=m
CONFIG_QRTR=m
CONFIG_QRTR_SMD=m
@@ -288,6 +289,7 @@ CONFIG_ICPLUS_PHY=y
CONFIG_MARVELL_PHY=y
CONFIG_AT803X_PHY=y
CONFIG_ROCKCHIP_PHY=y
+CONFIG_DP83848_PHY=m
CONFIG_DP83867_PHY=y
CONFIG_CAN_AT91=m
CONFIG_CAN_FLEXCAN=m
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Liviu Dudau @ 2026-03-31 14:31 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Jiyu Yang
In-Reply-To: <20260331-master-v1-1-65c8e318d462@nxp.com>
On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> Add compatible string of Mali G310 GPU on i.MX952 board.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> index 8eccd4338a2b..6a10843a26e2 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> @@ -20,6 +20,7 @@ properties:
> - enum:
> - mediatek,mt8196-mali
> - nxp,imx95-mali # G310
> + - nxp,imx952-mali # G310
Can you explain why this is needed? Can it not be covered by the existing compatible?
Best regards,
Liviu
> - rockchip,rk3588-mali
> - const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
>
>
> --
> 2.34.1
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v7 1/5] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
From: Maíra Canal @ 2026-03-31 14:32 UTC (permalink / raw)
To: Mark Brown
Cc: Michael Turquette, Stephen Boyd, Nicolas Saenz Julienne,
Florian Fainelli, Stefan Wahren, Maxime Ripard, Melissa Wen,
Iago Toral Quiroga, Chema Casanova, Dave Stevenson, Philipp Zabel,
linux-clk, dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev
In-Reply-To: <5f0bec08-f458-4fba-8bf3-06817a100c4c@sirena.org.uk>
Hi Mark,
Thanks for reporting this issue!
On 31/03/26 09:49, Mark Brown wrote:
> On Thu, Mar 12, 2026 at 06:34:23PM -0300, Maíra Canal wrote:
>
>> On current firmware versions, RPI_FIRMWARE_SET_CLOCK_STATE doesn't
>> actually power off the clock. To achieve meaningful power savings, the
>> clock rate must be set to the minimum before disabling. This might be
>> fixed in future firmware releases.
>
>> Rather than pushing rate management to clock consumers, handle it
>> directly in the clock framework's prepare/unprepare callbacks. In
>> unprepare, set the rate to the minimum before disabling the clock.
>> In prepare, for clocks marked with `maximize` (currently v3d),
>> restore the rate to the maximum after enabling.
>
> I'm seeing boot regressions in -next with NFS root on Raspberry Pi 3B+
> which bisect to this commit. We get a likely unrelated oops from the
> firmware interface and the boot grinds to a halt some time later since
> the ethernet never comes up:
>
> [ 21.898686] Firmware transaction 0x00030066 timeout
> [ 21.898769] WARNING: drivers/firmware/raspberrypi.c:128 at rpi_firmware_property_list+0x200/0x280, CPU#2: (udev-worker)/115
>
> ...
>
> [ 22.067074] Call trace:
> [ 22.069538] rpi_firmware_property_list+0x200/0x280 (P)
> [ 22.074824] rpi_firmware_property+0x70/0xb8
> [ 22.079140] vc4_drm_bind+0x12c/0x354 [vc4]
> [ 22.083368] try_to_bring_up_aggregate_device+0x16c/0x1e0
> [ 22.088831] component_master_add_with_match+0xb0/0xec
> [ 22.094027] vc4_platform_drm_probe+0xc0/0xfc [vc4]
> [ 22.098961] platform_probe+0x5c/0xa4
>
I've managed to address this issue locally with the following diff:
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b/drivers/clk/bcm/clk-raspberrypi.c
index df2d246eb6ef..ef5ae3b4adca 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -160,6 +160,7 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = {
[RPI_FIRMWARE_VEC_CLK_ID] = {
.export = true,
.minimize = true,
+ .flags = CLK_IGNORE_UNUSED,
},
[RPI_FIRMWARE_DISP_CLK_ID] = {
.export = true,
It looks like the VEC_CLK can't be disabled at boot time. Otherwise, a
bus lookup will happen (similar what happens to other RPi firmware
clocks).
Is it possible for me to test this change in LAVA CI before sending it
to the list? Just to double check that this patch indeed fixes the
issue on your side as well.
Best regards,
- Maíra
> [0;1;31mTimed out while waiting for udev queue to empty.[0m
> Begin: Loading essential drivers ... done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ... Begin: Running /scripts/nfs-top ... done.
> Begin: Running /scripts/nfs-premount ... Waiting up to 60 secs for any ethernet to become available
>
> Full log:
> https://lava.sirena.org.uk/scheduler/job/2617478#L1124
>
> bisect log:
>
> # bad: [cf7c3c02fdd0dfccf4d6611714273dcb538af2cb] Add linux-next specific files for 20260330
> # good: [a010730e610019b6d010ec43ce737cb59a37809d] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
> # good: [3398da5432899c09712f30c92a154f3bf760a3e7] Merge branch 'clk-renesas' into clk-next
> # good: [777bc3284f0360c66ac75a44f35fc96053536ca4] Merge branch 'clk-cleanup' into clk-next
> # good: [f520a492e07bc6718e26cfb7543ab4cadd8bb0e2] clk: xgene: Fix mapping leak in xgene_pllclk_init()
> # good: [aeb078cebc40d421f61a8f07b0e7919aeb44d751] arm64: dts: broadcom: bcm2712-d-rpi-5-b: add fixes for pinctrl/pinctrl_aon
> # good: [9be71d462c33b1a00acfa4ab8f0f5332ed592817] firmware: cs_dsp: Simplify suppressing log messages during KUnit testing
> # good: [7b3f8db159f710d432c4edc024fcefa9e62e8b4b] ASoC: fsl_xcvr: add bitcount and timestamp controls
> # good: [8fc5c7895185d1119ae76b509892a1d14e0bd483] ASoC: wm_adsp: Combine some similar code in firmware file search
> # good: [981b080a79724738882b0af1c5bb7ade30d94f24] spi: fsl-qspi: Use reinit_completion() for repeated operations
> # good: [ed0313223ce6514dbd39c049e25f702980d7e3cc] ASoC: codecs: wcd9335: Remove potential undefined behavior in wcd9335_slimbus_irq()
> # good: [97af961568c8682c44506c9ad4b26c8a5455ec1d] ASoC: cs35l56: Put OTP register defines in correct address order
> # good: [0a208adefecb287d22321054470d4619cb303839] ASoC: cs42l43: Add support for the B variant
> # good: [a8075ada4a341ce58ebf8bef0188cefe6c2f6487] ASoC: ti: davinci-mcasp: improve aux_div selection for mid-range dividers
> # good: [82169065ffb07577075a5088b313d78673ded331] memory: tegra: Add MC error logging support for Tegra264
> # good: [aa3d0c93a333182e887426366a4f3e5f06ee0d83] regulator: max20411: show failure on register
> # good: [ef0b4783afc211a4b120e72b5a57f3d0340a9981] ASoC: cs35l56: KUnit tests for reading speaker ID from host GPIOs
> # good: [e7662bced2e98ffa2c572126677deb9cf55d43b3] regcache: Move HW readback after cache initialisation
> # good: [b1ef855c62601ed4de2c4b0ff75a075877e3dac8] regmap: Simplify devres handling
> # good: [96f06d055ca03d1dfb5830fd07ff6eadbd66264c] spi: dt-bindings: mpfs-spi: remove clock-names
> # good: [2adac914c72b6cb5aba2612f49050c82aecd498e] ASoC: cs35l56-test: Add test cases without onchip pulls defined
> # good: [f48e7a246a567e3764112e2463274c479d95cd96] ASoC: soc-core: Use guard()/scoped_guard() for mutex lock
> # good: [9891b52ba12e9d5fed5901b6b5f6e0cdcd424390] regcache: Factor out regcache_hw_exit() helper
> # good: [e84141846decb77d2826e553318a608b256804e5] regulator: pf9453: Allow shared IRQ
> # good: [9ab637ac5d3826606947f4e861107da958eda324] regcache: Amend printf() specifiers when printing registers
> # good: [34b4fc44e4f904fbb81335d53163ffdcb0180000] ASoC: soc_sdw_utils: remove index from sdca codec name
> # good: [1696fad8b259a2d46e51cd6e17e4bcdbe02279fa] ASoC: sti: use managed regmap_field allocations
> # good: [d3b693a13b39bce16e284e1c737874966b3a96de] spi: spi-mem: clean up kernel-doc in spi-mem.h
> # good: [06dba254de95b16e7793224d29daa5195de2e581] ASoC: dt-bindings: nvidia,tegra-audio-max9808x: document additional board pins
> # good: [17c6bf433742e0c1ff5ce175145877c0194e4a7a] ASoC: cs35l45: Hibernate wm_adsp on runtime suspend
> # good: [da37bfe76b5b4ccc01ed8132215098e20d78e5f3] ASoC: cs42xx8: add error checks for constraints in TDM mode
> # good: [501efdcb3b3ab099fc0ce2f6e668b1c4095dd476] ASoC: SDCA: Pull the Q7.8 volume helpers out of soc-ops
> # good: [2974aa42e6696a1d95b727d677dc01a71af5b998] ASoC: remove snd_soc_pcm_subclass
> # good: [d90c0f78379454d51a428e312ac6db573060185c] regulator: cpcap-regulator: add support for Mot regulators
> # good: [5c74a008ffc62fc57a041602b4517519c8bf9436] firmware: cs_dsp: Mark KUnit test suites KUNIT_SPEED_SLOW
> # good: [260c3fff1fefc570d8f23e87953e181d7d248861] ASoC: cs-amp-lib-test: Stop including platform_device.h
> # good: [7c12f6ead4672cb08b74e6f6115eb04dca8ccfa4] spi: tegra210-quad: Add runtime autosuspend support
> # good: [37983fad7f3ef296fa0504c8e945987459dc5487] regmap: define cleanup helper for regmap_field
> # good: [ada32396f90951e12465224c04742607ca56a982] ASoC: SDCA: Add CS47L47 to class driver
> # good: [e02902dd493bf9c9b05353c761737ac514ad7a5c] spi: add devm_spi_new_ancillary_device()
> # good: [507a071d9868cb60e4e76f8a06fc8eb014f59ae4] spi: pxa2xx: use min() instead of min_t()
> # good: [fed6e5084894373d76270cad4a32eb6479ad8247] spi: atcspi200: Remove redundant assignment to .owner
> # good: [5ebc20921b7fff9feb44de465448e17a382c9965] ASoC: tas2552: Allow audio enable GPIO to sleep
> # good: [171b3663f33e1efdc97f5112f49be10b47b20fa8] ASoC: codecs: aw88261: Add firmware-name support
> # good: [c2bcf62ca75c541ec4297e6ff02a68ddc2e02029] regcache: Split regcache_count_cacheable_registers() helper
> # good: [0556bb42a84ee391a2145ddba86756f9747bc27f] regulator: pf0900: Make regu_irqs variable static const
> # good: [d075cef4af6327a5de4bee7bf77591e3201e54f4] ASoC: simple-card-utils: add sysclk ordering support
> # good: [78dfbd4ad0be9f51de7b9a19388809254aeccd26] ASoC: Add quirk for Lecoo Bellator N176
> # good: [bf122191473e26a8f195308b1ba924c98424c8e1] ASoC: rt5677-spi: Add SPI device ID matching table
> # good: [fbb4c52ccdcb4a612d2b7f800aa57090eeee16d7] regulator: spacemit-p1: Update supply names
> git bisect start 'cf7c3c02fdd0dfccf4d6611714273dcb538af2cb' 'a010730e610019b6d010ec43ce737cb59a37809d' '3398da5432899c09712f30c92a154f3bf760a3e7' '777bc3284f0360c66ac75a44f35fc96053536ca4' 'f520a492e07bc6718e26cfb7543ab4cadd8bb0e2' 'aeb078cebc40d421f61a8f07b0e7919aeb44d751' '9be71d462c33b1a00acfa4ab8f0f5332ed592817' '7b3f8db159f710d432c4edc024fcefa9e62e8b4b' '8fc5c7895185d1119ae76b509892a1d14e0bd483' '981b080a79724738882b0af1c5bb7ade30d94f24' 'ed0313223ce6514dbd39c049e25f702980d7e3cc' '97af961568c8682c44506c9ad4b26c8a5455ec1d' '0a208adefecb287d22321054470d4619cb303839' 'a8075ada4a341ce58ebf8bef0188cefe6c2f6487' '82169065ffb07577075a5088b313d78673ded331' 'aa3d0c93a333182e887426366a4f3e5f06ee0d83' 'ef0b4783afc211a4b120e72b5a57f3d0340a9981' 'e7662bced2e98ffa2c572126677deb9cf55d43b3' 'b1ef855c62601ed4de2c4b0ff75a075877e3dac8' '96f06d055ca03d1dfb5830fd07ff6eadbd66264c' '2adac914c72b6cb5aba2612f49050c82aecd498e' 'f48e7a246a567e3764112e2463274c479d95cd96' '9891b52ba12e9d5fed5901b6b5f6e0cdcd424390' 'e84141846decb77d2826e553318a608b256804e5' '9ab637ac5d3826606947f4e861107da958eda324' '34b4fc44e4f904fbb81335d53163ffdcb0180000' '1696fad8b259a2d46e51cd6e17e4bcdbe02279fa' 'd3b693a13b39bce16e284e1c737874966b3a96de' '06dba254de95b16e7793224d29daa5195de2e581' '17c6bf433742e0c1ff5ce175145877c0194e4a7a' 'da37bfe76b5b4ccc01ed8132215098e20d78e5f3' '501efdcb3b3ab099fc0ce2f6e668b1c4095dd476' '2974aa42e6696a1d95b727d677dc01a71af5b998' 'd90c0f78379454d51a428e312ac6db573060185c' '5c74a008ffc62fc57a041602b4517519c8bf9436' '260c3fff1fefc570d8f23e87953e181d7d248861' '7c12f6ead4672cb08b74e6f6115eb04dca8ccfa4' '37983fad7f3ef296fa0504c8e945987459dc5487' 'ada32396f90951e12465224c04742607ca56a982' 'e02902dd493bf9c9b05353c761737ac514ad7a5c' '507a071d9868cb60e4e76f8a06fc8eb014f59ae4' 'fed6e5084894373d76270cad4a32eb6479ad8247' '5ebc20921b7fff9feb44de465448e17a382c9965' '171b3663f33e1efdc97f5112f49be10b47b20fa8' 'c2bcf62ca75c541ec4297e6ff02a68ddc2e02029' '0556bb42a84ee391a2145ddba86756f9747bc27f' 'd075cef4af6327a5de4bee7bf77591e3201e54f4' '78dfbd4ad0be9f51de7b9a19388809254aeccd26' 'bf122191473e26a8f195308b1ba924c98424c8e1' 'fbb4c52ccdcb4a612d2b7f800aa57090eeee16d7'
> # test job: [3398da5432899c09712f30c92a154f3bf760a3e7] https://lava.sirena.org.uk/scheduler/job/2608225
> # test job: [777bc3284f0360c66ac75a44f35fc96053536ca4] https://lava.sirena.org.uk/scheduler/job/2608418
> # test job: [f520a492e07bc6718e26cfb7543ab4cadd8bb0e2] https://lava.sirena.org.uk/scheduler/job/2608110
> # test job: [aeb078cebc40d421f61a8f07b0e7919aeb44d751] https://lava.sirena.org.uk/scheduler/job/2579214
> # test job: [9be71d462c33b1a00acfa4ab8f0f5332ed592817] https://lava.sirena.org.uk/scheduler/job/2548706
> # test job: [7b3f8db159f710d432c4edc024fcefa9e62e8b4b] https://lava.sirena.org.uk/scheduler/job/2548248
> # test job: [8fc5c7895185d1119ae76b509892a1d14e0bd483] https://lava.sirena.org.uk/scheduler/job/2548893
> # test job: [981b080a79724738882b0af1c5bb7ade30d94f24] https://lava.sirena.org.uk/scheduler/job/2545092
> # test job: [ed0313223ce6514dbd39c049e25f702980d7e3cc] https://lava.sirena.org.uk/scheduler/job/2544887
> # test job: [97af961568c8682c44506c9ad4b26c8a5455ec1d] https://lava.sirena.org.uk/scheduler/job/2543911
> # test job: [0a208adefecb287d22321054470d4619cb303839] https://lava.sirena.org.uk/scheduler/job/2542875
> # test job: [a8075ada4a341ce58ebf8bef0188cefe6c2f6487] https://lava.sirena.org.uk/scheduler/job/2540933
> # test job: [82169065ffb07577075a5088b313d78673ded331] https://lava.sirena.org.uk/scheduler/job/2582197
> # test job: [aa3d0c93a333182e887426366a4f3e5f06ee0d83] https://lava.sirena.org.uk/scheduler/job/2531504
> # test job: [ef0b4783afc211a4b120e72b5a57f3d0340a9981] https://lava.sirena.org.uk/scheduler/job/2530821
> # test job: [e7662bced2e98ffa2c572126677deb9cf55d43b3] https://lava.sirena.org.uk/scheduler/job/2530804
> # test job: [b1ef855c62601ed4de2c4b0ff75a075877e3dac8] https://lava.sirena.org.uk/scheduler/job/2531890
> # test job: [96f06d055ca03d1dfb5830fd07ff6eadbd66264c] https://lava.sirena.org.uk/scheduler/job/2523404
> # test job: [2adac914c72b6cb5aba2612f49050c82aecd498e] https://lava.sirena.org.uk/scheduler/job/2523920
> # test job: [f48e7a246a567e3764112e2463274c479d95cd96] https://lava.sirena.org.uk/scheduler/job/2522185
> # test job: [9891b52ba12e9d5fed5901b6b5f6e0cdcd424390] https://lava.sirena.org.uk/scheduler/job/2522240
> # test job: [e84141846decb77d2826e553318a608b256804e5] https://lava.sirena.org.uk/scheduler/job/2516913
> # test job: [9ab637ac5d3826606947f4e861107da958eda324] https://lava.sirena.org.uk/scheduler/job/2516426
> # test job: [34b4fc44e4f904fbb81335d53163ffdcb0180000] https://lava.sirena.org.uk/scheduler/job/2513607
> # test job: [1696fad8b259a2d46e51cd6e17e4bcdbe02279fa] https://lava.sirena.org.uk/scheduler/job/2514118
> # test job: [d3b693a13b39bce16e284e1c737874966b3a96de] https://lava.sirena.org.uk/scheduler/job/2511841
> # test job: [06dba254de95b16e7793224d29daa5195de2e581] https://lava.sirena.org.uk/scheduler/job/2513766
> # test job: [17c6bf433742e0c1ff5ce175145877c0194e4a7a] https://lava.sirena.org.uk/scheduler/job/2513835
> # test job: [da37bfe76b5b4ccc01ed8132215098e20d78e5f3] https://lava.sirena.org.uk/scheduler/job/2511899
> # test job: [501efdcb3b3ab099fc0ce2f6e668b1c4095dd476] https://lava.sirena.org.uk/scheduler/job/2500586
> # test job: [2974aa42e6696a1d95b727d677dc01a71af5b998] https://lava.sirena.org.uk/scheduler/job/2502174
> # test job: [d90c0f78379454d51a428e312ac6db573060185c] https://lava.sirena.org.uk/scheduler/job/2500322
> # test job: [5c74a008ffc62fc57a041602b4517519c8bf9436] https://lava.sirena.org.uk/scheduler/job/2496391
> # test job: [260c3fff1fefc570d8f23e87953e181d7d248861] https://lava.sirena.org.uk/scheduler/job/2494171
> # test job: [7c12f6ead4672cb08b74e6f6115eb04dca8ccfa4] https://lava.sirena.org.uk/scheduler/job/2488528
> # test job: [37983fad7f3ef296fa0504c8e945987459dc5487] https://lava.sirena.org.uk/scheduler/job/2489154
> # test job: [ada32396f90951e12465224c04742607ca56a982] https://lava.sirena.org.uk/scheduler/job/2489236
> # test job: [e02902dd493bf9c9b05353c761737ac514ad7a5c] https://lava.sirena.org.uk/scheduler/job/2489718
> # test job: [507a071d9868cb60e4e76f8a06fc8eb014f59ae4] https://lava.sirena.org.uk/scheduler/job/2486375
> # test job: [fed6e5084894373d76270cad4a32eb6479ad8247] https://lava.sirena.org.uk/scheduler/job/2484717
> # test job: [5ebc20921b7fff9feb44de465448e17a382c9965] https://lava.sirena.org.uk/scheduler/job/2485130
> # test job: [171b3663f33e1efdc97f5112f49be10b47b20fa8] https://lava.sirena.org.uk/scheduler/job/2482581
> # test job: [c2bcf62ca75c541ec4297e6ff02a68ddc2e02029] https://lava.sirena.org.uk/scheduler/job/2483282
> # test job: [0556bb42a84ee391a2145ddba86756f9747bc27f] https://lava.sirena.org.uk/scheduler/job/2483207
> # test job: [d075cef4af6327a5de4bee7bf77591e3201e54f4] https://lava.sirena.org.uk/scheduler/job/2483468
> # test job: [78dfbd4ad0be9f51de7b9a19388809254aeccd26] https://lava.sirena.org.uk/scheduler/job/2483108
> # test job: [bf122191473e26a8f195308b1ba924c98424c8e1] https://lava.sirena.org.uk/scheduler/job/2482758
> # test job: [fbb4c52ccdcb4a612d2b7f800aa57090eeee16d7] https://lava.sirena.org.uk/scheduler/job/2482462
> # test job: [cf7c3c02fdd0dfccf4d6611714273dcb538af2cb] https://lava.sirena.org.uk/scheduler/job/2617478
> # bad: [cf7c3c02fdd0dfccf4d6611714273dcb538af2cb] Add linux-next specific files for 20260330
> git bisect bad cf7c3c02fdd0dfccf4d6611714273dcb538af2cb
> # test job: [c99ea8b71328bb73baf24b2fb1591e076f1617a1] https://lava.sirena.org.uk/scheduler/job/2608073
> # bad: [c99ea8b71328bb73baf24b2fb1591e076f1617a1] Merge branch 'clk-rpi' into clk-next
> git bisect bad c99ea8b71328bb73baf24b2fb1591e076f1617a1
> # test job: [672299736af6c398e867782708b7400957e62c76] https://lava.sirena.org.uk/scheduler/job/2608599
> # bad: [672299736af6c398e867782708b7400957e62c76] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
> git bisect bad 672299736af6c398e867782708b7400957e62c76
> # first bad commit: [672299736af6c398e867782708b7400957e62c76] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
> # test job: [672299736af6c398e867782708b7400957e62c76] https://lava.sirena.org.uk/scheduler/job/2608599
> # bad: [672299736af6c398e867782708b7400957e62c76] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
> git bisect bad 672299736af6c398e867782708b7400957e62c76
> # first bad commit: [672299736af6c398e867782708b7400957e62c76] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
^ permalink raw reply related
* Re: [PATCH 0/4] drm/exynos: Random cleanups
From: Marek Szyprowski @ 2026-03-31 14:33 UTC (permalink / raw)
To: Chen-Yu Tsai, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Alim Akhtar
Cc: David Airlie, Simona Vetter, dri-devel, linux-samsung-soc,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAGXv+5G2H3CSic5hCSd2g6RrfGyNSbpYS7Z9uo-XUn6No3a4Rw@mail.gmail.com>
On 27.03.2026 06:44, Chen-Yu Tsai wrote:
> On Thu, Mar 26, 2026 at 5:43 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>> Here are some cleanups for the exynos drm driver. This was done as part
>> of the conversion of the driver to GEM DMA helpers. These patches have
>> no dependency, unlike the actual conversion, so I am sending them
>> separately for inclusion now.
>>
>> Please take a look.
> I should add that these patches were only compile tested.
I've tested this on the real hardware and it works fine.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [RFC PATCH 1/7] media: v4l2-ctrls: Add V4L2_CID_MEMORY_USAGE control
From: Frank Li @ 2026-03-31 14:33 UTC (permalink / raw)
To: ming.qian
Cc: linux-media, mchehab, hverkuil-cisco, nicolas, sebastian.fricke,
shawnguo, s.hauer, kernel, festevam, linux-imx, xiahong.bao,
eagle.zhou, imx, linux-kernel, linux-arm-kernel
In-Reply-To: <20260331072347.253-2-ming.qian@oss.nxp.com>
On Tue, Mar 31, 2026 at 03:23:11PM +0800, ming.qian@oss.nxp.com wrote:
> From: Ming Qian <ming.qian@oss.nxp.com>
>
> Add a new read-only control V4L2_CID_MEMORY_USAGE that allows
> applications to query the total amount of memory currently used
> by a device instance.
>
> This control reports the memory consumption in bytes, including
> internal buffers, intermediate processing data, and other
> driver-managed allocations. Applications can use this information
> for debugging, resource monitoring, or making informed decisions
> about buffer allocation strategies.
>
> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
> ---
Not sure why not export these information by debugfs, or any benefit vs
debugfs?
Generanlly document should be first patch, then driver change.
Frank
> drivers/media/v4l2-core/v4l2-ctrls-defs.c | 8 ++++++++
> include/uapi/linux/v4l2-controls.h | 4 +++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> index 551426c4cd01..053db78ff661 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> @@ -831,6 +831,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component";
> case V4L2_CID_COLORFX_CBCR: return "Color Effects, CbCr";
> case V4L2_CID_COLORFX_RGB: return "Color Effects, RGB";
> + case V4L2_CID_MEMORY_USAGE: return "Memory Usage";
>
> /*
> * Codec controls
> @@ -1476,6 +1477,13 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> *min = 0;
> *max = 0xffff;
> break;
> + case V4L2_CID_MEMORY_USAGE:
> + *type = V4L2_CTRL_TYPE_INTEGER64;
> + *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> + *min = 0;
> + *max = S64_MAX;
> + *step = 1;
> + break;
> case V4L2_CID_FLASH_FAULT:
> case V4L2_CID_JPEG_ACTIVE_MARKER:
> case V4L2_CID_3A_LOCK:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 68dd0c4e47b2..02c6f960d38e 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -110,8 +110,10 @@ enum v4l2_colorfx {
> #define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
> #define V4L2_CID_COLORFX_RGB (V4L2_CID_BASE+43)
>
> +#define V4L2_CID_MEMORY_USAGE (V4L2_CID_BASE+44)
> +
> /* last CID + 1 */
> -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
> +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+45)
>
> /* USER-class private control IDs */
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Suzuki K Poulose @ 2026-03-31 14:35 UTC (permalink / raw)
To: Ryan Roberts, Catalin Marinas, Will Deacon,
David Hildenbrand (Arm), Dev Jain, Yang Shi, Jinjiang Tu,
Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260330161705.3349825-2-ryan.roberts@arm.com>
On 30/03/2026 17:17, Ryan Roberts wrote:
> Commit a166563e7ec37 ("arm64: mm: support large block mapping when
> rodata=full") enabled the linear map to be mapped by block/cont while
> still allowing granular permission changes on BBML2_NOABORT systems by
> lazily splitting the live mappings. This mechanism was intended to be
> usable by realm guests since they need to dynamically share dma buffers
> with the host by "decrypting" them - which for Arm CCA, means marking
> them as shared in the page tables.
>
> However, it turns out that the mechanism was failing for realm guests
> because realms need to share their dma buffers (via
> __set_memory_enc_dec()) much earlier during boot than
> split_kernel_leaf_mapping() was able to handle. The report linked below
> showed that GIC's ITS was one such user. But during the investigation I
> found other callsites that could not meet the
> split_kernel_leaf_mapping() constraints.
>
> The problem is that we block map the linear map based on the boot CPU
> supporting BBML2_NOABORT, then check that all the other CPUs support it
> too when finalizing the caps. If they don't, then we stop_machine() and
> split to ptes. For safety, split_kernel_leaf_mapping() previously
> wouldn't permit splitting until after the caps were finalized. That
> ensured that if any secondary cpus were running that didn't support
> BBML2_NOABORT, we wouldn't risk breaking them.
>
> I've fix this problem by reducing the black-out window where we refuse
> to split; there are now 2 windows. The first is from T0 until the page
> allocator is inititialized. Splitting allocates memory for the page
> allocator so it must be in use. The second covers the period between
> starting to online the secondary cpus until the system caps are
> finalized (this is a very small window).
>
> All of the problematic callers are calling __set_memory_enc_dec() before
> the secondary cpus come online, so this solves the problem. However, one
> of these callers, swiotlb_update_mem_attributes(), was trying to split
> before the page allocator was initialized. So I have moved this call
> from arch_mm_preinit() to mem_init(), which solves the ordering issue.
>
> I've added warnings and return an error if any attempt is made to split
> in the black-out windows.
>
> Note there are other issues which prevent booting all the way to user
> space, which will be fixed in subsequent patches.
>
> Reported-by: Jinjiang Tu <tujinjiang@huawei.com>
> Closes: https://lore.kernel.org/all/0b2a4ae5-fc51-4d77-b177-b2e9db74f11d@huawei.com/
> Fixes: a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full")
> Cc: stable@vger.kernel.org
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
I have tested with a hacked cpufeature code to enable BBML2_NOABORT
for FVP MIDRs.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Suzuki
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/include/asm/mmu.h | 2 ++
> arch/arm64/mm/init.c | 9 +++++++-
> arch/arm64/mm/mmu.c | 45 +++++++++++++++++++++++++-----------
> 3 files changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 137a173df1ff8..472610433aaea 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -112,5 +112,7 @@ void kpti_install_ng_mappings(void);
> static inline void kpti_install_ng_mappings(void) {}
> #endif
>
> +extern bool page_alloc_available;
> +
> #endif /* !__ASSEMBLER__ */
> #endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 96711b8578fd0..b9b248d24fd10 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -350,7 +350,6 @@ void __init arch_mm_preinit(void)
> }
>
> swiotlb_init(swiotlb, flags);
> - swiotlb_update_mem_attributes();
>
> /*
> * Check boundaries twice: Some fundamental inconsistencies can be
> @@ -377,6 +376,14 @@ void __init arch_mm_preinit(void)
> }
> }
>
> +bool page_alloc_available __ro_after_init;
> +
> +void __init mem_init(void)
> +{
> + page_alloc_available = true;
> + swiotlb_update_mem_attributes();
> +}
> +
> void free_initmem(void)
> {
> void *lm_init_begin = lm_alias(__init_begin);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a6a00accf4f93..223947487a223 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -768,30 +768,51 @@ static inline bool force_pte_mapping(void)
> }
>
> static DEFINE_MUTEX(pgtable_split_lock);
> +static bool linear_map_requires_bbml2;
>
> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
> {
> int ret;
>
> - /*
> - * !BBML2_NOABORT systems should not be trying to change permissions on
> - * anything that is not pte-mapped in the first place. Just return early
> - * and let the permission change code raise a warning if not already
> - * pte-mapped.
> - */
> - if (!system_supports_bbml2_noabort())
> - return 0;
> -
> /*
> * If the region is within a pte-mapped area, there is no need to try to
> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
> * change permissions from atomic context so for those cases (which are
> * always pte-mapped), we must not go any further because taking the
> - * mutex below may sleep.
> + * mutex below may sleep. Do not call force_pte_mapping() here because
> + * it could return a confusing result if called from a secondary cpu
> + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
> + * what we need.
> */
> - if (force_pte_mapping() || is_kfence_address((void *)start))
> + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
> return 0;
>
> + if (!system_supports_bbml2_noabort()) {
> + /*
> + * !BBML2_NOABORT systems should not be trying to change
> + * permissions on anything that is not pte-mapped in the first
> + * place. Just return early and let the permission change code
> + * raise a warning if not already pte-mapped.
> + */
> + if (system_capabilities_finalized())
> + return 0;
> +
> + /*
> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
> + * page allocator. Can't split until it's available.
> + */
> + if (WARN_ON(!page_alloc_available))
> + return -EBUSY;
> +
> + /*
> + * Boot-time: Started secondary cpus but don't know if they
> + * support BBML2_NOABORT yet. Can't allow splitting in this
> + * window in case they don't.
> + */
> + if (WARN_ON(num_online_cpus() > 1))
> + return -EBUSY;
> + }
> +
> /*
> * Ensure start and end are at least page-aligned since this is the
> * finest granularity we can split to.
> @@ -891,8 +912,6 @@ static int range_split_to_ptes(unsigned long start, unsigned long end, gfp_t gfp
> return ret;
> }
>
> -static bool linear_map_requires_bbml2 __initdata;
> -
> u32 idmap_kpti_bbml2_flag;
>
> static void __init init_idmap_kpti_bbml2_flag(void)
^ permalink raw reply
* Re: [PATCH v12 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Frank Li @ 2026-03-31 14:43 UTC (permalink / raw)
To: Vijayanand Jitta
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia,
linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-2-decfd305eea9@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 07:34:47PM +0530, Vijayanand Jitta wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>
> Change of_map_id() to take a pointer to struct of_phandle_args
> instead of passing target device node and translated IDs separately.
> Update all callers accordingly.
>
> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
> to separate the filter input from the output. Previously, the target
> parameter served dual purpose: as an input filter (if non-NULL, only
> match entries targeting that node) and as an output (receiving the
> matched node with a reference held). Now filter_np is the explicit
> input filter and arg->np is the pure output.
>
> Previously, of_map_id() would call of_node_put() on the matched node
> when a filter was provided, making reference ownership inconsistent.
> Remove this internal of_node_put() call so that of_map_id() now always
> transfers ownership of the matched node reference to the caller via
> arg->np. Callers are now consistently responsible for releasing this
> reference with of_node_put(arg->np) when done.
>
> Suggested-by: Rob Herring (Arm) <robh@kernel.org>
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> ---
> drivers/cdx/cdx_msi.c | 7 ++--
> drivers/iommu/of_iommu.c | 4 +-
> drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
> drivers/of/base.c | 68 +++++++++++++++++---------------
> drivers/of/irq.c | 10 ++++-
> drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
>
> for imx part.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v7 1/5] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
From: Mark Brown @ 2026-03-31 14:44 UTC (permalink / raw)
To: Maíra Canal
Cc: Michael Turquette, Stephen Boyd, Nicolas Saenz Julienne,
Florian Fainelli, Stefan Wahren, Maxime Ripard, Melissa Wen,
Iago Toral Quiroga, Chema Casanova, Dave Stevenson, Philipp Zabel,
linux-clk, dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev
In-Reply-To: <d251c380-f2f5-4daf-9661-bbb6dc6c959e@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]
On Tue, Mar 31, 2026 at 11:32:07AM -0300, Maíra Canal wrote:
> On 31/03/26 09:49, Mark Brown wrote:
> > On Thu, Mar 12, 2026 at 06:34:23PM -0300, Maíra Canal wrote:
> > > Rather than pushing rate management to clock consumers, handle it
> > > directly in the clock framework's prepare/unprepare callbacks. In
> > > unprepare, set the rate to the minimum before disabling the clock.
> > > In prepare, for clocks marked with `maximize` (currently v3d),
> > > restore the rate to the maximum after enabling.
> > I'm seeing boot regressions in -next with NFS root on Raspberry Pi 3B+
> > which bisect to this commit. We get a likely unrelated oops from the
> > firmware interface and the boot grinds to a halt some time later since
> > the ethernet never comes up:
> I've managed to address this issue locally with the following diff:
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c
> b/drivers/clk/bcm/clk-raspberrypi.c
> index df2d246eb6ef..ef5ae3b4adca 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -160,6 +160,7 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = {
> [RPI_FIRMWARE_VEC_CLK_ID] = {
> .export = true,
> .minimize = true,
> + .flags = CLK_IGNORE_UNUSED,
> },
> [RPI_FIRMWARE_DISP_CLK_ID] = {
> .export = true,
> It looks like the VEC_CLK can't be disabled at boot time. Otherwise, a
> bus lookup will happen (similar what happens to other RPi firmware
> clocks).
> Is it possible for me to test this change in LAVA CI before sending it
> to the list? Just to double check that this patch indeed fixes the
> issue on your side as well.
I can give you access to submit jobs easily enough, if you're already
familiar with LAVA and have somewhere to host the binaries that'd work.
It might be more straightforward for me to just test it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/7] media: v4l2-ctrls: Add V4L2_CID_MEMORY_USAGE control
From: Nicolas Dufresne @ 2026-03-31 14:54 UTC (permalink / raw)
To: Frank Li, ming.qian
Cc: linux-media, mchehab, hverkuil-cisco, sebastian.fricke, shawnguo,
s.hauer, kernel, festevam, linux-imx, xiahong.bao, eagle.zhou,
imx, linux-kernel, linux-arm-kernel
In-Reply-To: <acvbOo17tU-s20BS@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]
Le mardi 31 mars 2026 à 10:33 -0400, Frank Li a écrit :
> On Tue, Mar 31, 2026 at 03:23:11PM +0800, ming.qian@oss.nxp.com wrote:
> > From: Ming Qian <ming.qian@oss.nxp.com>
> >
> > Add a new read-only control V4L2_CID_MEMORY_USAGE that allows
> > applications to query the total amount of memory currently used
> > by a device instance.
> >
> > This control reports the memory consumption in bytes, including
> > internal buffers, intermediate processing data, and other
> > driver-managed allocations. Applications can use this information
> > for debugging, resource monitoring, or making informed decisions
> > about buffer allocation strategies.
> >
> > Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
> > ---
>
> Not sure why not export these information by debugfs, or any benefit vs
> debugfs?
There is also a on-going proposal that uses fdinfo.
Nicolas
>
> Generanlly document should be first patch, then driver change.
>
> Frank
>
> > drivers/media/v4l2-core/v4l2-ctrls-defs.c | 8 ++++++++
> > include/uapi/linux/v4l2-controls.h | 4 +++-
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > index 551426c4cd01..053db78ff661 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > @@ -831,6 +831,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component";
> > case V4L2_CID_COLORFX_CBCR: return "Color Effects, CbCr";
> > case V4L2_CID_COLORFX_RGB: return "Color Effects, RGB";
> > + case V4L2_CID_MEMORY_USAGE: return "Memory Usage";
> >
> > /*
> > * Codec controls
> > @@ -1476,6 +1477,13 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > *min = 0;
> > *max = 0xffff;
> > break;
> > + case V4L2_CID_MEMORY_USAGE:
> > + *type = V4L2_CTRL_TYPE_INTEGER64;
> > + *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > + *min = 0;
> > + *max = S64_MAX;
> > + *step = 1;
> > + break;
> > case V4L2_CID_FLASH_FAULT:
> > case V4L2_CID_JPEG_ACTIVE_MARKER:
> > case V4L2_CID_3A_LOCK:
> > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > index 68dd0c4e47b2..02c6f960d38e 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -110,8 +110,10 @@ enum v4l2_colorfx {
> > #define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
> > #define V4L2_CID_COLORFX_RGB (V4L2_CID_BASE+43)
> >
> > +#define V4L2_CID_MEMORY_USAGE (V4L2_CID_BASE+44)
> > +
> > /* last CID + 1 */
> > -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
> > +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+45)
> >
> > /* USER-class private control IDs */
> >
> > --
> > 2.53.0
> >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Philipp Zabel @ 2026-03-31 14:54 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-1-eb95b625234c@aliel.fr>
On Di, 2026-03-31 at 16:24 +0200, Ronald Claveau wrote:
> Fix missing reset ops causing kernel null pointer dereference.
> This SOC's reset is currently not used yet.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
This is
Fixes: fb4c31587adf ("reset: amlogic: add auxiliary reset driver support")
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2] ARM: module: fix unwind section relocation out of range error
From: Ard Biesheuvel @ 2026-03-31 14:56 UTC (permalink / raw)
To: William Zhang, linux-arm-kernel
Cc: Song Liu, linus.walleij, florian.fainelli, anand.gore,
Broadcom Kernel List, kursad.oney, Sebastian Andrzej Siewior,
Peter Zijlstra, Luis Chamberlain, linux-kernel, Thomas Gleixner,
Christophe Leroy, Petr Pavlu, Russell King
In-Reply-To: <CAHi4H7EC9+7yBofXE=AabeHtHFsrzOQA9kAq4of8Eu0CG2dfnA@mail.gmail.com>
Hi,
On Mon, 23 Feb 2026, at 03:30, William Zhang wrote:
> Hi,
>
> On Mon, Sep 22, 2025 at 1:24 PM William Zhang
> <william.zhang@broadcom.com> wrote:
>>
>> In an armv7 system that uses non-3G/1G split and with more than 512MB
>> physical memory, driver load may fail with following error:
>> section 29 reloc 0 sym '': relocation 42 out of range (0xc2ab9be8 ->
>> 0x7fad5998)
>>
>> This happens when relocation R_ARM_PREL31 from the unwind section
>> .ARM.extab and .ARM.exidx are allocated from the VMALLOC space while
>> .text section is from MODULES_VADDR space. It exceeds the +/-1GB
>> relocation requirement of R_ARM_PREL31 hence triggers the error.
>>
>> The fix is to mark .ARM.extab and .ARM.exidx sections as executable so
>> they can be allocated along with .text section and always meet range
>> requirement.
>>
>> Fixes: ac3b43283923 ("module: replace module_layout with module_memory")
>>
>> Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> Signed-off-by: William Zhang <william.zhang@broadcom.com>
>>
>> ---
>>
>> Changes in v2:
>> - Fix the comment in code and commit message regarding the unwind
>> section location
>> - Add fix tag for more visibility
>>
>> arch/arm/kernel/module-plts.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/kernel/module-plts.c b/arch/arm/kernel/module-plts.c
>> index 354ce16d83cb..b5338fe59706 100644
>> --- a/arch/arm/kernel/module-plts.c
>> +++ b/arch/arm/kernel/module-plts.c
>> @@ -225,6 +225,18 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>> mod->arch.init.plt = s;
>> else if (s->sh_type == SHT_SYMTAB)
>> syms = (Elf32_Sym *)s->sh_addr;
>> +#if defined(CONFIG_ARM_UNWIND) && !defined(CONFIG_VMSPLIT_3G)
>> + else if (s->sh_type == ELF_SECTION_UNWIND ||
>> + (strncmp(".ARM.extab", secstrings + s->sh_name, 10) == 0)) {
>> + /*
>> + * To avoid the possible relocation out of range issue for
>> + * R_ARM_PREL31, mark unwind section .ARM.extab and .ARM.exidx as
>> + * executable so they will be allocated along with .text section to
>> + * meet +/-1GB range requirement of the R_ARM_PREL31 relocation
>> + */
>> + s->sh_flags |= SHF_EXECINSTR;
>> + }
>> +#endif
>> }
>>
>> if (!mod->arch.core.plt || !mod->arch.init.plt) {
>> --
>> 2.43.7
>>
>
> Is this version okay to be accepted?
>
Please put it in Russell's patch tracker.
https://www.arm.linux.org.uk/developer/patches/
^ permalink raw reply
* Re: [PATCH 09/15] KVM: arm64: vgic-v5: align priority comparison with other GICs
From: Sascha Bischoff @ 2026-03-31 15:09 UTC (permalink / raw)
To: maz@kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Joey Gouly, yuzenghui@huawei.com, Suzuki Poulose,
oupton@kernel.org, broonie@kernel.org, nd
In-Reply-To: <20260326153530.3981879-10-maz@kernel.org>
On Thu, 2026-03-26 at 15:35 +0000, Marc Zyngier wrote:
> The way the effective priority mask is computed, and then compared
> to the priority of an interrupt to decide whether to wake-up or not,
> is slightly odd, and breaks at the limits.
>
> This could result in spurious wake-ups that are undesirable.
>
> Adopt the GICv[23] logic instead, which checks that the priority
> value
> is strictly lower than the mask.
>
> Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
> Link:
> https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> b/arch/arm64/kvm/vgic/vgic-v5.c
> index 0f269321ece4b..75372bbfb6a6a 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -238,7 +238,7 @@ static u32
> vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
> */
> priority_mask = FIELD_GET(FEAT_GCIE_ICH_VMCR_EL2_VPMR,
> cpu_if->vgic_vmcr);
>
> - return min(highest_ap, priority_mask + 1);
> + return min(highest_ap, priority_mask);
Hi Marc,
This part of your change (dropping the `- 1`) is not correct for GICv5.
The GICv[23] PMR works differently to the GICv5 PCR.
For GICv[23] the mask is exclusive, i.e., only higher priority (lower
numerical value) interrupts are of sufficient priority to be signalled.
For GICv5, the priority of an interrupt can be equal to or higher than
(numerically lower than) the mask. See DMSQKF in the GICv5 spec:
A physical interrupt has Sufficient priority to be signaled when all of
the following are true:
* The priority of the interrupt is higher than the physical running
priority for the Physical Interrupt Domain.
* The priority of the interrupt is equal to or higher than the
Physical Priority Mask for the Physical Interrupt Domain.
Therefore, we require this `+ 1` for the priority_mask in order to allow
us to combine the active priority and priority mask. Else, they operate on
different scales.
I'd tried to explain this in a comment that lies just outside the diff,
but hadn't explicitly called out that GICv5 operates differently to
GICv[23] in this regard. Apologies.
> }
>
> /*
> @@ -367,7 +367,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu
> *vcpu)
>
> scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> has_pending = (irq->enabled &&
> irq_is_pending(irq) &&
> - irq->priority <=
> priority_mask);
> + irq->priority <
> priority_mask);
I agree that this was wrong and should never have included the
equality. This was definitely a bug!
Thanks,
Sascha
>
> vgic_put_irq(vcpu->kvm, irq);
>
^ permalink raw reply
* Re: [PATCH 1/4] KVM: arm64: nv: Avoid full shadow s2 unmap
From: kernel test robot @ 2026-03-31 15:16 UTC (permalink / raw)
To: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel
Cc: llvm, oe-kbuild-all, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Wei-Lin Chang
In-Reply-To: <20260330100633.2817076-2-weilin.chang@arm.com>
Hi Wei-Lin,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260327]
[cannot apply to kvmarm/next arm64/for-next/core arm/for-next arm/fixes soc/for-next v7.0-rc6 v7.0-rc5 v7.0-rc4 linus/master v7.0-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Wei-Lin-Chang/KVM-arm64-nv-Avoid-full-shadow-s2-unmap/20260330-230122
base: next-20260327
patch link: https://lore.kernel.org/r/20260330100633.2817076-2-weilin.chang%40arm.com
patch subject: [PATCH 1/4] KVM: arm64: nv: Avoid full shadow s2 unmap
config: arm64-randconfig-002-20260331 (https://download.01.org/0day-ci/archive/20260331/202603312322.Bli3MO76-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603312322.Bli3MO76-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603312322.Bli3MO76-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/arm64/kvm/nested.c:792:2: error: member reference type 'rwlock_t' (aka 'struct rwlock') is not a pointer; did you mean to use '.'?
792 | lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:291:22: note: expanded from macro 'lockdep_assert_held_write'
291 | do { lockdep_assert(lockdep_is_held_type(l, 0)); __assume_ctx_lock(l); } while (0)
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:253:64: note: expanded from macro 'lockdep_is_held_type'
253 | #define lockdep_is_held_type(lock, r) lock_is_held_type(&(lock)->dep_map, (r))
| ^
include/linux/lockdep.h:279:32: note: expanded from macro 'lockdep_assert'
279 | do { WARN_ON(debug_locks && !(cond)); } while (0)
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
include/asm-generic/bug.h:110:25: note: expanded from macro 'WARN_ON'
110 | int __ret_warn_on = !!(condition); \
| ^~~~~~~~~
>> arch/arm64/kvm/nested.c:792:2: error: cannot take the address of an rvalue of type 'struct lockdep_map'
792 | lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:291:22: note: expanded from macro 'lockdep_assert_held_write'
291 | do { lockdep_assert(lockdep_is_held_type(l, 0)); __assume_ctx_lock(l); } while (0)
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/lockdep.h:253:57: note: expanded from macro 'lockdep_is_held_type'
253 | #define lockdep_is_held_type(lock, r) lock_is_held_type(&(lock)->dep_map, (r))
| ^
include/linux/lockdep.h:279:32: note: expanded from macro 'lockdep_assert'
279 | do { WARN_ON(debug_locks && !(cond)); } while (0)
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
include/asm-generic/bug.h:110:25: note: expanded from macro 'WARN_ON'
110 | int __ret_warn_on = !!(condition); \
| ^~~~~~~~~
2 errors generated.
vim +792 arch/arm64/kvm/nested.c
782
783 int kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
784 gpa_t fault_ipa, size_t map_size)
785 {
786 struct maple_tree *mt = &mmu->nested_revmap_mt;
787 gpa_t start = ipa;
788 gpa_t end = ipa + map_size - 1;
789 u64 entry, new_entry = 0;
790 int r = 0;
791
> 792 lockdep_assert_held_write(kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
793
794 MA_STATE(mas, mt, start, end);
795 entry = (u64)mas_find_range(&mas, end);
796
797 if (entry) {
798 /* maybe just a perm update... */
799 if (!(entry & UNKNOWN_IPA) && mas.index == start &&
800 mas.last == end &&
801 fault_ipa == (entry & NESTED_IPA_MASK))
802 goto out;
803 /*
804 * Remove every overlapping range, then create a "polluted"
805 * range that spans all these ranges and store it.
806 */
807 while (entry && mas.index <= end) {
808 start = min(mas.index, start);
809 end = max(mas.last, end);
810 mas_erase(&mas);
811 entry = (u64)mas_find_range(&mas, end);
812 }
813 new_entry |= UNKNOWN_IPA;
814 } else {
815 new_entry |= fault_ipa;
816 }
817
818 mas_set_range(&mas, start, end);
819 r = mas_store_gfp(&mas, (void *)new_entry, GFP_KERNEL_ACCOUNT);
820 out:
821 return r;
822 }
823
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 0/5] xor/arm: Replace vectorized version with intrinsics
From: Christoph Hellwig @ 2026-03-31 15:16 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-raid, linux-arm-kernel, linux-crypto, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260331074940.55502-7-ardb+git@google.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
I think some of the intrinsics patches were also in your crc64 series,
so I'm not sure how to be merge this.
^ permalink raw reply
* Re: [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Paul Kocialkowski @ 2026-03-31 15:17 UTC (permalink / raw)
To: Lucas Stach
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, Krzysztof Hałasa,
Marco Felsch, Liu Ying
In-Reply-To: <f5b628f50def756da356184ff6febb11cc9aaa68.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]
Hi Lucas,
Le Tue 31 Mar 26, 11:09, Lucas Stach a écrit :
> Hi Paul,
>
> Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> > 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.
> >
> I don't really like that patch, as it blows up what is currently a
> single register access to three separate ones. If there is no clear
> benefit (as in it has been shown to fix any issue), I would prefer this
> code to stay as-is.
Well I guess the cost of a few writes vs a single one is rather
negligible. I'm rather worried that there might be an undocumented
reason why these registers exist in the first place and why they are
used in the BSP.
But yes this is only speculation and I could not witness any actual
issue. My setup (lcdif3 with hdmi) uses all positive polarities which is
the default state, so not a good way to check.
It would be great if somebody from NXP could confirm whether this is
needed or not. In the meantime I guess we can drop the patch. It'll stay
on the list in case someone has polarity issues later :)
All the best,
Paul
> Regards,
> Lucas
>
> > 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),
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1] media: rkisp1: Add support for CAC
From: Barnabás Pőcze @ 2026-03-31 15:24 UTC (permalink / raw)
To: Laurent Pinchart, Jacopo Mondi
Cc: Dafna Hirschfeld, Mauro Carvalho Chehab, Heiko Stuebner,
linux-media, linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331133934.GC3357297@killaraus.ideasonboard.com>
2026. 03. 31. 15:39 keltezéssel, Laurent Pinchart írta:
> On Tue, Mar 31, 2026 at 02:42:33PM +0200, Jacopo Mondi wrote:
>> On Mon, Mar 30, 2026 at 04:40:18PM +0200, Barnabás Pőcze wrote:
>>> 2026. 03. 25. 16:21 keltezéssel, Jacopo Mondi írta:
>>>> On Mon, Mar 23, 2026 at 03:02:16PM +0100, Barnabás Pőcze wrote:
>>>>> The CAC block implements chromatic aberration correction. Expose it to
>>>>> userspace using the extensible parameters format. This was tested on the
>>>>> i.MX8MP platform, but based on available documentation it is also present
>>>>> in the RK3399 variant (V10). Thus presumably also in later versions,
>>>>> so no feature flag is introduced.
>>>>>
>>>>> Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
>>>>
>>>> Only minors..
>>>>
>>>>> ---
>>>>> .../platform/rockchip/rkisp1/rkisp1-params.c | 69 ++++++++++++
>>>>> .../platform/rockchip/rkisp1/rkisp1-regs.h | 21 +++-
>>>>> include/uapi/linux/rkisp1-config.h | 106 +++++++++++++++++-
>>>>> 3 files changed, 193 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
>>>>> index 6442436a5e428..b889af9dcee45 100644
>>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
>>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
>>>>> @@ -64,6 +64,7 @@ union rkisp1_ext_params_config {
>>>>> struct rkisp1_ext_params_compand_bls_config compand_bls;
>>>>> struct rkisp1_ext_params_compand_curve_config compand_curve;
>>>>> struct rkisp1_ext_params_wdr_config wdr;
>>>>> + struct rkisp1_ext_params_cac_config cac;
>>>>> };
>>>>>
>>>>> enum rkisp1_params_formats {
>>>>> @@ -1413,6 +1414,48 @@ static void rkisp1_wdr_config(struct rkisp1_params *params,
>>>>> RKISP1_CIF_ISP_WDR_TONE_CURVE_YM_MASK);
>>>>> }
>>>>>
>>>>> +static void
>>>>> +rkisp1_cac_config(struct rkisp1_params *params,
>>>>> + const struct rkisp1_cif_isp_cac_config *arg)
>>>>
>>>> Fits in one line without going over 80 cols
>>>
>>> This is what the other functions looks like, so went this this.
>>
>> It seems to me not all of them are broken, but only the ones that go
>> over 80 cols
I think I misunderstood initially. Adjusted now.
>>
>> in example:
>>
>> static void rkisp1_dpf_config(struct rkisp1_params *params,
>> const struct rkisp1_cif_isp_dpf_config *arg)
>>
>> A detail anyway, up to you
>>
>>>>> +{
>>>>> + u32 regval;
>
> All other functions in this file name similar variables "val", "value"
> or "reg_val". Let's not introduce a fourth one. I have a small
> preference for "val", but that's not mandatory.
Adjusted.
>
>>>>> +
>>>>> + /*
>>>>> + * The enable bit is in the same register (RKISP1_CIF_ISP_CAC_CTRL),
>>>>> + * so only set the clipping mode, and do not modify the other bits.
>>>>> + */
>>>>> + regval = rkisp1_read(params->rkisp1, RKISP1_CIF_ISP_CAC_CTRL);
>>>>> + regval &= ~(RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE |
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE);
>>>>> + regval |= FIELD_PREP(RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE, arg->h_clip_mode) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE, arg->v_clip_mode);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_CTRL, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_COUNT_START_H_MASK, arg->h_count_start) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_COUNT_START_V_MASK, arg->v_count_start);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_COUNT_START, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_A_RED_MASK, arg->red[0]) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_A_BLUE_MASK, arg->blue[0]);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_A, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_B_RED_MASK, arg->red[1]) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_B_BLUE_MASK, arg->blue[1]);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_B, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_C_RED_MASK, arg->red[2]) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_C_BLUE_MASK, arg->blue[2]);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_C, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_X_NORM_NF_MASK, arg->x_nf) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_X_NORM_NS_MASK, arg->x_ns);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_X_NORM, regval);
>>>>> +
>>>>> + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_Y_NORM_NF_MASK, arg->y_nf) |
>>>>> + FIELD_PREP(RKISP1_CIF_ISP_CAC_Y_NORM_NS_MASK, arg->y_ns);
>>>>> + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_Y_NORM, regval);
>>>>> +}
>>>>> +
>>>>> static void
>>>>> rkisp1_isp_isr_other_config(struct rkisp1_params *params,
>>>>> const struct rkisp1_params_cfg *new_params)
>>>>> @@ -2089,6 +2132,25 @@ static void rkisp1_ext_params_wdr(struct rkisp1_params *params,
>>>>> RKISP1_CIF_ISP_WDR_CTRL_ENABLE);
>>>>> }
>>>>>
>>>>> +static void rkisp1_ext_params_cac(struct rkisp1_params *params,
>>>>> + const union rkisp1_ext_params_config *block)
>>>>> +{
>>>>> + const struct rkisp1_ext_params_cac_config *cac = &block->cac;
>>>>> +
>>>>> + if (cac->header.flags & RKISP1_EXT_PARAMS_FL_BLOCK_DISABLE) {
>>>>> + rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> + rkisp1_cac_config(params, &cac->config);
>>>>> +
>>>>> + if ((cac->header.flags & RKISP1_EXT_PARAMS_FL_BLOCK_ENABLE) &&
>>>>> + !(params->enabled_blocks & BIT(cac->header.type)))
>>>>> + rkisp1_param_set_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
>>>>> +}
>>>>> +
>>>>> typedef void (*rkisp1_block_handler)(struct rkisp1_params *params,
>>>>> const union rkisp1_ext_params_config *config);
>>>>>
>>>>> @@ -2185,6 +2247,10 @@ static const struct rkisp1_ext_params_handler {
>>>>> .handler = rkisp1_ext_params_wdr,
>>>>> .group = RKISP1_EXT_PARAMS_BLOCK_GROUP_OTHERS,
>>>>> },
>>>>> + [RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC] = {
>>>>> + .handler = rkisp1_ext_params_cac,
>>>>> + .group = RKISP1_EXT_PARAMS_BLOCK_GROUP_OTHERS,
>>>>> + },
>>>>> };
>>>>>
>>>>> #define RKISP1_PARAMS_BLOCK_INFO(block, data) \
>>>>> @@ -2215,6 +2281,7 @@ rkisp1_ext_params_block_types_info[] = {
>>>>> RKISP1_PARAMS_BLOCK_INFO(COMPAND_EXPAND, compand_curve),
>>>>> RKISP1_PARAMS_BLOCK_INFO(COMPAND_COMPRESS, compand_curve),
>>>>> RKISP1_PARAMS_BLOCK_INFO(WDR, wdr),
>>>>> + RKISP1_PARAMS_BLOCK_INFO(CAC, cac),
>>>>> };
>>>>>
>>>>> static_assert(ARRAY_SIZE(rkisp1_ext_params_handlers) ==
>>>>> @@ -2474,6 +2541,8 @@ void rkisp1_params_disable(struct rkisp1_params *params)
>>>>> rkisp1_ie_enable(params, false);
>>>>> rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPF_MODE,
>>>>> RKISP1_CIF_ISP_DPF_MODE_EN);
>>>>> + rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
>>>>> + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
>>>>> }
>>>>>
>>>>> static const struct rkisp1_params_ops rkisp1_v10_params_ops = {
>>>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
>>>>> index fbeb186cde0d5..8e25537459bbd 100644
>>>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
>>>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
>>>>> @@ -724,6 +724,23 @@
>>>>> #define RKISP1_CIF_ISP_WDR_DMIN_STRENGTH_MASK GENMASK(20, 16)
>>>>> #define RKISP1_CIF_ISP_WDR_DMIN_STRENGTH_MAX 16U
>>>>>
>>>>> +/* CAC */
>>>>> +#define RKISP1_CIF_ISP_CAC_CTRL_ENABLE BIT(0)
>>>>> +#define RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE GENMASK(2, 1)
>>>>> +#define RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE GENMASK(3, 3)
>
> I'd go for BIT(3) as you use BIT(0) for the enable bit.
Adjusted.
>
>>>>> +#define RKISP1_CIF_ISP_CAC_COUNT_START_H_MASK GENMASK(12, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_COUNT_START_V_MASK GENMASK(28, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_A_RED_MASK GENMASK(8, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_A_BLUE_MASK GENMASK(24, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_B_RED_MASK GENMASK(8, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_B_BLUE_MASK GENMASK(24, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_C_RED_MASK GENMASK(8, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_C_BLUE_MASK GENMASK(24, 16)
>>>>
>>>> All these masks for coefficients 0, 1 and 2 are identical. Maybe
>>>> #define RKISP1_CIF_ISP_CAC_RED_MASK GENMASK(8, 0)
>>>> #define RKISP1_CIF_ISP_CAC_BLUE_MASK GENMASK(24, 16)
>>>>
>>>> is enough
>>>
>>> Adjusted.
>>>
>>>>> +#define RKISP1_CIF_ISP_CAC_X_NORM_NF_MASK GENMASK(4, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_X_NORM_NS_MASK GENMASK(19, 16)
>>>>> +#define RKISP1_CIF_ISP_CAC_Y_NORM_NF_MASK GENMASK(4, 0)
>>>>> +#define RKISP1_CIF_ISP_CAC_Y_NORM_NS_MASK GENMASK(19, 16)
>>>
>>> Did the same with these as well.
>>
>> Ah thanks!
>>
>>>>> +
>>>>> /* =================================================================== */
>>>>> /* CIF Registers */
>>>>> /* =================================================================== */
>>>>> @@ -1196,8 +1213,8 @@
>>>>> #define RKISP1_CIF_ISP_CAC_A (RKISP1_CIF_ISP_CAC_BASE + 0x00000008)
>>>>> #define RKISP1_CIF_ISP_CAC_B (RKISP1_CIF_ISP_CAC_BASE + 0x0000000c)
>>>>> #define RKISP1_CIF_ISP_CAC_C (RKISP1_CIF_ISP_CAC_BASE + 0x00000010)
>>>>> -#define RKISP1_CIF_ISP_X_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000014)
>>>>> -#define RKISP1_CIF_ISP_Y_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000018)
>>>>> +#define RKISP1_CIF_ISP_CAC_X_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000014)
>>>>> +#define RKISP1_CIF_ISP_CAC_Y_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000018)
>>>>>
>>>>> #define RKISP1_CIF_ISP_EXP_BASE 0x00002600
>>>>> #define RKISP1_CIF_ISP_EXP_CTRL (RKISP1_CIF_ISP_EXP_BASE + 0x00000000)
>>>>> diff --git a/include/uapi/linux/rkisp1-config.h b/include/uapi/linux/rkisp1-config.h
>>>>> index b2d2a71f7baff..d8acccaddd0e9 100644
>>>>> --- a/include/uapi/linux/rkisp1-config.h
>>>>> +++ b/include/uapi/linux/rkisp1-config.h
>>>>> @@ -967,6 +967,92 @@ struct rkisp1_cif_isp_wdr_config {
>>>>> __u8 use_iref;
>>>>> };
>>>>>
>>>>> +/*
>>>>> + * enum rkisp1_cif_isp_cac_h_clip_mode - horizontal clipping mode
>>>>> + *
>>>>> + * @RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4PX: +/- 4 pixels
>>>>> + * @RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4_5PX: +/- 4/5 pixels depending on bayer position
>>>>> + */
>>>>> +enum rkisp1_cif_isp_cac_h_clip_mode {
>>>>> + RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4PX = 0,
>>>>> + RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4_5PX = 1,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * enum rkisp1_cif_isp_cac_v_clip_mode - vertical clipping mode
>>>>> + *
>>>>> + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_2PX: +/- 2 pixels
>>>>> + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3PX: +/- 3 pixels
>>>>> + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3_4PX: +/- 3/4 pixels depending on bayer position
>>>>> + */
>>>>> +enum rkisp1_cif_isp_cac_v_clip_mode {
>>>>> + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_2PX = 0,
>>>>> + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3PX = 1,
>>>>> + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3_4PX = 2,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct rkisp1_cif_isp_cac_config - chromatic aberration correction configuration
>>>>> + *
>>>>> + * The correction is carried out by shifting the red and blue pixels relative
>>>>> + * to the green ones, depending on the distance from the optical center:
>>>>
>>>> Yes, the distance to the center is one parameter, but the shifting
>>>> amount depends on other things. I would drop the last part of the
>>>> sentence and move the description of the two below fields after the
>>>> text
>>>
>>> That's true, but within a specific image, the only varying quantity
>>> is the distance, so I think it is important to emphasize that.
>>>
>>> And I also quite like this structure of
>>> - description of step
>>> - parameters of step
>>> - description of step
>>> ...
>>>
>>> so I would love to keep it like this, if that's ok?
>>
>> Ok!
>
> Ack.
>
>>>>> + *
>>>>> + * @h_count_start: horizontal coordinate of the optical center (13-bit unsigned integer; [1,8191])
>>>>> + * @v_count_start: vertical coordinate of the optical center (13-bit unsigned integer; [1,8191])
>>>>
>>>> so these could go just before @x_nf
>>>>
>>>>> + *
>>>>> + * For each pixel, the x/y distances from the optical center are calculated and
>>>>
>>>> I forgot: did we establish that the correction is applied to the
>>>> euclidean distance or to x and y separately ?
>>>
>>> Given that there are two sets of "normalization" parameters, the assumption is that
>>> at least the x/y distances are transformed separately. I see two reasonable choices
>>> after that: (a) use the two distances separately, (b) use the radial distance. The
>>> documentation says (b). However, testing with sensor test patterns suggests that
>>> it is not the case (a horizontal/vertical boundary between appropriately colored
>>> regions should have a curvature after the transformation with appropriate parameters).
>>
>> I now recall that you have been able to shift just one plan when using
>> the sensor's test pattern
>
> I agree about the normalization, but it sounds really weird that the
> hardware would then shift separately in the X and Y directions. Below
> you document the radial correction formula, which looks correct to me.
I think so, too. But if it uses the radial distance, I would expect the shifting to happen
along the radius. But that does not appear to be the case (e.g. y_nf=0 removes all vertical
correction). This could be explained by saying that the shifting actually happens along the
direction determined by the sum of the normalized distance vectors, but that seemed a bit
far fetched to me. And even with that, I would expect to be able to turn a straight line
into a curve. Maybe I'm doing something wrong, but I can't recall ever being able to.
>
>>>>> + * then transformed into the [0,255] range based on the following formula:
>>>>
>>>> s/transformed/normalized ?
>>>
>>> To be honest I vastly prefer "transform" / "map" over "normalize" here.
>>
>> You're right here, the below formula doesn't normalize the
>> distance in an interval but just re-scale it
>>
>>>>> + *
>>>>> + * (((d << 4) >> s) * f) >> 5
>>>>> + *
>>>>> + * where `d` is the distance, `s` and `f` are the normalization parameters:
>>>>
>>>> Can you use 'ns' and 'nf' to match the below ?
>>>
>>> Adjusted.
>>
>> Thanks!
>>
>>>>> + *
>>>>> + * @x_nf: horizontal normalization scale parameter (5-bit unsigned integer; [0,31])
>>>>> + * @x_ns: horizontal normalization shift parameter (4-bit unsigned integer; [0,15])
>>>>> + *
>>>>> + * @y_nf: vertical normalization scale parameter (5-bit unsigned integer; [0,31])
>>>>> + * @y_ns: vertical normalization shift parameter (4-bit unsigned integer; [0,15])
>>>>> + *
>>>>> + * These parameters should be chosen based on the image resolution, the position
>>>>> + * of the optical center, and the shape of pixels: so that no normalized distance
>>>>
>>>> s/pixels:/pixels/
>>>
>>> Replaced `:` with `,`.
>>>
>>>>> + * is larger than 255. If the pixels have square shape, the two sets of parameters
>>>>> + * should be equal.
>
> I wonder if we could have anisotropic lenses (from the point of view of
> chromatic aberrations) with square pixels. We can deal with it later.
Right, this is what the documentation suggests, and I believe it is probably "correct enough"
most of the time. But should I remove it?
>
>>>>> + *
>>>>> + * The actual amount of correction is calculated with a third degree polynomial:
>>>>> + *
>>>>> + * c[0] * r + c[1] * r^2 + c[2] * r^3
>>>>> + *
>>>>> + * where `c` is the set of coefficients for the given color, and `r` is distance:
>>>>> + *
>>>>> + * @red: red coefficients (5.4 two's complement; [-16,15.9375])
>>>>> + * @blue: blue coefficients (5.4 two's complement; [-16,15.9375])
>>>>> + *
>>>>> + * Finally, the amount is clipped as requested:
>>>>> + *
>>>>> + * @h_clip_mode: maximum horizontal shift (from enum rkisp1_cif_isp_cac_h_clip_mode)
>>>>> + * @v_clip_mode: maximum vertical shift (from enum rkisp1_cif_isp_cac_v_clip_mode)
>>>>> + *
>>>>> + * A positive result will shift away from the optical center, while a negative
>>>>> + * one will shift towards the optical center. In the latter case, the pixel
>>>>> + * values at the edges are duplicated.
>>>>> + */
>>>>> +struct rkisp1_cif_isp_cac_config {
>>>>> + __u8 h_clip_mode;
>>>>> + __u8 v_clip_mode;
>>>>> +
>>>>> + __u16 h_count_start;
>>>>> + __u16 v_count_start;
>>>>> +
>>>>> + __u16 red[3];
>>>>> + __u16 blue[3];
>>>>> +
>>>>> + __u8 x_nf;
>>>>> + __u8 x_ns;
>>>>> +
>>>>> + __u8 y_nf;
>>>>> + __u8 y_ns;
>>>>> +};
>>>>> +
>>>>> /*---------- PART2: Measurement Statistics ------------*/
>>>>>
>>>>> /**
>>>>> @@ -1161,6 +1247,7 @@ enum rkisp1_ext_params_block_type {
>>>>> RKISP1_EXT_PARAMS_BLOCK_TYPE_COMPAND_EXPAND,
>>>>> RKISP1_EXT_PARAMS_BLOCK_TYPE_COMPAND_COMPRESS,
>>>>> RKISP1_EXT_PARAMS_BLOCK_TYPE_WDR,
>>>>> + RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC,
>>>>> };
>>>>>
>>>>> /* For backward compatibility */
>>>>> @@ -1507,6 +1594,22 @@ struct rkisp1_ext_params_wdr_config {
>>>>> struct rkisp1_cif_isp_wdr_config config;
>>>>> } __attribute__((aligned(8)));
>>>>>
>>>>> +/**
>>>>> + * struct rkisp1_ext_params_cac_config - RkISP1 extensible params CAC config
>>>>> + *
>>>>> + * RkISP1 extensible parameters CAC block.
>>>>> + * Identified by :c:type:`RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC`.
>>>>> + *
>>>>> + * @header: The RkISP1 extensible parameters header, see
>>>>> + * :c:type:`rkisp1_ext_params_block_header`
>>>>> + * @config: CAC configuration, see
>>>>> + * :c:type:`rkisp1_cif_isp_cac_config`
>>>>> + */
>>>>> +struct rkisp1_ext_params_cac_config {
>>>>> + struct rkisp1_ext_params_block_header header;
>>>>> + struct rkisp1_cif_isp_cac_config config;
>>>>> +} __attribute__((aligned(8)));
>>>>> +
>>>>> /*
>>>>> * The rkisp1_ext_params_compand_curve_config structure is counted twice as it
>>>>> * is used for both the COMPAND_EXPAND and COMPAND_COMPRESS block types.
>>>>> @@ -1532,7 +1635,8 @@ struct rkisp1_ext_params_wdr_config {
>>>>> sizeof(struct rkisp1_ext_params_compand_bls_config) +\
>>>>> sizeof(struct rkisp1_ext_params_compand_curve_config) +\
>>>>> sizeof(struct rkisp1_ext_params_compand_curve_config) +\
>>>>> - sizeof(struct rkisp1_ext_params_wdr_config))
>>>>> + sizeof(struct rkisp1_ext_params_wdr_config) +\
>>>>> + sizeof(struct rkisp1_ext_params_cac_config))
>>>>
>>>> All minors, please add
>>>> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
>
> and
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>>>>>
>>>>> /**
>>>>> * enum rksip1_ext_param_buffer_version - RkISP1 extensible parameters version
>
^ permalink raw reply
* Re: [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Philipp Zabel @ 2026-03-31 15:25 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-1-eb95b625234c@aliel.fr>
On Di, 2026-03-31 at 16:24 +0200, Ronald Claveau wrote:
> Fix missing reset ops causing kernel null pointer dereference.
> This SOC's reset is currently not used yet.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Applied to reset/fixes, thanks!
[1/2] reset: amlogic: t7: Fix null reset ops
https://git.pengutronix.de/cgit/pza/linux/commit/?id=9797524ef2b6
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 0/5] xor/arm: Replace vectorized version with intrinsics
From: Ard Biesheuvel @ 2026-03-31 15:26 UTC (permalink / raw)
To: Christoph Hellwig, Ard Biesheuvel
Cc: linux-raid, linux-arm-kernel, linux-crypto, Russell King,
Arnd Bergmann, Eric Biggers
In-Reply-To: <20260331151653.GA8011@lst.de>
On Tue, 31 Mar 2026, at 17:16, Christoph Hellwig wrote:
> Looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
Thanks.
> I think some of the intrinsics patches were also in your crc64 series,
> so I'm not sure how to be merge this.
The first patch is used by both series, yes. If this is good to go, we might as well just merge it, and defer the crc work (or at least the 32-bit ARM specific changes) to the next cycle. I am in no particular hurry with any of this, so whatever works for other people is fine with me.
The RAID pieces are going through akpm's tree, right?
Eric, any preferences? (assuming you are on board with the CRC64 changes in the first place)
^ permalink raw reply
* Re: [PATCH v2 0/5] xor/arm: Replace vectorized version with intrinsics
From: Christoph Hellwig @ 2026-03-31 15:28 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Christoph Hellwig, Ard Biesheuvel, linux-raid, linux-arm-kernel,
linux-crypto, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <2176aab5-2167-4cdf-9090-0f8e0a6fb5a0@app.fastmail.com>
On Tue, Mar 31, 2026 at 05:26:33PM +0200, Ard Biesheuvel wrote:
> The RAID pieces are going through akpm's tree, right?
Yes.
^ permalink raw reply
* Re: [PATCHv2] clk: kirkwood: use kzalloc_flex
From: Gustavo A. R. Silva @ 2026-03-31 15:27 UTC (permalink / raw)
To: Brian Masney, Rosen Penev
Cc: linux-clk, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <acvUoSOOF_9UQC75@redhat.com>
On 3/31/26 08:05, Brian Masney wrote:
> On Mon, Mar 30, 2026 at 01:55:04PM -0700, Rosen Penev wrote:
>> Simplify allocation by using a flexible array member and kzalloc_flex to
>> combine allocations.
>>
>> Add __counted_by for extra runtime analysis. Move counting variable
>> assignment to right after allocation as required by __counted_by.
This is misinformation and should be phrased differently[1]
-Gustavo
[1] https://lore.kernel.org/linux-hardening/37378f49-437f-438b-ad6c-d60480feb306@embeddedor.com/
>>
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> ---
>> v2: remove unused goto.
>
> Reviewed-by: Brian Masney <bmasney@redhat.com>
>
> For the future, if someone asks for changes in a previous version, then
> be sure to CC them on the next revision.
>
^ permalink raw reply
* Re: [PATCH v9 3/3] drm/v3d: Introduce Runtime Power Management
From: Florian Fainelli @ 2026-03-31 15:33 UTC (permalink / raw)
To: Maíra Canal, Stefan Wahren, Maxime Ripard, Melissa Wen,
Iago Toral Quiroga, Dave Stevenson
Cc: dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev
In-Reply-To: <20260331-v3d-power-management-v9-3-f52ff87bfd36@igalia.com>
On 3/31/26 05:35, Maíra Canal wrote:
> Commit 90a64adb0876 ("drm/v3d: Get rid of pm code") removed the last
> bits of power management code that V3D had, which were actually never
> hooked. Therefore, currently, the GPU clock is enabled during probe
> and only disabled when removing the driver.
>
> Implement proper power management using the kernel's Runtime PM
> framework.
>
> Reviewed-by: Melissa Wen <mwen@igalia.com>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: [PATCH] dmaengine: st_fdma: simplify allocation
From: Gustavo A. R. Silva @ 2026-03-31 15:33 UTC (permalink / raw)
To: Rosen Penev, dmaengine
Cc: Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260330211555.13974-1-rosenp@gmail.com>
On 3/30/26 15:15, Rosen Penev wrote:
> Use a flexible array member to combine kzalloc and kcalloc to a single
> allocation.
>
> Add __counted_by for extra runtime analysis.
Assign counting variable
> after allocation as required by __counted_by.
This is misinformation and should be phrased differently[1]
-Gustavo
[1] https://lore.kernel.org/linux-hardening/37378f49-437f-438b-ad6c-d60480feb306@embeddedor.com/
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/dma/st_fdma.c | 27 ++++++++-------------------
> drivers/dma/st_fdma.h | 4 ++--
> 2 files changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
> index d9547017f3bd..3ec0d6731b8d 100644
> --- a/drivers/dma/st_fdma.c
> +++ b/drivers/dma/st_fdma.c
> @@ -710,16 +710,6 @@ static const struct of_device_id st_fdma_match[] = {
> };
> MODULE_DEVICE_TABLE(of, st_fdma_match);
>
> -static int st_fdma_parse_dt(struct platform_device *pdev,
> - const struct st_fdma_driverdata *drvdata,
> - struct st_fdma_dev *fdev)
> -{
> - snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
> - drvdata->name, drvdata->id);
> -
> - return of_property_read_u32(pdev->dev.of_node, "dma-channels",
> - &fdev->nr_channels);
> -}
> #define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
> @@ -742,27 +732,26 @@ static int st_fdma_probe(struct platform_device *pdev)
> struct st_fdma_dev *fdev;
> struct device_node *np = pdev->dev.of_node;
> const struct st_fdma_driverdata *drvdata;
> + u32 nr_channels;
> int ret, i;
>
> drvdata = device_get_match_data(&pdev->dev);
>
> - fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
> - if (!fdev)
> - return -ENOMEM;
> -
> - ret = st_fdma_parse_dt(pdev, drvdata, fdev);
> + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", &nr_channels);
> if (ret) {
> dev_err(&pdev->dev, "unable to find platform data\n");
> - goto err;
> + return ret;
> }
>
> - fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
> - sizeof(struct st_fdma_chan), GFP_KERNEL);
> - if (!fdev->chans)
> + fdev = devm_kzalloc(&pdev->dev, struct_size(fdev, chans, nr_channels), GFP_KERNEL);
> + if (!fdev)
> return -ENOMEM;
>
> + fdev->nr_channels = nr_channels;
> fdev->dev = &pdev->dev;
> fdev->drvdata = drvdata;
> + snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf", drvdata->name, drvdata->id);
> +
> platform_set_drvdata(pdev, fdev);
>
> fdev->irq = platform_get_irq(pdev, 0);
> diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
> index f1e746f7bc7d..27ded555879f 100644
> --- a/drivers/dma/st_fdma.h
> +++ b/drivers/dma/st_fdma.h
> @@ -136,13 +136,13 @@ struct st_fdma_dev {
>
> int irq;
>
> - struct st_fdma_chan *chans;
> -
> spinlock_t dreq_lock;
> unsigned long dreq_mask;
>
> u32 nr_channels;
> char fw_name[FW_NAME_SIZE];
> +
> + struct st_fdma_chan chans[] __counted_by(nr_channels);
> };
>
> /* Peripheral Registers*/
^ permalink raw reply
* [PATCH 0/3] KVM: arm64: Fix teardown of non-protected VMs with pKVM
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
Hi folks,
Sashiko continues to throw rocks at me.
This time, it spotted that my fix (introduced in v5 [1] of the pKVM
series) to prevent taking a reference on a VM in the 'is_dying' state
also prevents unsharing of pages shared with a non-protected VM if that
VM is torn down by its VM fd being destroyed, rather than the usual path
via the MMU notifiers.
Rather than send a v6 of the whole series, here are three patches that
apply on top of v5 and fix the issue by (a) preventing teardown of a
referenced VM and (b) allowing some references to be taken on a dying
VM. As an added bonus, this simplifies the locking on the reclaim path
because now a VM reference is enough to stop the page-tables from going
away.
Cheers,
Will
[1] https://lore.kernel.org/kvmarm/20260330144841.26181-1-will@kernel.org
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Quentin Perret <qperret@google.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Vincent Donnefort <vdonnefort@google.com>
Cc: Mostafa Saleh <smostafa@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
--->8
Will Deacon (3):
KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
arch/arm64/kvm/hyp/nvhe/pkvm.c | 53 +++++++++++++++++-----------------
1 file changed, 26 insertions(+), 27 deletions(-)
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply
* [PATCH 1/3] KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260331155056.28220-1-will@kernel.org>
Destroying a 'hyp_vm' with an elevated referenced count in
__pkvm_finalize_teardown_vm() is only going to lead to tears.
In preparation for allowing limited references to be acquired on dying
VMs during the teardown process, factor out the handle-to-vm logic for
the teardown path and reuse it for both the 'start' and 'finalise'
stages of the teardown process.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 8b906217c4c3..3fd3b930beeb 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -936,20 +936,27 @@ int __pkvm_reclaim_dying_guest_page(pkvm_handle_t handle, u64 gfn)
return ret;
}
+static struct pkvm_hyp_vm *get_pkvm_unref_hyp_vm_locked(pkvm_handle_t handle)
+{
+ struct pkvm_hyp_vm *hyp_vm;
+
+ hyp_assert_lock_held(&vm_table_lock);
+
+ hyp_vm = get_vm_by_handle(handle);
+ if (!hyp_vm || hyp_page_count(hyp_vm))
+ return NULL;
+
+ return hyp_vm;
+}
+
int __pkvm_start_teardown_vm(pkvm_handle_t handle)
{
struct pkvm_hyp_vm *hyp_vm;
int ret = 0;
hyp_spin_lock(&vm_table_lock);
- hyp_vm = get_vm_by_handle(handle);
- if (!hyp_vm) {
- ret = -ENOENT;
- goto unlock;
- } else if (WARN_ON(hyp_page_count(hyp_vm))) {
- ret = -EBUSY;
- goto unlock;
- } else if (hyp_vm->kvm.arch.pkvm.is_dying) {
+ hyp_vm = get_pkvm_unref_hyp_vm_locked(handle);
+ if (!hyp_vm || hyp_vm->kvm.arch.pkvm.is_dying) {
ret = -EINVAL;
goto unlock;
}
@@ -971,12 +978,9 @@ int __pkvm_finalize_teardown_vm(pkvm_handle_t handle)
int err;
hyp_spin_lock(&vm_table_lock);
- hyp_vm = get_vm_by_handle(handle);
- if (!hyp_vm) {
- err = -ENOENT;
- goto err_unlock;
- } else if (!hyp_vm->kvm.arch.pkvm.is_dying) {
- err = -EBUSY;
+ hyp_vm = get_pkvm_unref_hyp_vm_locked(handle);
+ if (!hyp_vm || !hyp_vm->kvm.arch.pkvm.is_dying) {
+ err = -EINVAL;
goto err_unlock;
}
--
2.53.0.1118.gaef5881109-goog
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
From: Will Deacon @ 2026-03-31 15:50 UTC (permalink / raw)
To: kvmarm
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Quentin Perret, Fuad Tabba, Vincent Donnefort, Mostafa Saleh,
Alexandru Elisei
In-Reply-To: <20260331155056.28220-1-will@kernel.org>
Now that completion of the teardown path requires a refcount of zero for
the target VM, we can allow get_pkvm_hyp_vm() to take a reference on a
dying VM, which is necessary to unshare pages with a non-protected VM
during the teardown process itself.
Note that vCPUs belonging to a dying VM cannot be loaded and pages can
only be reclaimed from a protected VM (via
__pkvm_reclaim_dying_guest_page()) if the target VM is in the dying
state.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index 3fd3b930beeb..b955da0e50bc 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -309,14 +309,8 @@ struct pkvm_hyp_vm *get_pkvm_hyp_vm(pkvm_handle_t handle)
hyp_spin_lock(&vm_table_lock);
hyp_vm = get_vm_by_handle(handle);
- if (!hyp_vm)
- goto unlock;
-
- if (hyp_vm->kvm.arch.pkvm.is_dying)
- hyp_vm = NULL;
- else
+ if (hyp_vm)
hyp_page_ref_inc(hyp_virt_to_page(hyp_vm));
-unlock:
hyp_spin_unlock(&vm_table_lock);
return hyp_vm;
--
2.53.0.1118.gaef5881109-goog
^ 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