arm64: rockchip: add MIPI CSI camera pipeline support for RK3576 by hz2 · Pull Request #10 · flipperdevices/flipper-linux-kernel

hz2 · 2026-05-22T16:27:04Z

Adds initial MIPI CSI-2 camera capture support for the RK3576 SoC, porting the existing RK3588 pipeline to the RK3576. The two SoCs share the same IP blocks (Innosilicon CSI DPHY, Synopsys DW CSI-2 Host, Rockchip VICAP) with minor differences in instance count and register base addresses.

RK3576 has 2 Inno CSI DPHY instances, 5 CSI Host controllers, and a VICAP unit with 5 MIPI input ports (vs 6 on RK3588).

Register addresses and layouts were verified against the RK3576 TRM V1.2 Part 2 and the Rockchip BSP kernel (develop-6.1 branch).

Changes:

phy: rockchip: inno-csidphy: add rockchip,rk3576-csi-dphy compatible
media: synopsys: dw-mipi-csi2rx: add rockchip,rk3576-mipi-csi2 compatible
media: rockchip: rkcif: add rockchip,rk3576-vicap with 5-port MIPI support
arm64: dts: rockchip: add VICAP, CSI Host, CSIDPHY, and GRF nodes to rk3576.dtsi

This is still missing DT binding YAML updates and board-level DTS wiring (sensor not yet identified for Flipper One). Compile-tested with the flipperone-linux-build-scripts config, RK3576 DTBs builds.

Closes #6

alchark · 2026-05-22T17:07:29Z

Thanks for your contribution!

As we are targeting mainline Linux kernel, we'll need to follow the mainline Linux contribution rules - in particular the part about the Developer Certificate of Origin there (i.e. please include your real name and email address in both the patch author information and the Signed-off-by: trailer to assert the DCO).

Are you certain that there is no register-level difference vs. RK3588? Rockchip's downstream driver has some GRF registers used by RK3588 but not RK3576

Please also check if https://docs.kernel.org/process/coding-assistants.html applies and also if Rockchip authorship/sign-off needs to be preserved in any of the patches (depending on how much of this was copied from the downstream develop-6.1 kernel)

hz2 · 2026-05-22T17:36:11Z

Thanks for getting back so quickly!

As we are targeting mainline Linux kernel, we'll need to follow the mainline Linux contribution rules - in particular the part about the Developer Certificate of Origin there (i.e. please include your real name and email address in both the patch author information and the Signed-off-by: trailer to assert the DCO).

added DCO, somewhat familiar with the process

Are you certain that there is no register-level difference vs. RK3588? Rockchip's downstream driver has some GRF registers used by RK3588 but not RK3576

RK3576 uses sys_grf for lane select at 0x14 (GRF_SOC_CON5), where RK3588 uses 0x308 (GRF_SOC_CON2). Mainline doesn't have sys_grf at all currently, only writes GRF for lane and clock enable i believe. the register layout is identical between RK3576 and RK3588 when looking at BSP source and TRM, however, sys_grf is missing from this series and will be added. for the flipper-one use case, per-PHY GRF writes should be sufficient? i'll add sys_grf support in a follow-up or fold it into this series before submitting to the lists, open to your thoughts here as well.

Please also check if https://docs.kernel.org/process/coding-assistants.html applies

ack, will review and comply

also if Rockchip authorship/sign-off needs to be preserved in any of the patches (depending on how much of this was copied from the downstream develop-6.1 kernel)

no code was copied from the BSP driver, the driver changes follow mainline patterns (RK3588 entries already in-tree) and register addresses come from TRM and BSP DTS so no Rockchip sign-off should be needed here but please keep me honest.

plan would be to address the sys_grf gap i mentioned and add DT binding YAML updates then submit a proper patch series to:

accordingly. happy to hear if you think anything else needs to change before that.

ps: wouldn't hurt to get a dev flipper one to test with 👀

alchark · 2026-05-22T19:31:41Z

FWIW, our builds didn't enable the CSI2 driver and its siblings up to now - I've just changed that. It builds fine with your patches, thank you!

Do you have any RK3576 based board to test it on? It would be great to also add the necessary board DTS nodes along with sensor-specific DTSO

hz2 · 2026-05-22T20:26:54Z

FWIW, our builds didn't enable the CSI2 driver and its siblings up to now - I've just changed that. It builds fine with your patches, thank you!

great! i tried it in a nix-shell (probably should have mentioned that) previously when building locally

Do you have any RK3576 based board to test it on?

i do not atm (why i asked about a dev board)

It would be great to also add the necessary board DTS nodes along with sensor-specific DTSO

agree that the sensor wiring should go in a DTSO, assuming sensor choice isn't finalized, right? happy to work on the overlay once ik what module to target

hz2 · 2026-05-30T05:09:51Z

will be sending a RFC to mailing list to denote i haven't tested on hardware and get feedback

alchark · 2026-06-01T09:05:22Z

+		struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+		priv->sys_grf_lane_sel_bit = (res && res->start == 0x2b070000) ? 2 : 1;


Ouch, this looks ugly. Firstly, you are not guarding this block by a particular SoC compatible but use a SoC specific MMIO address. Secondly, this should probably be encoded as a data attribute somewhere instead of hardcoding register addresses.

Ouch, this looks ugly.

Thanks! lol

Fair enough, one thing I can't verify without hardware: does rk3576 full mode actually need the SYS_GRF_SOC_CON5 write, or is the reset default already full mode? That decides whether I drop it cleanly or rework it in place.

When it comes back I'd carry the lane select bit as a phandle arg, rockchip,sys-grf = <&sys_grf 1>, read with syscon_regmap_lookup_by_phandle_args, rather than sniffing the MMIO address

hz2 · 2026-06-03T17:28:17Z

I'd like to drop the sys_grf lane select from this series and bring it back as a proper follow-up. The precedent is your own upstream RK3588 CSI DPHY support: the BSP has the lane select (rk3588_grf_dphy_regs, GRF_SOC_CON2 bit 6) but the mainline rk3588 variant left it out, and the upstream rk3588 csi_dphy nodes carry only rockchip,grf, never a sys_grf. RK3576 is the same IP and the target boards all use a single 2 lane PHY in full mode, so the core port should stand on its own the same way.

The one thing I cannot verify: does RK3576 full mode actually work without writing SYS_GRF_SOC_CON5? TRM Part 2 only gives the bit meaning (bit 1 = DPHY0, bit 2 = DPHY1, 0 = full, 1 = split), not the reset value, and the BSP writes it explicitly even for full mode. If POR is full mode, dropping is safe. If not, I should rework it in-series instead. If you'd rather keep it in-series, the plan is to carry the lane select bit as a DT phandle arg, rockchip,sys-grf = <&sys_grf 1>, read with syscon_regmap_lookup_by_phandle_args, so there's no MMIO address sniffing and no offset sentinel.

Open to a different representation.

Also log to normal dmesg to assist debugging hard reset issues. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Add a new DIV_ROUND_UP helper, which cannot overflow when big numbers are being used. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

The clock framework handles clock rates as "unsigned long", so u32 on 32-bit architectures and u64 on 64-bit architectures. The current code casts the dividend to u64 on 32-bit to avoid a potential overflow. For example DIV_ROUND_UP(3000000000, 1500000000) = (3.0G + 1.5G - 1) / 1.5G = = OVERFLOW / 1.5G, which has been introduced in commit 9556f9d ("clk: divider: handle integer overflow when dividing large clock rates"). On 64 bit platforms this masks the divisor, so that only the lower 32 bit are used. Thus requesting a frequency >= 4.3GHz results in incorrect values. For example requesting 4300000000 (4.3 GHz) will effectively request ca. 5 MHz. Requesting clk_round_rate(clk, ULONG_MAX) is a bit of a special case, since that still returns correct values as long as the parent clock is below 8.5 GHz. Fix this by switching to DIV_ROUND_UP_NO_OVERFLOW, which cannot overflow. This avoids any requirements on the arguments (except that divisor should not be 0 obviously). Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Replace the open coded abs_diff() with the existing helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Add rfkill support for bluetooth. Bluetooth support itself is still missing, but this ensures bluetooth can be powered off properly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Also describe wake signal PCIe pinmux for the onboard LAN card. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

This drops to hs200 mode and 150Mhz as this is actually stable across eMMC modules. There exist some that are incompatible at higher rates with the rk3588 and to avoid your filesystem corrupting due to IO errors, be more conservative and reduce the max. speed. Signed-off-by: Carsten Haitzler <raster@rasterman.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

When I converted rk808 to device managed resources I converted the rk808 specific pm_power_off handler to devm_register_sys_off_handler() using SYS_OFF_MODE_POWER_OFF_PREPARE, which is allowed to sleep. I did this because the driver's poweroff function makes use of regmap and the backend of that might sleep. But the PMIC poweroff function will kill off the board power and the kernel does some extra steps after the prepare handler. Thus the prepare handler should not be used for the PMIC's poweroff routine. Instead the normal SYS_OFF_MODE_POWER_OFF phase should be used. The old pm_power_off method is also being called from there, so this would have been a cleaner conversion anyways. But it still makes sense to investigate the sleep handling and check if there are any issues. Apparently the Rockchip and Meson I2C drivers (the only platforms using the PMICs handled by this driver) both have support for atomic transfers and thus may be called from the atomic poweroff context. Things are different on the SPI side. That is so far only used by rk806 and that one is only used by Rockchip RK3588. Unfortunately the Rockchip SPI driver does not support atomic transfers. That means this change will introduce an error splash directly before doing the final power off on all upstream supported RK3588 boards: [ 13.761353] ------------[ cut here ]------------ [ 13.761764] Voluntary context switch within RCU read-side critical section! [ 13.761776] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree_plugin.h:330 rcu_note_context_switch+0x3ac/0x404 [ 13.763219] Modules linked in: [ 13.763498] CPU: 0 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.10.0-12284-g2818a9a19514 #1499 [ 13.764297] Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) [ 13.764812] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 13.765427] pc : rcu_note_context_switch+0x3ac/0x404 [ 13.765871] lr : rcu_note_context_switch+0x3ac/0x404 [ 13.766314] sp : ffff800084f4b5b0 [ 13.766609] x29: ffff800084f4b5b0 x28: ffff00040139b800 x27: 00007dfb4439ae80 [ 13.767245] x26: ffff00040139bc80 x25: 0000000000000000 x24: ffff800082118470 [ 13.767880] x23: 0000000000000000 x22: ffff000400300000 x21: ffff000400300000 [ 13.768515] x20: ffff800083a9d600 x19: ffff0004fee48600 x18: fffffffffffed448 [ 13.769151] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000048 [ 13.769787] x14: fffffffffffed490 x13: ffff80008473b3c0 x12: 0000000000000900 [ 13.770421] x11: 0000000000000300 x10: ffff800084797bc0 x9 : ffff80008473b3c0 [ 13.771057] x8 : 00000000ffffefff x7 : ffff8000847933c0 x6 : 0000000000000300 [ 13.771692] x5 : 0000000000000301 x4 : 40000000fffff300 x3 : 0000000000000000 [ 13.772328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000400300000 [ 13.772964] Call trace: [ 13.773184] rcu_note_context_switch+0x3ac/0x404 [ 13.773598] __schedule+0x94/0xb0c [ 13.773907] schedule+0x34/0x104 [ 13.774198] schedule_timeout+0x84/0xfc [ 13.774544] wait_for_completion_timeout+0x78/0x14c [ 13.774980] spi_transfer_one_message+0x588/0x690 [ 13.775403] __spi_pump_transfer_message+0x19c/0x4ec [ 13.775846] __spi_sync+0x2a8/0x3c4 [ 13.776161] spi_write_then_read+0x120/0x208 [ 13.776543] rk806_spi_bus_read+0x54/0x88 [ 13.776905] _regmap_raw_read+0xec/0x16c [ 13.777257] _regmap_bus_read+0x44/0x7c [ 13.777601] _regmap_read+0x60/0xd8 [ 13.777915] _regmap_update_bits+0xf4/0x13c [ 13.778289] regmap_update_bits_base+0x64/0x98 [ 13.778686] rk808_power_off+0x70/0xfc [ 13.779024] sys_off_notify+0x40/0x6c [ 13.779356] atomic_notifier_call_chain+0x60/0x90 [ 13.779776] do_kernel_power_off+0x54/0x6c [ 13.780146] machine_power_off+0x18/0x24 [ 13.780499] kernel_power_off+0x70/0x7c [ 13.780845] __do_sys_reboot+0x210/0x270 [ 13.781198] __arm64_sys_reboot+0x24/0x30 [ 13.781558] invoke_syscall+0x48/0x10c [ 13.781897] el0_svc_common+0x3c/0xe8 [ 13.782228] do_el0_svc+0x20/0x2c [ 13.782528] el0_svc+0x34/0xd8 [ 13.782806] el0t_64_sync_handler+0x120/0x12c [ 13.783197] el0t_64_sync+0x190/0x194 [ 13.783527] ---[ end trace 0000000000000000 ]--- The board will shutdown nevertheless, since this also re-enables interrupts. A proper fix for this requires changes to the core SPI subsystem and will be done as a follow-up series. Note, that this patch also fixes a problem for the Asus C201. Without the function being registered as a proper shutdown handler the syscall for poweroff exits early and does not even call the shutdown prepare handler. This in turn means the system can no longer poweroff properly since my original change. Fixes: 4fec8a5 ("mfd: rk808: Convert to device managed resources") Cc: stable@vger.kernel.org Reported-by: Urja <urja@urja.dev> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Add the documentation for VOP2 video ports reset clocks. One reset can be set per video port. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

At the end of initialization, each VP clock needs to be reset before they can be used. Failing to do so can put the VOP in an undefined state where the generated HDMI signal is either lost or not matching the selected mode. This issue can be reproduced by switching modes multiple times. Depending on the setup, after about 10 mode switches, the signal will be lost and the value in register 0x890 (VSYNCWIDTH + VFRONT) will take the value `0x0000018c`. That makes VSYNCWIDTH=0, which is wrong. Adding the clock resets after the VOP configuration fixes the issue. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

This adds the needed clock resets for all rk3588(s) based SOCs. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

The RK3588 EVB1 comes with a W552793DBA-V10 Touchscreen/Display combination. It contains a Wanchanglong W552793BAA panel and a Goodix GT1158 touchscreen. This adds the DT description of it. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

A previous from Detlev Casanova adds reset handling for the video ports. This also resets the AHB and AXI interface when the system binds the VOP2 controller. This fixes issues when the bootloader (or a previously running kernel when using kexec) left the VOP2 initialized to some degree. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Fix the USB-C connector description, so that it follows the binding: port@0 is the high-speed lanes port@1 is the super-speed lanes port@2 is the SBU lanes Right now the high-speed and super-speed links are swapped and for the high-speed lanes the link points to the controller instead of the PHY. I'm still investigating if this should be changed. This also updates the port naming, so that it describes the hardware instead of how the drivers are using the information. These are effectively the same, but the DT should describe hardware and not software. Fixes: b37146b ("arm64: dts: rockchip: add USB3 to rk3588-evb1") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Any camera related IP of the RK3588 is not yet supported and the cameras must be handled via overlays anyways, but it is sensible to expose the related I2C interfaces by default. This allows using i2cdetect to investigate anything connected to the CSI connectors right now. Since the Rockchip I2C driver implements proper power management there are no disadvantages, if nothing is connected to the port. Note, that the second CSI port's I2C in the Rock 5B+ and Rock 5T reuse I2C4, which is already used by fusb302 and thus already enabled. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Flipper One has a haptic LRA (linear resonant actuator) exposed via its MCU interconnect interface. Add a driver to expose the haptic actuator as a force feedback device. Signed-off-by: Alexey Charkov <alchark@flipper.net>

Flipper One is a handheld multi-tool device with an integrated MCU that exposes USB Type-C controller functionality among other things, following the UCSI specification. Add a driver for it. Signed-off-by: Alexey Charkov <alchark@flipper.net>

The RK3576 has two Innosilicon MIPI CSI D-PHY instances that use the same register layout as the RK3588 variant (THS-settle at offset 0x160, calibration at 0x168, GRF at offset 0x0). Add the compatible string and driver data for these PHY instances. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 uses the same Synopsys DesignWare MIPI CSI-2 Host controller IP as the RK3568. Add the compatible string using the existing RK3568 driver data. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 Video Capture (VICAP) unit features five MIPI CSI-2 capture interfaces (compared to six on RK3588). The register layout is identical to the RK3588 variant. Add the compatible string and match data with mipi_num set to 5. Signed-off-by: Jason Devers <dev.json2@gmail.com>

Add device tree nodes for the RK3576 camera capture pipeline: - Two Innosilicon CSI D-PHY instances (csi_dphy0, csi_dphy1) - Two MIPI D-PHY GRF syscon nodes (mipidphy0_grf, mipidphy1_grf) - Five MIPI CSI-2 receiver nodes (csi0 through csi4) - Video Capture (VICAP) unit with five MIPI input ports - VICAP IOMMU The CSI hosts are connected to the VICAP ports and wired to the Innosilicon D-PHY instances. All nodes are disabled by default and must be enabled by board device trees that have camera connectors. Signed-off-by: Jason Devers <dev.json2@gmail.com>

Add rockchip,rk3576-csi-dphy to the compatible enum. The RK3576 has two Innosilicon CSI D-PHY instances and follows the same two-reset pattern (apb, phy) as the existing rk3588-csi-dphy entry. Signed-off-by: Jason Devers <dev.json2@gmail.com>

Add rockchip,rk3576-mipi-csi2 as a compatible that falls back to rockchip,rk3568-mipi-csi2, following the same pattern as the existing rk3588-mipi-csi2 entry. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 VICAP uses the same register layout and clock setup as the RK3588 one, with two differences: it has five MIPI CSI-2 input ports instead of six and no DVP parallel port. Extend the existing RK3588 binding rather than adding a separate file: add the rockchip,rk3576-vicap compatible and an allOf/if-then block that drops the DVP port@0 and the sixth MIPI port@6, and caps resets at eight, when that compatible is used. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 has two GRF blocks for its Innosilicon CSI D-PHY instances, analogous to the rk3588-csidphy-grf. Document the compatible so the rk3576 camera pipeline nodes validate. Signed-off-by: Jason Devers <dev.json2@gmail.com>

hz2 · 2026-06-26T15:05:38Z

Apparently something's also off with the power domains handling, as the boot stalls with the following messages once a camera module is enabled (it gets unstuck after a while, but this doesn't seem right)

i dug into this and think it is a kernel config gap rather than a DT driver bug and would think this would be harmless once the drivers are built in.

each node in your log is a consumer of VI/VO/audio power domain whose device link has not gone active yet, so the controller defers and you see "pending due to ..." and the fw_devlink timeout then force-syncs, which is the "gets unstuck after awhile" part, so it's a deferred cleanup, not a true hang.

i didn't see the drivers I have and the config from the build scripts:

# CONFIG_VIDEO_ROCKCHIP_CIF is not set
# CONFIG_VIDEO_DW_MIPI_CSI2RX is not set
# CONFIG_PHY_ROCKCHIP_INNO_CSIDPHY is not set

with those off, enabling vicap/csi/csi_dphy is an overlay creates power-domain callers that can never probe. could you check the config on your side? you mentioned enabling the CSI2 driver previously, want to confirm that PHY_ROCKCHIP_INNO_CSIDPHY (and not CIF) did not make it into the same both. If all three enabled and a node does not bind, a dmesg log from you would help with this (or hardware sent out). i can't verify the config gap without a hardware boot.

for what it's worth, the power-domain wiring on the rk3576 camera nodes is the same shape as the rk3588 camera nodes now on the branch so if a real sync_state issue remained after the drivers are enabled, I would expect rk3588 to show it too.

Futex hash computation requires a mask operation with read-only after init data that will be converted to a runtime constant in the subsequent commit. Introduce runtime_const_mask_32 to further optimize the mask operation in the futex hash computation hot path. Since all the current use-cases are of the form GENMASK(n, 0), with n > 0, following sequence: srli a0, a1, imm slli a0, a0, imm is used for RISC-V where imm = (31 - width) to improve instruction density and performance. "The RISC-V Instruction Set Manual, Volume I - Unprivileged Architecture" [1] Sec. 2.4.1 "Integer Register-Immediate Instructions" notes the immediate shift for SRLI and SLLI are 5 bits wide starting at bit #10. __runtime_fixup_shift() is reused to patch the immediate shifts for the two instructions. If a future use case arises that needs to tackle arbitrary mask, consider using: lui a0, 0x12346 # upper; +0x800 then >>12 for correct rounding addi a0, a0, 0x678 # lower 12 bits to patch the 32-bit mask in the asm block and return "__ret & (val)" from runtime_const_mask_32() which allows compiler to further optimize the logical and operation. __runtime_fixup_ptr() already patches a lui + addi sequence which can be reused when the need arises. A possible implementation for this alternate scheme can be found at [2]. Suggested-by: Samuel Holland <samuel.holland@sifive.com> Suggested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://docs.riscv.org/reference/isa/_attachments/riscv-unprivileged.pdf [1] Link: https://lore.kernel.org/lkml/20260430094730.31624-6-kprateek.nayak@amd.com/ [2] Link: https://patch.msgid.link/20260728052540.4728-6-kprateek.nayak@amd.com

Leon Hwang says: ==================== bpf: Introduce global percpu data This patch set introduces global percpu data, similar to commit 6316f78 ("Merge branch 'support-global-data'"), to reduce restrictions in C for BPF programs. With this enhancement, it becomes possible to define and use global percpu variables, like the DEFINE_PER_CPU() macro in the kernel include/linux/percpu-defs.h. The section name for global peurcpu data is ".percpu". Even though, a one-byte percpu variable (e.g., char run SEC(".percpu") = 0;) can trigger a crash with Clang 17 [1], users are expected to use such small variables as global percpu data with newer Clang versions, which don't have the issue. The idea stems from the bpfsnoop [2], which itself was inspired by retsnoop [3]. During testing of bpfsnoop on the v6.6 kernel, two LBR (Last Branch Record) entries were observed related to the bpf_get_smp_processor_id() helper. Since commit 1ae6921 ("bpf: inline bpf_get_smp_processor_id() helper"), the bpf_get_smp_processor_id() helper has been inlined on x86_64, reducing the overhead and consequently minimizing these two LBR records. However, the introduction of global percpu data offers a more robust solution. By leveraging the percpu_array map and percpu instruction, global percpu data can be implemented intrinsically. This feature also facilitates sharing percpu information between tail callers and callees or between freplace callers and callees through a shared global percpu variable. Previously, this was achieved using a 1-entry percpu_array map, which this patch set aims to improve upon. Links: [1] https://lore.kernel.org/bpf/fd1b3f58-c27f-403d-ad99-644b7d06ecb3@linux.dev/ [2] https://github.com/bpfsnoop/bpfsnoop [3] https://github.com/anakryiko/retsnoop Changes: v11 -> v12: * Improve feature check in bpf_object__create_maps() in libbpf. * Add percpu_array map support in bpf_map__set_value_size() in libbpf. * Exercise bpf_map__set_value_size() in selftest. * Drop dead warning in bpf_object__populate_internal_map() in libbpf. (Sashiko) * v11: https://lore.kernel.org/bpf/20260806163125.11172-1-leon.hwang@linux.dev/ v10 -> v11: * Drop env->prog->jit_requested check when inlining insns for global percpu data. * Do not autocreate percpu_array map when kernel does not have global percpu data support in libbpf. * Check map->btf_value_type_id in bpftool's is_skel_data(). * Exercise bpf_map__lookup_elem() in selftest. * Collect Reviewed-by tags from Emil, thanks. * Drop all duplicate blank lines in kernel/bpf/*.c. (Emil) * Factor out check_map_mem_read() helper. (Emil) * Check bpf_jit_supports_percpu_insn() first in percpu_array_map_direct_value_addr/meta(). (Emil) * Add comment for 'map->libbpf_type == LIBBPF_MAP_PERCPU' in libbpf's map_is_mmapable(). (Emil) * Init update_flags as a const var in libbpf's bpf_object__populate_internal_map(). (Emil) * Keep is_mmapable_map() beyond is_skel_data() in bpftool. (Emil) * Add 'run' and 'cpu_id' in selftest. (Emil) * Drop subskel test. Verify the generated subskel manually. (Emil) * Add comment to the raw insns in selftest. (Emil) * v10: https://lore.kernel.org/bpf/20260715153254.92010-1-leon.hwang@linux.dev/ v9 -> v10: * Rebase latest bpf-next tree to resolve code conflict in verifier in patch #1. * v9: https://lore.kernel.org/bpf/20260713154024.30851-1-leon.hwang@linux.dev/ v8 -> v9: * Use real name for percpu data maps in libbpf in patch #4. * Add long map name test in patch #6. * Move parse_cpu_mask_file() to test_percpu_data_on_cpus() in test in patch #6. * Validate map type in get_map_ident() for percpu data maps in patch #5. * Update code comment in verifier in patch #2. (per Andrii) * Pass 'type' to internal_map_name in libbpf in patch #4. (per Andrii) * Factor out the helper is_skel_data() in bpftool in patch #5. (per Quentin and Andrii) * v8: https://lore.kernel.org/bpf/20260629152406.52582-1-leon.hwang@linux.dev/ v7 -> v8: * Send patch #1 and #2 separately that fix interpreter fallback issues. (Andrii) * Use 'array->elem_size' to avoid 'range' local variable in percpu_array_map_direct_value_meta(). (Andrii) * Keep original map name for percpu data's map in libbpf. (Andrii) * Factor out helper bpf_map_is_skel_data() in bpftool. (Andrii) * Update commit message of direct access read-only percpu_array map. (Andrii) * Add test to verify that it is disallowed to directly write data of read-only percpu_array map. (Andrii) * Drop unused 'num_cpus' in test. (bot+bpf-ci) * Factor out helper test_percpu_data_on_cpus() in test. (bot+bpf-ci) * v7: https://lore.kernel.org/bpf/20260622143557.22955-1-leon.hwang@linux.dev/ v6 -> v7: * Use tgt_endian() in bpf_gen__map_update_elem() in patch #6. (Sashiko) * Use sizeof(args) in verifier_snprintf test in patch #10. (Sashiko) * Drop xlated test of v6. (Alexei) * v6: https://lore.kernel.org/bpf/20260615152646.27639-1-leon.hwang@linux.dev/ v5 -> v6: * Prevent running user addr_space_cast and addr_percpu insns in interpreter. (Sashiko) * Cast __percpu pointer to u64 with (__force unsigned long). (lkp) * Exclude BPF_MAP_TYPE_PERCPU_ARRAY in check_mem_access() before calling bpf_map_direct_read(), and add a test to verify it. (Sashiko, bot+bpf-ci) * Skip percpu data variables for subskeleton in bpftool. (Sashiko) * Protect skel->percpu using mprotect(..., PROT_READ) in light skeleton. (Sashiko, bot+bpf-ci) * Drop roundup() in tests. (Sashiko) * Call test_global_percpu_data_verifier_log() without test__start_subtest(). (Sashiko) * Cast insn->imm to __u64 with (__u32) in xlated test. (Sashiko) * Check cnt using the new idx in xlated test. (Sashiko) * v5: https://lore.kernel.org/bpf/20260608145113.65857-1-leon.hwang@linux.dev/ v4 -> v5: * Add prog->jit_requested check to prevent running percpu data in interpreter in patch #1. * Factor out verifier log tests using its own patch. * Address comments from Alexei: * Move map_type check from check_mem_access() to bpf_map_direct_read() in patch #2. * Move BPF_MAP_TYPE_INSN_ARRAY map_type check from const_reg_xfer() to bpf_map_direct_read() in patch #2. * Add a test to verify that the off of xlated ldimm64 insn matches the off encoded in the ELF ldimm64 insn. * Drop patch #5 of v4. * Address reviews from Sashiko: * Update commit message of patch #6 to indicate that maps.percpu->mmaped has been marked as read-only in libbpf. * Lookup elem on specified CPU using BPF_F_CPU in tests. * Drop unnecessary err == -EOPNOTSUPP in test. * Locate target field using its offset in the iter test. * v4: https://lore.kernel.org/bpf/20260414132421.63409-1-leon.hwang@linux.dev/ v3 -> v4: * Drop duplicate blank lines in verifier. * Add percpu data feature probe in libbpf. * Update percpu_array map using BPF_F_ALL_CPUS flag for lskel, if no cpu flag is set. * Add two tests to verify verifier log. * Add a test to verify mov64_percpu_reg instruction. * Add a test to verify bpf_iter for percpu data map. * Update percpu_array map using BPF_F_ALL_CPUS flag in libbpf (per Alexei and Andrii). * Address comments from Andrii: * Use .percpu as section identifier. * Use bpf_jit_supports_percpu_insn() instead of CONFIG_SMP. * Drop bpf_map__is_internal_percpu() API. * Drop unnecessary __aligned(8) in libbpf, verified by selftest. * Make mmap data read-only after loading prog. v3: https://lore.kernel.org/bpf/20250526162146.24429-1-leon.hwang@linux.dev/ v2 -> v3: * Use ".data..percpu" as PERCPU_DATA_SEC. * Address comment from Alexei: * Add u8, array of ints and struct { .. } vars to selftest. v2: https://lore.kernel.org/bpf/20250213161931.46399-1-leon.hwang@linux.dev/ v1 -> v2: * Address comments from Andrii: * Use LIBBPF_MAP_PERCPU and SEC_PERCPU. * Reuse mmaped of libbpf's struct bpf_map for .percpu map data. * Set .percpu struct pointer to NULL after loading skeleton. * Make sure value size of .percpu map is __aligned(8). * Use raw_tp and opts.cpu to test global percpu variables on all CPUs. * Address comments from Alexei: * Test non-zero offset of global percpu variable. * Test case about BPF_PSEUDO_MAP_IDX_VALUE. v1: https://lore.kernel.org/bpf/20250127162158.84906-1-leon.hwang@linux.dev/ rfc -> v1: * Address comments from Andrii: * Keep one image of global percpu variable for all CPUs. * Reject non-ARRAY map in bpf_map_direct_read(), check_reg_const_str(), and check_bpf_snprintf_call() in verifier. * Split out libbpf changes from kernel-side changes. * Use ".percpu" as PERCPU_DATA_SEC. * Use enum libbpf_map_type to distinguish BSS, DATA, RODATA and PERCPU_DATA. * Avoid using errno for checking err from libbpf_num_possible_cpus(). * Use "map '%s': " prefix for error message. rfc: https://lore.kernel.org/bpf/20250113152437.67196-1-leon.hwang@linux.dev/ ==================== Link: https://patch.msgid.link/20260813152324.97937-1-leon.hwang@linux.dev Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

secretmem_fault() allocates a folio with GFP_HIGHUSER and then calls set_direct_map_invalid_noflush() without checking folio_test_highmem(). This causes a warning and process crash (vibe-coded reproducer in Link below): Su[ 30.071284] ------------[ cut here ]------------ ccessfully allocated and mapped 2097152000 bytes at 0x3a449000 Populating memor[ 30.074614] CPA: called for zero pte. vaddr = 0 cpa->vaddr = 0 y... [ 30.078636] WARNING: arch/x86/mm/pat/set_memory.c:1840 at __cpa_process_fault+0x34d/0x360, CPU#5: allocate_secret/570 [ 30.084789] CPU: 5 UID: 0 PID: 570 Comm: allocate_secret Not tainted 7.1.0-14063-g4edcdefd4083-dirty #10 PREEMPTLAZY [ 30.090937] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 30.097543] EIP: __cpa_process_fault+0x34d/0x360 [ 30.100514] Code: ff ff 85 c0 0f 89 7d fe ff ff e9 3d fe ff ff 8b 03 8b 00 c7 04 24 c8 ff 64 c1 89 44 24 08 8b 45 e8 89 44 24 04 e8 53 7 a 00 00 <0f> 0b c7 45 f0 f2 ff ff ff e9 fc fc ff ff 90 8d 74 26 00 55 25 00 [ 30.110829] EAX: 00000000 EBX: f64afe98 ECX: 00000000 EDX: 00000000 [ 30.114799] ESI: 00000000 EDI: f64afe98 EBP: f64afe04 ESP: f64afdcc [ 30.118785] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010246 [ 30.123020] CR0: 80050033 CR2: 46c48ffc CR3: 038c8000 CR4: 00000690 [ 30.127010] Call Trace: [ 30.129078] __change_page_attr_set_clr+0x5e7/0x870 [ 30.132275] ? console_unlock+0x99/0x130 [ 30.135069] ? irq_work_queue+0x36/0x70 [ 30.137853] ? page_address+0xd3/0xf0 [ 30.140421] set_direct_map_invalid_noflush+0x52/0x60 [ 30.143782] secretmem_fault+0x128/0x210 [ 30.146560] __do_fault+0x25/0x90 [ 30.149053] handle_mm_fault+0x6d1/0xcb0 [ 30.151759] exc_page_fault+0x135/0x3b0 [ 30.154487] ? doublefault_shim+0x150/0x150 [ 30.157416] handle_exception+0x130/0x130 [ 30.160137] EIP: 0x804d29f [ 30.162307] Code: 89 54 08 e1 89 54 08 e5 89 54 08 e9 89 54 08 ed c3 0f b6 44 24 08 89 7c 24 0c 69 c0 01 01 01 01 8b 7c 24 04 f7 c7 0f 0 0 00 00 <89> 44 0f fc 75 0e c1 e9 02 f3 ab 8b 44 24 04 8b 7c 24 0c c3 31 d2 [ 30.172936] EAX: 5a5a5a5a EBX: 00000000 ECX: 0c800000 EDX: 3a449000 [ 30.176927] ESI: 00000000 EDI: 3a449000 EBP: bfbbae18 ESP: bfbbadac [ 30.180897] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00010246 [ 30.185161] ? doublefault_shim+0x150/0x150 [ 30.187979] ---[ end trace 0000000000000000 ]--- Bus error (core dumped) ./allocate_secret_i686 2000M The equivalent bug was pointed out by a local Sashiko instance on https://lore.kernel.org/all/20260410151746.61150-3-kalyazin@amazon.com/ This hasn't been reproduced it on older kernel versions but from code inspection the bug seems to go back to the original introduction in commit 1507f51 ("mm: introduce memfd_secret system call to create "secret" memory areas"). If this configuration has always been broken, there's no need to worry too much about feature regression here. Nonetheless, instead of just completely disabling secretmem under !HIGHMEM, just drop __GFP_HIGHMEM. This means that now where you previously got a crash, instead you'll just see the secretmem process OOM. Could secretmem just support highmem by saying "this isn't in the direct map anyway" and bailing out before the set_direct_map_invalid_noflush()? Maybe. That depends on requirements that are not well-defined (e.g. is it OK that kmap_local_page() is not a NOP for those pages?), and would require some research and deep thinking. Let's "defer" that until an actual usecase arises. Link: bjackman/limmat-kernel-nix@7b2acba Link: https://lore.kernel.org/20260717-secretmem-highmem-v2-1-1f1a961ca91e@google.com Link: https://lore.kernel.org/all/20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org/ Fixes: 1507f51 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Brendan Jackman <jackmanb@google.com> Suggested-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Brendan Jackman <brendan.jackman@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs. Fixes: b8d26b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Link: https://patch.msgid.link/20260731041212.1733364-1-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky <leon@kernel.org>

Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: "Thread-3" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10 Cc: stable@kernel.org Fixes: 05e65c1 ("f2fs: support large folio for immutable non-compressed case") Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>

hz2 force-pushed the hz2/rk3576-csi-camera branch from 5befd87 to 82192bf Compare May 22, 2026 17:21

hz2 marked this pull request as ready for review May 30, 2026 05:09

hz2 requested a review from a team May 30, 2026 05:09

alchark requested changes Jun 1, 2026

View reviewed changes

alchark force-pushed the flipper-devel branch 2 times, most recently from 2ac16f5 to c32805c Compare June 5, 2026 17:42

hz2 force-pushed the hz2/rk3576-csi-camera branch from c233671 to 56c5e08 Compare June 12, 2026 16:41

hz2 requested a review from alchark June 12, 2026 18:31

sre and others added 16 commits June 17, 2026 18:14

[DEBUG] usb: typec: tcpm: also log to dmesg

06db0bd

Also log to normal dmesg to assist debugging hard reset issues. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

[DEBUG] usb: typec: fusb302: also log to dmesg

fd51427

Also log to normal dmesg to assist debugging hard reset issues. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

math.h: add DIV_ROUND_UP_NO_OVERFLOW

858fa93

Add a new DIV_ROUND_UP helper, which cannot overflow when big numbers are being used. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

clk: composite: replace open-coded abs_diff()

22cee55

Replace the open coded abs_diff() with the existing helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

arm64: dts: rockchip: rk3588-evb1: add bluetooth rfkill

5307cca

Add rfkill support for bluetooth. Bluetooth support itself is still missing, but this ensures bluetooth can be powered off properly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

arm64: dts: rockchip: rk3588-evb1: improve PCIe ethernet pin muxing

c1073b0

Also describe wake signal PCIe pinmux for the onboard LAN card. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

dt-bindings: display: vop2: Add VP clock resets

ef6d60c

Add the documentation for VOP2 video ports reset clocks. One reset can be set per video port. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

arm64: dts: rockchip: Add VOP clock resets for rk3588s

b278c7e

This adds the needed clock resets for all rk3588(s) based SOCs. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

alchark added 2 commits June 22, 2026 17:26

Input: add support for Flipper One haptic LRA

c05b7d9

Flipper One has a haptic LRA (linear resonant actuator) exposed via its MCU interconnect interface. Add a driver to expose the haptic actuator as a force feedback device. Signed-off-by: Alexey Charkov <alchark@flipper.net>

alchark force-pushed the flipper-devel branch from d2446f3 to 5f8b212 Compare June 22, 2026 13:26

hz2 added 8 commits June 25, 2026 09:40

media: synopsys: dw-mipi-csi2rx: add support for RK3576

700e8ba

The RK3576 uses the same Synopsys DesignWare MIPI CSI-2 Host controller IP as the RK3568. Add the compatible string using the existing RK3568 driver data. Signed-off-by: Jason Devers <dev.json2@gmail.com>

dt-bindings: media: rockchip,rk3568-mipi-csi2: add rk3576 support

47691ff

Add rockchip,rk3576-mipi-csi2 as a compatible that falls back to rockchip,rk3568-mipi-csi2, following the same pattern as the existing rk3588-mipi-csi2 entry. Signed-off-by: Jason Devers <dev.json2@gmail.com>

dt-bindings: soc: rockchip: grf: add rk3576 CSI D-PHY GRF

b3f915a

The RK3576 has two GRF blocks for its Innosilicon CSI D-PHY instances, analogous to the rk3588-csidphy-grf. Document the compatible so the rk3576 camera pipeline nodes validate. Signed-off-by: Jason Devers <dev.json2@gmail.com>

hz2 force-pushed the hz2/rk3576-csi-camera branch from 56c5e08 to b3f915a Compare June 26, 2026 15:05

alchark force-pushed the flipper-devel branch from 927d9f5 to 72bef51 Compare July 14, 2026 17:20

Owen-Boardcon mentioned this pull request Jul 15, 2026

[社区追踪] RK3576 MIPI CSI 摄像头管线主线支持（flipperdevices/flipper-linux-kernel#10） Owen-Boardcon/bsp-rk3576#9

Open

alchark force-pushed the flipper-devel branch from 72bef51 to 895107b Compare July 15, 2026 11:28

alchark force-pushed the flipper-devel branch 3 times, most recently from 8c6f049 to e846cb3 Compare July 28, 2026 14:00

alchark force-pushed the flipper-devel branch from 22ef53f to 9111dec Compare August 4, 2026 12:36

alchark force-pushed the flipper-devel branch 2 times, most recently from aa812ec to 99a245c Compare August 21, 2026 13:24

alchark force-pushed the flipper-devel branch 2 times, most recently from 4bafbea to ef831a3 Compare September 7, 2026 15:05

alchark force-pushed the flipper-devel branch from d1b95bc to e1d9cab Compare September 11, 2026 08:13

Navigation Menu

arm64: rockchip: add MIPI CSI camera pipeline support for RK3576 - #10

arm64: rockchip: add MIPI CSI camera pipeline support for RK3576#10
hz2 wants to merge 218 commits into
flipperdevices:flipper-develfrom
hz2:hz2/rk3576-csi-camera

hz2 commented May 22, 2026

Uh oh!

alchark commented May 22, 2026

Uh oh!

hz2 commented May 22, 2026

Uh oh!

alchark commented May 22, 2026

Uh oh!

hz2 commented May 22, 2026 •

edited

Loading

Uh oh!

hz2 commented May 30, 2026

Uh oh!

Uh oh!

Uh oh!

alchark Jun 1, 2026

Uh oh!

hz2 Jun 3, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hz2 commented Jun 3, 2026

Uh oh!

hz2 commented Jun 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

		struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

		priv->sys_grf_lane_sel_bit = (res && res->start == 0x2b070000) ? 2 : 1;

Conversation

hz2 commented May 22, 2026

Uh oh!

alchark commented May 22, 2026

Uh oh!

hz2 commented May 22, 2026

Uh oh!

alchark commented May 22, 2026

Uh oh!

hz2 commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hz2 commented May 30, 2026

Uh oh!

Uh oh!

Uh oh!

alchark Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

hz2 Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hz2 commented Jun 3, 2026

Uh oh!

hz2 commented Jun 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

hz2 commented May 22, 2026 •

edited

Loading