Re: [PATCH] of/platform: Don't include reserved memory compatibles that aren't needed

[Daniel Palmer]

Hi Krzysztof,

On Wed, 1 Apr 2026 at 19:54, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On Wed, Apr 01, 2026 at 06:57:35AM +0900, Daniel Palmer wrote:
> > There are a number of very platform specific compatibles for reserved
> > memory that the vast majority of people don't need and they waste
> > 196/200 bytes each.
>
> We don't want #ifdefs in the code because they are more difficult to
> maintain and review. Following your approach we would need to add such
> ifdefs in multiple other places, so I am not convinced it is worth.

I sort of disagree here. At the moment these compatibles are not
coupled to the code that uses them at all.
If that code gets deleted or moved for some reason, the Kconfig symbol
they belong to will disappear but since these compatibles aren't
coupled to them and are in a file on the other side of the kernel
it'll be easy to miss them.
If they are wrapped in something that links them back to where they
are used grep or whatever indexer can spot them.

> And this file should not be having different rules than rest of drivers.

There are other places with #ifdefs in match tables. It would be nice
if there was a nicer way to do it in C but there doesn't seem to be.
It would be nice if vendor specific stuff wasn't in the core code but
I don't see a nice way of fixing that either.
And if you want to see some of the more crazy examples of match tables
take a look here:
https://elixir.bootlin.com/linux/v7.0-rc6/source/drivers/cpufreq/cpufreq-dt-platdev.c

Since these matches are not the size of the compatible string but
actually 200 bytes on 64 bit machines the two megatables in that
driver will consume about 40K. It doesn't seem like much but DT is
being used by systems that have megabytes of RAM like a RISC-V
softcore on an FPGA. I think they might prefer to have a 40K of usable
memory over 40K of tables that don't contain any values that are
actually used on their machine ever... and it could be cleaned up
easily by wrapping each of the vendor specific chunks in the Kconfig
symbol for their platform.

Cheers,

Daniel