]> git.ipfire.org Git - thirdparty/kernel/stable.git/log
thirdparty/kernel/stable.git
2 weeks agomd/raid0: use str_plural helper in dump_zones
Thorsten Blum [Wed, 27 May 2026 14:19:33 +0000 (16:19 +0200)] 
md/raid0: use str_plural helper in dump_zones

Replace the manual ternary "s" pluralization with str_plural() to
simplify the code.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260527141932.1243503-2-thorsten.blum@linux.dev
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agoraid1: fix nr_pending leak in REQ_ATOMIC bad-block error path
Abd-Alrhman Masalkhi [Sat, 30 May 2026 15:14:11 +0000 (15:14 +0000)] 
raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path

In raid1_write_request(), each per-mirror loop iteration begins by
incrementing rdev->nr_pending. If a REQ_ATOMIC write encounters a
badblock within the requested range, the code jumps to err_handle
without dropping the reference taken for the current mirror.

err_handle's cleanup loop will only decrements for k < i and
r1_bio->bios[k] is non-NULL. The current slot is therefore skipped,
leaving its nr_pending reference leaked permanently. The reference
prevents the rdev from ever being removed, since raid1_remove_conf()
refuses to remove an rdev with nr_pending > 0.

Fix this by calling rdev_dec_pending() before jumping to err_handle.

Fixes: f2a38abf5f1c ("md/raid1: Atomic write support")
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Link: https://patch.msgid.link/20260530151411.4119-1-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd/raid1: move the exceed_read_errors condition out of fix_read_error
Christoph Hellwig [Fri, 29 May 2026 05:43:00 +0000 (07:43 +0200)] 
md/raid1: move the exceed_read_errors condition out of fix_read_error

This condition much better fits into the only caller, limiting
fix_read_error to actually fix up data devices after a read error.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260529054308.2720300-3-hch@lst.de
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd/raid1: cleanup handle_read_error
Christoph Hellwig [Fri, 29 May 2026 05:42:59 +0000 (07:42 +0200)] 
md/raid1: cleanup handle_read_error

Unwind the main conditional with duplicate conditions and initialize
variables at initialization time where possible.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260529054308.2720300-2-hch@lst.de
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd/raid1,raid10: fix bio accounting for split md cloned bios
Abd-Alrhman Masalkhi [Fri, 1 May 2026 11:46:51 +0000 (13:46 +0200)] 
md/raid1,raid10: fix bio accounting for split md cloned bios

Use md_cloned_bio() to control bio accounting instead of relying
on r1bio_existed in raid1 or the io_accounting flag in raid10.

The previous logic does not reliably reflect whether a bio is an
md cloned bio. When a failed bio is split and resubmitted via
bio_submit_split_bioset() on the error path, this can lead to either
double accounting for md cloned bios, or missing accounting for bios
returned from bio_submit_split_bioset()

Fix this by using md_cloned_bio() to detect md cloned bios and
skip accounting accordingly.

Fixes: bb2a9acefaf9 ("md/raid1: switch to use md_account_bio() for io accounting")
Fixes: 820455238366 ("md/raid10: switch to use md_account_bio() for io accounting")
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Reviewed-by: Xiao Ni <xiao@kernel.org>
Link: https://patch.msgid.link/20260501114652.590037-4-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd/raid1,raid10: fix error-path detection with md_cloned_bio()
Abd-Alrhman Masalkhi [Fri, 1 May 2026 11:46:50 +0000 (13:46 +0200)] 
md/raid1,raid10: fix error-path detection with md_cloned_bio()

Detect the error path using md_cloned_bio() instead of relying
on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be
NULL or -1 after splitting and resubmitting a failed bio.

As a result, the error path may not be recognized and memory
allocations can incorrectly use GFP_NOIO instead of
(GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under
memory pressure.

Fixes: 689389a06ce7 ("md/raid1: simplify handle_read_error().")
Fixes: 545250f24809 ("md/raid10: simplify handle_read_error()")
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Reviewed-by: Xiao Ni <xiao@kernel.org>
Link: https://patch.msgid.link/20260501114652.590037-3-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd/raid1,raid10: fix deadlock in read error recovery path
Abd-Alrhman Masalkhi [Fri, 1 May 2026 11:46:49 +0000 (13:46 +0200)] 
md/raid1,raid10: fix deadlock in read error recovery path

raid1d and raid10d may resubmit a split md cloned bio while handling
a read error. In this case, resubmitting the bio can lead to a deadlock
if the array is suspended before md_handle_request() acquires an
active_io reference via percpu_ref_tryget_live().

Since the cloned bio already holds an active_io reference,
trying to acquire another reference via percpu_ref_tryget_live()
can lead to a deadlock while the array is suspended.

Fix this by using percpu_ref_get() for md cloned bios.

Fixes: bb2a9acefaf9 ("md/raid1: switch to use md_account_bio() for io accounting")
Fixes: 820455238366 ("md/raid10: switch to use md_account_bio() for io accounting")
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Reviewed-by: Xiao Ni <xiao@kernel.org>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260501114652.590037-2-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd/raid10: reset read_slot when reusing r10bio for discard
Chen Cheng [Fri, 15 May 2026 09:30:19 +0000 (17:30 +0800)] 
md/raid10: reset read_slot when reusing r10bio for discard

put_all_bios() always drops devs[i].bio, but it only drops
devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an
r10bio that was previously used for a read, read_slot can still be
non-negative, and discard cleanup can skip bio_put() on repl_bio.

Reset read_slot to -1 when preparing an r10bio for discard so the
replacement bio is always released correctly.

Fixes: d30588b2731f ("md/raid10: improve raid10 discard request")
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
Reviewed-by: Xiao Ni <xiao@kernel.org>
Link: https://patch.msgid.link/20260515093019.3436882-1-chencheng@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agomd: skip redundant raid_disks update when value is unchanged
Abd-Alrhman Masalkhi [Tue, 28 Apr 2026 13:05:24 +0000 (15:05 +0200)] 
md: skip redundant raid_disks update when value is unchanged

Calling update_raid_disks() with the same value as the current one
can trigger unnecessary work. For example, RAID1 will reallocate
resources such as the mempool for r1bio.

Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Link: https://patch.msgid.link/20260428130524.448063-1-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agodm-raid: only requeue bios when dm is suspending
Benjamin Marzinski [Tue, 28 Apr 2026 23:20:10 +0000 (19:20 -0400)] 
dm-raid: only requeue bios when dm is suspending

Returning DM_MAPIO_REQUEUE from the target map() function only requeues
the bio during noflush suspends. During regular operations or during
flushing suspends, it fails the bio. Failing the bio during flushing
suspends is the correct behavior here. The bio cannot be handled, and
dm-raid cannot suspend while it is outstanding. But during normal
operations, dm-raid should not push the bio back to dm. Instead, wait
for the reshape to be resumed.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Xiao Ni <xiao@kernel.org>
Link: https://patch.msgid.link/20260428232010.2785514-1-bmarzins@redhat.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agoMAINTAINERS: Update Li Nan's E-mail address
Li Nan [Fri, 8 May 2026 09:55:13 +0000 (17:55 +0800)] 
MAINTAINERS: Update Li Nan's E-mail address

Change to my new email address on didiglobal.com.

Signed-off-by: Li Nan <magiclinan@didiglobal.com>
Link: https://patch.msgid.link/tencent_8F8173BEDF20E98550D5429DF802F34A7108@qq.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agoMAINTAINERS: update Yu Kuai's email address
Yu Kuai [Wed, 20 May 2026 11:21:48 +0000 (19:21 +0800)] 
MAINTAINERS: update Yu Kuai's email address

Update Yu Kuai's maintainer entries to use the new fygo.io address.

Link: https://patch.msgid.link/20260520112627.1264368-1-yukuai@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
2 weeks agoarm64: dts: renesas: r9a08g046l48-smarc: Enable audio
Biju Das [Thu, 28 May 2026 07:45:45 +0000 (08:45 +0100)] 
arm64: dts: renesas: r9a08g046l48-smarc: Enable audio

Enable audio on the RZ/G3L SMARC EVK by linking SSI0 with the DA7212
audio CODEC.  The SSI0 signals are multiplexed with SD2 and are selected
by switch SW_SD2_EN#.  Add regulator nodes regulator-{1p8v,3p3v} to the
SoM DTSI for reuse by eMMC.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260528074615.91110-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: rzg3l-smarc-som: Enable Versa clock generator
Biju Das [Thu, 28 May 2026 07:45:44 +0000 (08:45 +0100)] 
arm64: dts: renesas: rzg3l-smarc-som: Enable Versa clock generator

The RZ/G3L SMARC SoM has a Versa 5P35023B clock generator to generate
the following clocks:
  - ref: Not connected,
  - se1: AUDIO_MCK (11.2896 or 12.2880 MHz),
  - se2: RZ_AUDIO_CLK_B (11.2896 MHz),
  - se3: RZ_AUDIO_CLK_C (12.2880 MHz),
  - diff{1,1B}: ET{0,1}_PHY_CLK (25 MHz),
  - diff2{2,2B}: Not connected.

Enable the Vversa 5P35023B clock generator on the RZ/G3L SoM DTSI.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260528074615.91110-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046l48-smarc: Enable I2C{2,3} devices
Biju Das [Thu, 28 May 2026 07:02:35 +0000 (08:02 +0100)] 
arm64: dts: renesas: r9a08g046l48-smarc: Enable I2C{2,3} devices

Enable I2C{2,3} on the RZ/G3L SMARC EVK board.  I2C3 is enabled by
setting SW SYS.2 to the OFF position.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20260528070239.33352-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046l48-smarc: Add gpio keys
Biju Das [Thu, 28 May 2026 07:02:34 +0000 (08:02 +0100)] 
arm64: dts: renesas: r9a08g046l48-smarc: Add gpio keys

RZ/G3L SMARC EVK  has 3 user buttons called USER_SW1, USER_SW2 and
USER_SW3.  Instantiate the gpio-keys driver for these buttons by
removing place holders and replacing proper pins for the buttons.

USER_SW{1,2,3} are configured as wakeup-sources, so they can wake up the
system during s2idle.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260528070239.33352-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: rzt2h-n2h-evk: Enable xSPI nodes
Lad Prabhakar [Wed, 27 May 2026 20:24:30 +0000 (21:24 +0100)] 
arm64: dts: renesas: rzt2h-n2h-evk: Enable xSPI nodes

Enable the xSPI0 and xSPI1 controllers on the RZ/T2H N2H EVK board.

Configure the xSPI0 controller interface to 1-bit (x1) mode, even though
the connected MX25LW51245 octal flash device supports octal mode.  Add a
corresponding inline hardware comment detailing this restriction;
operating in octal mode causes the BootROM to fail loading the
first-stage bootloader following a Watchdog Timer (WDT) reset.

Configure the xSPI1 controller interface connected to the AT25SF128A
flash device for 4-bit (x4) mode to utilize all available data lines.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260527202430.606341-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g087: Add xSPI nodes
Lad Prabhakar [Tue, 26 May 2026 20:40:44 +0000 (21:40 +0100)] 
arm64: dts: renesas: r9a09g087: Add xSPI nodes

Add device tree nodes for the two xSPI (Expanded SPI) controllers
integrated into the RZ/N2H (R9A09G087) SoC.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260526204045.3481604-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g077: Add xSPI nodes
Lad Prabhakar [Tue, 26 May 2026 20:40:43 +0000 (21:40 +0100)] 
arm64: dts: renesas: r9a09g077: Add xSPI nodes

Add device tree nodes for the two xSPI (Expanded SPI) controllers
integrated into the RZ/T2H (R9A09G077) SoC.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260526204045.3481604-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: rzg3e-smarc-som: Sort GMAC pinmux entries
Biju Das [Sun, 24 May 2026 09:20:11 +0000 (10:20 +0100)] 
arm64: dts: renesas: rzg3e-smarc-som: Sort GMAC pinmux entries

Sort the pinmux entries for both GMAC ctrl nodes in port order (A/B/C and
D/E/F respectively) and remove the extra blank line before the second
pinmux assignment.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260524092016.46346-1-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist
Nguyen Tran [Fri, 22 May 2026 17:19:57 +0000 (19:19 +0200)] 
arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist

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.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20260522172000.15096-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a07g044: Add DMA properties to serial nodes
Claudiu Beznea [Wed, 20 May 2026 13:23:15 +0000 (16:23 +0300)] 
arm64: dts: renesas: r9a07g044: Add DMA properties to serial nodes

Add DMA properties to the serial nodes on the RZ/G2L SoC.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260520132315.944117-1-claudiu.beznea@kernel.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a07g054: Add max-frequency to SDHI nodes
Biju Das [Wed, 20 May 2026 11:51:41 +0000 (12:51 +0100)] 
arm64: dts: renesas: r9a07g054: Add max-frequency to SDHI nodes

Add the max-frequency property set to 133333333 Hz (133.33 MHz) to both
SDHI0 and SDHI1 MMC controller nodes in the RZ/V2L (r9a07g054) device
tree, increasing performance by ca. 33%.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260520115144.60067-4-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a07g044: Add max-frequency to SDHI nodes
Biju Das [Wed, 20 May 2026 11:51:40 +0000 (12:51 +0100)] 
arm64: dts: renesas: r9a07g044: Add max-frequency to SDHI nodes

Add the max-frequency property set to 133333333 Hz (133.33 MHz) to both
SDHI0 and SDHI1 MMC controller nodes in the RZ/{G2L,G2LC} (r9a07g044)
device tree, increasing performance by ca. 33%.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260520115144.60067-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a07g043: Add max-frequency to SDHI nodes
Biju Das [Wed, 20 May 2026 11:51:39 +0000 (12:51 +0100)] 
arm64: dts: renesas: r9a07g043: Add max-frequency to SDHI nodes

Add the max-frequency property set to 133333333 Hz (133.33 MHz) to both
SDHI0 and SDHI1 MMC controller nodes in the RZ/{G2UL,Five} (r9a07g043)
device tree, increasing performance by ca. 33%.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260520115144.60067-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046: Add rsci{0..3} device nodes
Biju Das [Tue, 19 May 2026 10:00:17 +0000 (11:00 +0100)] 
arm64: dts: renesas: r9a08g046: Add rsci{0..3} device nodes

Add rsci{0..3} device nodes to the RZ/G3L ("R9A08G046") SoC DTSI.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260519100022.116318-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: ironhide: Enable to use SCMI
Kuninori Morimoto [Tue, 19 May 2026 07:47:04 +0000 (09:47 +0200)] 
arm64: dts: renesas: ironhide: Enable to use SCMI

Enable SCMI via MFIS-SCP and S-TCM transport area.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260519074702.3308-6-wsa+renesas@sang-engineering.com
[geert: Drop scmi_clk node]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoMerge tag 'renesas-r8a78000-dt-binding-defs-tag1' into renesas-dts-for-v7.2
Geert Uytterhoeven [Sun, 31 May 2026 08:52:05 +0000 (10:52 +0200)] 
Merge tag 'renesas-r8a78000-dt-binding-defs-tag1' into renesas-dts-for-v7.2

Renesas R-Car X5H MFIS DT Binding Definitions

DT bindings and binding definitions for the Renesas R-Car X5H (R8A78000)
Multifunctional Interface (MFIS), shared by driver and DT source files.

2 weeks agoarm64: dts: renesas: r8a78000: Add MFIS, MFIS-SCP, and transport nodes
Kuninori Morimoto [Tue, 19 May 2026 07:47:03 +0000 (09:47 +0200)] 
arm64: dts: renesas: r8a78000: Add MFIS, MFIS-SCP, and transport nodes

Describe the MFIS and MFIS SCP instances which are used for various
tasks including inter-processor communication.  Remove the PRR node
because it is part of MFIS on R-Car X5H and should be handled using the
MFIS compatible. Also, describe the S-TCM transport area used for shared
memory mailboxing.

Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260519074702.3308-5-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: ironhide: Describe all reserved memory
Marek Vasut [Sun, 17 May 2026 16:31:25 +0000 (18:31 +0200)] 
arm64: dts: renesas: ironhide: Describe all reserved memory

Fully describe all available DRAM in the DT, and describe regions which
are not accessible because they are used by firmware in reserved-memory
nodes.

Replace the first memory bank memory@60600000 with memory@40000000 and a
518 MiB long reserved-memory no-map subnode. This memory region is used
by other cores in the system.

Reserve 32 kiB of memory at 0x8c100000 for parameters shared by IPL,
SCP, TFA BL31 and TEE.

Reserve 512 kiB of memory at 0x8c200000 for TFA BL31.  The upcoming
upstream TFA 2.15 BL31 uses memory from 0x8c200000..0x8c242fff; rounding
up to 512 kiB is slight future-proofing.

Reserve 32 MiB of memory at 0x8c400000 for OPTEE-OS, which is the entire
OPTEE-OS TZ protected DRAM area.

Neither TFA BL31 nor OPTEE-OS modify the DT passed to Linux in any way
with any new reserved-memory {} nodes to reserve memory areas used by
the TFA BL31 or OPTEE-OS to prevent the next stage from using those
areas, which lets Linux use all of the available DRAM as it is described
in the DT that was passed in by U-Boot, including the areas that are
newly utilized by TFA BL31 or OPTEE-OS.

In case of high DRAM utilization, unless the memory used by TFA BL31 or
OPTEE-OS is properly reserved, Linux may use and corrupt the memory used
by TFA BL31 or OPTEE-OS, which would lead to the system becoming
unresponsive.

Fixes: ad142a4ef710 ("arm64: dts: renesas: r8a78000: Add initial Ironhide board support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260517163212.18016-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: rzt2h-n2h-evk: Configure eMMC/SDHI pins
Fabrizio Castro [Thu, 14 May 2026 21:02:17 +0000 (22:02 +0100)] 
arm64: dts: renesas: rzt2h-n2h-evk: Configure eMMC/SDHI pins

The HW user manual for the Renesas RZ/T2H and the RZ/N2H states that for
SDR104, SDR50, and HS200 to work properly the eMMC/SDHI interface pins
have to be configured as specified below:
  - SDn_CLK pin - drive strength: Ultra High, slew rate: Fast,
  - Other SDn_* pins: drive strength: High, slew rate: Fast,
    Schmitt trigger: disabled (not applicable to SDn_RST pins).

HS DDR and DDR50 are currently not supported, and for every other bus
mode the eMMC/SDHI interface pins should be configured as specified
below:
  - SDn_CLK pin - drive strength: High, slew rate: Fast,
  - Other SDn_* pins: drive strength: Middle, slew rate: Fast,
    Schmitt trigger: disabled (not applicable to SDn_RST pins).

Adjust the pin definitions accordingly.

Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/20260514210220.7616-1-fabrizio.castro.jz@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor description
Marek Vasut [Thu, 14 May 2026 12:53:06 +0000 (14:53 +0200)] 
arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor description

The Renesas R-Car X5H (R8A78000) SoC contains Arm CoreLink GIC-720AE
Generic Interrupt Controller with Multi View capability. Firmware has
access to configuration View 0, Linux kernel has access to View 1.

The Arm CoreLink GIC-720AE Generic Interrupt Controller Technical
Reference Manual, currently latest r2p1 [1], chapter "5. Programmers
model for GIC-720AE", subchapter "5.4 Redistributor registers
for control and physical LPIs summary", part "5.4.3 GICR_TYPER,
Redistributor Type Register", "Table 5-50: GICR_TYPER bit descriptions"
on page 200, clarifies register "GICR_TYPER" bit 4 "Last" behavior
in Multi View setup as follows:

    Last
    Last Redistributor:

    0 ... This Redistributor is not the last Redistributor on the chip.
    1 ... This Redistributor is the last Redistributor on the chip.
  When GICD_CFGID.VIEW == 1, for views 1, 2, or 3 this bit
  always returns 1.

On this SoC, GICD_CFGID.VIEW is 1 and the Linux kernel has access to
View 1, therefore Linux kernel GICv3 driver will interpret register
"GICR_TYPER" bit 4 "Last" = 1 in the first Redistributor in continuous
Redistributor page as that first Redistributor being the one and only
Redistributor and will stop processing the continuous Redistributor
page further. This will prevent the other Redistributors from being
recognized by the system and used for other PEs.

Because the hardware indicates that the continuous Redistributor page
is not continuous for View 1, 2, or 3, describe every Redistributor
separately in the DT. This makes all Redistributors for all cores
accessible in Linux.

[1] https://documentation-service.arm.com/static/69ef3c1cd35efd294e335c43
    Arm® CoreLinkâ„¢ GIC-720AE Generic Interrupt Controller
    Revision: r2p1 / Issue 12 / 102666_0201_12_en

Fixes: 63500d12cf76 ("arm64: dts: renesas: Add R8A78000 SoC support")
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260514125328.20954-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r8a78000: Add PSCI node
Marek Vasut [Wed, 13 May 2026 22:50:24 +0000 (00:50 +0200)] 
arm64: dts: renesas: r8a78000: Add PSCI node

Describe SMC based PSCI access in SoC DT.  The system can interact with
TFA BL31 PSCI provider running on the Cortex-A cores via SMC calls.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260513225037.49803-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g056n48-rzv2n-evk: Add alias for on-SoC RTC
Lad Prabhakar [Wed, 6 May 2026 15:58:04 +0000 (16:58 +0100)] 
arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Add alias for on-SoC RTC

The RZ/V2N SoC provides an internal RTC, which is enabled in the DT.
The RZ/V2N EVK board also includes an external RTC in the RAA215300
PMIC.

Add an "rtc0" alias pointing to the on-SoC RTC node to ensure a stable
device numbering.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260506155804.3984418-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add alias for on-SoC RTC
Lad Prabhakar [Wed, 6 May 2026 15:58:03 +0000 (16:58 +0100)] 
arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add alias for on-SoC RTC

The RZ/V2H SoC provides an internal RTC, which is enabled in the DT.
The RZ/V2H EVK board also includes an external RTC in the RAA215300
PMIC.

Add an "rtc0" alias pointing to the on-SoC RTC node to ensure a stable
device numbering.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260506155804.3984418-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046: Add audio clock nodes
Biju Das [Tue, 5 May 2026 12:37:01 +0000 (13:37 +0100)] 
arm64: dts: renesas: r9a08g046: Add audio clock nodes

Add audio_clk1 and audio_clk2 fixed-clock nodes to the RZ/G3L (r9a08g046)
SoC DTSI. These clocks are external to the SoC and their frequencies are
board-dependent, so they are defined with clock-frequency = <0> as
placeholders that must be overridden in board-level DTS files.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505123708.134069-4-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046: Add SSI support
Biju Das [Tue, 5 May 2026 12:37:00 +0000 (13:37 +0100)] 
arm64: dts: renesas: r9a08g046: Add SSI support

Add SSI{0,1,2,3} nodes to RZ/G3L SoC DTSI.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505123708.134069-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046: Add DMAC node
Biju Das [Tue, 5 May 2026 12:36:59 +0000 (13:36 +0100)] 
arm64: dts: renesas: r9a08g046: Add DMAC node

Add the DMA controller device tree node for the RZ/G3L (r9a08g046) SoC.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505123708.134069-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046: Add i2c{0..3} device nodes
Biju Das [Tue, 5 May 2026 07:01:55 +0000 (08:01 +0100)] 
arm64: dts: renesas: r9a08g046: Add i2c{0..3} device nodes

Add i2c{0..3} device nodes to RZ/G3L ("R9A08G046") SoC DTSI.
As the place holders for i2c0 is removed, add the pincontrol
device nodes to make it functional on the board DTS.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505070206.7932-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a08g046: Add scif{1..5} device nodes
Biju Das [Tue, 5 May 2026 07:01:54 +0000 (08:01 +0100)] 
arm64: dts: renesas: r9a08g046: Add scif{1..5} device nodes

Add scif{1..5} device nodes to RZ/G3L ("R9A08G046") SoC DTSI.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505070206.7932-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agomedia: qcom: camss: vfe-340: Proper client handling
Loic Poulain [Tue, 14 Apr 2026 18:52:01 +0000 (20:52 +0200)] 
media: qcom: camss: vfe-340: Proper client handling

We need to properly map camss WM index to our internal WM client
instance. Today we only support RDI interfaces with the RDI_WM
macro, introduce a __wm_to_client helper to support any interface.

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
2 weeks agomedia: qcom: camss: csid-340: Enable PIX interface routing
Loic Poulain [Tue, 14 Apr 2026 18:52:00 +0000 (20:52 +0200)] 
media: qcom: camss: csid-340: Enable PIX interface routing

Add PIX path support to the CSID-340 driver. The hardware exposes a
dedicated PIX interface in addition to the existing RDI paths, but
the driver only supported RDI stream configuration so far.

The PIX path is configured similarly to RDI but requires decode-format
to be specified.

The PIX pipeline can subsequently perform further processing,
including scaling, cropping, and statistics.

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
2 weeks agomedia: qcom: camss: csid-340: Add port-to-interface mapping
Loic Poulain [Tue, 14 Apr 2026 18:51:59 +0000 (20:51 +0200)] 
media: qcom: camss: csid-340: Add port-to-interface mapping

The CSID-340 block uses different register offsets for the PIX and RDI
interfaces, but the driver previously indexed these registers directly
with the camss port number. This happened to work for RDI because the
port index matches the RDI register layout, but this assumption breaks
with upcoming PIX interface support

Introduce an explicit port-to-interface mapping and use the mapped iface
index when programming CSID_CFG0 and CSID_CTRL. This replaces the
standalone __csid_ctrl_rdi() helper and simplifies the RDI stream setup
path.

Also correct the CSID_CFG0/CTRL base offsets and clean up the code in
preparation for full PIX path support.

Like RDI, PIX outputs Bayer frames but can also achieve some image
processing such as scaling, cropping and generating statitics (e.g.
histogram), it also offer more flexebility in term of image alignment
and stride. All of that can then later be leveraged to improve
software or hardware frames post-processing.

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
2 weeks agomedia: qcom: camss: csid-340: Switch to generic CSID_CFG/CTRL registers
Loic Poulain [Tue, 14 Apr 2026 18:51:58 +0000 (20:51 +0200)] 
media: qcom: camss: csid-340: Switch to generic CSID_CFG/CTRL registers

The former RDI-specific register definitions (CSID_RDI_CFG0/CTRL) are
renamed to unified CSID_CFG0/CSID_CTRL variants, as their layout is
interface agnostic. This refactoring provides the foundation for
extending csid-340 with missing PIX interface/path support.

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
2 weeks agoarm64: dts: renesas: gray-hawk: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:52 +0000 (05:42 +0200)] 
arm64: dts: renesas: gray-hawk: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-12-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: white-hawk: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:51 +0000 (05:42 +0200)] 
arm64: dts: renesas: white-hawk: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-11-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: falcon: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:50 +0000 (05:42 +0200)] 
arm64: dts: renesas: falcon: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-10-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: draak: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:49 +0000 (05:42 +0200)] 
arm64: dts: renesas: draak: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-9-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: ebisu: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:48 +0000 (05:42 +0200)] 
arm64: dts: renesas: ebisu: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-8-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: v3hsk: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:47 +0000 (05:42 +0200)] 
arm64: dts: renesas: v3hsk: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-7-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: condor-common: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:46 +0000 (05:42 +0200)] 
arm64: dts: renesas: condor-common: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-6-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: v3msk: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:45 +0000 (05:42 +0200)] 
arm64: dts: renesas: v3msk: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-5-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: eagle: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:44 +0000 (05:42 +0200)] 
arm64: dts: renesas: eagle: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-4-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: ulcb: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:43 +0000 (05:42 +0200)] 
arm64: dts: renesas: ulcb: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-3-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: salvator-common: Specify ethernet PHY reset timings
Marek Vasut [Tue, 5 May 2026 03:42:42 +0000 (05:42 +0200)] 
arm64: dts: renesas: salvator-common: Specify ethernet PHY reset timings

The KSZ9031RNX reference manual [1] DS00002117K page 62 FIGURE 7-5:
POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
de-assertion of reset, wait a minimum of 100 us before starting
programming on the MIIM (MDC/MDIO) interface. Set DT property
reset-deassert-us to three times that, 300 us, to provide ample
time between reset deassertion and MDIO access.

The KSZ9031RNX reference manual [1] DS00002117K page 62 TABLE 7-4:
POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
voltages to de-assertion of reset is at minimum 10 ms. Set DT
property reset-assert-us to 10ms because the KSZ9031RNX RM does
not explicitly spell out how long the reset has to be asserted,
but this at least covers the worst case scenario.

[1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031RNX-Data-Sheet-DS00002117.pdf

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260505034325.167797-2-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: ulcb: Rename clk-multiplier to clock-controller
Marek Vasut [Mon, 4 May 2026 22:56:55 +0000 (00:56 +0200)] 
arm64: dts: renesas: ulcb: Rename clk-multiplier to clock-controller

Use standard clock-controller node name for the CS2000-CP.
No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504225704.115125-5-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: salvator-common: Rename clk-multiplier to clock-controller
Marek Vasut [Mon, 4 May 2026 22:56:54 +0000 (00:56 +0200)] 
arm64: dts: renesas: salvator-common: Rename clk-multiplier to clock-controller

Use standard clock-controller node name for the CS2000-CP.
No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504225704.115125-4-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: hihope: Rename clk-multiplier to clock-controller
Marek Vasut [Mon, 4 May 2026 22:56:53 +0000 (00:56 +0200)] 
arm64: dts: renesas: hihope: Rename clk-multiplier to clock-controller

Use standard clock-controller node name for the CS2000-CP.
No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504225704.115125-3-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: ebisu: Rename clk-multiplier to clock-controller
Marek Vasut [Mon, 4 May 2026 22:56:52 +0000 (00:56 +0200)] 
arm64: dts: renesas: ebisu: Rename clk-multiplier to clock-controller

Use standard clock-controller node name for the CS2000-CP.
No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504225704.115125-2-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: draak: Rename clk-multiplier to clock-controller
Marek Vasut [Mon, 4 May 2026 22:56:51 +0000 (00:56 +0200)] 
arm64: dts: renesas: draak: Rename clk-multiplier to clock-controller

Use standard clock-controller node name for the CS2000-CP.
No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504225704.115125-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
Nguyen Tran [Mon, 4 May 2026 14:43:28 +0000 (16:43 +0200)] 
arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs

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>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504144534.43745-7-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agodt-bindings: soc: renesas: Document R-Car R8A779MD Geist
Marek Vasut [Mon, 4 May 2026 14:43:26 +0000 (16:43 +0200)] 
dt-bindings: soc: renesas: Document R-Car R8A779MD Geist

Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
SoC and the Renesas Geist development board.  The Renesas M3Le SoC is
a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals.  The Geist board is derived from Renesas Salvator-X/XS
boards, with adjustment for the R8A779MD SoC.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20260504144534.43745-5-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agodt-bindings: clock: cirrus,cs2000-cp: Document CS2500
Marek Vasut [Mon, 4 May 2026 14:43:25 +0000 (16:43 +0200)] 
dt-bindings: clock: cirrus,cs2000-cp: Document CS2500

Document backward compatibility support for the CS2500 chip, which is a
drop-in replacement for the CS2000 chip.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504144534.43745-4-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: Simplify AA1024XD12 display DTO
Marek Vasut [Mon, 4 May 2026 14:37:15 +0000 (16:37 +0200)] 
arm64: dts: renesas: Simplify AA1024XD12 display DTO

Move all differences into panel-aa104xd12.dtsi, rename OF_GRAPH links to
generic lvds_panel_out and lvds_panel_in names, and parametrize the LVDS
output in use using RENESAS_LVDS_OUTPUT macro.  No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260504143751.42753-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable PCIe
Lad Prabhakar [Fri, 1 May 2026 10:51:16 +0000 (11:51 +0100)] 
arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable PCIe

Enable the PCIE1 slot available on the RZ/V2N EVK.

Note, the PCIE_REFCLK comes from 5L35023B versa clock generator, once the
support for this clock generator is added, the fixed clock node can be
removed and can be replaced with a reference to the clock generator.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260501105116.33452-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g056: Add PCIe node
Lad Prabhakar [Fri, 1 May 2026 10:51:15 +0000 (11:51 +0100)] 
arm64: dts: renesas: r9a09g056: Add PCIe node

Add PCIe node to Renesas RZ/V2N ("R9A09G056") SoC DTSI.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260501105116.33452-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: rz-smarc-du-adv7513: Simplify DU port configuration
Lad Prabhakar [Mon, 20 Apr 2026 13:22:11 +0000 (14:22 +0100)] 
arm64: dts: renesas: rz-smarc-du-adv7513: Simplify DU port configuration

The SoC dtsi already defines the du node with its ports hierarchy,
including the du_out_rgb endpoint node under port@0.  There is no need
to redefine the entire ports/port@0 structure in the board-level dtsi.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260420132211.1350656-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g087: Add MTU3 support
Cosmin Tanislav [Fri, 10 Apr 2026 16:35:30 +0000 (19:35 +0300)] 
arm64: dts: renesas: r9a09g087: Add MTU3 support

The Renesas RZ/N2H (R9A09G087) SoC has an MTU3 block.

Add support for it.

Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260410163530.383818-11-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g077: Add MTU3 support
Cosmin Tanislav [Fri, 10 Apr 2026 16:35:29 +0000 (19:35 +0300)] 
arm64: dts: renesas: r9a09g077: Add MTU3 support

The Renesas RZ/T2H (R9A09G077) SoC has an MTU3 block.

Add support for it.

Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260410163530.383818-10-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a07g0{43,44,54}: Remove TCIU8 interrupt from MTU3
Cosmin Tanislav [Fri, 10 Apr 2026 16:35:28 +0000 (19:35 +0300)] 
arm64: dts: renesas: r9a07g0{43,44,54}: Remove TCIU8 interrupt from MTU3

The TCIU8 interrupt used to be documented in earlier revisions of the
user manuals, but has since been removed.  The corresponding entry is
now marked as reserved in the interrupt mapping tables of all supported
SoCs.

  - Page 486, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2UL
    Rev.1.40 User Manual
  - Page 363, Table 8.2 Interrupt Mapping (6/13) in the Renesas RZ/Five
    Rev.1.30 User Manual
  - Page 528, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2L
    and RZ/G2LC Rev.1.50 User Manual
  - Page 540, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/V2L
    Rev.1.50 User Manual

Remove the TCIU8 interrupt.  This does not cause any breakage as the
driver does not make use of the interrupts.

Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260410163530.383818-9-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g047: Add vspd{0,1} nodes
Tommaso Merciai [Wed, 8 Apr 2026 10:37:04 +0000 (12:37 +0200)] 
arm64: dts: renesas: r9a09g047: Add vspd{0,1} nodes

Add vspd{0,1} nodes to the RZ/G3E SoC DTSI.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/46547aaff3cdb8ea6e17cf1fdec699d83a1cd71b.1775636898.git.tommaso.merciai.xr@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agoarm64: dts: renesas: r9a09g047: Add fcpvd{0,1} nodes
Tommaso Merciai [Wed, 8 Apr 2026 10:37:03 +0000 (12:37 +0200)] 
arm64: dts: renesas: r9a09g047: Add fcpvd{0,1} nodes

Add fcpvd{0,1} nodes to the RZ/G3E SoC DTSI.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/1ba6a98ace4ad9525d054cbaa308d3aeeecfa22a.1775636898.git.tommaso.merciai.xr@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2 weeks agofirmware: tegra: bpmp: Add support for multi-socket platforms
Jon Hunter [Fri, 29 May 2026 17:33:37 +0000 (18:33 +0100)] 
firmware: tegra: bpmp: Add support for multi-socket platforms

On multi-socket platforms each socket has its own BPMP that is
registered with the kernel, so the existing single fixed "bpmp"
debugfs directory name cannot accommodate more than one instance.

Group the per-socket BPMP debugfs entries under a shared top-level
/sys/kernel/debug/bpmp/ directory, with each socket's BPMP device
under a "<numa-node-id>-bpmp" subdirectory:

  /sys/kernel/debug/bpmp/0-bpmp/...
  /sys/kernel/debug/bpmp/1-bpmp/...

For a multi-socket platform, the root debugfs bpmp/ directory is created
by the first BPMP device that is populated. For single-socket platforms,
the existing directory structure is preserved.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agofirmware: tegra: bpmp: Propagate debugfs errors
Jon Hunter [Fri, 29 May 2026 17:33:36 +0000 (18:33 +0100)] 
firmware: tegra: bpmp: Propagate debugfs errors

The Tegra BPMP debugfs code returns -ENOMEM for most cases where calls
to debugfs_create_dir() or debugfs_create_file() fail. These debugfs
functions return an ERR_PTR with the actual error code on failure.
Therefore, update the Tegra BPMP debugfs code to propagate the actual
error code on failure.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agosoc/tegra: pmc: Add Tegra238 support
Prathamesh Shete [Mon, 18 May 2026 10:14:20 +0000 (10:14 +0000)] 
soc/tegra: pmc: Add Tegra238 support

The Tegra238 PMC is largely similar to that found on earlier chips, but
not completely compatible. Add support for the PMC on Tegra238.

Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agosoc/tegra: pmc: Restrict power-off handler to Nexus 7
Diogo Ivo [Thu, 21 May 2026 13:48:48 +0000 (15:48 +0200)] 
soc/tegra: pmc: Restrict power-off handler to Nexus 7

The Tegra PMC power-off handler exists solely to reboot the Nexus 7 into
a special bootloader mode when a USB cable is connected, so that the
bootloader can display battery status instead of powering off. There is
no reason to register it on any other Tegra board.

Guard the registration behind of_machine_is_compatible("asus,grouper")
and rename the handler to tegra_pmc_grouper_power_off_handler to make
its scope explicit. The of_machine_is_compatible() check inside the
handler itself is now redundant and is removed.

This also avoids occupying SYS_OFF_PRIO_FIRMWARE on boards that have
other handlers at that priority level.

Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agosoc/tegra: pmc: Populate powergate debugfs only when needed
Jon Hunter [Fri, 22 May 2026 15:58:24 +0000 (16:58 +0100)] 
soc/tegra: pmc: Populate powergate debugfs only when needed

The 'powergate' debugfs node is used to show the state of the powergates
but for some devices the 'num_powergates' is 0 and so it displays
nothing. Therefore, only populate this debugfs entry for devices where
num_powergates is greater than 0.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agosoc/tegra: pmc: Move legacy code behind CONFIG_ARM guard
Thierry Reding [Tue, 4 Feb 2025 18:04:51 +0000 (19:04 +0100)] 
soc/tegra: pmc: Move legacy code behind CONFIG_ARM guard

None of this legacy code is needed on 64-bit ARM devices, so it can be
moved behind a corresponding preprocessor guard. This more cleanly
separates out the legacy code from code needed on current platforms.

Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agosoc/tegra: pmc: Remove unused legacy functions
Thierry Reding [Tue, 4 Feb 2025 18:45:19 +0000 (19:45 +0100)] 
soc/tegra: pmc: Remove unused legacy functions

All callers of these functions have been replaced by their variants
taking a PMC context as an input, so they are no longer used and can be
removed.

Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agosoc/tegra: pmc: Create PMC context dynamically
Thierry Reding [Mon, 3 Feb 2025 17:12:58 +0000 (18:12 +0100)] 
soc/tegra: pmc: Create PMC context dynamically

For legacy purposes, an early PMC context is needed to support certain
drivers and functionalities. However, when the PMC driver is probed in
the later boot stages, the early context is no longer needed. Allocate
the PMC context dynamically at probe time so that it can be used going
forward.

While at it, rename the early PMC context to more accurately reflect
what it is used for. It's technically not only for early boot stages,
but also to support some code that doesn't have a way of obtaining the
correct context otherwise (e.g. no access to device tree).

Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2 weeks agoMerge tag 'v7.1-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Linus Torvalds [Sun, 31 May 2026 00:05:58 +0000 (17:05 -0700)] 
Merge tag 'v7.1-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6

Pull smb client fixes from Steve French:

 - fix uninitialized variable in smb2_writev_callback()

 - detect short folioq copy in cifs_copy_folioq_to_iter()

* tag 'v7.1-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  smb: client: fix uninitialized variable in smb2_writev_callback
  smb: client: detect short folioq copy in cifs_copy_folioq_to_iter()

2 weeks agoMerge tag 'liveupdate-fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sat, 30 May 2026 22:39:47 +0000 (15:39 -0700)] 
Merge tag 'liveupdate-fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux

Pull liveupdate fixes from Mike Rapoport:
 "Two kexec handover regression fixes:

   - fix order calculation for kho_unpreserve_pages() to make sure sure
     that the order calculation in kho_unpreserve_pages() mathes the
     order calculation in kho_preserve_pages().

   - fix math in calculation of KHO_TREE_MAX_DEPTH to make it work with
     16KB pages"

* tag 'liveupdate-fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux:
  kho: fix order calculation for kho_unpreserve_pages()
  kho: fix KHO_TREE_MAX_DEPTH for non-4KB page sizes

2 weeks agoMerge tag 'fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt...
Linus Torvalds [Sat, 30 May 2026 22:37:05 +0000 (15:37 -0700)] 
Merge tag 'fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock

Pull memblock fix from Mike Rapoport:
 "Fix regression from memblock_free_late() refactoring

  After refactoring of memblock_free_late() and free_init_pages() it
  became possible to call memblock_free() after memblock init data was
  discarded.

  Make sure memblock_free() does not touch memblock.reserved unless it
  is called early enough or when ARCH_KEEP_MEMBLOCK is enabled"

* tag 'fixes-2026-05-30' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock:
  memblock: don't touch memblock arrays when memblock_free() is called late

2 weeks agoi2c: core: clean up adapter registration error label
Johan Hovold [Mon, 11 May 2026 14:37:15 +0000 (16:37 +0200)] 
i2c: core: clean up adapter registration error label

Clean up the adapter registration error labels by making sure that also
the last one is named after what it does.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: clean up bus id allocation
Johan Hovold [Mon, 11 May 2026 14:37:14 +0000 (16:37 +0200)] 
i2c: core: clean up bus id allocation

Clean up bus id allocation by using a common helper and deferring it
until it is needed during adapter registration.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix adapter deregistration race
Johan Hovold [Mon, 11 May 2026 14:37:13 +0000 (16:37 +0200)] 
i2c: core: fix adapter deregistration race

Adapters can be looked up by their id using i2c_get_adapter() which
takes a reference to the embedded struct device.

Remove the adapter from the IDR before tearing it down during
deregistration (and on registration failure) to make sure its resources
are not accessed after having been freed (e.g. the device name).

Fixes: 35fc37f81881 ("i2c: Limit core locking to the necessary sections")
Cc: stable@vger.kernel.org # 2.6.31
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix adapter registration race
Johan Hovold [Mon, 11 May 2026 14:37:12 +0000 (16:37 +0200)] 
i2c: core: fix adapter registration race

Adapters can be looked up based on their id using i2c_get_adapter()
which takes a reference to the embedded struct device.

Make sure that the adapter (including its struct device) has been
initialised before adding it to the IDR to avoid accessing uninitialised
data which could, for example, lead to NULL-pointer dereferences or
use-after-free.

Note that the i2c-dev chardev, which is registered from a bus notifier,
currently uses i2c_get_adapter() so the adapter needs to be added to the
IDR before registration.

Fixes: 6e13e6418418 ("i2c: Add i2c_add_numbered_adapter()")
Cc: stable@vger.kernel.org # 2.6.22
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: disable runtime PM on adapter registration failure
Johan Hovold [Mon, 11 May 2026 14:37:11 +0000 (16:37 +0200)] 
i2c: core: disable runtime PM on adapter registration failure

Runtime PM is disabled by driver core when deregistering a device (and
on registration failure) but add an explicit disable to balance the
enable call when adapter registration fails for symmetry.

Fixes: 23a698fe65ec ("i2c: core: treat EPROBE_DEFER when acquiring SCL/SDA GPIOs")
Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix adapter debugfs creation
Johan Hovold [Mon, 11 May 2026 14:37:10 +0000 (16:37 +0200)] 
i2c: core: fix adapter debugfs creation

Clients can be registered from bus notifier callbacks so the debugfs
directory needs to be created before registering the adapter as clients
use that directory as their debugfs parent.

Move debugfs creation before adapter registration to avoid having
clients create their debugfs directories in the debugfs root (which is
also more likely to fail due to name collisions).

Note that failure to allocate the adapter name must now be handled
explicitly as debugfs_create_dir() cannot handle a NULL name (unlike
device_add() which returns an error).

Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter")
Cc: stable@vger.kernel.org # 6.8
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix adapter probe deferral loop
Johan Hovold [Mon, 11 May 2026 14:37:09 +0000 (16:37 +0200)] 
i2c: core: fix adapter probe deferral loop

Drivers must not probe defer after having registered devices as that
will trigger a probe loop if the devices bind to a driver (cf. commit
fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).

Move the recovery initialisation, where the GPIO lookup may fail, before
registering the adapter to prevent this.

Fixes: 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
Cc: stable@vger.kernel.org # 5.9
Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix NULL-deref on adapter registration failure
Johan Hovold [Mon, 11 May 2026 14:37:08 +0000 (16:37 +0200)] 
i2c: core: fix NULL-deref on adapter registration failure

If adapter registration ever fails the release callback would trigger a
NULL-pointer dereference as the completion struct has not been
initialised.

Note that before the offending commit this would instead have resulted
in a minor memory leak of the adapter name.

Fixes: 3f8c4f5e9a57 ("i2c: core: fix reference leak in i2c_register_adapter()")
Cc: stable@vger.kernel.org
Cc: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix hang on adapter registration failure
Johan Hovold [Mon, 11 May 2026 14:37:07 +0000 (16:37 +0200)] 
i2c: core: fix hang on adapter registration failure

Clients may be registered from bus notifier callbacks when the adapter
is registered. On a subsequent error during registration, the adapter
references taken by such clients prevent the wait for the references to
be released from ever completing.

Fix this by refactoring client deregistration and deregistering also on
late adapter registration failures.

Fixes: f8756c67b3de ("i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter")
Cc: stable@vger.kernel.org # 4.15
Cc: Phil Reid <preid@electromag.com.au>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agoi2c: core: fix irq domain leak on adapter registration failure
Johan Hovold [Mon, 11 May 2026 14:37:06 +0000 (16:37 +0200)] 
i2c: core: fix irq domain leak on adapter registration failure

Make sure to tear down the host notify irq domain on adapter
registration failure to avoid leaking it.

This issue was flagged by Sashiko when reviewing another adapter
registration fix.

Fixes: 4d5538f5882a ("i2c: use an IRQ to report Host Notify events, not alert")
Cc: stable@vger.kernel.org # 4.10
Cc: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2 weeks agowifi: iwlwifi: mvm: avoid oversized UATS command copy
Emmanuel Grumbach [Fri, 29 May 2026 05:57:07 +0000 (08:57 +0300)] 
wifi: iwlwifi: mvm: avoid oversized UATS command copy

MCC_ALLOWED_AP_TYPE_CMD exceeds the fixed copied host-command buffer
and triggers warnings in the gen2 enqueue path when command
0xc05 is sent.

Use IWL_HCMD_DFL_NOCOPY as it was done before the offending commit.

Fixes: 078df640ef05 ("wifi: iwlwifi: mld: add support for iwl_mcc_allowed_ap_type_cmd v2")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260529085453.9af349ab459b.I348df3980764c15efce0099a35fe8a88fb2a6ee2@changeid
2 weeks agowifi: iwlwifi: mld: send tx power constraints before link activation
Pagadala Yesu Anjaneyulu [Fri, 29 May 2026 05:57:06 +0000 (08:57 +0300)] 
wifi: iwlwifi: mld: send tx power constraints before link activation

TX power constraints must be sent to the firmware before link
activation. If not, the firmware will use default power values.

Fix this by moving the iwl_mld_send_ap_tx_power_constraint_cmd()
call from iwl_mld_start_ap_ibss() to iwl_mld_assign_vif_chanctx(),
before iwl_mld_activate_link() for AP interfaces. Also update
the guard in the function to allow it to run before link activation
for AP interfaces.

Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260529085453.06c94b01efd2.Id43bdfe5eb030061c23348779687ba71b5f58182@changeid
2 weeks agowifi: iwlwifi: mvm: don't support the reset handshake for old firmwares
Emmanuel Grumbach [Fri, 29 May 2026 05:57:05 +0000 (08:57 +0300)] 
wifi: iwlwifi: mvm: don't support the reset handshake for old firmwares

-77.ucode doesn't contain the fixes for this flow it seems.
Don't use the firmware reset handshake even if the firmware claims
support for it.

Fixes: 906d4eb84408 ("iwlwifi: support firmware reset handshake")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220600
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260529085453.9307b81d9b02.I21bba9e649f4cd0e35d3ea6cd97a03258be5832f@changeid
2 weeks agodriver core: remove driver_set_override()
Danilo Krummrich [Tue, 5 May 2026 13:37:25 +0000 (15:37 +0200)] 
driver core: remove driver_set_override()

All buses have been converted from driver_set_override() to the generic
driver_override infrastructure introduced in commit cb3d1049f4ea
("driver core: generalize driver_override in struct device").

Buses now either opt into the generic sysfs callbacks via the
bus_type::driver_override flag, or use device_set_driver_override() /
__device_set_driver_override() directly.

Thus, remove the now-unused driver_set_override() helper.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260505133935.3772495-6-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2 weeks agorpmsg: use generic driver_override infrastructure
Danilo Krummrich [Tue, 5 May 2026 13:37:24 +0000 (15:37 +0200)] 
rpmsg: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]

Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/
Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Fixes: e95060478244 ("rpmsg: Introduce a driver override mechanism")
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260505133935.3772495-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2 weeks agoDrivers: hv: vmbus: use generic driver_override infrastructure
Danilo Krummrich [Tue, 5 May 2026 13:37:23 +0000 (15:37 +0200)] 
Drivers: hv: vmbus: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]

Tested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/
Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Fixes: d765edbb301c ("vmbus: add driver_override support")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260505133935.3772495-4-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2 weeks agocdx: use generic driver_override infrastructure
Danilo Krummrich [Tue, 5 May 2026 13:37:22 +0000 (15:37 +0200)] 
cdx: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]

Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/
Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Fixes: 2959ab247061 ("cdx: add the cdx bus driver")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260505133935.3772495-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>