[GIT PULL 0/4] Renesas SoC updates for v7.1

[GIT PULL 0/4] Renesas SoC updates for v7.1

[Geert Uytterhoeven]

	Hi SoC folks,

This is my first pull request for the inclusion of Renesas SoC updates
for v7.1.

It consists of 4 parts:

  [GIT PULL 1/4] Renesas ARM defconfig updates for v7.1

    - Refresh the ARM SH-Mobile defconfig for v7.0-rc1.

  [GIT PULL 2/4] Renesas driver updates for v7.1

    - Initial support for the Renesas RZ/G3L (R9A08G046) SoC.

  [GIT PULL 3/4] Renesas DT binding updates for v7.1

    - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L
      SMARC SoM and Carrier-II EVK boards.

  [GIT PULL 4/4] Renesas DTS updates for v7.1

    - Add CPU frequency scaling and QSPI NOR FLASH support on the RZ/N1
      SoC and the RZN1D-DB development board,
    - Add PCIe slot power control on the R-Car H3, M3-W(+), M3-N, and E3
      SoCs,
    - Add USB3.0 PHY support on the R-Car E3 SoC and the Ebisu development
      board,
    - Add PCIe/USB3.0 clock generator support on the Salvator-X(S), ULCB
      King Fisher extension, and Ebisu development boards,
    - Add RTC support on the RZ/V2N SoC and its EVK board,
    - Add SPI DMA support on the RZ/T2H, RZ/N2H, RZ/V2H(P), and RZ/V2N
      SoCs,
    - Add support for the second SDHI channel on the Atmark Techno
      Armadillo-800-EVA board,
    - Miscellaneous fixes and improvements.

Note that the fourth PR is based on "[GIT PULL] Renesas SoC fixes for
v7.0".

Thanks for pulling!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[GIT PULL 1/4] Renesas ARM defconfig updates for v7.1

[Geert Uytterhoeven]

The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:

  Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-defconfig-for-v7.1-tag1

for you to fetch changes up to 8c6cccefb33e20224ef35497e3f55ee360942f14:

  ARM: shmobile: defconfig: Refresh for v7.0-rc1 (2026-03-06 13:42:09 +0100)

----------------------------------------------------------------
Renesas ARM defconfig updates for v7.1

  - Refresh the ARM SH-Mobile defconfig for v7.0-rc1.

----------------------------------------------------------------
Geert Uytterhoeven (1):
      ARM: shmobile: defconfig: Refresh for v7.0-rc1

 arch/arm/configs/shmobile_defconfig | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

[GIT PULL 2/4] Renesas driver updates for v7.1

[Geert Uytterhoeven]

The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:

  Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v7.1-tag1

for you to fetch changes up to b1de9823fdc67a8e9cd0dcf1f6f0e9780d425d4e:

  soc: renesas: rz-sysc: Add SoC identification for RZ/G3L SoC (2026-03-06 13:40:12 +0100)

----------------------------------------------------------------
Renesas driver updates for v7.1

  - Initial support for the Renesas RZ/G3L (R9A08G046) SoC.

----------------------------------------------------------------
Biju Das (1):
      soc: renesas: rz-sysc: Add SoC identification for RZ/G3L SoC

 drivers/soc/renesas/Kconfig          | 12 +++++
 drivers/soc/renesas/Makefile         |  1 +
 drivers/soc/renesas/r9a08g046-sysc.c | 91 ++++++++++++++++++++++++++++++++++++
 drivers/soc/renesas/rz-sysc.c        |  3 ++
 drivers/soc/renesas/rz-sysc.h        |  1 +
 5 files changed, 108 insertions(+)
 create mode 100644 drivers/soc/renesas/r9a08g046-sysc.c

[GIT PULL 3/4] Renesas DT binding updates for v7.1

[Geert Uytterhoeven]

The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:

  Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dt-bindings-for-v7.1-tag1

for you to fetch changes up to 3ac4e6b92fc200e047d13aae06224b2a72539b9e:

  dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC (2026-03-06 13:38:54 +0100)

----------------------------------------------------------------
Renesas DT binding updates for v7.1

  - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L
    SMARC SoM and Carrier-II EVK boards.

----------------------------------------------------------------
Biju Das (2):
      dt-bindings: soc: renesas: Document RZ/G3L SoC variants, SMARC SoM and Carrier-II EVK
      dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC

 .../devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml |  1 +
 Documentation/devicetree/bindings/soc/renesas/renesas.yaml  | 13 +++++++++++++
 2 files changed, 14 insertions(+)

Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1

[Krzysztof Kozlowski]

On Fri, Mar 13, 2026 at 12:12:59PM +0100, Geert Uytterhoeven wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
> 
>   Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dt-bindings-for-v7.1-tag1
> 
> for you to fetch changes up to 3ac4e6b92fc200e047d13aae06224b2a72539b9e:
> 
>   dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC (2026-03-06 13:38:54 +0100)
> 
> ----------------------------------------------------------------
> Renesas DT binding updates for v7.1
> 
>   - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L
>     SMARC SoM and Carrier-II EVK boards.
> 
> ----------------------------------------------------------------
> Biju Das (2):
>       dt-bindings: soc: renesas: Document RZ/G3L SoC variants, SMARC SoM and Carrier-II EVK

This is DTS branch patch.

>       dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC

This is drivers. Splitting it into additional branch is not making it
easier. I don't know where is this supposed to be merged. I will take it
to drivers, but in the future, please do not put DTS bindings into
driver bindings.

See also submitting patches in DT dir.

Best regards,
Krzysztof

Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1

[Geert Uytterhoeven]

Hi Krzysztof,

Thanks for your comments!

On Sat, 14 Mar 2026 at 12:09, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Mar 13, 2026 at 12:12:59PM +0100, Geert Uytterhoeven wrote:
> > Renesas DT binding updates for v7.1
> >
> >   - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L
> >     SMARC SoM and Carrier-II EVK boards.
> >
> > ----------------------------------------------------------------
> > Biju Das (2):
> >       dt-bindings: soc: renesas: Document RZ/G3L SoC variants, SMARC SoM and Carrier-II EVK
>
> This is DTS branch patch.

It is a DT bindings patch.

> >       dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC
>
> This is drivers. Splitting it into additional branch is not making it
> easier. I don't know where is this supposed to be merged. I will take it
> to drivers, but in the future, please do not put DTS bindings into
> driver bindings.

This is also a DT bindings patch.

DT bindings are soft dependencies for drivers and DTS.
DT binding definitions (I don't have any this time) are hard
dependencies for drivers, DTS, and examples and DT bindings.
Arnd merges dt-bindings PRs in the soc DTS branch.

> See also submitting patches in DT dir.

So the second commit is subject to II.3:

  3) For a series going through multiple trees, the binding patch should be
     kept with the driver using the binding.

In this particular case, I could have included it in my drivers branch.
Where do I put SoC-specific DT binding changes that are not picked
up by anyone else (I don't have any this time)?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1

[Krzysztof Kozlowski]

On 16/03/2026 09:51, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> Thanks for your comments!
> 
> On Sat, 14 Mar 2026 at 12:09, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Fri, Mar 13, 2026 at 12:12:59PM +0100, Geert Uytterhoeven wrote:
>>> Renesas DT binding updates for v7.1
>>>
>>>   - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L
>>>     SMARC SoM and Carrier-II EVK boards.
>>>
>>> ----------------------------------------------------------------
>>> Biju Das (2):
>>>       dt-bindings: soc: renesas: Document RZ/G3L SoC variants, SMARC SoM and Carrier-II EVK
>>
>> This is DTS branch patch.
> 
> It is a DT bindings patch.

I speak about branches. You quoted submitting patches in DT, but that is
implied. I already know it, I was making changes there and I already use
that document as arguments in multiple discussion, so please assume I
know it and my comments reflect that knowledge. I actually assumed that
you also knew it.

DT binding patch should go with the patch using the binding. So DT
binding for board is clearly a DTS branch patch.

> 
>>>       dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC
>>
>> This is drivers. Splitting it into additional branch is not making it
>> easier. I don't know where is this supposed to be merged. I will take it
>> to drivers, but in the future, please do not put DTS bindings into
>> driver bindings.
> 
> This is also a DT bindings patch.

But for which code? Driver or DTS?

> 
> DT bindings are soft dependencies for drivers and DTS.
> DT binding definitions (I don't have any this time) are hard
> dependencies for drivers, DTS, and examples and DT bindings.
> Arnd merges dt-bindings PRs in the soc DTS branch.

Then this should not be a separate branch, because:

1. No benefits - you did not solve any soft dependency. Your DTS branch
is non-bisectable from dtbs_check point of view and you as maintainer of
that tree should try to make it bisectable, meaning: "bindings go before
user" like explained in what you quoted further.

And please also read rest of submitting patches, although it is in part
for "submitters" but explains the concept:

" 5) The Documentation/ portion of the patch should come in the series
before the code implementing the binding."

"6) Any compatible strings used in a chip or board DTS file must be
previously documented in the corresponding DT binding file"

Previously means "before", so your DTS branch is failing above.

2. It is additional effort to handle this, because instead of merging
one branch, I need to merge two.

> 
>> See also submitting patches in DT dir.
> 
> So the second commit is subject to II.3:
> 
>   3) For a series going through multiple trees, the binding patch should be
>      kept with the driver using the binding.
> 
> In this particular case, I could have included it in my drivers branch.
> Where do I put SoC-specific DT binding changes that are not picked
> up by anyone else (I don't have any this time)?

What is "SoC-specific"? You put the DT binding with the user, that was
always the rule and that is implied by submitting patches. If you do not
have any user, why would you pick that up?

Best regards,
Krzysztof

Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1

[Krzysztof Kozlowski]

On 17/03/2026 10:29, Krzysztof Kozlowski wrote:
> 
>>
>>> See also submitting patches in DT dir.
>>
>> So the second commit is subject to II.3:
>>
>>   3) For a series going through multiple trees, the binding patch should be
>>      kept with the driver using the binding.
>>
>> In this particular case, I could have included it in my drivers branch.
>> Where do I put SoC-specific DT binding changes that are not picked
>> up by anyone else (I don't have any this time)?
> 
> What is "SoC-specific"? You put the DT binding with the user, that was
> always the rule and that is implied by submitting patches. If you do not
> have any user, why would you pick that up?

Actually I want to correct myself or explain more. If you document ABI
for existing driver with DTS user of the ABI, but without driver change,
e.g. new front compatible when using already documented fallback, I
would keep the change in the driver branch, even  though technically the
DTS is the user of new compatible. That is what I was always doing at least.

Why? Because I expect there might be a next patchset with binding+driver
adding new fallback to the same binding, which would have to go via
driver branch because of mentioned submitting patches rule. Therefore if
I put that first binding in DTS branch and in the future I want to put
next change in the driver branch I would have unnecessary conflicts.


Best regards,
Krzysztof

Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1

[Arnd Bergmann]

On Tue, Mar 17, 2026, at 10:53, Krzysztof Kozlowski wrote:
> On 17/03/2026 10:29, Krzysztof Kozlowski wrote:
>>>> See also submitting patches in DT dir.
>>>
>>> So the second commit is subject to II.3:
>>>
>>>   3) For a series going through multiple trees, the binding patch should be
>>>      kept with the driver using the binding.
>>>
>>> In this particular case, I could have included it in my drivers branch.
>>> Where do I put SoC-specific DT binding changes that are not picked
>>> up by anyone else (I don't have any this time)?
>> 
>> What is "SoC-specific"? You put the DT binding with the user, that was
>> always the rule and that is implied by submitting patches. If you do not
>> have any user, why would you pick that up?
>
> Actually I want to correct myself or explain more. If you document ABI
> for existing driver with DTS user of the ABI, but without driver change,
> e.g. new front compatible when using already documented fallback, I
> would keep the change in the driver branch, even  though technically the
> DTS is the user of new compatible. That is what I was always doing at least.
>
> Why? Because I expect there might be a next patchset with binding+driver
> adding new fallback to the same binding, which would have to go via
> driver branch because of mentioned submitting patches rule. Therefore if
> I put that first binding in DTS branch and in the future I want to put
> next change in the driver branch I would have unnecessary conflicts.

Right, this makes sense, though I've been rather relaxed about binding
updates in the past, merging them either through the soc/drivers
branches if they came with the driver changes, or through the soc/dt
branch otherwise.

       Arnd

[GIT PULL 4/4] Renesas DTS updates for v7.1

[Geert Uytterhoeven]

The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:

  arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v7.1-tag1

for you to fetch changes up to 0928a28daf017504e14920f4131bb99e3bc39dba:

  ARM: dts: renesas: armadillo800eva: Add wakeup-source to st1232 (2026-03-13 11:00:48 +0100)

----------------------------------------------------------------
Renesas DTS updates for v7.1

  - Add CPU frequency scaling and QSPI NOR FLASH support on the RZ/N1
    SoC and the RZN1D-DB development board,
  - Add PCIe slot power control on the R-Car H3, M3-W(+), M3-N, and E3
    SoCs,
  - Add USB3.0 PHY support on the R-Car E3 SoC and the Ebisu development
    board,
  - Add PCIe/USB3.0 clock generator support on the Salvator-X(S), ULCB
    King Fisher extension, and Ebisu development boards,
  - Add RTC support on the RZ/V2N SoC and its EVK board,
  - Add SPI DMA support on the RZ/T2H, RZ/N2H, RZ/V2H(P), and RZ/V2N
    SoCs,
  - Add support for the second SDHI channel on the Atmark Techno
    Armadillo-800-EVA board,
  - Miscellaneous fixes and improvements.

Note that this PR is based on "[GIT PULL] Renesas SoC fixes for v7.0".

----------------------------------------------------------------
Cosmin Tanislav (2):
      arm64: dts: renesas: r9a09g077: Wire up DMA support for SPI
      arm64: dts: renesas: r9a09g087: Wire up DMA support for SPI

Geert Uytterhoeven (1):
      ARM: dts: renesas: r9a06g032-rzn1d400-db: Do not use underscores in node names

Herve Codina (Schneider Electric) (1):
      ARM: dts: renesas: r9a06g032: Add support for CPU frequency scaling

Lad Prabhakar (2):
      arm64: dts: renesas: r9a09g056: Add DMA support for RSPI channels
      arm64: dts: renesas: r9a09g057: Add DMA support for RSPI channels

Marek Vasut (10):
      arm64: dts: renesas: sparrow-hawk: Mark OTP and HSCIF0 pins as bootph-all
      arm64: dts: renesas: r8a77951: Describe PCIe root ports
      arm64: dts: renesas: r8a77960: Describe PCIe root ports
      arm64: dts: renesas: r8a77961: Describe PCIe root ports
      arm64: dts: renesas: r8a77965: Describe PCIe root ports
      arm64: dts: renesas: r8a77990: Describe PCIe root port
      arm64: dts: renesas: r8a77990: Add USB 3.0 PHY and USB3S0 clock nodes
      arm64: dts: renesas: salvator-common: Describe PCIe/USB3.0 clock generator
      arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generator
      arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator

Miquel Raynal (Schneider Electric) (1):
      ARM: dts: renesas: r9a06g032: Describe the QSPI controller

Ovidiu Panait (2):
      arm64: dts: renesas: r9a09g056: Add RTC node
      arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable RTC

Wolfram Sang (2):
      ARM: dts: renesas: r9a06g032-rzn1d400-db: Add QSPI node including NOR flash
      ARM: dts: renesas: r9a06g032-rzn1d400-db: Use interrupts for Micrel PHYs

bui duc phuc (2):
      ARM: dts: renesas: armadillo800eva: Enable SDHI1
      ARM: dts: renesas: armadillo800eva: Add wakeup-source to st1232

 .../boot/dts/renesas/r8a7740-armadillo800eva.dts   |  32 ++++++
 .../arm/boot/dts/renesas/r9a06g032-rzn1d400-db.dts | 111 +++++++++++++++++++--
 arch/arm/boot/dts/renesas/r9a06g032.dtsi           |  47 +++++++++
 arch/arm64/boot/dts/renesas/ebisu.dtsi             |  43 +++++++-
 arch/arm64/boot/dts/renesas/r8a77951.dtsi          |  20 ++++
 arch/arm64/boot/dts/renesas/r8a77960.dtsi          |  20 ++++
 arch/arm64/boot/dts/renesas/r8a77961.dtsi          |  20 ++++
 arch/arm64/boot/dts/renesas/r8a77965.dtsi          |  20 ++++
 arch/arm64/boot/dts/renesas/r8a77990.dtsi          |  27 +++++
 .../boot/dts/renesas/r8a779g3-sparrow-hawk.dts     |   5 +
 arch/arm64/boot/dts/renesas/r9a09g056.dtsi         |  36 +++++++
 .../boot/dts/renesas/r9a09g056n48-rzv2n-evk.dts    |   4 +
 arch/arm64/boot/dts/renesas/r9a09g057.dtsi         |  21 ++++
 arch/arm64/boot/dts/renesas/r9a09g077.dtsi         |  16 +++
 arch/arm64/boot/dts/renesas/r9a09g087.dtsi         |  16 +++
 arch/arm64/boot/dts/renesas/salvator-common.dtsi   |  28 +++++-
 arch/arm64/boot/dts/renesas/ulcb-kf.dtsi           |  21 +++-
 arch/arm64/boot/dts/renesas/ulcb.dtsi              |  13 +++
 18 files changed, 490 insertions(+), 10 deletions(-)

Re: [GIT PULL 4/4] Renesas DTS updates for v7.1

[Krzysztof Kozlowski]

On Fri, Mar 13, 2026 at 12:13:00PM +0100, Geert Uytterhoeven wrote:
> The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:
> 
>   arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v7.1-tag1
> 
> for you to fetch changes up to 0928a28daf017504e14920f4131bb99e3bc39dba:
> 
>   ARM: dts: renesas: armadillo800eva: Add wakeup-source to st1232 (2026-03-13 11:00:48 +0100)

Next analysis tells me:

Days in linux-next:
----------------------------------------
 1 | ++ (2)
 2 | ++++++ (6)
 3 |
 4 |
 5 | ++++++++++++++++++++++ (22)

Please keep non-fix patches in the next for at least 3 next releases, so
you are sure any community tests/complains reached you. It is
unreasonable to expect that community will test your for-next patch
immediately the next day.

I merged other pulls but this one I will leave for few days more.

Best regards,
Krzysztof

Re: [GIT PULL 4/4] Renesas DTS updates for v7.1

[Geert Uytterhoeven]

Hi Krzysztof,

On Sat, 14 Mar 2026 at 12:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Mar 13, 2026 at 12:13:00PM +0100, Geert Uytterhoeven wrote:
> > The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:
> >
> >   arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dts-for-v7.1-tag1
> >
> > for you to fetch changes up to 0928a28daf017504e14920f4131bb99e3bc39dba:
> >
> >   ARM: dts: renesas: armadillo800eva: Add wakeup-source to st1232 (2026-03-13 11:00:48 +0100)
>
> Next analysis tells me:
>
> Days in linux-next:
> ----------------------------------------
>  1 | ++ (2)
>  2 | ++++++ (6)
>  3 |
>  4 |
>  5 | ++++++++++++++++++++++ (22)
>
> Please keep non-fix patches in the next for at least 3 next releases, so
> you are sure any community tests/complains reached you. It is
> unreasonable to expect that community will test your for-next patch
> immediately the next day.

Sorry, you are just soo much quicker than Arnd ;-)

> I merged other pulls but this one I will leave for few days more.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 4/4] Renesas DTS updates for v7.1

[Krzysztof Kozlowski]

On 13/03/2026 12:13, Geert Uytterhoeven wrote:
> The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:
> 
>   arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)

Also nothing explains me what is this, IOW, why this is not RC1. Pull
request email has place at the beginning where you explain such things
and I can easily locate or understand the base.

Best regards,
Krzysztof

Re: [GIT PULL 4/4] Renesas DTS updates for v7.1

[Geert Uytterhoeven]

Hi Krzysztof,

On Sat, 14 Mar 2026 at 12:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 13/03/2026 12:13, Geert Uytterhoeven wrote:
> > The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:
> >
> >   arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)
>
> Also nothing explains me what is this, IOW, why this is not RC1. Pull
> request email has place at the beginning where you explain such things
> and I can easily locate or understand the base.

Let's readd the part you cut, which is also present in the cover letter:

> > Note that this PR is based on "[GIT PULL] Renesas SoC fixes for v7.0".

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 4/4] Renesas DTS updates for v7.1

[Krzysztof Kozlowski]

On 16/03/2026 09:18, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Sat, 14 Mar 2026 at 12:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 13/03/2026 12:13, Geert Uytterhoeven wrote:
>>> The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:
>>>
>>>   arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)
>>
>> Also nothing explains me what is this, IOW, why this is not RC1. Pull
>> request email has place at the beginning where you explain such things
>> and I can easily locate or understand the base.
> 
> Let's readd the part you cut, which is also present in the cover letter:
> 
>>> Note that this PR is based on "[GIT PULL] Renesas SoC fixes for v7.0".

Ah... no one reads cover letters :) so I expected that information here,
before the pull boilerplate. I guess this depends on scripting, so it's
fine. I will look for cover letters in the future.

Best regards,
Krzysztof

Re: [GIT PULL 4/4] Renesas DTS updates for v7.1

[Geert Uytterhoeven]

Hi Krzystof,

On Mon, 16 Mar 2026 at 09:22, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 16/03/2026 09:18, Geert Uytterhoeven wrote:
> > On Sat, 14 Mar 2026 at 12:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 13/03/2026 12:13, Geert Uytterhoeven wrote:
> >>> The following changes since commit 85c2601e2c2feb60980c7ca23de28c49472f61f1:
> >>>
> >>>   arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers (2026-03-06 13:15:21 +0100)
> >>
> >> Also nothing explains me what is this, IOW, why this is not RC1. Pull
> >> request email has place at the beginning where you explain such things
> >> and I can easily locate or understand the base.
> >
> > Let's readd the part you cut, which is also present in the cover letter:
> >
> >>> Note that this PR is based on "[GIT PULL] Renesas SoC fixes for v7.0".
>
> Ah... no one reads cover letters :) so I expected that information here,
> before the pull boilerplate. I guess this depends on scripting, so it's
> fine. I will look for cover letters in the future.

As I wrote above, it was also mentioned in the PR itself.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 0/4] Renesas SoC updates for v7.1

[Krzysztof Kozlowski]

On Fri, Mar 13, 2026 at 12:12:56PM +0100, Geert Uytterhoeven wrote:
> 	Hi SoC folks,
> 
> This is my first pull request for the inclusion of Renesas SoC updates
> for v7.1.
> 
> It consists of 4 parts:

I think pw-bot did not reply to any of these pulls, but I applied now
all of them.


Best regards,
Krzysztof

Re: [GIT PULL 0/4] Renesas SoC updates for v7.1

[Geert Uytterhoeven]

Hi Krzysztof,

On Tue, 17 Mar 2026 at 09:33, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Fri, Mar 13, 2026 at 12:12:56PM +0100, Geert Uytterhoeven wrote:
> > This is my first pull request for the inclusion of Renesas SoC updates
> > for v7.1.
> >
> > It consists of 4 parts:
>
> I think pw-bot did not reply to any of these pulls, but I applied now
> all of them.

That is correct: no replies from the pw-bot.
renesas-dts-for-v7.1-tag1 does not seem to be in soc/for-next yet,
perhaps you forgot to push? No need to confirm if that is true,
I'll notice tomorrow ;-)
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 0/4] Renesas SoC updates for v7.1

[Krzysztof Kozlowski]

On 17/03/2026 09:46, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Tue, 17 Mar 2026 at 09:33, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Fri, Mar 13, 2026 at 12:12:56PM +0100, Geert Uytterhoeven wrote:
>>> This is my first pull request for the inclusion of Renesas SoC updates
>>> for v7.1.
>>>
>>> It consists of 4 parts:
>>
>> I think pw-bot did not reply to any of these pulls, but I applied now
>> all of them.
> 
> That is correct: no replies from the pw-bot.
> renesas-dts-for-v7.1-tag1 does not seem to be in soc/for-next yet,
> perhaps you forgot to push? No need to confirm if that is true,

I pushed for-next a bit after this email.

The workflow is far from optimal, because it has two stages:
1. Iterate over each pull email, check, merge and eventually push only
this branch,

2. Merge to for-next and document the merges for internal
accounting/tracing. I guess I could merge it after each stage (1) above.

The bigger problem is lack of replies from pw-bot.


@Konstantin,
I use modified Rob's script to go over patch/pull queue in Patchwork:
https://patchwork.kernel.org/project/linux-soc/list/?state=*

I deal with them one-by-one, so when I finish merging, I want to be sure
that Patchwork status is updated, thus through the script I mark it
"Accepted".
Like this one:
https://patchwork.kernel.org/project/linux-soc/patch/cover.1773399675.git.geert+renesas@glider.be/

Around then - can be just before or after - I push the updated branch to
git.kernel.org. I fear that because the pull is manually updated in
Patchwork to "Accepted", pw-bot ignores it and does not send the
notification.

Is it feasible to change pw-bot so it will notify even if it is marked
as "Accepted"? Or any ideas how to change the flow to have both:
A. pw-bot reply,
B. Be 100% sure that Patchwork status is updated (allow my manual update
via script)?


Best regards,
Krzysztof

Re: [GIT PULL 0/4] Renesas SoC updates for v7.1

[Arnd Bergmann]

On Tue, Mar 17, 2026, at 10:11, Krzysztof Kozlowski wrote:
> On 17/03/2026 09:46, Geert Uytterhoeven wrote:
>
> @Konstantin,
> I use modified Rob's script to go over patch/pull queue in Patchwork:
> https://patchwork.kernel.org/project/linux-soc/list/?state=*
>
> I deal with them one-by-one, so when I finish merging, I want to be sure
> that Patchwork status is updated, thus through the script I mark it
> "Accepted".
> Like this one:
> https://patchwork.kernel.org/project/linux-soc/patch/cover.1773399675.git.geert+renesas@glider.be/
>
> Around then - can be just before or after - I push the updated branch to
> git.kernel.org. I fear that because the pull is manually updated in
> Patchwork to "Accepted", pw-bot ignores it and does not send the
> notification.
>
> Is it feasible to change pw-bot so it will notify even if it is marked
> as "Accepted"? Or any ideas how to change the flow to have both:
> A. pw-bot reply,
> B. Be 100% sure that Patchwork status is updated (allow my manual update
> via script)?

In my experience, the pw-bot reply always happens at the same time as
the update in the patchwork state, we either get both or nothing.

The way I've used it in the past was to let pw-bot handle the replies.
If anything was missing htere, I would know that I had to send a
manual reply and update the status.

I suspect that setting the status to Accepted first would stop this
from working, but right now the pwbot interaction appears to be
broken regardless of the status update, i.e. it only handles
patches but not pull requests at all.

Konstantin, this seems to have broken around the time you modified
pwbot to handle git:// URL rewrites earlier this year. Previously
it only ever caught commit messages that had the exact same URL
as the pull request message, IIRC you said that it should now handle
the case where a git:// URL gets turned into a https:// one, but
the actual result appears to be that no pull requests get matched
at all.

    Arnd

Re: [GIT PULL 0/4] Renesas SoC updates for v7.1

[Arnd Bergmann]

On Wed, Mar 18, 2026, at 13:56, Arnd Bergmann wrote:
> On Tue, Mar 17, 2026, at 10:11, Krzysztof Kozlowski wrote:
>> On 17/03/2026 09:46, Geert Uytterhoeven wrote:
>>
>> @Konstantin,
>> I use modified Rob's script to go over patch/pull queue in Patchwork:
>> https://patchwork.kernel.org/project/linux-soc/list/?state=*
>>
>> I deal with them one-by-one, so when I finish merging, I want to be sure
>> that Patchwork status is updated, thus through the script I mark it
>> "Accepted".
>> Like this one:
>> https://patchwork.kernel.org/project/linux-soc/patch/cover.1773399675.git.geert+renesas@glider.be/
>>
>> Around then - can be just before or after - I push the updated branch to
>> git.kernel.org. I fear that because the pull is manually updated in
>> Patchwork to "Accepted", pw-bot ignores it and does not send the
>> notification.
>>
>> Is it feasible to change pw-bot so it will notify even if it is marked
>> as "Accepted"? Or any ideas how to change the flow to have both:
>> A. pw-bot reply,
>> B. Be 100% sure that Patchwork status is updated (allow my manual update
>> via script)?
>
> In my experience, the pw-bot reply always happens at the same time as
> the update in the patchwork state, we either get both or nothing.
>
> The way I've used it in the past was to let pw-bot handle the replies.
> If anything was missing htere, I would know that I had to send a
> manual reply and update the status.
>
> I suspect that setting the status to Accepted first would stop this
> from working, but right now the pwbot interaction appears to be
> broken regardless of the status update, i.e. it only handles
> patches but not pull requests at all.
>
> Konstantin, this seems to have broken around the time you modified
> pwbot to handle git:// URL rewrites earlier this year. Previously
> it only ever caught commit messages that had the exact same URL
> as the pull request message, IIRC you said that it should now handle
> the case where a git:// URL gets turned into a https:// one, but
> the actual result appears to be that no pull requests get matched
> at all.

Update: this one did get marked as 'Accepted' by pwbot, and
it sent the reply, so either it's back to working correctly,
or there is something else that makes it only work sometimes:

https://patchwork.kernel.org/project/linux-soc/patch/20260316074150.GA2474723@rayden/

     Arnd