* [PATCH v3 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-04-23 8:30 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
Cc: Krzysztof Kozlowski
In-Reply-To: <cover.1776932336.git.andrea.porta@suse.com>
From: Naushir Patuck <naush@raspberrypi.com>
Add the devicetree binding documentation for the PWM
controller found in the Raspberry Pi RP1 chipset.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
new file mode 100644
index 0000000000000..6f8461d0454f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/raspberrypi,rp1-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi RP1 PWM controller
+
+maintainers:
+ - Naushir Patuck <naush@raspberrypi.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+description: |
+ The PWM peripheral is a flexible waveform generator with a
+ variety of operational modes. It has the following features:
+ - four independent output channels
+ - 32-bit counter widths
+ - Seven output generation modes
+ - Optional per-channel output inversion
+ - Optional duty-cycle data FIFO with DMA support
+ - Optional sigma-delta noise shaping engine
+ Serves as a fan speed provider to other nodes for a PWM-connected
+ fan using shared registers (syscon).
+
+properties:
+ compatible:
+ const: raspberrypi,rp1-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@98000 {
+ compatible = "raspberrypi,rp1-pwm";
+ reg = <0x98000 0x100>;
+ clocks = <&rp1_clocks 17>;
+ #pwm-cells = <3>;
+ };
--
2.35.3
^ permalink raw reply related
* [PATCH v3 0/3] Add RP1 PWM controller support
From: Andrea della Porta @ 2026-04-23 8:30 UTC (permalink / raw)
To: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Andrea della Porta,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov, mbrugger
This patchset adds support for the PWM controller found on the
Raspberry Pi RP1 southbridge. This is necessary to operate the
cooling fan connected to one of the PWM channels.
The tachometer pin for the fan speed is managed by the firmware
running on the RP1's M-core. It uses the PHASE2 register
to report the RPM, which is then exported by this driver via
syscon registers. A subsequent patch will add a new device
and driver to read the RPM and export this value via hwmon.
Subsequent patches will also add the CPU thermal zone, which
acts as a consumer of the PWM device.
Best regards,
Andrea
CHANGES in V3:
- Refactored all the register macros. They now have RP1_PWM_ prefix
and follow the register name.
- Dropped the tab alignment in front of struct declarations (use a space
instead).
- Added a check in tohw() to test (and bail out quickly) in case that
period_length_ns is zero.
- Probing now returns an error if clk_rate > 1 GHz.
- Added a check on minimum period ticks. Return 1 to signal round-up.
- Fixed inverted polarity detection on edge cases.
- Fixed rounding errors (in both tohwi() and fromhw()) in inverted
polarity calculations.
- Dropped a redundant check on period >= duty.
- Replaced memset by inline struct init.
- Disabling a channel now is faster, skipping the duty/period/polarity
setup.
- Fixed an error string (s/Fail/Failed)
- Used %pe to signal error string instead of an integer.
- Added several new sections to the Limitations paragraph to better
explain what will happen on edge cases.
- Maximum period is now U32_MAX-1 to allow 100% duty cycle on all
selectable periods.
- The hw period register now takes into account for the extra tick at
the end of the period (subtracted one to wfhw->period_ticks in tohw
and added 1 in fromhw).
- Added .remove() callback to free resources even if the driver is
not unbindable/unloadable, to avoid accumulating tech debt.
Naushir Patuck (2):
dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
pwm: rp1: Add RP1 PWM controller driver
Stanimir Varbanov (1):
arm64: dts: broadcom: rpi-5: Add RP1 PWM node
.../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++
.../boot/dts/broadcom/bcm2712-rpi-5-b.dts | 12 +
arch/arm64/boot/dts/broadcom/rp1-common.dtsi | 10 +
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-rp1.c | 414 ++++++++++++++++++
6 files changed, 500 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
create mode 100644 drivers/pwm/pwm-rp1.c
--
2.35.3
^ permalink raw reply
* Re: [PATCH v17 0/5] ring-buffer: Making persistent ring buffers robust
From: Masami Hiramatsu @ 2026-04-23 8:26 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Steven Rostedt, Catalin Marinas, Will Deacon, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <177687458572.932171.10907864814735342737.stgit@mhiramat.tok.corp.google.com>
Hi,
Sashiko[1] pointed out other problems. Let me review it.
I also found one mistake (not by this series), so I will fix it too.
[1] https://sashiko.dev/#/patchset/177687458572.932171.10907864814735342737.stgit%40mhiramat.tok.corp.google.com
Thanks,
On Thu, 23 Apr 2026 01:16:26 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> Hi,
>
> Here is the 17th version of improvement patches for making persistent
> ring buffers robust to failures.
> The previous version is here:
>
> https://lore.kernel.org/all/177547105523.259641.14385891517704197263.stgit@mhiramat.tok.corp.google.com/
>
> This version fixes some review comments from Sashiko[1], which
> includes:
> [2/5] Fix to use rb_page_size() of rewound pages for entry_bytes.
> [3/5] - Fix to verify head_page at first before using its timestamp.
> - Reset timestamp if the page is invalid.
> [4/5] - In rb_test_inject_invalid_pages(), changed entry_bytes and
> idx to unsigned long
> - Added NULL checks for cpu_buffer and meta.
> - In allocate_trace_buffer(), added a NULL check for tr->name
> before comparing it with strcmp.
> [5/5] Added NULL check for dpage in rbm_show in ring_buffer.c.
>
> [1] https://sashiko.dev/#/patchset/177552432201.853249.5125045538812833325.stgit%40mhiramat.tok.corp.google.com
>
> Thank you,
>
> Masami Hiramatsu (Google) (5):
> ring-buffer: Flush and stop persistent ring buffer on panic
> ring-buffer: Skip invalid sub-buffers when validating persistent ring buffer
> ring-buffer: Skip invalid sub-buffers when rewinding persistent ring buffer
> ring-buffer: Add persistent ring buffer invalid-page inject test
> ring-buffer: Show commit numbers in buffer_meta file
>
>
> arch/alpha/include/asm/Kbuild | 1
> arch/arc/include/asm/Kbuild | 1
> arch/arm/include/asm/Kbuild | 1
> arch/arm64/include/asm/ring_buffer.h | 10 +
> arch/csky/include/asm/Kbuild | 1
> arch/hexagon/include/asm/Kbuild | 1
> arch/loongarch/include/asm/Kbuild | 1
> arch/m68k/include/asm/Kbuild | 1
> arch/microblaze/include/asm/Kbuild | 1
> arch/mips/include/asm/Kbuild | 1
> arch/nios2/include/asm/Kbuild | 1
> arch/openrisc/include/asm/Kbuild | 1
> arch/parisc/include/asm/Kbuild | 1
> arch/powerpc/include/asm/Kbuild | 1
> arch/riscv/include/asm/Kbuild | 1
> arch/s390/include/asm/Kbuild | 1
> arch/sh/include/asm/Kbuild | 1
> arch/sparc/include/asm/Kbuild | 1
> arch/um/include/asm/Kbuild | 1
> arch/x86/include/asm/Kbuild | 1
> arch/xtensa/include/asm/Kbuild | 1
> include/asm-generic/ring_buffer.h | 13 ++
> include/linux/ring_buffer.h | 1
> kernel/trace/Kconfig | 34 ++++
> kernel/trace/ring_buffer.c | 275 ++++++++++++++++++++++++++--------
> kernel/trace/trace.c | 4
> 26 files changed, 290 insertions(+), 67 deletions(-)
> create mode 100644 arch/arm64/include/asm/ring_buffer.h
> create mode 100644 include/asm-generic/ring_buffer.h
>
>
> base-commit: 6170922f137231b98fc568571befef63e1edff3f
> --
> Masami Hiramatsu (Google) <mhiramat@kernel.org>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
From: Sudeep Holla @ 2026-04-23 8:25 UTC (permalink / raw)
To: Peng Fan
Cc: Michael Turquette, Sudeep Holla, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <aelzO5W2HD8zAgxf@shlinux89>
On Thu, Apr 23, 2026 at 09:17:47AM +0800, Peng Fan wrote:
> On Wed, Apr 22, 2026 at 07:51:03PM +0100, Sudeep Holla wrote:
> >On Wed, Apr 22, 2026 at 10:00:23PM +0800, Peng Fan wrote:
> >> Hi Sudeep,
> >>
> >> Thanks for giving a look.
> >>
> >> On Wed, Apr 22, 2026 at 02:14:56PM +0100, Sudeep Holla wrote:
> >> >On Fri, Mar 06, 2026 at 02:20:13PM +0800, Peng Fan (OSS) wrote:
> >> >> From: Peng Fan <peng.fan@nxp.com>
> >> >>
> >> >> SCMI CLOCK_RATE_SET allows the caller to specify the rounding behaviour
> >> >> when setting a clock rate. The previously added dt-bindings header
> >> >> defines three modes:
> >> >>
> >> >> ROUND_DOWN / ROUND_UP / ROUND_AUTO
> >> >>
> >> >> To enable device tree clients to select a rounding mode, extend the
> >> >> SCMI clock provider to support "#clock-cells = <2>", where the second
> >> >> cell encodes the desired rounding mode. The default remains
> >> >> ROUND_DOWN for backwards compatibility with existing device trees.
> >> >>
> >> >
> >> >Where is the binding update documented ? It's not in 1/2.
> >>
> >> This was missed in this patchset, I will fix in new version, if this
> >> patchset does not have big design flaw.
> >>
> >> >
> >> >Also if it can be static in the device tree, why can't it be
> >> >autonomously handled in the platform firmware ? I think I know the
> >>
> >> Linux passes ROUND_DOWN, SCMI firmware uses round down for clk calculation.
> >>
> >> >answer for this but I want to make sure it is a valid use-case and
> >> >gets documented here as part of binding updates.
> >>
> >> Per info from our video software team.
> >> We have some video modes where the best pixel clock rate is slightly above the
> >> nominal rate, and the default round down rule (CLOCK_ROUND_RULE_CEILING in SM
> >> firmware) can cause the resulting clock rate to be much lower than expected.
> >>
> >> disp1pix = 96200000 Hz (desired pixel clock rate)
> >>
> >> The MIPI DPHY cannot hit the exact frequency of 288600000 Hz needed for this
> >> pixel clock rate, so the next best DPHY PLL frequency is 289000000 Hz. This
> >> corresponds to a pixel clock frequency of 96333333 Hz, which is slightly higher
> >> than the nominal rate of 96200000 Hz the video mode specifies.
> >>
> >> Setting the VIDEOPLL (disp1pix parent) to 289000000 Hz should divide down to
> >> the adjusted disp1pix frequency of 96333333 Hz, but here is what happens in the
> >> SM firmware:
> >>
> >> quotient = 289000000 / (96200000 + 1) = 3.004 => 3 (notice that the SM always
> >> receives the nominal clock rate, not the adjusted rate)
> >>
> >> If the rounding rule is round down (CLOCK_ROUND_RULE_CEILING),
> >> quotient = quotient + 1. Therefore, quotient becomes 4.
> >>
> >> disp1pix = 289000000 / 4 = 72250000, which is nowhere close to the target of
> >> 96333333.
> >>
> >
> >I do not think this is the correct interpretation of `CLOCK_ROUND_DOWN/UP`.
> >
> >`CLOCK_ROUND_DOWN/UP` should apply to the requested `disp1pix` rate itself,
> >not to the divider choice in a way that forces selection of the next integer
> >divisor and produces a much lower output clock.
> >
> >Here, the requested `disp1pix` is `96,200,000 Hz`, and the parent rate is
> >`289,000,000 Hz`. The achievable child rates nearby are:
> >
> >`289,000,000 / 3 = 96,333,333 Hz`
> >`289,000,000 / 4 = 72,250,000 Hz`
> >
> >Given those options, the firmware should be able to round the request
> >autonomously to the nearest supported `disp1pix` rate, which is `96,333,333
> >Hz` (`289,000,000 / 3`).
> >
> >Under that interpretation:
> >
> >`CLOCK_ROUND_UP` would permit choosing `96,333,333`
> >`CLOCK_ROUND_AUTO` would also likely choose `96,333,333`
> >Choosing `/4` and ending up at `72,250,000` does not look like a meaningful
> >rounding of `96,200,000`
> >
> >So the issue appears to be that the firmware is applying the rounding rule to
> >divider selection rather than to the resulting `disp1pix` frequency.
>
> User requests 96.2 MHz with ROUND_DOWN semantics, expecting the closest
> achievable frequency that does not meaningfully deviate from the request.
>
> Firmware evaluates the parent rate of 289,000,000 Hz and computes:
>
> 289,000,000 / 3 = 96,333,333 Hz
>
> Since this resulting frequency is slightly higher than the requested
> 96.2 MHz, the firmware, applying a strict `output <= requested` rule,
> rejects divider 3 and selects divider 4 instead, producing:
>
> 289,000,000 / 4 = 72,250,000 Hz
>
> This leads to an output frequency that is much farther from the requested
> value.
>
> My question is: if the firmware were to select divider 3 and produce
> 96,333,333 Hz (only ~0.13% higher than the request), would that be
> considered a violation of ROUND_DOWN semantics, or is ROUND_DOWN intended
> to select the closest achievable output frequency rather than enforcing
> a strict inequality against the requested rate?
>
We can change the driver to default to ROUND_AUTO if that helps. I fully
understand the default ROUND_DOWN is not good but if firmware can't handle
your use case with ROUND_AUTO, it is firmware issue.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: at91: remove unnecessary of_platform_default_populate calls
From: Alexander Dahl @ 2026-04-23 8:24 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Russell King,
linux-mtd, linux-arm-kernel, linux-kernel
In-Reply-To: <20260105-at91-probe-v3-3-594013ff2965@kernel.org>
Hello everyone,
I'm afraid this patch breaks finding rootfs on raw nand on sam9x60,
see below:
Am Mon, Jan 05, 2026 at 03:06:45PM -0600 schrieb Rob Herring (Arm):
> The DT core will call of_platform_default_populate, so it is not
> necessary for machine specific code to call it unless there are custom
> match entries, auxdata or parent device. Neither of those apply here, so
> remove the call.
>
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Not sure what was actually tested, but this change breaks booting from
raw NAND flash on our sam9x60 based board. I bisected the boot
failure to this exact change. Before the change I see the nand
controller messages in the kernel log like this:
atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
nand: device found, Manufacturer ID: 0x01, Chip ID: 0xda
nand: AMD/Spansion S34ML02G1
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
After the change, there are no kernel log messages related to nand at
all, the driver does not seem to load. This of course leads to no mtd
and ubi devices created, no ubi volumes found, no rootfs, and
eventually this message:
VFS: Cannot open root device "ubi0:rootfs2" or unknown-block(0,253): error -19
I tried to understand the whole patch series, and to my understanding
the intend was the device nodes still get populated, and the drivers
loaded, right? Patch 1/3 is related to the atmel nand controller, and
that one is not in the tree yet when bisecting to the end. However it
is present in v7.0-rc1 (and later) and trying to boot that kernel (or
7.0 or todays master) fails, too. (Also I don't see those probe defer
messages related to SRAM on v7.0-rc1, so I assume that's not the
problem?)
Now the strange thing is: on a different hardware based on sama5d2
v7.0-rc1 boots fine from raw nand flash. I wonder what's the
difference which makes it work on one atmel platform and not work on
the other?
I compared kernel .config of both boards, no obvious pieces missing.
Looking at the dts (and included dtsi) files of both boards I could
spot no mistake. Also no obvious flaws in sama5d2.dtsi or
sam9x60.dtsi.
Note: raw NAND flash is the only storage for rootfs on our platforms,
we can not simply put rootfs to a different storage. I could try
setting up NFS boot for further investigation, but that will take a
while.
Does anyone have an idea how to make booting from raw NAND flash work
on sam9x60 again (despite the obviously not desired revert)? What can
I try? What information would be interesting for debugging?
Greets
Alex
> ---
> v3:
> - Fixup split between patch 2 and 3.
>
> v2:
> - Dust off and rebase to 6.18-rc1
> - Add new platforms added since v1
> ---
> arch/arm/mach-at91/at91rm9200.c | 9 ---------
> arch/arm/mach-at91/at91sam9.c | 9 ---------
> arch/arm/mach-at91/sam9x60.c | 9 ---------
> arch/arm/mach-at91/sam9x7.c | 9 ---------
> arch/arm/mach-at91/sama5.c | 16 ----------------
> arch/arm/mach-at91/sama7.c | 9 ---------
> 6 files changed, 61 deletions(-)
>
> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
> index 2ac564eb8bbb..d15997fff5d7 100644
> --- a/arch/arm/mach-at91/at91rm9200.c
> +++ b/arch/arm/mach-at91/at91rm9200.c
> @@ -7,18 +7,10 @@
> * 2012 Joachim Eastwood <manabian@gmail.com>
> */
>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -
> #include <asm/mach/arch.h>
>
> #include "generic.h"
>
> -static void __init at91rm9200_dt_device_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char *const at91rm9200_dt_board_compat[] __initconst = {
> "atmel,at91rm9200",
> NULL
> @@ -26,6 +18,5 @@ static const char *const at91rm9200_dt_board_compat[] __initconst = {
>
> DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200")
> .init_late = at91rm9200_pm_init,
> - .init_machine = at91rm9200_dt_device_init,
> .dt_compat = at91rm9200_dt_board_compat,
> MACHINE_END
> diff --git a/arch/arm/mach-at91/at91sam9.c b/arch/arm/mach-at91/at91sam9.c
> index cf07cba4ee5d..b9d2909d1b65 100644
> --- a/arch/arm/mach-at91/at91sam9.c
> +++ b/arch/arm/mach-at91/at91sam9.c
> @@ -6,19 +6,11 @@
> * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
> */
>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -
> #include <asm/mach/arch.h>
> #include <asm/system_misc.h>
>
> #include "generic.h"
>
> -static void __init at91sam9_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char *const at91_dt_board_compat[] __initconst = {
> "atmel,at91sam9",
> NULL
> @@ -27,6 +19,5 @@ static const char *const at91_dt_board_compat[] __initconst = {
> DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM9")
> /* Maintainer: Atmel */
> .init_late = at91sam9_pm_init,
> - .init_machine = at91sam9_init,
> .dt_compat = at91_dt_board_compat,
> MACHINE_END
> diff --git a/arch/arm/mach-at91/sam9x60.c b/arch/arm/mach-at91/sam9x60.c
> index a31beaaeffcd..744bab2cbb92 100644
> --- a/arch/arm/mach-at91/sam9x60.c
> +++ b/arch/arm/mach-at91/sam9x60.c
> @@ -7,19 +7,11 @@
> * Author: Claudiu Beznea <claudiu.beznea@microchip.com>
> */
>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -
> #include <asm/mach/arch.h>
> #include <asm/system_misc.h>
>
> #include "generic.h"
>
> -static void __init sam9x60_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char *const sam9x60_dt_board_compat[] __initconst = {
> "microchip,sam9x60",
> NULL
> @@ -28,6 +20,5 @@ static const char *const sam9x60_dt_board_compat[] __initconst = {
> DT_MACHINE_START(sam9x60_dt, "Microchip SAM9X60")
> /* Maintainer: Microchip */
> .init_late = sam9x60_pm_init,
> - .init_machine = sam9x60_init,
> .dt_compat = sam9x60_dt_board_compat,
> MACHINE_END
> diff --git a/arch/arm/mach-at91/sam9x7.c b/arch/arm/mach-at91/sam9x7.c
> index 0c73f7fefd4f..166c8625509d 100644
> --- a/arch/arm/mach-at91/sam9x7.c
> +++ b/arch/arm/mach-at91/sam9x7.c
> @@ -7,18 +7,10 @@
> * Author: Varshini Rajendran <varshini.rajendran@microchip.com>
> */
>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -
> #include <asm/mach/arch.h>
>
> #include "generic.h"
>
> -static void __init sam9x7_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char * const sam9x7_dt_board_compat[] __initconst = {
> "microchip,sam9x7",
> NULL
> @@ -27,6 +19,5 @@ static const char * const sam9x7_dt_board_compat[] __initconst = {
> DT_MACHINE_START(sam9x7_dt, "Microchip SAM9X7")
> /* Maintainer: Microchip */
> .init_late = sam9x7_pm_init,
> - .init_machine = sam9x7_init,
> .dt_compat = sam9x7_dt_board_compat,
> MACHINE_END
> diff --git a/arch/arm/mach-at91/sama5.c b/arch/arm/mach-at91/sama5.c
> index 576654cba82d..e56022f00800 100644
> --- a/arch/arm/mach-at91/sama5.c
> +++ b/arch/arm/mach-at91/sama5.c
> @@ -6,9 +6,6 @@
> * 2013 Ludovic Desroches <ludovic.desroches@atmel.com>
> */
>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -
> #include <asm/hardware/cache-l2x0.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> @@ -30,11 +27,6 @@ static void __init sama5_secure_cache_init(void)
> outer_cache.write_sec = sama5_l2c310_write_sec;
> }
>
> -static void __init sama5_dt_device_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char *const sama5_dt_board_compat[] __initconst = {
> "atmel,sama5",
> NULL
> @@ -43,7 +35,6 @@ static const char *const sama5_dt_board_compat[] __initconst = {
> DT_MACHINE_START(sama5_dt, "Atmel SAMA5")
> /* Maintainer: Atmel */
> .init_late = sama5_pm_init,
> - .init_machine = sama5_dt_device_init,
> .dt_compat = sama5_dt_board_compat,
> MACHINE_END
>
> @@ -54,17 +45,11 @@ static const char *const sama5_alt_dt_board_compat[] __initconst = {
>
> DT_MACHINE_START(sama5_alt_dt, "Atmel SAMA5")
> /* Maintainer: Atmel */
> - .init_machine = sama5_dt_device_init,
> .init_late = sama5_pm_init,
> .dt_compat = sama5_alt_dt_board_compat,
> .l2c_aux_mask = ~0UL,
> MACHINE_END
>
> -static void __init sama5d2_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char *const sama5d2_compat[] __initconst = {
> "atmel,sama5d2",
> NULL
> @@ -72,7 +57,6 @@ static const char *const sama5d2_compat[] __initconst = {
>
> DT_MACHINE_START(sama5d2, "Atmel SAMA5")
> /* Maintainer: Atmel */
> - .init_machine = sama5d2_init,
> .init_early = sama5_secure_cache_init,
> .init_late = sama5d2_pm_init,
> .dt_compat = sama5d2_compat,
> diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
> index 8bf57a020f1c..f56828d61199 100644
> --- a/arch/arm/mach-at91/sama7.c
> +++ b/arch/arm/mach-at91/sama7.c
> @@ -6,19 +6,11 @@
> *
> */
>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -
> #include <asm/mach/arch.h>
> #include <asm/system_misc.h>
>
> #include "generic.h"
>
> -static void __init sama7_dt_device_init(void)
> -{
> - of_platform_default_populate(NULL, NULL, NULL);
> -}
> -
> static const char *const sama7_dt_board_compat[] __initconst = {
> "microchip,sama7",
> NULL
> @@ -27,7 +19,6 @@ static const char *const sama7_dt_board_compat[] __initconst = {
> DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
> /* Maintainer: Microchip */
> .init_late = sama7_pm_init,
> - .init_machine = sama7_dt_device_init,
> .dt_compat = sama7_dt_board_compat,
> MACHINE_END
>
>
> --
> 2.51.0
>
>
^ permalink raw reply
* [PATCH v2 7/7] media: synopsys: Add support for i.MX95
From: Guoniu Zhou @ 2026-04-23 8:23 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
Add support for the i.MX95 MIPI CSI-2 receiver. The i.MX95 variant is
nearly identical to i.MX93, with the main difference being the use of
IDI (Image Data Interface) instead of IPI (Image Pixel Interface).
However, the IDI interface is transparent to software, requiring only
a different register map definition while sharing the same PHY control
functions with i.MX93.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Add Reviewed-by tag from Frank Li <Frank.Li@nxp.com>
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 8c38fe8a3f06..62910d61eb64 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -154,6 +154,17 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
[DW_MIPI_CSI2RX_IPI_SOFTRSTN] = DW_REG(0xa0),
};
+static const u32 imx95_regs[DW_MIPI_CSI2RX_MAX] = {
+ [DW_MIPI_CSI2RX_N_LANES] = DW_REG(0x4),
+ [DW_MIPI_CSI2RX_RESETN] = DW_REG(0x8),
+ [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
+ [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
+ [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
+ [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
+ [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
+ [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
+};
+
static const struct v4l2_mbus_framefmt default_format = {
.width = 3840,
.height = 2160,
@@ -907,11 +918,22 @@ static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
.wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
};
+static const struct dw_mipi_csi2rx_drvdata imx95_drvdata = {
+ .regs = imx95_regs,
+ .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
+ .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
+ .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
+};
+
static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
{
.compatible = "fsl,imx93-mipi-csi2",
.data = &imx93_drvdata,
},
+ {
+ .compatible = "fsl,imx95-mipi-csi2",
+ .data = &imx95_drvdata,
+ },
{
.compatible = "rockchip,rk3568-mipi-csi2",
.data = &rk3568_drvdata,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/7] media: dt-bindings: add NXP i.MX95 compatible string
From: Guoniu Zhou @ 2026-04-23 8:23 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
main difference being the data output interface:
i.MX93 use IPI (Image Pixel Interface), which requires:
- Pixel clock input
- Software configuration through registers
i.MX95 uses IDI (Image Data Interface), which:
- Does not require pixel clock
- Is software transparent (no register configuration needed)
Due to these differences in register layout and initialization needs,
the two variants cannot share the same compatible string. The driver
needs to distinguish between them to handle the interface correctly.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Add dedicated constraint block for i.MX95 to reflect different clock
requirements (only per clock needed vs i.MX93 which needs both per
and pixel clocks)
- Update commit message to include more details about interface differences
---
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
index 4ac4a3b6f406..4e0bc75c2136 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- fsl,imx93-mipi-csi2
+ - fsl,imx95-mipi-csi2
- rockchip,rk3568-mipi-csi2
reg:
@@ -135,6 +136,21 @@ allOf:
clock-names:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx95-mipi-csi2
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names: false
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
examples:
- |
#include <dt-bindings/clock/rk3568-cru.h>
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/7] media: synopsys: Add PHY stopstate wait for i.MX93
From: Guoniu Zhou @ 2026-04-23 8:23 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
ensures proper PHY initialization by verifying that the clock lane and
all active data lanes have entered the stop state before proceeding with
further operations.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Removes redundant register availability check
- Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
readl_poll_timeout() with direct register address
- Fixes stopstate condition logic
- Check PHY stopstate after sensor enable instead of before to ensure
correct timing.
- Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
balance performance and responsiveness.
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 36 ++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 5a2e74d055c0..8c38fe8a3f06 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -11,6 +11,7 @@
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy/phy.h>
@@ -35,6 +36,8 @@
#define DW_REG_EXIST BIT(31)
#define DW_REG(x) (DW_REG_EXIST | (x))
+#define DPHY_STOPSTATE_CLK_LANE BIT(16)
+
#define DPHY_TEST_CTRL0_TEST_CLR BIT(0)
#define IPI_VCID_VC(x) FIELD_PREP(GENMASK(1, 0), (x))
@@ -65,6 +68,7 @@ enum dw_mipi_csi2rx_regs_index {
DW_MIPI_CSI2RX_PHY_TST_CTRL0,
DW_MIPI_CSI2RX_PHY_TST_CTRL1,
DW_MIPI_CSI2RX_PHY_SHUTDOWNZ,
+ DW_MIPI_CSI2RX_PHY_STOPSTATE,
DW_MIPI_CSI2RX_IPI_DATATYPE,
DW_MIPI_CSI2RX_IPI_MEM_FLUSH,
DW_MIPI_CSI2RX_IPI_MODE,
@@ -87,6 +91,7 @@ struct dw_mipi_csi2rx_drvdata {
void (*dphy_assert_reset)(struct dw_mipi_csi2rx_device *csi2);
void (*dphy_deassert_reset)(struct dw_mipi_csi2rx_device *csi2);
void (*ipi_enable)(struct dw_mipi_csi2rx_device *csi2);
+ int (*wait_for_phy_stopstate)(struct dw_mipi_csi2rx_device *csi2);
};
struct dw_mipi_csi2rx_format {
@@ -139,6 +144,7 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
[DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
[DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
[DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
+ [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
[DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
[DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
[DW_MIPI_CSI2RX_IPI_MODE] = DW_REG(0x80),
@@ -550,10 +556,19 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
if (ret)
goto err_csi_stop;
+ if (!csi2->enabled_streams &&
+ csi2->drvdata->wait_for_phy_stopstate) {
+ ret = csi2->drvdata->wait_for_phy_stopstate(csi2);
+ if (ret)
+ goto err_disable_streams;
+ }
+
csi2->enabled_streams |= streams_mask;
return 0;
+err_disable_streams:
+ v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
err_csi_stop:
/* Stop CSI hardware if no streams are enabled */
if (!csi2->enabled_streams)
@@ -864,11 +879,32 @@ static void imx93_csi2rx_dphy_ipi_enable(struct dw_mipi_csi2rx_device *csi2)
dw_mipi_csi2rx_write(csi2, DW_MIPI_CSI2RX_IPI_MODE, val);
}
+static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
+{
+ struct device *dev = csi2->dev;
+ u32 stopstate_mask;
+ u32 val;
+ int ret;
+
+ stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
+
+ ret = read_poll_timeout(dw_mipi_csi2rx_read, val,
+ (val & stopstate_mask) == stopstate_mask,
+ 10, 1000, true,
+ csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
+ if (ret)
+ dev_err(dev, "lanes are not in stop state: %#x, expected %#x\n",
+ val, stopstate_mask);
+
+ return ret;
+}
+
static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
.regs = imx93_regs,
.dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
.dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
.ipi_enable = imx93_csi2rx_dphy_ipi_enable,
+ .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
};
static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/7] media: synopsys: Add support for multiple streams
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
The current driver only supports single stream operation. Add support
for multiple concurrent streams by tracking enabled streams with a
bitmask and only initializing the hardware once for the first stream.
This enables use cases such as surround view systems where multiple
camera streams need to be processed simultaneously through the same
CSI-2 receiver interface.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Simplify error handling by keeping goto labels instead of early returns
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index d572d2eb3bcb..5a2e74d055c0 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -113,6 +113,7 @@ struct dw_mipi_csi2rx_device {
enum v4l2_mbus_type bus_type;
u32 lanes_num;
+ u64 enabled_streams;
const struct dw_mipi_csi2rx_drvdata *drvdata;
};
@@ -537,20 +538,26 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
if (ret)
goto err;
- ret = dw_mipi_csi2rx_start(csi2);
- if (ret) {
- dev_err(dev, "failed to enable CSI hardware\n");
- goto err_pm_runtime_put;
+ if (!csi2->enabled_streams) {
+ ret = dw_mipi_csi2rx_start(csi2);
+ if (ret) {
+ dev_err(dev, "failed to enable CSI hardware\n");
+ goto err_pm_runtime_put;
+ }
}
ret = v4l2_subdev_enable_streams(remote_sd, remote_pad->index, mask);
if (ret)
goto err_csi_stop;
+ csi2->enabled_streams |= streams_mask;
+
return 0;
err_csi_stop:
- dw_mipi_csi2rx_stop(csi2);
+ /* Stop CSI hardware if no streams are enabled */
+ if (!csi2->enabled_streams)
+ dw_mipi_csi2rx_stop(csi2);
err_pm_runtime_put:
pm_runtime_put(dev);
err:
@@ -577,11 +584,16 @@ static int dw_mipi_csi2rx_disable_streams(struct v4l2_subdev *sd,
&streams_mask);
ret = v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
+ if (ret)
+ dev_err(dev, "failed to disable streams on remote subdev: %d\n", ret);
- dw_mipi_csi2rx_stop(csi2);
+ csi2->enabled_streams &= ~streams_mask;
pm_runtime_put(dev);
+ if (!csi2->enabled_streams)
+ dw_mipi_csi2rx_stop(csi2);
+
return ret;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/7] media: synopsys: Add support for RAW16 Bayer formats
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
Add higher bit-depth raw image data support for the sensors, which supports
16-bit output.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Update commit message
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index b3f90da8b43c..d572d2eb3bcb 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -252,6 +252,26 @@ static const struct dw_mipi_csi2rx_format formats[] = {
.depth = 12,
.csi_dt = MIPI_CSI2_DT_RAW12,
},
+ {
+ .code = MEDIA_BUS_FMT_SBGGR16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SGBRG16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SGRBG16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SRGGB16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
};
static inline struct dw_mipi_csi2rx_device *to_csi2(struct v4l2_subdev *sd)
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] media: synopsys: Fix IPI using hardcoded datatype
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
The imx93_csi2rx_dphy_ipi_enable() function configures the IPI datatype
using csi2->formats->csi_dt, which is initialized during probe but never
updated in set_fmt(). This causes the IPI to always use the probe-time
default datatype, ignoring the actual media bus format negotiated at
runtime. When userspace requests a different format, the IPI hardware is
configured with the wrong datatype, resulting in incorrect image output.
Fix by updating csi2->formats in the set_fmt callback to reflect the
currently negotiated format, ensuring the IPI configuration matches the
runtime datatype.
Fixes: ec40b431f0ab ("media: synopsys: csi2rx: add i.MX93 support")
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- New added in v2
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 02eb4a6cafad..b3f90da8b43c 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -470,6 +470,11 @@ static int dw_mipi_csi2rx_set_fmt(struct v4l2_subdev *sd,
*src = *sink;
+ /* Store the CSIS format descriptor for active formats. */
+ if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+ csi2->formats = fmt ? :
+ dw_mipi_csi2rx_find_format(csi2, default_format.code);
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/7] media: synopsys: Fix out-of-bounds check in enum_mbus_code
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
dw_mipi_csi2rx_enum_mbus_code() contains an off-by-one error in the
bounds check for code->index, allowing an access past the end of the
formats array.
Fixes: 355a11004066 ("media: synopsys: add driver for the designware mipi csi-2 receiver")
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- New added in v2
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index ce17f986279e..02eb4a6cafad 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -430,7 +430,7 @@ dw_mipi_csi2rx_enum_mbus_code(struct v4l2_subdev *sd,
return 0;
case DW_MIPI_CSI2RX_PAD_SINK:
- if (code->index > csi2->formats_num)
+ if (code->index >= csi2->formats_num)
return -EINVAL;
code->code = csi2->formats[code->index].code;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/7] media: synopsys: enhancements and i.MX95 support
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
This series enhances the Synopsys DesignWare MIPI CSI-2 receiver driver
with multiple stream support and adds i.MX95 platform support.
The i.MX95 variant is similar to i.MX93 but uses IDI instead of IPI. Since
IDI is software transparent, only a different register map is needed.
Tested on i.MX93 and i.MX95 platforms.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Add two new patches
- Simplify error handling by keeping goto labels instead of early returns
- Removes redundant register availability check
- Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
readl_poll_timeout() with direct register address
- Fixes stopstate condition logic
- Check PHY stopstate after sensor enable instead of before to ensure
correct timing.
- Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
balance performance and responsiveness.
- Add dedicated constraint block for i.MX95 to reflect different clock
requirements (only per clock needed vs i.MX93 which needs both per and
pixel clocks)
- Update commit message to include more details about interface differences
- Add Reviewed-by tag from Frank Li <Frank.Li@nxp.com>
- Update commit message
- See each patch's changelog for details.
- Link to v1: https://lore.kernel.org/r/20260415-csi2_imx95-v1-0-7d63f3508719@oss.nxp.com
---
Guoniu Zhou (7):
media: synopsys: Fix out-of-bounds check in enum_mbus_code
media: synopsys: Fix IPI using hardcoded datatype
media: synopsys: Add support for RAW16 Bayer formats
media: synopsys: Add support for multiple streams
media: synopsys: Add PHY stopstate wait for i.MX93
media: dt-bindings: add NXP i.MX95 compatible string
media: synopsys: Add support for i.MX95
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 16 +++
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 109 +++++++++++++++++++--
2 files changed, 118 insertions(+), 7 deletions(-)
---
base-commit: 4fbeef21f5387234111b5d52924e77757626faa5
change-id: 20260414-csi2_imx95-65ad0e7f630a
Best regards,
--
Guoniu Zhou <guoniu.zhou@oss.nxp.com>
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix BQL imbalance in TX path
From: Lorenzo Bianconi @ 2026-04-23 8:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Hariprasad Kelam
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4017 bytes --]
> Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight
> packets are accounted only for the AIROHA_NUM_TX_RING netdev TX
> queues. The queue index is computed as:
>
> qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx)
> txq = netdev_get_tx_queue(dev, qid);
>
> However, airoha_qdma_tx_napi_poll() accounts completions across all
> netdev TX queues (num_tx_queues), leading to inconsistent BQL
> accounting.
>
> Also reset all netdev TX queues in the ndo_stop callback.
>
> Fixes: 1d304174106c ("net: airoha: Implement BQL support")
> Fixes: c9f947769b77 ("net: airoha: Reset BQL stopping the netdevice")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..6c7390f0de5d 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -929,10 +929,9 @@ static int airoha_qdma_tx_napi_poll(struct napi_struct *napi, int budget)
> q->queued--;
>
> if (skb) {
> - u16 queue = skb_get_queue_mapping(skb);
> struct netdev_queue *txq;
>
> - txq = netdev_get_tx_queue(skb->dev, queue);
> + txq = skb_get_tx_queue(skb->dev, skb);
> netdev_tx_completed_queue(txq, 1, skb->len);
> dev_kfree_skb_any(skb);
> }
> @@ -1711,7 +1710,7 @@ static int airoha_dev_stop(struct net_device *dev)
> if (err)
> return err;
>
> - for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> + for (i = 0; i < dev->num_tx_queues; i++)
> netdev_tx_reset_subqueue(dev, i);
>
> airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> @@ -2002,7 +2001,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>
> spin_lock_bh(&q->lock);
>
> - txq = netdev_get_tx_queue(dev, qid);
> + txq = skb_get_tx_queue(dev, skb);
> nr_frags = 1 + skb_shinfo(skb)->nr_frags;
>
> if (q->queued + nr_frags >= q->ndesc) {
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-fix-bql-7fff7cebbc9a
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko reported issues:
https://sashiko.dev/#/patchset/20260421-airoha-fix-bql-v1-1-f135afe4275b%40kernel.org
- This isn't a bug in this patch, but does using 0xff as a sentinel value cause a permanent stall?
I do not think this is a real issue since, according to my understanding, the NIC
never writes 0xff in irq_q queue.
- This is another pre-existing issue, but does freeing the SKB here cause a DMA use-after-free
for multi-fragment packets?
This issue is not related to this patch, and I will fix it in a dedicated
patch storing the skb pointer in the last descriptor in airoha_dev_xmit()
- Since the QDMA hardware and NAPI instance are shared among multiple ports (qdma->users),
could active NAPI polling cause a BUG_ON() in dql_completed()?
This is not an issue related to this patch since here we are just resetting
all the netdev tx queues instead of just the first ARRAY_SIZE(qdma->q_tx)
ones.
- This isn't a bug in this patch, but does failing to wait for the DMA engines to become
idle before unmapping buffers cause memory corruption?
This issue is not related to this patch and it will be fixed with a dedicated
patch.
- This is also pre-existing, but can this mapping cause a kernel panic on highmem systems?
Can we have fragments in high memory? e.g on ARM architecture? Anyway, as
pointed out by Sashiko, this issue is not related to this patch.
- This isn't introduced here, but does this logic cause a permanent TX stall?
this issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] crypto: ixp4xx: Fix null-pointer dereference in chainup_buffers()
From: Herbert Xu @ 2026-04-23 8:11 UTC (permalink / raw)
To: Ruoyu Wang
Cc: clabbe, linusw, kaloz, davem, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260421093917.1001688-1-ruoyuw560@gmail.com>
On Tue, Apr 21, 2026 at 05:39:17PM +0800, Ruoyu Wang wrote:
> chainup_buffers() builds a linked list of buffer descriptors for a
> scatterlist. If dma_pool_alloc() fails while constructing the list, the
> current code sets buf to NULL and later dereferences it unconditionally
> at the end of the function:
>
> buf->next = NULL;
> buf->phys_next = 0;
>
> This can lead to a null-pointer dereference on allocation failure.
>
> If the failure happens after part of the descriptor chain has already
> been allocated and DMA-mapped, the partially constructed chain also
> needs to be released.
>
> Fix this by unwinding the partially constructed chain, resetting the
> caller-provided hook descriptor, and returning NULL on allocation
> failure.
>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 24 +++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> index fcc0cf4df637..63ef28cd5766 100644
> --- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> +++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> @@ -874,6 +874,11 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> struct buffer_desc *buf, gfp_t flags,
> enum dma_data_direction dir)
> {
> + struct buffer_desc *first = buf;
> +
> + first->next = NULL;
> + first->phys_next = 0;
> +
> for (; nbytes > 0; sg = sg_next(sg)) {
> unsigned int len = min(nbytes, sg->length);
> struct buffer_desc *next_buf;
> @@ -883,10 +888,15 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> nbytes -= len;
> ptr = sg_virt(sg);
> next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
> - if (!next_buf) {
> - buf = NULL;
> - break;
> - }
> + if (!next_buf)
> + goto err_unwind;
> +
> + /*
> + * Keep the chain well-formed even on partial construction,
> + * so free_buf_chain() can safely unwind it on failure.
> + */
> + next_buf->next = NULL;
> + next_buf->phys_next = 0;
> sg_dma_address(sg) = dma_map_single(dev, ptr, len, dir);
> buf->next = next_buf;
> buf->phys_next = next_buf_phys;
> @@ -899,6 +909,12 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> buf->next = NULL;
> buf->phys_next = 0;
> return buf;
> +
> +err_unwind:
> + free_buf_chain(dev, first->next, first->phys_next);
> + first->next = NULL;
> + first->phys_next = 0;
> + return NULL;
All callers of chainup_buffers try to unwind by calling free_buf_chain
too, although a couple of them might do so incorrectly.
It looks like the callers need the unwind path anyway, so perhaps
just fix up the callers so that their unwind paths actually work?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Marc Zyngier @ 2026-04-23 8:08 UTC (permalink / raw)
To: Sebastian Ene
Cc: oupton, will, ayrton, catalin.marinas, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui, stable
In-Reply-To: <aejOu98q1lEZoFfW@google.com>
On Wed, 22 Apr 2026 14:35:55 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote:
> > On Wed, 22 Apr 2026 11:25:40 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header and enforce a strict placement for it
> > > when validating an FF-A memory lend/share transaction.
>
> Hello Marc,
>
> >
> > As I read this, you want to remove a bad assumption...
> >
> > >
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this:
> > >
> > > Field name | Offset
> > > -- 0
> > > [ Header (ffa_mem_region) |__ ep_mem_offset
> > > EMAD 1 (ffa_mem_region_attributes) |
> > > ]
> > >
> > > Reject the host from specifying a memory access descriptor offset
> > > that is different than the size of the memory region header.
> >
> > And yet you decide that you want to enforce this assumption. I don't
> > understand how you arrive to this conclusion.
> >
> > Looking at the spec, it appears that the offset is *designed* to allow
> > a gap between the header and the EMAD. Refusing to handle a it seems to be a
> > violation of the spec.
> >
> > What am I missing?
>
> While the spec allows the gap to be variable (since version 1.1), the
> arm ff-a driver places it at a fixed position in:
> ffa_mem_region_additional_setup()
> https://elixir.bootlin.com/linux/v7.0/source/drivers/firmware/arm_ffa/driver.c#L671
That's an implementation detail, and you shouldn't rely on this.
> and makes use of the same assumption in: ffa_mem_desc_offset().
> https://elixir.bootlin.com/linux/v7.0/source/include/linux/arm_ffa.h#L448
> The later one seems wrong IMO. because we should compute the offset
> based on the value stored in ep_mem_offset and not adding it up with
> sizeof(struct ffa_mem_region).
>
> Maybe this should be the fix instead and not the one in pKVM ? What do
> you think ?
I think you should parse the buffers as the spec intends them, without
assumptions or limitations.
>
> The current implementation in pKVM makes use of the
> ffa_mem_desc_offset() to validate the first EMAD. If a compromised host
> places an EMAD at a different offset than sizeof(struct ffa_mem_region),
> then pKVM will not validate that EMAD.
Why compromised? Isn't that a perfectly valid thing to do? What I
understand is that the FFA 1.1 implementation in pKVM doesn't match
the expectations of the spec. If that's indeed the case, pKVM should
be fixed to accept these messages correctly, or stop using FFA 1.1.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check
From: Marc Zyngier @ 2026-04-23 8:04 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, smostafa, kees, catalin.marinas, Jinjie Ruan,
linux-kernel, mrigendra.chaubey, leitao, will, linux-arm-kernel
In-Reply-To: <ae6f2b57-4644-424e-aab7-84042dca23e6@arm.com>
On Thu, 23 Apr 2026 06:29:09 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
>
> On 20/03/26 1:58 PM, Jinjie Ruan wrote:
> > Add DEFINE_COND_CHECK macro to define the simple __check_* functions
> > to simplify the condition codes check.
> >
> > No functional changes.
> >
> > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> > ---
> > arch/arm64/kernel/traps.c | 59 ++++++++++-----------------------------
> > 1 file changed, 15 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index 914282016069..6216fe9e8e42 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -49,45 +49,21 @@
> > #include <asm/system_misc.h>
> > #include <asm/sysreg.h>
> >
> > -static bool __kprobes __check_eq(unsigned long pstate)
> > -{
> > - return (pstate & PSR_Z_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_ne(unsigned long pstate)
> > -{
> > - return (pstate & PSR_Z_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_cs(unsigned long pstate)
> > -{
> > - return (pstate & PSR_C_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_cc(unsigned long pstate)
> > -{
> > - return (pstate & PSR_C_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_mi(unsigned long pstate)
> > -{
> > - return (pstate & PSR_N_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_pl(unsigned long pstate)
> > -{
> > - return (pstate & PSR_N_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_vs(unsigned long pstate)
> > -{
> > - return (pstate & PSR_V_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_vc(unsigned long pstate)
> > -{
> > - return (pstate & PSR_V_BIT) == 0;
> > -}
> > +#define DEFINE_COND_CHECK(name, flag, expected) \
> > +static bool __kprobes __check_##name(unsigned long pstate) \
> > +{ \
> > + return ((pstate & (flag)) != 0) == (expected); \
> > +}
> > +
> > +DEFINE_COND_CHECK(eq, PSR_Z_BIT, true)
> > +DEFINE_COND_CHECK(ne, PSR_Z_BIT, false)
> > +DEFINE_COND_CHECK(cs, PSR_C_BIT, true)
> > +DEFINE_COND_CHECK(cc, PSR_C_BIT, false)
> > +DEFINE_COND_CHECK(mi, PSR_N_BIT, true)
> > +DEFINE_COND_CHECK(pl, PSR_N_BIT, false)
> > +DEFINE_COND_CHECK(vs, PSR_V_BIT, true)
> > +DEFINE_COND_CHECK(vc, PSR_V_BIT, false)
> > +DEFINE_COND_CHECK(al, 0, false) /* Always true */
>
> (((pstate & 0 == 0) != 0) == false) ---> return true
>
> Although this looks OK but wondering if __check_al() should
> be left unchanged for simplicity. OR could all its call sites
> be changed assuming an unconditional 'true' return thus later
> __check_al() can be dropped.
Which call site? We emulate an instruction, and we're not in control
of the condition code associated with it. The condition code directly
indexes into aarch32_opcode_cond_checks[].
Anyway, this is a moot point, as we have consensus to not touch that
code at all.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 0/2] gpio: drop bitmap_complement() where feasible
From: Bartosz Golaszewski @ 2026-04-23 7:58 UTC (permalink / raw)
To: Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Yury Norov,
linux-gpio, linux-kernel, linux-arm-kernel, Yury Norov
Cc: Bartosz Golaszewski
In-Reply-To: <20260417175955.375275-1-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:59:52 -0400, Yury Norov wrote:
> The gpio drivers reproduce the following pattern:
>
> bitmap_complement(tmp, data1, nbits);
> bitmap_and(dst, data2, tmp, nbits);
>
> This can be done in a single pass:
>
> [...]
Tweaked the grammar in commit messages and applied, thanks!
[1/2] gpio: pca953x: drop bitmap_complement() where feasible
https://git.kernel.org/brgl/c/a56604e397575647bfc425a8df176948577a364e
[2/2] gpio: xilinx: drop bitmap_complement() where feasible
https://git.kernel.org/brgl/c/2757a5b1bca76a1b6378496b669a2baf1faddec5
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 06/11] iommu: Defer __iommu_group_free_device() to be outside group->mutex
From: Baolu Lu @ 2026-04-23 7:55 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Robin Murphy, Joerg Roedel,
Bjorn Helgaas, Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <3f5d229267d1f4d918641bc5b896f54b5c4b7782.1776381841.git.nicolinc@nvidia.com>
On 4/17/26 07:28, Nicolin Chen wrote:
> __iommu_group_remove_device() holds group->mutex across the entire call to
> __iommu_group_free_device() that performs sysfs removals, tracing, and the
> final kfree_rcu(). But in fact, most of these operations don't really need
> the group->mutex.
>
> The group_device structure will support a work_struct to quarantine broken
> devices asynchronously. The work function must hold group->mutex to safely
> update group state. cancel_work_sync() must be called, to cancel that work
> before freeing the device. But doing so under group->mutex would deadlock
> if the worker is already running and waiting to acquire the same lock.
>
> Separate the assertion from __iommu_group_free_device() to another helper
> __iommu_group_empty_assert_owner_cnt().
>
> Defer the __iommu_group_free_device() until the mutex is released.
>
> This is a preparatory refactor with no functional change.
>
> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
> ---
> drivers/iommu/iommu.c | 35 +++++++++++++++++++++++------------
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d1be62a07904a..810e7b94a1ae2 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -627,6 +627,19 @@ static struct iommu_domain *pasid_array_entry_to_domain(void *entry)
>
> DEFINE_MUTEX(iommu_probe_device_lock);
>
> +static void __iommu_group_empty_assert_owner_cnt(struct iommu_group *group)
> +{
> + lockdep_assert_held(&group->mutex);
> + /*
> + * If the group has become empty then ownership must have been
> + * released, and the current domain must be set back to NULL or
> + * the default domain.
> + */
Nit: this comment doesn't quite match the following code. The code
doesn't check "group->domain != NULL". Or perhaps in that case,
group->default_domain must be NULL?
Furthermore, if a device is currently quarantined, group->domain will be
the blocking_domain. If that quarantined device is then hot-removed and
happens to be the last device in the group, will this WARN_ON trigger
unnecessarily?
> + if (list_empty(&group->devices))
> + WARN_ON(group->owner_cnt ||
> + group->domain != group->default_domain);
> +}
> +
> static int __iommu_probe_device(struct device *dev, struct list_head *group_list)
> {
> struct iommu_group *group;
Thanks,
baolu
^ permalink raw reply
* Re: [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic
From: Ard Biesheuvel @ 2026-04-23 7:56 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-4-l.rubusch@gmail.com>
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The non-blocking path was (also) failing to provide valid entropy
> due to improper buffer management and a lack of hardware execution
> time.
>
> Ensure cmd.msecs (30ms) and cmd.rxsize (35ms) are initialized before
> enqueuing the background work. Fix the data offset to skip the
> 1-byte hardware count header when copying bits to the caller. Correctly
> return 0 (busy) to the hwrng core while hardware execution is in
> progress, preventing zero-filled buffers, which was the situation
> before.
>
> With this fix applied, tests will look similar to this:
> $ socat -u OPEN:/dev/hwrng,nonblock - | head -c 32 | hexdump -C
> 00000000 23 cc 42 3c 90 b1 38 fc 54 37 35 4b 09 c5 e1 0d
> |#.B<..8.T75K....|
> 2026/03/23 14:30:18 socat[858] E read(5, 0x55be363000, 8192): Resource
> temporarily unavailable
> 00000010 73 3b af d9 02 70 76 bd 2d 59 4b 12 01 ac ae 2b
> |s;...pv.-YK....+|
> 00000020
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index f7dc00d0f4cd..04cbf80c1411 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -33,7 +33,6 @@ static void atmel_sha204a_rng_done(struct
> atmel_i2c_work_data *work_data,
> "i2c transaction failed (%d)\n",
> status);
> kfree(work_data);
> - rng->priv = 0;
> atomic_dec(&i2c_priv->tfm_count);
> return;
> }
> @@ -49,20 +48,19 @@ static int
> atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
>
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> - /* Verify if data available from last run */
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> - max = min(sizeof(work_data->cmd.data), max);
> - memcpy(data, &work_data->cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &work_data->cmd.data[1], max);
>
Please combine this with the buffer size fix in the previous patch.
> - /* Now, free memory */
> + /* Free memory and clear the in-flight flag */
> kfree(work_data);
> rng->priv = 0;
> atomic_dec(&i2c_priv->tfm_count);
> return max;
> }
>
> - /* When a request is still in-flight but not processed */
> + /* If a request is still in-flight, return 0 (busy) */
> if (atomic_read(&i2c_priv->tfm_count) > 0)
> return 0;
>
> @@ -76,8 +74,14 @@ static int atmel_sha204a_rng_read_nonblocking(struct
> hwrng *rng, void *data,
> work_data->client = i2c_priv->client;
>
> atmel_i2c_init_random_cmd(&work_data->cmd);
> +
> + /* Set the execution time for the RNG command (from datasheet) */
> + work_data->cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + work_data->cmd.rxsize = RANDOM_RSP_SIZE;
> +
Again, this is either redundant or wrong.
> atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
>
> + /* Return 0 to indicate 'busy', data will be ready on next call */
> return 0;
> }
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Ard Biesheuvel @ 2026-04-23 7:55 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-3-l.rubusch@gmail.com>
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> implementation was incorrectly copying data starting from the
> count byte, leading to offset data and truncated entropy.
>
> Additionally, the chip requires significant execution time to
> generate random numbers, going by the datasheet. Reading the I2C bus
> too early results in the chip NACK-ing or returning a partial buffer
> followed by zeros.
>
> Verification:
> Tests before showed repeadetly reading only 8 bytes of entropy:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After this patch applied, the result will be as follows:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fix these issues by:
> Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> hardware response. Eventually, correct the memcpy() offset to index 1 of
> the data buffer to skip the count byte and retrieve exactly 32 bytes of
> entropy.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 19720bdd446d..f7dc00d0f4cd 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -19,6 +19,9 @@
> #include <linux/workqueue.h>
> #include "atmel-i2c.h"
>
> +#define ATMEL_RNG_BLOCK_SIZE 32
> +#define ATMEL_RNG_EXEC_TIME 30
> +
> static void atmel_sha204a_rng_done(struct atmel_i2c_work_data
> *work_data,
> void *areq, int status)
> {
> @@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng
> *rng, void *data, size_t max,
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> atmel_i2c_init_random_cmd(&cmd);
> + cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + cmd.rxsize = RANDOM_RSP_SIZE;
>
Please fix atmel_i2c_init_random_cmd() instead if it doesn't set the right
values for these fields. But afaict, you are decreasing the execution time
here, so I struggle to see how this could explain the improved behavior.
> ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
>
This looks correct - better to put this in a separate patch.
> return max;
> }
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-23 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]
> Do not wake every netdev TX queue across all ports sharing the QDMA
> running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
> but only the ones that are mapped the specific QDMA stopped hw TX queue.
> This patch can potentially avoid waking already stopped netdev TX queues
> that are mapped to a different QDMA hw TX queue.
> Introduce airoha_qdma_get_txq utility routine.
>
> Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 19 +++++++++++++++----
> drivers/net/ethernet/airoha/airoha_eth.h | 5 +++++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..2ca569501045 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -847,13 +847,24 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
> {
> struct airoha_qdma *qdma = q->qdma;
> struct airoha_eth *eth = qdma->eth;
> - int i;
> + int i, qid = q - &qdma->q_tx[0];
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
>
> - if (port && port->qdma == qdma)
> - netif_tx_wake_all_queues(port->dev);
> + if (port->qdma != qdma)
> + continue;
> +
> + for (j = 0; j < port->dev->num_tx_queues; j++) {
> + if (airoha_qdma_get_txq(qdma, j) != qid)
> + continue;
> +
> + netif_wake_subqueue(port->dev, j);
> + }
> }
> q->txq_stopped = false;
> }
> @@ -1965,7 +1976,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> u16 index;
> u8 fport;
>
> - qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);
> + qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
> tag = airoha_get_dsa_tag(skb, dev);
>
> msg0 = FIELD_PREP(QDMA_ETH_TXMSG_CHAN_MASK,
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 87b328cfefb0..c3ea7aadbd82 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -631,6 +631,11 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
> #define airoha_qdma_clear(qdma, offset, val) \
> airoha_rmw((qdma)->regs, (offset), (val), 0)
>
> +static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
> +{
> + return qid % ARRAY_SIZE(qdma->q_tx);
> +}
> +
> static inline bool airoha_is_lan_gdm_port(struct airoha_gdm_port *port)
> {
> /* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-wake_netdev_txqs-optmization-65171ce4ebad
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53%40kernel.org
- Can this cause an infinite NETDEV_TX_BUSY livelock when a QDMA hardware queue is full?
The issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Ard Biesheuvel @ 2026-04-23 7:48 UTC (permalink / raw)
To: Christoph Hellwig, Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Russell King,
Arnd Bergmann, Eric Biggers
In-Reply-To: <20260423074614.GB31018@lst.de>
On Thu, 23 Apr 2026, at 09:46, Christoph Hellwig wrote:
>> +extern void __xor_eor3_2(unsigned long bytes, unsigned long * __restrict p1,
>> + const unsigned long * __restrict p2);
>
> Does the alias magic prevent this from being in a header?
Yes, it emits the ELF symbol for the alias, and this is only permitted
in the compilation unit that defines the original.
> If so a comment
> would be nice, otherwise moving it to a header would be even better.
Ack.
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: mediatek: Convert mtk-btcvsd-snd to DT Schema
From: Krzysztof Kozlowski @ 2026-04-23 7:48 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-sound, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260421193858.347258-1-l.scorcia@gmail.com>
On Tue, Apr 21, 2026 at 08:38:35PM +0100, Luca Leonardo Scorcia wrote:
> +title: Mediatek ALSA BT SCO CVSD/MSBC Driver
s/Driver//
> +
> +maintainers:
> + - Luca Leonardo Scorcia <l.scorcia@gmail.com>
> +
> +properties:
> + compatible:
> + const: mediatek,mtk-btcvsd-snd
> +
> + reg:
> + minItems: 2
Drop
> + maxItems: 2
and actually drop this too and list the items with description - PKV and
SRAM_BANK2 regions
> +
> + reg-names:
> + items:
> + - const: pkv
> + - const: sram-bank2
Old binding did not have reg-names and nothing in commit msg explains
changes done to the binding.
To remind: if you change the binding, you must mention it and explain
WHY.
I don't see any use of that, so why did you add it?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Christoph Hellwig @ 2026-04-23 7:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-17-ardb+git@google.com>
On Wed, Apr 22, 2026 at 07:17:03PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> arm_neon.h is a compiler header which needs some scaffolding to work
> correctly in the linux context, and so it is better not to include it
> directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
> takes care of this.
This could potentially clash with the raid6 library rework I'm doing
for 7.2. Although git has become pretty good about renamed files, so
maybe it won't be so bad.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox