[GIT PULL] RISC-V soc fixes for v7.0-rc1

[GIT PULL] RISC-V soc fixes for v7.0-rc1

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Hey folks,

Nothing super urgent here, but figured I'd send before -rc1 in case
there's a second new content PR this window and you can squeeze them
in. Otherwise, of course this can just go into whatever regular fixes
PR occurs later in the cycle.

Cheers,
Conor.

The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:

  Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ tags/riscv-soc-fixes-for-v7.0-rc1

for you to fetch changes up to 0528a348b04b327a4611e29589beb4c9ae81304a:

  cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() (2026-02-06 19:54:40 +0000)

----------------------------------------------------------------
RISC-V soc fixes for v7.0-rc1

drivers:
Fix leaks in probe/init function teardown code in three drivers.

microchip:
Fix a warning introduced by a recent binding change, that made resets
required on Polarfire SoC's CAN IP.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

----------------------------------------------------------------
Conor Dooley (1):
      riscv: dts: microchip: add can resets to mpfs

Felix Gu (2):
      cache: starfive: fix device node leak in starlink_cache_init()
      cache: ax45mp: Fix device node reference leak in ax45mp_cache_init()

Zilin Guan (1):
      soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()

 arch/riscv/boot/dts/microchip/mpfs.dtsi     |  2 ++
 drivers/cache/ax45mp_cache.c                |  4 ++--
 drivers/cache/starfive_starlink_cache.c     |  4 ++--
 drivers/soc/microchip/mpfs-sys-controller.c | 13 +++++++++----
 4 files changed, 15 insertions(+), 8 deletions(-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [GIT PULL] RISC-V soc fixes for v7.0-rc1

[Linus Walleij]

Hi Conor,

On Fri, Feb 13, 2026 at 1:20 PM Conor Dooley <conor@kernel.org> wrote:

> Conor Dooley (1):
>       riscv: dts: microchip: add can resets to mpfs
>
> Felix Gu (2):
>       cache: starfive: fix device node leak in starlink_cache_init()
>       cache: ax45mp: Fix device node reference leak in ax45mp_cache_init()
>
> Zilin Guan (1):
>       soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()

You have DTS fixes mixed up with cache/SoC fixes, this is
a bit unorthodox, is there some hard dependency or can you send
the DTS fix separately?

I guess we could also split it off manually ... I'm just a bit insecure
with that.

Yours,
Linus Walleij

Re: [GIT PULL] RISC-V soc fixes for v7.0-rc1

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Tue, Mar 03, 2026 at 09:15:14AM +0100, Linus Walleij wrote:
> Hi Conor,
> 
> On Fri, Feb 13, 2026 at 1:20 PM Conor Dooley <conor@kernel.org> wrote:
> 
> > Conor Dooley (1):
> >       riscv: dts: microchip: add can resets to mpfs
> >
> > Felix Gu (2):
> >       cache: starfive: fix device node leak in starlink_cache_init()
> >       cache: ax45mp: Fix device node reference leak in ax45mp_cache_init()
> >
> > Zilin Guan (1):
> >       soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()
> 
> You have DTS fixes mixed up with cache/SoC fixes, this is
> a bit unorthodox, is there some hard dependency or can you send
> the DTS fix separately?

There's no dependency of course, I'll split it out.
Ordinarily I would always split them, but I'd swear I was told at one
point that since fixes were on one branch in the soc tree that it was
okay for me to do the same. In this case I did it on one branch to be
less work to get onto a potential fixes PR that went out before -rc1.

> 
> I guess we could also split it off manually ... I'm just a bit insecure
> with that.
> 
> Yours,
> Linus Walleij

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [GIT PULL] RISC-V soc fixes for v7.0-rc1

[Linus Walleij]

On Tue, Mar 3, 2026 at 10:41 AM Conor Dooley <conor@kernel.org> wrote:

> There's no dependency of course, I'll split it out.
> Ordinarily I would always split them, but I'd swear I was told at one
> point that since fixes were on one branch in the soc tree that it was
> okay for me to do the same. In this case I did it on one branch to be
> less work to get onto a potential fixes PR that went out before -rc1.

You might be right about that, I'm learning myself.

Perhaps you know more about this process than me,
despite me being one of the SoC maintainers now :P

Let's see what the others say.

Yours,
Linus Walleij

Re: [GIT PULL] RISC-V soc fixes for v7.0-rc1

[Arnd Bergmann]

On Tue, Mar 3, 2026, at 10:51, Linus Walleij wrote:
> On Tue, Mar 3, 2026 at 10:41 AM Conor Dooley <conor@kernel.org> wrote:
>
>> There's no dependency of course, I'll split it out.
>> Ordinarily I would always split them, but I'd swear I was told at one
>> point that since fixes were on one branch in the soc tree that it was
>> okay for me to do the same. In this case I did it on one branch to be
>> less work to get onto a potential fixes PR that went out before -rc1.
>
> You might be right about that, I'm learning myself.
>
> Perhaps you know more about this process than me,
> despite me being one of the SoC maintainers now :P
>
> Let's see what the others say.

The pull requests for -next have to be split because they go
to torvalds as separate branches, but for bug fixes, I never
made this a rule so far.

I just merged Conor's PR before I saw this thread, and decided
not to undo the merge because it's fine for the current way we
send the upstream PRs.

We could consider changing the process though and having two
separate fixes branches for DT and non-DT changes, as I tend
to have to write two descriptions for one tag anyway, and
it would be more natural to send the fixes separately.

There are already some maintainers that send split fixes PRs
anyway, but we'd have to make sure to communicate it to everyone
before we make it a general requirement.

      Arnd