* [PATCH v3 00/11] arm64: dts: ti: k3-am62-verdin: Add display and peripheral overlays
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
From: Vitor Soares <vitor.soares@toradex.com>
This series adds device tree overlays, expanding the hardware support for
the Toradex Verdin AM62 SoM. The overlays target displays, cameras, audio,
and peripherals available through Toradex carrier boards and the accessory
ecosystem.
Display additions cover three interface types:
- native OLDI (LVDS) with Toradex Capacitive Touch Display 10.1" LVDS
- DSI-to-LVDS adapter based on the SN65DSI84 with Toradex Capacitive Touch
Display 10.1" LVDS
- DSI driving Toradex Capacitive Touch Display 7" and 10.1" DSI.
The Riverdi vendor prefix and panel bindings required by the DSI overlay
patches are also added.
Non-display additions include OV5640 CSI camera support in 24 MHz and
27 MHz oscillator variants, NAU8822 Bridge Tied Load mode on the
Development Board, MCU_MCAN1 on the Mezzanine board low-speed header,
and MCU_UART0 reservation for the Cortex-M4F debug UART.
TI maintainers: patches adding the Riverdi vendor prefix and panel-lvds
bindings are required by the DTS patches.
Are you fine picking up the full series once those patches are acked by
the DT/display maintainers?
---
Changes in v3:
- Add missing regulator-name property on fixed regulators
- Simplify regulator labels (reg_3v3_lvds_native -> reg_3v3_lvds,
reg_3v3_lvds_bridge -> reg_3v3_dsi)
- Rename touch@ nodes to touchscreen@
- Link v2: https://lore.kernel.org/all/20260522132014.226721-13-ivitro@gmail.com/
Changes in v2:
- Add Ab tags
- Drop introduction of the LG LP156WF1 15.6" FHD dual-channel LVDS panel
- Drop migration of "logictechno,lt170410-2whc" to panel-lvds.yaml
- Link v1: https://lore.kernel.org/all/20260521150038.103538-17-ivitro@gmail.com/
---
Vitor Soares (11):
arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with
10.1" display
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
10.1" LVDS
dt-bindings: vendor-prefixes: Add Riverdi
dt-bindings: display: panel-lvds: Add Riverdi RVT70HSLNWCA0 and
RVT101HVLNWC00
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
10.1" DSI
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
7" DSI
arm64: dts: ti: k3-am62-verdin: Add NAU8822 Bridge Tied Load
arm64: dts: ti: k3-am62-verdin: Reserve UART_4 for Cortex-M4F
arm64: dts: ti: k3-am62-verdin: Add Toradex OV5640 CSI Cameras
arm64: dts: ti: k3-am62-verdin: Add Toradex Verdin Mezzanine CAN
arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display
10.1" LVDS
.../bindings/display/panel/panel-lvds.yaml | 4 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/ti/Makefile | 49 +++++++
.../ti/k3-am625-verdin-dev-mezzanine-can.dtso | 28 ++++
...mezzanine-panel-cap-touch-10inch-lvds.dtso | 98 +++++++++++++
.../ti/k3-am625-verdin-dev-nau8822-btl.dtso | 14 ++
...in-dsi-to-lvds-panel-cap-touch-10inch.dtso | 124 ++++++++++++++++
.../dts/ti/k3-am625-verdin-ov5640-24mhz.dtso | 17 +++
.../boot/dts/ti/k3-am625-verdin-ov5640.dtsi | 71 ++++++++++
.../boot/dts/ti/k3-am625-verdin-ov5640.dtso | 18 +++
...625-verdin-panel-cap-touch-10inch-dsi.dtso | 132 ++++++++++++++++++
...25-verdin-panel-cap-touch-10inch-lvds.dtso | 120 ++++++++++++++++
...m625-verdin-panel-cap-touch-7inch-dsi.dtso | 132 ++++++++++++++++++
.../dts/ti/k3-am625-verdin-uart4-mcu.dtso | 13 ++
14 files changed, 822 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-can.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-nau8822-btl.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640-24mhz.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-uart4-mcu.dtso
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist
From: Geert Uytterhoeven @ 2026-05-22 15:47 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Nguyen Tran, Brian Masney, Conor Dooley,
Geert Uytterhoeven, Krzysztof Kozlowski, Kuninori Morimoto,
Magnus Damm, Michael Turquette, Rob Herring, Stephen Boyd,
Ulf Hansson, Wolfram Sang, devicetree, linux-clk, linux-kernel,
linux-mmc, linux-renesas-soc
In-Reply-To: <20260504144534.43745-8-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
>
> Add support for the Geist board based on the Renesas R-Car R8A779MD (M3Le)
> SoC, a register-compatible variant of the R8A77965 (M3-N) with reduced set
> of peripherals.
>
> Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: - Drop CS2500 variant suffix
> - Drop cells from rcar_sound ports {}
> - Drop ehci1, ohci1, usb2_phy1
> - Drop Salvator-X reference from commit message
> - Split panel DTO into separate patch
> - Drop FCNL node
> - Add another memory node for the second 2 GiB of DRAM,
> although the DRAM layout is patched in by U-Boot
> - Drop FIXME from audio-clkout {}
> - Sort nodes without unit address
> - Rename regulators, use npmv suffix for n.m V regulators
> - Rename x12 node to x12-clock node
> - Add PHY compatible string
> - Use interrupts-extended in PHY node
> - Rename clk_multiplier/clock-generator to clock-controller
> - Use interrupts-extended
> - Reinstate port@0 to rsound
> - Drop iommus from SDHI2
> - Drop DU until it can be tested
Thanks for the update!
--- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
> +&avb {
> + pinctrl-0 = <&avb_pins>;
> + pinctrl-names = "default";
> + phy-handle = <&phy0>;
> + tx-internal-delay-ps = <2000>;
> + status = "okay";
> +
> + phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-id0022.1622";
> + rxc-skew-ps = <1500>;
> + reg = <0>;
> + interrupts-extended = <&gpio2 11 IRQ_TYPE_LEVEL_LOW>;
> + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <100>;
10000?
> + reset-deassert-us = <100>;
300?
> + };
> +};
> +&pfc {
> + pwm2_pins: pwm2 {
> + groups = "pwm2_a";
> + function = "pwm2";
> + };
Shall I drop this while applying?
> +&pwm2 {
> + pinctrl-0 = <&pwm2_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
Shall I drop this while applying?
With the above fixed:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-22 15:53 UTC (permalink / raw)
To: Barry Song
Cc: David Hildenbrand (Arm), Matthew Wilcox, Liam R. Howlett,
Suren Baghdasaryan, akpm, linux-mm, vbabka, rppt, mhocko, jack,
pfalcato, wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1,
chrisl, kasong, shikemeng, nphamcs, bhe, youngjun.park,
linux-arm-kernel, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4xC5LdhuoWV1=tK-RZ5rkjc8aOKOkmb1L_8BG_3gtJhDg@mail.gmail.com>
On Thu, May 21, 2026 at 07:37:58AM +0800, Barry Song wrote:
> On Thu, May 21, 2026 at 5:35 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
> >
> > On 5/20/26 23:15, Matthew Wilcox wrote:
> > > On Thu, May 21, 2026 at 05:14:20AM +0800, Barry Song wrote:
> > >> My understanding is that we should not blame applications here. This is 2026:
> > >> there are basically only two kinds of applications — single-threaded and
> > >> multi-threaded — and single-threaded applications are nearly extinct.
> > >
> > > all of the applications i run are either single threaded or don't fork.
> > > what multithreaded applications call fork?
> >
> > Traditionally the problem was random libraries using fork+execve to launch other
> > programs ... instead of using alternatives like posix_spwan (some use cases
> > require more work done before execve and cannot yet switch to that). I'd hope
> > that that is less of a problem on Android.
> >
> > I assume Android zygote might be multi threaded? Maybe sshd as well? Systemd?
> > But I'd be surprised if there are really performance implications.
>
> I am trying to answer the question above:
>
> 1. zygote, multi-threaded on my phone using Android13.
> / # ls /proc/`pidof zygote64`/task/
> 1359 22728 22729 22730 22731 22732
>
> /proc/1359/task # cat 22728/comm
> Jit thread pool
> /proc/1359/task # cat 22730/comm
> ReferenceQueueD
> /proc/1359/task # cat 22731/comm
> FinalizerDaemon
> /proc/1359/task # cat 22732/comm
> FinalizerWatchd
> /proc/1359/task # cat 1359/comm
> main
>
> But on another phone of mine running Android 16, zygote64 is
> single-threaded.
> Not sure if it is due to the Android team making some changes
> related to threads from Android 13 to Android 16.
>
> 2. sshd, multi-processes instead of multi-threads:
> $ ps aux | grep sshd
> root 1192 0.0 0.0 15444 9032 ? Ss 09:42 0:00
> sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
> root 2465 0.0 0.0 17164 10760 ? Ss 09:42 0:00
> sshd: barry [priv]
> barry 2632 0.0 0.0 17164 7852 ? S 09:42 0:00
> sshd: barry@pts/0
> root 3305 2.5 0.0 17164 10772 ? Ss 09:44 0:00
> sshd: barry [priv]
> barry 3406 0.0 0.0 17164 7940 ? S 09:44 0:00
> sshd: barry@pts/1
>
> 3. systemd, also multi-processes
>
> $ ps ax | grep systemd
> 350 ? S<s 0:00 /lib/systemd/systemd-journald
> 387 ? Ss 0:00 /lib/systemd/systemd-udevd
> 666 ? Ss 0:00 /lib/systemd/systemd-oomd
> 667 ? Ss 0:00 /lib/systemd/systemd-resolved
> 728 ? Ss 0:00 @dbus-daemon --system --address=systemd:
> --nofork --nopidfile --systemd-activation --syslog-only
> 751 ? Ss 0:00 /lib/systemd/systemd-logind
> 753 ? Ssl 0:00 /usr/sbin/thermald --systemd
> --dbus-enable --adaptive
> 1350 ? Ss 0:00 /lib/systemd/systemd --user
> 1428 ? Ss 0:00 /usr/bin/dbus-daemon --session
> --address=systemd: --nofork --nopidfile --systemd-activation
> --syslog-only
> 1900 ? Ssl 0:00 /usr/libexec/gnome-session-binary
> --systemd-service --session=ubuntu
> 2141 ? Ssl 0:00 /lib/systemd/systemd-timesyncd
>
> >
> > Not sure about webbroswers .... I think most of them switched to fork servers,
> > where I would assume fork servers would be single-threaded.
>
> On my phone, Chrome is multi-process, but its parent process
> chrome_zygote (10774) is single-threaded:
>
> ps -A | grep chrome
> u0_i15 9883 10774 321066464 119452 do_epoll_wait 0 S
> com.android.chrome:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:15
> u0_a142 10164 1359 35110548 277640 do_epoll_wait 0 S
> com.android.chrome
> u0_a278 10724 1359 9779864 104988 do_epoll_wait 0 S
> com.google.android.apps.chromecast.app
> u0_a142 10774 1359 32803908 64076 do_sys_poll 0 S
> com.android.chrome_zygote
> u0_a142 11173 1359 34208592 142192 do_epoll_wait 0 S
> com.android.chrome:privileged_process0
>
> /proc/10774/task # ls
> 10774
>
> >
> > So, yeah, getting a clear understanding how this ends up being a problem on
> > Android would be great.
>
> I guess the real issue is that in the Android market, there
> are so many applications that are out of our control？
>
> Here are some trace examples from Nanzhe:
>
> iQIYI plugin
> vma reader thread:
> PbMisc-0, pid=27183, tgid=26444
>
> vma writer thread:
> i.video:plugin1, pid=27298, tgid=26444
> writer blocked: 440394938 ns (440 ms)
>
> reader stack:
> vma_start_read
> lock_vma_under_rcu
> do_page_fault
> do_translation_fault
> do_mem_abort
> el0_da
> el0t_64_sync_handler
> el0t_64_sync
>
> writer stack:
> __vma_start_write
> dup_mmap
> copy_mm
> copy_process
> kernel_clone
> __arm64_sys_clone
> invoke_syscall
> el0_svc_common
> do_el0_svc
> el0_svc
>
>
> Baidu Tieba
> vma reader thread:
> elastic_pms_pro, pid=7731, tgid=7575
>
> vma writer thread:
> com.baidu.tieba, pid=8005, tgid=7575
> writer blocked: 514975545 ns(515 ms)
>
> reader stack:
> vma_start_read
> lock_vma_under_rcu
> do_page_fault
> do_translation_fault
> do_mem_abort
> el0_da
> el0t_64_sync_handler
> el0t_64_sync
>
> writer stack:
> __vma_start_write
> dup_mmap
> copy_mm
> copy_process
> kernel_clone
> __arm64_sys_clone
> invoke_syscall
> el0_svc_common
> do_el0_svc
> el0_svc
>
> Thanks
> Barry
Again this is making me want to sit outside and sip on some lemonade and
ice :)
Yes - android processes are aggressively multi-threaded, sure of course.
The missing bit here is the forking - what, where, why, when?
And then you say zygote is sometimes multi-threaded but sometimes
single-threaded, which is adding a whole bunch of confusion on top of all
that.
I don't find these stack trace dumps all that useful (though thanks of
course for taking the time to gather them), I think we'd be better off with
specific data on forking, in some _concise_ _summarised_ form, ideally with
numbers.
There's such a thing as too much information :))
Anyway, again, please let's see a new _RFC_ with the approach proposed by
Suren, with some _succinct_ data demonstrating _exactly_ what the problem
is, so we can make some headway here.
And now I'm off for a cornetto! :)
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 01/11] arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with 10.1" display
From: Vitor Soares @ 2026-05-22 15:51 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260522132014.226721-14-ivitro@gmail.com>
Hi,
On Fri, 2026-05-22 at 14:20 +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> Add a device tree overlay for the Toradex DSI to LVDS Adapter with the
> Toradex Capacitive Touch Display 10.1" LVDS. The adapter connects to the
> Verdin DSI_1 interface. It is based on the Texas Instruments SN65DSI84
> DSI-to-LVDS bridge and drives a LogicTechno LT170410-2WHC 10.1" WXGA LVDS
> panel. Touch input is provided by an Atmel MaxTouch capacitive touch
> controller.
>
> Link:
> https://developer.toradex.com/hardware/accessories/add-ons/dsi-lvds-adapter
> Link:
> https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
> Assisted-by: Claude:claude-sonnet-4.6
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
>
[...]
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-
> touch-10inch.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-
> cap-touch-10inch.dtso
> new file mode 100644
> index 000000000000..0e873f2ccf65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-
> 10inch.dtso
>
[...]
> +
> + reg_3v3_lvds_bridge: regulator-3v3-lvds-bridge {
> + compatible = "regulator-fixed";
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
Sashiko flagged the missing 'regulator-name' property here,
> + };
> +};
> +
>
[...]
> +
> + touch@4a {
and to use the generic node name 'touchscreen@4a' here instead of
'touch@4a'.
> + compatible = "atmel,maxtouch";
> + reg = <0x4a>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_dsi1_int>, <&pinctrl_i2s_2_bclk_gpio>;
> + /* Verdin GPIO_9_DSI (SODIMM 17) - TOUCH_INT# */
> + interrupt-parent = <&main_gpio1>;
> + interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
> + /* Verdin I2S_2_BCLK (SODIMM 42) - TOUCH_RESET# */
> + reset-gpios = <&main_gpio0 35 GPIO_ACTIVE_LOW>;
> + };
> +};
I will send a v3 addressing these issues here and where it applies.
Thanks,
Vitor Soares
^ permalink raw reply
* RE: [PATCH v2 2/2] spi: aspeed: Replace VLA parameter with flat pointer in calibration helper
From: Chin-Ting Kuo @ 2026-05-22 15:48 UTC (permalink / raw)
To: David Laight
Cc: clg@kaod.org, broonie@kernel.org, joel@jms.id.au,
andrew@codeconstruct.com.au, linux-aspeed@lists.ozlabs.org,
openbmc@lists.ozlabs.org, linux-spi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, BMC-SW, kernel test robot
In-Reply-To: <20260522091915.65dde4ad@pumpkin>
Hi David,
> -----Original Message-----
> From: David Laight <david.laight.linux@gmail.com>
> Sent: Friday, May 22, 2026 4:19 PM
> Subject: Re: [PATCH v2 2/2] spi: aspeed: Replace VLA parameter with flat
> pointer in calibration helper
>
> On Fri, 22 May 2026 15:16:21 +0800
> Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> wrote:
>
> > aspeed_spi_ast2600_optimized_timing() declared its buffer argument as
> > a variable-length array parameter (u8 buf[rows][cols]), which causes a
> > sparse warning. Replace the VLA parameter with a plain u8 * and
> > compute the 2-D index manually. The corresponding call site is also updated.
>
> This code is all a bit horrid.
> The 6 and 17 (which are also used in the array declaration) have to match the
> TIMING_DELAY_HCYCLE_MAX and TIMING_DELAY_INPUT_MAX values used
> for the loops.
>
The magic numbers 6 and 17 can be derived from
TIMING_DELAY_HCYCLE_MAX and TIMING_DELAY_INPUT_MAX. However, this is
a pre-existing issue unrelated to the current patch. Will address it in a separate
cleanup patch series in the future.
> In any case the code would be more obvious if the 'run length' of test passes
> was counted during the initial loop.
> Looks like it wants at least 4 ones, after you've got that many (and a fail) there
> is little point continuing the delay loop for that hcycle.
>
The intent is to find the center of the longest consecutive pass window across
all hcycle/delay combinations, not just the first window with 4 passes.
The threshold of 4 is the minimum tolerable window size derived from
empirical results, not an early exit hint. Besides, recording all results in
a 2-D array also keeps the data collection and the analysis cleanly separated,
which makes the calibration logic easier to follow and test independently.
Chin-Ting
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: xlnx: enable auto boot feature
From: Mathieu Poirier @ 2026-05-22 15:46 UTC (permalink / raw)
To: tanmay.shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cbd418a3-1585-4592-8e86-b0750e19ec0f@amd.com>
On Thu, May 21, 2026 at 01:38:57PM -0500, Shah, Tanmay wrote:
> Hello,
>
> Thank you for the reviews, please find my comments below:
>
> On 5/21/2026 12:48 PM, Mathieu Poirier wrote:
> > Good morning,
> >
> > I don't recal reviewing the first revision of this set. Can you provide a link
> > to it so that I can read the comments that were provided?
> >
>
> Here it is:
> https://lore.kernel.org/linux-remoteproc/20260422202558.2362971-1-tanmay.shah@amd.com/
>
> The device-tree bindings needed rework in v1, so I sent v2, before we
> ever reviewed the driver part.
>
>
> > On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
> >> remoteproc framework has capability to start (or attach to) the remote
> >
> > The remoteproc framework...
> >
>
> Ack.
>
> >> processor automatically if auto boot flag is set by the driver during
> >> probe. If remote core is not started before the Linux boot, and linux is
> >> expected to start the remote core then it uses "firmware-name" property
> >> to load default firmware during auto boot.
> >>
> >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> >> ---
> >> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
> >> 1 file changed, 34 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> index 45a62cb98072..652030f9cea2 100644
> >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
> >> };
> >>
> >> /**
> >> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
> >> - * Allocate and add struct rproc object for each r5f core
> >> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
> >> + * Allocate struct rproc object for each r5f core
> >> * This is called for each individual r5f core
> >> *
> >> * @cdev: Device node of each r5 core
> >> *
> >> * Return: zynqmp_r5_core object for success else error code pointer
> >> */
> >> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
> >
> > Why is there a need to change the function's name?
> >
>
> Before, the function was actually adding the rproc core by calling
> rproc_add() function, but now it only allocates the memory by calling
> rproc_alloc(). For auto boot to work it's important to add rproc core
> after all the other hw is initialized (such as mbox, tcm, sram,
> power-domains etc). More details below [1].
>
Ok
> >> {
> >> struct zynqmp_r5_core *r5_core;
> >> + const char *fw_name = NULL;
> >> struct rproc *r5_rproc;
> >> int ret;
> >>
> >> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> if (ret)
> >> return ERR_PTR(ret);
> >>
> >> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
> >> + if (ret < 0 && ret != -EINVAL)
> >> + return ERR_PTR(dev_err_probe(cdev, ret,
> >> + "failed to parse firmware-name\n"));
> >> +
> >> /* Allocate remoteproc instance */
> >> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
> >> &zynqmp_r5_rproc_ops,
> >> - NULL, sizeof(struct zynqmp_r5_core));
> >> + fw_name, sizeof(struct zynqmp_r5_core));
> >> if (!r5_rproc) {
> >> dev_err(cdev, "failed to allocate memory for rproc instance\n");
> >> return ERR_PTR(-ENOMEM);
> >> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> r5_rproc->recovery_disabled = true;
> >> r5_rproc->has_iommu = false;
> >> r5_rproc->auto_boot = false;
> >> +
> >> + /* attempt to boot automatically if the firmware-name is provided */
> >> + if (fw_name)
> >> + r5_rproc->auto_boot = true;
> >> +
> >
> > What happens when a firmware name needs to be provided in the DT but you don't
> > want to automatically boot the remote processor?
> >
>
> I think that use case is not needed. If the user/system-designer doesn't
> want auto-boot, then having firmware-name in the device-tree serves no
> purpose. User can always load the firmware via sysfs once kernel boots.
>
Ok
> >> r5_core = r5_rproc->priv;
> >> r5_core->dev = cdev;
> >> r5_core->np = dev_of_node(cdev);
> >> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> goto free_rproc;
> >> }
> >>
> >> - /* Add R5 remoteproc core */
> >> - ret = rproc_add(r5_rproc);
> >> - if (ret) {
> >> - dev_err(cdev, "failed to add r5 remoteproc\n");
> >> - goto free_rproc;
> >> - }
> >> -
> >
> > I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
> > it simply to make the error path easier to handle? If so, please do that in a
> > separate patch.
> >
>
> [1] This was moved to make auto-boot work. The remote core can auto-boot
> only after other hardware is initialized. The zynqmp_r5_core_init()
> initializes sram, TCM and power-domains of the core. Also, mailbox is
> requested before zynqmp_r5_core_init() as well. We can't auto-boot core
> directly without all this. So, I had to move rproc_add() at the end of
> the cluster init, and rename above function from
> zynqmp_r5_add_rproc_core to zynqmp_r5_alloc_rproc_core.
>
> If you prefer, I will add above explanation in the commit text, or as
> comment right before rproc_add().
>
Yes, please add that to the commit log.
>
>
> >> r5_core->rproc = r5_rproc;
> >> return r5_core;
> >>
> >> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> >> if (zynqmp_r5_get_rsc_table_va(r5_core))
> >> dev_dbg(r5_core->dev, "rsc tbl not found\n");
> >> r5_core->rproc->state = RPROC_DETACHED;
> >> + r5_core->rproc->auto_boot = true;
> >
> > I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
> >
>
> That function is now zynqmp_r5_alloc_core() as mentioned above. Also,
> until now, auto_boot was set to 'false' only to show that it is
> disabled. It is actually used and enabled now.
>
Ok
> > Thanks,
> > Mathieu
> >
> >> }
> >> }
> >>
> >> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> >> enum rpu_oper_mode fw_reg_val;
> >> struct device **child_devs;
> >> enum rpu_tcm_comb tcm_mode;
> >> - int core_count, ret, i;
> >> + int core_count, ret, i, j;
> >> struct mbox_info *ipi;
> >>
> >> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
> >> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> >> child_devs[i] = &child_pdev->dev;
> >>
> >> /* create and add remoteproc instance of type struct rproc */
> >> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
> >> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
> >> if (IS_ERR(r5_cores[i])) {
> >> ret = PTR_ERR(r5_cores[i]);
> >> r5_cores[i] = NULL;
> >> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> >> goto release_r5_cores;
> >> }
> >>
> >> + for (j = 0; j < cluster->core_count; j++) {
> >> + /* Add R5 remoteproc core */
> >> + ret = rproc_add(r5_cores[j]->rproc);
> >> + if (ret) {
> >> + dev_err_probe(r5_cores[j]->dev, ret,
> >> + "failed to add remoteproc\n");
> >> + goto delete_r5_cores;
> >> + }
> >> + }
> >> +
> >> kfree(child_devs);
> >> return 0;
> >>
> >> +delete_r5_cores:
> >> + i = core_count - 1;
> >> + /* delete previous added rproc */
> >> + while (--j >= 0)
> >> + rproc_del(r5_cores[j]->rproc);
> >> +
> >> release_r5_cores:
> >> while (i >= 0) {
> >> put_device(child_devs[i]);
> >> if (r5_cores[i]) {
> >> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
> >> of_reserved_mem_device_release(r5_cores[i]->dev);
> >> - rproc_del(r5_cores[i]->rproc);
> >> rproc_free(r5_cores[i]->rproc);
> >> }
> >> i--;
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: [PATCH 2/3] iommu/vt-d: Add PCI segment and vendor:device ID to DMAR fault logs
From: Oguz, Yigit @ 2026-05-22 15:45 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
baolu.lu@linux.intel.com, dwmw2@infradead.org,
suravee.suthikulpanit@amd.com, jgg@ziepe.ca, nicolinc@nvidia.com,
iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Janpoladyan, Lilit, Yigit Oguz,
Saenz Julienne, Nicolas
In-Reply-To: <afzmQ6FieJ2YIt9Y@google.com>
> Not an Intel iommu expert, but I have concerns about using
> pci_get_domain_bus_and_slot() in this path.
>
> AFAICT, dmar_fault_do_one() is running in a IRQ context & the pci_get_*
> family of functions iterates the global PCI klist. It eventually calls
> bus_to_subsys(), which takes a plain spin_lock(&bus_kset->list_lock) [1]
> which isn't IRQ-safe. Same thing with klist_put [2] called in klist_iter_exit
Yes, confirmed. bus_to_subsys() takes a non-IRQ-safe spinlock, so this
is indeed broken in hard IRQ context.
> Same here, pci_dev_put call put_device which might sleep [3] and hence
> shouldn't be called in hard IRQ context.
Agreed.
I looked at converting this to request_threaded_irq() so the handler
runs in process context, but the DMAR fault interrupt is registered
early in boot before kthreads exist. Rearranging the boot sequence just
to enrich a log message isn't feasible.
I also considered a manual linear search, walk the PCI bus and device
lists to find the matching BDF. But on systems with hundreds of devices
registered, that's too much time spent in hard IRQ context.
Do you (or anyone on the list) have ideas for a clean way to get
vendor:device id in this context?
Thanks,
Yigit
On Wed, May 06, 2026 at 03:05:38PM +0000, Yigit Oguz wrote:
> Include the full SSSS:BB:DD.F address with PCI segment and
> vendor:device ID (VVVV:DDDD) in DMAR fault messages. Uses
> iommu->segment for the PCI domain and pci_get_domain_bus_and_slot
> to look up the pci_dev. Falls back to segment:BDF without
> vendor:device if the device is not found.
>
> This brings Intel IOMMU fault logging in line with the ARM SMMUv3
> event decoding, making it easier to identify faulting devices
> (e.g. after FLR) without cross-referencing lspci.
>
> Before:
> DMAR: [DMA Write NO_PASID] Request device [86:00.0] fault addr 0xe0000000
> [fault reason 0x05] PTE Write access is not set
>
> After:
> DMAR: [DMA Write NO_PASID] Request device [0000:86:00.0 8086:1533] fault addr 0xe0000000
> [fault reason 0x05] PTE Write access is not set
>
> Signed-off-by: Yigit Oguz <yigitogu@amazon.de <mailto:yigitogu@amazon.de>>
> Signed-off-by: Lilit Janpoladyan <lilitj@amazon.com <mailto:lilitj@amazon.com>>
> Assisted-by: Claude:claude-4.6-opus
> ---
> drivers/iommu/intel/dmar.c | 33 +++++++++++++++++++++------------
> 1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index d33c119a935e..225fa498d714 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -1890,30 +1890,39 @@ static int dmar_fault_do_one(struct intel_iommu *iommu, int type,
> {
> const char *reason;
> int fault_type;
> + u8 bus = source_id >> 8;
> + u8 devfn = source_id & 0xFF;
> + struct pci_dev *pdev;
> + char devid[48];
Why not have a #define for this like you have for AMD and Arm?
>
> reason = dmar_get_fault_reason(fault_reason, &fault_type);
>
> + pdev = pci_get_domain_bus_and_slot(iommu->segment, bus, devfn);
Not an Intel iommu expert, but I have concerns about using
pci_get_domain_bus_and_slot() in this path.
AFAICT, dmar_fault_do_one() is running in a IRQ context & the pci_get_*
family of functions iterates the global PCI klist. It eventually calls
bus_to_subsys(), which takes a plain spin_lock(&bus_kset->list_lock) [1]
which isn't IRQ-safe. Same thing with klist_put [2] called in klist_iter_exit
> + if (pdev) {
> + snprintf(devid, sizeof(devid), "%04x:%02x:%02x.%d %04x:%04x",
> + iommu->segment, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> + pdev->vendor, pdev->device);
> + pci_dev_put(pdev);
Same here, pci_dev_put call put_device which might sleep [3] and hence
shouldn't be called in hard IRQ context.
> + } else {
> + snprintf(devid, sizeof(devid), "%04x:%02x:%02x.%d",
> + iommu->segment, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> + }
> +
> if (fault_type == INTR_REMAP) {
> - pr_err("[INTR-REMAP] Request device [%02x:%02x.%d] fault index 0x%llx [fault reason 0x%02x] %s\n",
> - source_id >> 8, PCI_SLOT(source_id & 0xFF),
> - PCI_FUNC(source_id & 0xFF), addr >> 48,
> - fault_reason, reason);
> + pr_err("[INTR-REMAP] Request device [%s] fault index 0x%llx [fault reason 0x%02x] %s\n",
> + devid, addr >> 48, fault_reason, reason);
>
> return 0;
> }
>
[-------------- >8 -------------------]
Thanks,
Praan
[1] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/bus.c#L60 <https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/bus.c#L60>
[2] https://elixir.bootlin.com/linux/v7.0.1/source/lib/klist.c#L209 <https://elixir.bootlin.com/linux/v7.0.1/source/lib/klist.c#L209>
[3] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/core.c#L3794 <https://elixir.bootlin.com/linux/v7.0.1/source/drivers/base/core.c#L3794>
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-22 15:42 UTC (permalink / raw)
To: Barry Song
Cc: Matthew Wilcox, akpm, bhe, chentao, chrisl, david, jack, kasong,
kunwu.chan, liam, lianux.mm, linux-arm-kernel, linux-kernel,
linux-mm, linux-riscv, linux-s390, linuxppc-dev, liyangouwen1,
loongarch, mhocko, nphamcs, nzzhao, pfalcato, rppt, shikemeng,
surenb, vbabka, wanglian, youngjun.park
In-Reply-To: <CAGsJ_4zrm3sCp8Uz0Gh+sAwRcdtNF8rDLqX250sFVG3rZy9HNw@mail.gmail.com>
On Fri, May 22, 2026 at 09:48:35PM +0800, Barry Song wrote:
> On Fri, May 22, 2026 at 9:36 PM Barry Song <baohua@kernel.org> wrote:
> >
> > On Fri, May 22, 2026 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Fri, May 22, 2026 at 10:33:05AM +0800, Barry Song (Xiaomi) wrote:
> > > > need to touch `filemap.c` at all (probably because you are already
> > > > maintaining `filemap.c` perfectly):
> > >
> > > I'm going to give you one chance to apologise for that.
> >
> > Apologies if my wording caused any misunderstanding.
> > That was not my intention at all.
> >
> > What I meant is that filemap.c already has a very
> > solid design.
> >
> > For memory.c, I had to touch several places for the
> > blacklist; otherwise, the kernel would hang.
> >
> > But for filemap.c, I basically didn't need to touch
> > anything, and preliminary testing shows no issues after
> > moving it from the whitelist to the blacklist. This is
>
> Sorry, I feel I may be causing some misunderstanding
> again.
>
> By "whitelist", I mean I used to allow certain cases
> to use per-vma retry.
>
> By "blacklist", I mean I am now moving to disallow
> certain cases from using per-vma retry.
>
> Right now, I have to add several cases in memory.c
> to the blacklist; otherwise, the kernel would hang.
>
> But it seems that everything in filemap.c is fine so
> far based on testing.
>
> I'm not sure if I've explained things clearly. Please
> let me know if anything is still unclear or insufficient.
Barry - this thread is completely out of hand and getting _rapidly_
unproductive.
It's certainly about as clear as mud where we stand right now, so here's my
suggestion - let's just stop adding to the noise here :) and instead, you
take the approach suggested by Suren at LSF and send that as an _RFC_
series.
That way we can look at that and hopefully actually circle in on a solution
rather than have endless sub threads and sub discussions :) It's far too
sunny out in the UK right now for that ;)
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
From: Geert Uytterhoeven @ 2026-05-22 15:34 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Nguyen Tran, Brian Masney, Conor Dooley,
Krzysztof Kozlowski, Kuninori Morimoto, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, Ulf Hansson,
Wolfram Sang, devicetree, linux-clk, linux-kernel, linux-mmc,
linux-renesas-soc
In-Reply-To: <20260504144534.43745-7-marek.vasut+renesas@mailbox.org>
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
>
> Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a variant of the
> R-Car M3-N (R8A77965) SoC. The Renesas M3Le SoC is a register-compatible
> variant of the R8A77965 (M3-N) with reduced set of peripherals.
>
> Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: - Drop DU until it can be tested
> - Reinstate sdhi3, switch SDHI to dedicated M3Le compatible strings
> - Add no-mmc DT property to SDHI3/MMC1, because MMC1 is not supported
> - Disable ohci1, ehci1, usb2_phy1
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v6 04/10] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/Kconfig | 11 +++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 131 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 10 +++
4 files changed, 153 insertions(+)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0e..a1922b48d0c2e 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,15 @@ config NVMEM_QORIQ_EFUSE
This driver can also be built as a module. If so, the module
will be called nvmem_qoriq_efuse.
+config NVMEM_RASPBERRYPI_OTP
+ tristate "Raspberry Pi OTP support"
+ depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+ help
+ This driver provides access to the Raspberry Pi OTP memory via the
+ nvmem subsystem. The driver supports the customer OTP as well as the
+ device specific private key OTP (BCM2712 only).
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-otp.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d46..8ca2095e068f3 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
nvmem-qoriq-efuse-y := qoriq-efuse.o
+obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP) += raspberrypi-otp.o
diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
new file mode 100644
index 0000000000000..2e2537ee6793b
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+ struct rpi_firmware *fw;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_header {
+ __le32 start;
+ __le32 count;
+ __le32 data[] __counted_by_le(count);
+};
+
+static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ u32 count;
+ int ret;
+
+ count = bytes / 4;
+
+ fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = cpu_to_le32(offset / 4);
+ fwbuf->count = cpu_to_le32(count);
+
+ ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+ if (ret)
+ goto out;
+
+ memcpy(buf, fwbuf->data, bytes);
+
+out:
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ u32 count;
+ int ret;
+
+ count = bytes / 4;
+
+ fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = cpu_to_le32(offset / 4);
+ fwbuf->count = cpu_to_le32(count);
+ memcpy(fwbuf->data, val, bytes);
+
+ ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_device *nvmem;
+ struct rpi_otp_priv *priv;
+ const struct rpi_otp_driver_data *data;
+ struct nvmem_config config = {
+ .read_only = false,
+ .word_size = 4,
+ .stride = 4,
+ .reg_read = rpi_otp_read,
+ .reg_write = rpi_otp_write,
+ .id = NVMEM_DEVID_NONE,
+ };
+
+ data = dev_get_platdata(dev);
+ if (!data)
+ return -ENODEV;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->fw = dev_get_drvdata(dev->parent);
+ priv->read_tag = data->read_tag;
+ priv->write_tag = data->write_tag;
+ config.dev = dev;
+ config.priv = priv;
+ config.name = data->name;
+ config.size = data->size;
+ config.root_only = data->root_only;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem))
+ return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
+
+ return 0;
+}
+
+static const struct platform_device_id raspberrypi_otp_id[] = {
+ { "raspberrypi-otp" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, raspberrypi_otp_id);
+
+static struct platform_driver raspberrypi_otp_driver = {
+ .probe = rpi_otp_probe,
+ .driver = {
+ .name = "raspberrypi-otp",
+ },
+ .id_table = raspberrypi_otp_id,
+};
+module_platform_driver(raspberrypi_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry Pi OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index eb33838e0cd10..1e5e5f7e378d0 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
+ RPI_FIRMWARE_GET_PRIVATE_OTP = 0x00030081,
+ RPI_FIRMWARE_SET_PRIVATE_OTP = 0x00038081,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
@@ -174,6 +176,14 @@ struct rpi_firmware_clk_rate_request {
.id = cpu_to_le32(_id), \
}
+struct rpi_otp_driver_data {
+ const char *name;
+ u32 read_tag;
+ u32 write_tag;
+ int size;
+ bool root_only;
+};
+
#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
--
2.47.3
^ permalink raw reply related
* [PATCH v6 07/10] dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The "select" in schema is not necessary anymore since dtschema drops
simple-mfd when constructing the select/filter query for schemas with
compatibles.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a3a5243b91706..7cf9a6fa1e5be 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -10,15 +10,6 @@ maintainers:
- Eric Anholt <eric@anholt.net>
- Stefan Wahren <wahrenst@gmx.net>
-select:
- properties:
- compatible:
- contains:
- const: raspberrypi,bcm2835-firmware
-
- required:
- - compatible
-
properties:
compatible:
oneOf:
--
2.47.3
^ permalink raw reply related
* [PATCH v6 09/10] ARM: bcm2835_defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards.
Enabling this in the bcm2835 defconfig allows standard upstream kernels
to use these registers out of the box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm/configs/bcm2835_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 4a8ac09843d73..fd83bda9cfaaf 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -151,6 +151,8 @@ CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_PWM=y
CONFIG_PWM_BCM2835=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
2.47.3
^ permalink raw reply related
* [PATCH v6 08/10] arm64: defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards and the private OTP registers present
on the Raspberry Pi 5.
Enabling this in the generic arm64 defconfig allows standard upstream
kernels to use these registers on Raspberry Pi 3, 4 and 5 out of the
box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e44e83bc57812..3abb3ca34c708 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1849,6 +1849,7 @@ CONFIG_NVMEM_SPMI_SDAM=m
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_UNIPHIER_EFUSE=y
CONFIG_NVMEM_ZYNQMP=m
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_FPGA=y
CONFIG_FPGA_MGR_ALTERA_CVP=m
CONFIG_FPGA_MGR_STRATIX10_SOC=m
--
2.47.3
^ permalink raw reply related
* [PATCH v6 10/10] ARM: multi_v7_defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards.
Enabling this in the multi_v7_defconfg allows standard upstream kernels
to use these registers out of the box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc12028..4b61ad5f46ce7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1281,6 +1281,7 @@ CONFIG_NVMEM_ROCKCHIP_EFUSE=m
CONFIG_NVMEM_STM32_ROMEM=m
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_VF610_OCOTP=y
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_FSI=m
CONFIG_FSI_MASTER_GPIO=m
CONFIG_FSI_MASTER_HUB=m
--
2.47.3
^ permalink raw reply related
* [PATCH v6 06/10] arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The Raspberry Pi 5 (BCM2712) firmware exposes additional features such
as the additional OTP register region called 'private OTP'.
Add the raspberrypi,bcm2712-firmware compatible to allow drivers to
distinguish this hardware variant while keeping
raspberrypi,bcm2835-firmware as a fallback for backward compatibility
with existing drivers.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1ab..4aa8ec7601b84 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -46,7 +46,9 @@ power_button: power-button {
firmware {
firmware: rpi-firmware {
- compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
+ compatible = "raspberrypi,bcm2712-firmware",
+ "raspberrypi,bcm2835-firmware",
+ "simple-mfd";
mboxes = <&mailbox>;
--
2.47.3
^ permalink raw reply related
* [PATCH v6 05/10] firmware: raspberrypi: register nvmem driver
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The Raspberry Pi firmware exposes two regions with otp registers. The
first region called "customer otp" is available on all Raspberry Pi
models. The second is only available on the Raspberry Pi 5 (bcm2712).
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/firmware/raspberrypi.c | 59 +++++++++++++++++++++++++++++-
include/soc/bcm2835/raspberrypi-firmware.h | 5 +++
2 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 0aa322e9a2e73..1d3b8c190b2fd 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -24,12 +24,15 @@
static struct platform_device *rpi_hwmon;
static struct platform_device *rpi_clk;
+static struct platform_device *rpi_otp_customer;
+static struct platform_device *rpi_otp_private;
struct rpi_firmware {
struct mbox_client cl;
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+ enum rpi_firmware_soc soc;
struct kref consumers;
};
@@ -231,6 +234,47 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
}
+static const struct rpi_otp_driver_data rpi_otp_customer_data = {
+ .name = "rpi-otp-customer",
+ .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+ .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+ .size = 32,
+ .root_only = false,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private_data = {
+ .name = "rpi-otp-private",
+ .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+ .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+ .size = 32,
+ .root_only = true,
+};
+
+static void rpi_register_otp_driver(struct device *dev)
+{
+ struct rpi_firmware *fw = dev_get_drvdata(dev);
+
+ rpi_otp_customer = platform_device_register_data(dev, "raspberrypi-otp",
+ PLATFORM_DEVID_AUTO,
+ &rpi_otp_customer_data,
+ sizeof(rpi_otp_customer_data));
+
+ if (IS_ERR(rpi_otp_customer))
+ dev_err(dev, "Failed to register customer OTP device: %pe\n",
+ rpi_otp_customer);
+
+ if (fw->soc == RPI_FIRMWARE_SOC_BCM2712) {
+ rpi_otp_private = platform_device_register_data(dev, "raspberrypi-otp",
+ PLATFORM_DEVID_AUTO,
+ &rpi_otp_private_data,
+ sizeof(rpi_otp_private_data));
+
+ if (IS_ERR(rpi_otp_private))
+ dev_err(dev, "Failed to register private OTP device: %pe\n",
+ rpi_otp_private);
+ }
+}
+
unsigned int rpi_firmware_clk_get_max_rate(struct rpi_firmware *fw, unsigned int id)
{
struct rpi_firmware_clk_rate_request msg =
@@ -299,12 +343,14 @@ static int rpi_firmware_probe(struct platform_device *pdev)
init_completion(&fw->c);
kref_init(&fw->consumers);
+ fw->soc = (uintptr_t)device_get_match_data(dev);
platform_set_drvdata(pdev, fw);
rpi_firmware_print_firmware_revision(fw);
rpi_register_hwmon_driver(dev, fw);
rpi_register_clk_driver(dev);
+ rpi_register_otp_driver(dev);
return 0;
}
@@ -327,12 +373,23 @@ static void rpi_firmware_remove(struct platform_device *pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
+ platform_device_unregister(rpi_otp_customer);
+ rpi_otp_customer = NULL;
+ platform_device_unregister(rpi_otp_private);
+ rpi_otp_private = NULL;
rpi_firmware_put(fw);
}
static const struct of_device_id rpi_firmware_of_match[] = {
- { .compatible = "raspberrypi,bcm2835-firmware", },
+ {
+ .compatible = "raspberrypi,bcm2835-firmware",
+ .data = (void *)RPI_FIRMWARE_SOC_BCM2835,
+ },
+ {
+ .compatible = "raspberrypi,bcm2712-firmware",
+ .data = (void *)RPI_FIRMWARE_SOC_BCM2712,
+ },
{},
};
MODULE_DEVICE_TABLE(of, rpi_firmware_of_match);
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 1e5e5f7e378d0..a4c94b85b7aa9 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -9,6 +9,11 @@
#include <linux/types.h>
#include <linux/of_device.h>
+enum rpi_firmware_soc {
+ RPI_FIRMWARE_SOC_BCM2835,
+ RPI_FIRMWARE_SOC_BCM2712,
+};
+
struct rpi_firmware;
enum rpi_firmware_property_status {
--
2.47.3
^ permalink raw reply related
* [PATCH v6 02/10] nvmem: core: Enforce stride and alignment checks for nvmem_device functions
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The stride and word_size attributes in the nvmem_config struct are
currently only used when reading/writing through sysfs functions
bin_attr_nvmem_read/bin_attr_nvmem_write and in the nvmem_cell api.
Reads and writes with nvmem_device_write/nvmem_device_read still allow
unaligned access.
Add a check to these functions to enforce word_size and stride_length
aligned reads and writes.
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 311cb2e5a5c02..6b313f63d07ef 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2068,6 +2068,12 @@ int nvmem_device_read(struct nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
+ if (!IS_ALIGNED(offset, nvmem->stride))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(bytes, nvmem->word_size))
+ return -EINVAL;
+
rc = nvmem_reg_read(nvmem, offset, buf, bytes);
if (rc)
@@ -2096,6 +2102,12 @@ int nvmem_device_write(struct nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
+ if (!IS_ALIGNED(offset, nvmem->stride))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(bytes, nvmem->word_size))
+ return -EINVAL;
+
rc = nvmem_reg_write(nvmem, offset, buf, bytes);
if (rc)
--
2.47.3
^ permalink raw reply related
* [PATCH v6 01/10] soc: bcm2835: Use IS_REACHABLE for function declaration
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The drivers that depend on the RASPBERRYPI_FIRMWARE use
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
This should ensure that the driver is not compiled in when
RASPBERRYPI_FIRMWARE is 'm' on COMPILE_TEST which leads to linker
errors.
The same can be achieved by using IS_REACHABLE in the
raspberrypi-firmware header. This evaluates to false when invoked from
built-in code. This way the Kconfig can be written as
depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
Which is a more readable variant.
Suggested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
include/soc/bcm2835/raspberrypi-firmware.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe5542..eb33838e0cd10 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -174,7 +174,7 @@ struct rpi_firmware_clk_rate_request {
.id = cpu_to_le32(_id), \
}
-#if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
+#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
int rpi_firmware_property_list(struct rpi_firmware *fw,
--
2.47.3
^ permalink raw reply related
* [PATCH v6 03/10] dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Add a compatible string for the bcm2712 firmware. The bcm2712-firmware
is compatible with the bcm2835-firmware so allow the bcm2835-firmware as
fallback.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec97..a3a5243b91706 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -21,9 +21,14 @@ select:
properties:
compatible:
- items:
- - const: raspberrypi,bcm2835-firmware
- - const: simple-mfd
+ oneOf:
+ - items:
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-mfd
+ - items:
+ - const: raspberrypi,bcm2712-firmware
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-mfd
mboxes:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v6 00/10] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger, Conor Dooley
Hi,
This series adds support for the Raspberry Pis OTP registers. The
Raspberry Pi has one or more OTP regions. These registers are accessible
through the firmware. Add a driver for it and add updates the devicetree
for the Raspberry Pi 5.
---
Changes in v6:
- Use %pe in dev_err
- Include <linux/slab.h> to fix build on arm
- Add arm defconfigs: multi_v7_defconfig and bcm2835_defconfig
- Reword commit messages
- Link to v5: https://patch.msgid.link/20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de
Changes in v5:
- Move alignment check to nvmem core
- Use IS_REACHABLE to simplify Kconfig
- use root_only for private driver
- Add driver as module to arch64 defconfig
- Use MODULE_DEVICE_TABLE
- Remove some unused attributes, fix typos, minor fixups
- Link to v4: https://patch.msgid.link/20260508-rpi-otp-driver-v4-0-cf8d725d8821@linutronix.de
Changes in v4:
- Additional patch to drop unnecessary select schema
- fix dt-bindings
- use __counted_by_le
- additional alignment check in read/write callbacks
- Link to v3: https://patch.msgid.link/20260506-rpi-otp-driver-v3-0-294602663695@linutronix.de
Changes in v3:
- dts: add "raspberrypi,bcm2835-firmware" as fallback and fix dt-bindings
- Fix Kconfig depends
- Changed firmware data fields to __le32
- Add MODULE_ALIAS
- Link to v2: https://patch.msgid.link/20260505-rpi-otp-driver-v2-0-e9176ec72837@linutronix.de
Changes in v2:
- register nvmem driver from firmware driver and drop firmware sub nodes
- Use struct_size and __counted_by for dynamic array
- Drop unneeded comment in Kconfig
- Use NVMEM_DEVID_NONE
- Use kzalloc
- Update module description
- Link to v1: https://patch.msgid.link/20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de
---
Gregor Herburger (10):
soc: bcm2835: Use IS_REACHABLE for function declaration
nvmem: core: Enforce stride and alignment checks for nvmem_device functions
dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
nvmem: Add the Raspberry Pi OTP driver
firmware: raspberrypi: register nvmem driver
arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
arm64: defconfig: Enable the raspberrypi otp driver as module
ARM: bcm2835_defconfig: Enable the raspberrypi otp driver as module
ARM: multi_v7_defconfig: Enable the raspberrypi otp driver as module
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++--
arch/arm/configs/bcm2835_defconfig | 2 +
arch/arm/configs/multi_v7_defconfig | 1 +
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +-
arch/arm64/configs/defconfig | 1 +
drivers/firmware/raspberrypi.c | 59 +++++++++-
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/core.c | 12 ++
drivers/nvmem/raspberrypi-otp.c | 131 +++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 17 ++-
11 files changed, 244 insertions(+), 15 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-rpi-otp-driver-75fce1dcff7d
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-22 15:39 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Barry Song, Matthew Wilcox, akpm, linux-mm, david, liam, vbabka,
rppt, mhocko, jack, pfalcato, wanglian, chentao, lianux.mm,
kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAJuCfpG2Zmpf5N_ejB6ZDv8LDjpVtTfA_tYQ6sW+Noc9Y+XhdA@mail.gmail.com>
On Wed, May 20, 2026 at 05:51:23AM +0000, Suren Baghdasaryan wrote:
> On Tue, May 19, 2026 at 12:53 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> >
> > > >
> > > > I think we either need to fix `fork()`, or keep the current
> > > > behavior of dropping the VMA lock before performing I/O.
> > >
> > > I see. So, this problem arises from the fact that we are changing the
> > > pagefaults requiring I/O operation to hold VMA lock...
> > > And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > > anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > > any VMA modification. On the surface, that looks ok to me but I might
> > > be missing some corner cases. If nobody sees any obvious issues, I
> > > think it's worth a try.
> >
> > Not sure if you noticed but I did raise concerns ;)
>
> Sorry, I didn't realize your first comment was a conceptual objection
> to this approach of allowing page faults to race with the fork.
Ah yeah it's understandable I think there's been so many threads in this
conversation that it's easy to get lost :)
>
>
> >
> > I wonder if you've confused the fault path and fork here, as I think Barry has
> > been a little unclear on that.
> >
> > What's being suggested in this thread is to fundamentally change fork behaviour
> > so it's different from the entire history of the kernel (or - presumably - at
> > least recent history :) and permit concurrent page faults to occur on a forking
> > process.
> >
> > I absolutely object to this for being pretty crazy. I mean I'm not sure we
> > really want to be simultaneously modifying page tables while invoking
> > copy_page_range()? No?
> >
> > OK you cover anon and MAP_PRIVATE file-backed but hang on there's
> > VM_COPY_ON_FORK too.. so PFN mapped, mixed map and (the accursed) UFFD W/P as
> > well as possibly-guard region containing VMAs now can have page tables raced.
>
> Ugh, yeah, I realize now this is a minefield. Resolving all possible
> races there would not be trivial and might introduce other performance
> issues.
Yeah, it's dangerous waters :)
>
> >
> > That's not to mention anything else that relies on serialisation here (this
> > would be changing how forking has been done in general) that we may or may not
> > know about.
> >
> > The risk level is high, for what amounts to a hack to work around the fault
> > issue.
> >
> > I suggest that if we have a problem with the fault path, let's look at the fault
> > path :)
> >
> > So yeah I'm very opposed to this unless I'm somehow horribly mistaken here or a
> > very convincing argument is made.
>
> So, current approach of dropping locks during I/O sounds like still
> the best solution.
Yeah _of those proposed_ I think importantly. This doesn't mean there aren't
other potential solutions.
Thanks, Lorenzo
>
> >
> >
> > >
> > >
> > >
> > >
> > > >
> > > > >
> > > > > I'd also like to get Suren's input, however.
> > > >
> > > > Yes. of course.
> > > >
> > > > >
> > > > > Thanks, Lorenzo
> > > >
> > > > Best Regards
> > > > Barry
> >
> > Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-22 15:37 UTC (permalink / raw)
To: Yang Shi
Cc: David Hildenbrand (Arm), Suren Baghdasaryan, Barry Song,
Matthew Wilcox, akpm, linux-mm, liam, vbabka, rppt, mhocko, jack,
pfalcato, wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1,
chrisl, kasong, shikemeng, nphamcs, bhe, youngjun.park,
linux-arm-kernel, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAHbLzkq3S7NDYe4LXjurKNQU+40-wtqrD_PT18YcyHbAcNxiRQ@mail.gmail.com>
On Wed, May 20, 2026 at 02:39:49PM -0700, Yang Shi wrote:
> On Wed, May 20, 2026 at 3:34 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
> >
> > On 5/19/26 14:53, Lorenzo Stoakes wrote:
> > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> > >
> > >>>
> > >>> I think we either need to fix `fork()`, or keep the current
> > >>> behavior of dropping the VMA lock before performing I/O.
> > >>
> > >> I see. So, this problem arises from the fact that we are changing the
> > >> pagefaults requiring I/O operation to hold VMA lock...
> > >> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> > >> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> > >> anonymous and COW VMAs only while holding mmap_write_lock, preventing
> > >> any VMA modification. On the surface, that looks ok to me but I might
> > >> be missing some corner cases. If nobody sees any obvious issues, I
> > >> think it's worth a try.
> > >
> > > Not sure if you noticed but I did raise concerns ;)
> > >
> > > I wonder if you've confused the fault path and fork here, as I think Barry has
> > > been a little unclear on that.
> > >
> > > What's being suggested in this thread is to fundamentally change fork behaviour
> > > so it's different from the entire history of the kernel (or - presumably - at
> > > least recent history :)
> > I don't want fork() to become different in that regard.
> >
> > There is already a slight difference with vs. without per-VMA locks, because
> > there is a window in-between us taking the write mmap_lock and all the per-VMA
> > locks. I raised that previously [1] and assumed that it is probably fine.
> >
> > I also raised in the past why I think we must not allow concurrent page faults,
> > at least as soon as anonymous memory is involved [2].
>
> Thanks for sharing the context, it is quite helpful to understand the
> race conditions. Because Lorenzo also raised the concern about page
> fault race, I will reply to all the concerns regarding page fault race
> together in this thread.
>
> IIUC, there is already some sort of race with per vma lock. Before per
> vma lock, mmap_lock did lock everything. So page fault happened either
> before fork or after fork. But page fault can happen on other VMAs
> which have not been lock'ed yet during fork with per vma lock. For
> example, we have 3 VMAs, we lock the first VMA, but page fault still
> can happen on the other 2 VMAs during fork if they already have
> anon_vma. This is the status quo now, but it seems not harmful.
>
> The bad race shared by David is caused by racing with copy page. So it
> seems like it will be fine as long as we serialize copy page against
> page fault if I don't miss anything. Since we decide whether to copy
> page or not by checking vma->anon_vma, so it seems fine to not take
> vma lock if vma->anon_vma is NULL. This will not introduce more race
> either because setting up a new anon_vma in page fault or madvise
> requires taking mmap_lock according to the earlier discussions.
NAK. No.
We're not doing this, we're not changing how fork fundamentally behaves because
of concerns about the fault path.
I've delineated exactly why I think this is a problem and you're pressing ahead
without addressing those concerns.
So at this point I'm going to be a grumpy maintainer and just say no, stop
please :)
Let's fix this in the right place. You don't fix a leak in the roof by repairing
a shelf next door :)
Thanks, Lorenzo
>
> Thanks,
> Yang
>
> >
> > ... and I raised that this is pretty much slower by design right now: "Well, the
> > design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
> > and to make blocking any page faults from happening to be slower ..." [3]
> >
> > [1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
> > [2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
> > [3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
> >
> > --
> > Cheers,
> >
> > David
> >
^ permalink raw reply
* Re: [PATCH v2 5/7] soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
From: Geert Uytterhoeven @ 2026-05-22 15:29 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Kuninori Morimoto, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, Ulf Hansson, Wolfram Sang, devicetree, linux-clk,
linux-kernel, linux-mmc, linux-renesas-soc
In-Reply-To: <20260504144534.43745-6-marek.vasut+renesas@mailbox.org>
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add support for identifying the R-Car M3Le (R8A779MD) SoC.
>
> The Renesas R-Car R8A779MD M3Le SoC is a variant of the
> already supported R-Car M3-N SoC with reduced peripherals.
> Enable support for the M3Le SoC through already existing
> ARCH_R8A77965 configuration symbol. PRR reads 0x67c05501 .
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks, will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 02/20] [DO NOT MERGE] s390: Expose protected virtualization through cc_platform_has()
From: JAEHOON KIM @ 2026-05-22 15:35 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Halil Pasic,
Matthew Rosato
In-Reply-To: <20260522042815.370873-3-aneesh.kumar@kernel.org>
On 5/21/2026 11:27 PM, Aneesh Kumar K.V (Arm) wrote:
> Protected virtualization guests use memory encryption, so advertise that to
> the rest of the kernel through cc_platform_has(CC_ATTR_MEM_ENCRYPT).
>
> s390 already forces DMA mappings to be unencrypted for protected
> virtualization guests through force_dma_unencrypted(). Add
> ARCH_HAS_CC_PLATFORM and provide the matching cc_platform_has()
> implementation
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> Cc: Halil Pasic <pasic@linux.ibm.com>
> Cc: Matthew Rosato <mjrosato@linux.ibm.com>
> Cc: Jaehoon Kim <jhkim@linux.ibm.com>
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/mm/init.c | 14 ++++++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index ecbcbb781e40..9b5e6029e043 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -87,6 +87,7 @@ config S390
> select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
> select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
> select ARCH_HAS_CC_CAN_LINK
> + select ARCH_HAS_CC_PLATFORM
> select ARCH_HAS_CPU_FINALIZE_INIT
> select ARCH_HAS_CURRENT_STACK_POINTER
> select ARCH_HAS_DEBUG_VIRTUAL
> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> index 1f72efc2a579..ad3c6d92b801 100644
> --- a/arch/s390/mm/init.c
> +++ b/arch/s390/mm/init.c
> @@ -50,6 +50,7 @@
> #include <linux/virtio_anchor.h>
> #include <linux/virtio_config.h>
> #include <linux/execmem.h>
> +#include <linux/cc_platform.h>
>
> pgd_t swapper_pg_dir[PTRS_PER_PGD] __section(".bss..swapper_pg_dir");
> pgd_t invalid_pg_dir[PTRS_PER_PGD] __section(".bss..invalid_pg_dir");
> @@ -140,6 +141,19 @@ bool force_dma_unencrypted(struct device *dev)
> return is_prot_virt_guest();
> }
>
> +
> +bool cc_platform_has(enum cc_attr attr)
> +{
> + switch (attr) {
> + case CC_ATTR_MEM_ENCRYPT:
> + return is_prot_virt_guest();
> +
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL_GPL(cc_platform_has);
> +
> /* protected virtualization */
> static void __init pv_init(void)
> {
Hello Aneesh,
Thanks for adding this s390 support patch.
The previous v4 series broke virtio initialization and caused boot
failures on s390. With this patch in v5, the issue is completely
resolved and virtio devices now initialize successfully and are
working well.
I'm going to do some more testing and will let you know if I run
into any issues.
Thanks,
Jaehoon.
^ permalink raw reply
* [PATCH v2] media: bcm2835-unicam: Fix log status runtime access
From: Eugen Hristev @ 2026-05-22 15:28 UTC (permalink / raw)
To: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Dave Stevenson, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Jean-Michel Hautbois
Cc: Naushir Patuck, linux-media, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, Eugen Hristev
When requesting log status, the block might be powered off, but registers
are being read.
Avoid reading the registers if the device is not resumed, thus also avoid
powering up the device just for log status.
Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
Signed-off-by: Eugen Hristev <ehristev@kernel.org>
---
Changes in v2:
- changed to use pm_runtime_get_if_active()
- add corresponding put()
- Link to v1: https://patch.msgid.link/20260521-bcmpipm-v1-1-3eba88d88045@kernel.org
To: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Florian Fainelli <florian.fainelli@broadcom.com>
To: Ray Jui <rjui@broadcom.com>
To: Scott Branden <sbranden@broadcom.com>
To: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@kernel.org>
To: Naushir Patuck <naush@raspberrypi.com>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: linux-media@vger.kernel.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/media/platform/broadcom/bcm2835-unicam.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
index 8d28ba0b59a3..93815b8ab930 100644
--- a/drivers/media/platform/broadcom/bcm2835-unicam.c
+++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
@@ -2052,6 +2052,13 @@ static int unicam_log_status(struct file *file, void *fh)
node->fmt.fmt.pix.width, node->fmt.fmt.pix.height);
dev_info(unicam->dev, "V4L2 format: %08x\n",
node->fmt.fmt.pix.pixelformat);
+
+ if (!pm_runtime_get_if_active(unicam->dev)) {
+ dev_info(unicam->dev,
+ "Live data N/A due to device inactive\n");
+ return 0;
+ }
+
reg = unicam_reg_read(unicam, UNICAM_IPIPE);
dev_info(unicam->dev, "Unpacking/packing: %u / %u\n",
unicam_get_field(reg, UNICAM_PUM_MASK),
@@ -2065,6 +2072,8 @@ static int unicam_log_status(struct file *file, void *fh)
dev_info(unicam->dev, "Write pointer: %08x\n",
unicam_reg_read(unicam, UNICAM_IBWP));
+ pm_runtime_put(unicam->dev);
+
return 0;
}
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260521-bcmpipm-6c578e73239c
Best regards,
--
Eugen Hristev <ehristev@kernel.org>
^ 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