Hello,

The reserved memory regions handling code was reworked to handle
unlimited so called "static" memory nodes in commit 00c9a452a235 ("of:
reserved_mem: Add code to dynamically allocate reserved_mem array").

The side effect of this rework was a set of bugs fixed later by commits
0fd17e598333 ("of: reserved_mem: Allow reserved_mem framework detect
"cma=" kernel param") and 2c223f7239f3 ("of: reserved_mem: Restructure
call site for dma_contiguous_early_fixup()"). As a result, the code in
drivers/of/of_reserved_mem.c became a mix of generic code and CMA
specific fixups.

In this patchset I try to untangle this spaghetti and perform some code
cleanup. I hope nothing breaks this time.

Best regards
Marek Szyprowski, PhD
Samsung R&D Institute Poland


Changelog:

v2:
- added missing ops assignment removal in tegra210-emc-table and swiotlb
  drivers
- fixed issues pointed by kernel test robot and Sashiko: removed typos,
  improved comments
- fixed incorrect node passed to fdt_validate_reserved_mem_node() in
  fdt_scan_reserved_mem_reg_nodes()

v1: https://lore.kernel.org/all/20260313150802.1121442-1-m.szyprowski@samsung.com/
- initial version


Patch summary:

Marek Szyprowski (7):
  of: reserved_mem: remove fdt node from the structure
  of: reserved_mem: use -ENODEV instead of -ENOENT
  of: reserved_mem: switch to ops based OF_DECLARE()
  of: reserved_mem: replace CMA quirks by generic methods
  of: reserved_mem: rearrange code a bit
  of: reserved_mem: clarify fdt_scan_reserved_mem*() functions
  of: reserved_mem: rework fdt_init_reserved_mem_node()

 drivers/memory/tegra/tegra210-emc-table.c |  19 +-
 drivers/of/fdt.c                          |   2 +-
 drivers/of/of_private.h                   |   2 +-
 drivers/of/of_reserved_mem.c              | 318 +++++++++++++---------
 include/linux/cma.h                       |  10 -
 include/linux/dma-map-ops.h               |   3 -
 include/linux/of_reserved_mem.h           |  18 +-
 kernel/dma/coherent.c                     |  19 +-
 kernel/dma/contiguous.c                   |  86 ++++--
 kernel/dma/swiotlb.c                      |  19 +-
 10 files changed, 285 insertions(+), 211 deletions(-)

-- 
2.34.1

On Mon, 23 Mar 2026 11:08:54 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> The reserved memory regions handling code was reworked to handle
> unlimited so called "static" memory nodes in commit 00c9a452a235 ("of:
> reserved_mem: Add code to dynamically allocate reserved_mem array").
> 
> The side effect of this rework was a set of bugs fixed later by commits
> 0fd17e598333 ("of: reserved_mem: Allow reserved_mem framework detect
> "cma=" kernel param") and 2c223f7239f3 ("of: reserved_mem: Restructure
> call site for dma_contiguous_early_fixup()"). As a result, the code in
> drivers/of/of_reserved_mem.c became a mix of generic code and CMA
> specific fixups.
> 
> In this patchset I try to untangle this spaghetti and perform some code
> cleanup. I hope nothing breaks this time.

AI review wasn't able to get all the patches to apply, but it asked a
few questions:

	https://sashiko.dev/#/patchset/20260323100901.4079171-1-m.szyprowski@samsung.com

On Mon, Mar 23, 2026 at 3:18 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 23 Mar 2026 11:08:54 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> > The reserved memory regions handling code was reworked to handle
> > unlimited so called "static" memory nodes in commit 00c9a452a235 ("of:
> > reserved_mem: Add code to dynamically allocate reserved_mem array").
> >
> > The side effect of this rework was a set of bugs fixed later by commits
> > 0fd17e598333 ("of: reserved_mem: Allow reserved_mem framework detect
> > "cma=" kernel param") and 2c223f7239f3 ("of: reserved_mem: Restructure
> > call site for dma_contiguous_early_fixup()"). As a result, the code in
> > drivers/of/of_reserved_mem.c became a mix of generic code and CMA
> > specific fixups.
> >
> > In this patchset I try to untangle this spaghetti and perform some code
> > cleanup. I hope nothing breaks this time.
>
> AI review wasn't able to get all the patches to apply, but it asked a
> few questions:
>
>         https://sashiko.dev/#/patchset/20260323100901.4079171-1-m.szyprowski@samsung.com

Now I get these in several reviews. Just posting links here really
doesn't flow with the review process. How are we supposed to answer
when AI is wrong? Manually quote everything? No thanks.

To answer this one, I think 1 comment is wrong, 1 is right, and 1 I'm
not sure about.

Don't get me wrong, I think this all looks promising. I know email
support is planned, but please get that in place before sending
reports. Really, I'd rather just get the emails or mbox to review
first and then decide what to send for things I maintain. At least
initially.

Rob

On Tue, 24 Mar 2026 20:49:14 -0500 Rob Herring <robh@kernel.org> wrote:

> On Mon, Mar 23, 2026 at 3:18 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Mon, 23 Mar 2026 11:08:54 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> >
> > > The reserved memory regions handling code was reworked to handle
> > > unlimited so called "static" memory nodes in commit 00c9a452a235 ("of:
> > > reserved_mem: Add code to dynamically allocate reserved_mem array").
> > >
> > > The side effect of this rework was a set of bugs fixed later by commits
> > > 0fd17e598333 ("of: reserved_mem: Allow reserved_mem framework detect
> > > "cma=" kernel param") and 2c223f7239f3 ("of: reserved_mem: Restructure
> > > call site for dma_contiguous_early_fixup()"). As a result, the code in
> > > drivers/of/of_reserved_mem.c became a mix of generic code and CMA
> > > specific fixups.
> > >
> > > In this patchset I try to untangle this spaghetti and perform some code
> > > cleanup. I hope nothing breaks this time.
> >
> > AI review wasn't able to get all the patches to apply, but it asked a
> > few questions:
> >
> >         https://sashiko.dev/#/patchset/20260323100901.4079171-1-m.szyprowski@samsung.com
> 
> Now I get these in several reviews. Just posting links here really
> doesn't flow with the review process. How are we supposed to answer
> when AI is wrong? Manually quote everything? No thanks.

yeah, I know, it's quite dorkward at present.

> To answer this one, I think 1 comment is wrong, 1 is right, and 1 I'm
> not sure about.

Well that's good.  Really good.

I view Sashiko as a tool mainly for authors - view it as checkpatch on
steroids.  Reviewers will probably choose to take a pass if it appears
that the AI activity will result in a new version.

> Don't get me wrong, I think this all looks promising. I know email
> support is planned, but please get that in place before sending
> reports. Really, I'd rather just get the emails or mbox to review
> first and then decide what to send for things I maintain. At least
> initially.

"at least initially" is what we've got!  Be chill, it'll happen.