[PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[Yu-Chun Lin]

The memory node unit-address should match the first address in the reg
property. Correct the unit-address from @40000 to @50000 to align with the
actual base address (0x50000) defined in the reg property.

Fixes: b095c27fc874 ("arm64: dts: realtek: Add Kent SoC and EVB device trees")
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
This patch series is sent to both Realtek and ARM SoC maintainers.
While Andreas Färber is listed as the Realtek maintainer, there has been
limited activity recently.
---
 arch/arm64/boot/dts/realtek/rtd1501s-phantom-8gb.dts    | 2 +-
 arch/arm64/boot/dts/realtek/rtd1861b-krypton-8gb.dts    | 2 +-
 arch/arm64/boot/dts/realtek/rtd1920s-smallville-4gb.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/realtek/rtd1501s-phantom-8gb.dts b/arch/arm64/boot/dts/realtek/rtd1501s-phantom-8gb.dts
index 09e544acfd34..e487622424f1 100644
--- a/arch/arm64/boot/dts/realtek/rtd1501s-phantom-8gb.dts
+++ b/arch/arm64/boot/dts/realtek/rtd1501s-phantom-8gb.dts
@@ -13,7 +13,7 @@ / {
 	compatible = "realtek,phantom", "realtek,rtd1501s";
 	model = "Realtek Phantom EVB Chromium (8GB)";
 
-	memory@40000 {
+	memory@50000 {
 		device_type = "memory";
 		reg = <0x0 0x50000 0x0 0x7ffb0000>,
 		      <0x0 0x8a100000 0x0 0xdef0000>,
diff --git a/arch/arm64/boot/dts/realtek/rtd1861b-krypton-8gb.dts b/arch/arm64/boot/dts/realtek/rtd1861b-krypton-8gb.dts
index 9c23d901c49c..f0f810ab8aa8 100644
--- a/arch/arm64/boot/dts/realtek/rtd1861b-krypton-8gb.dts
+++ b/arch/arm64/boot/dts/realtek/rtd1861b-krypton-8gb.dts
@@ -13,7 +13,7 @@ / {
 	compatible = "realtek,krypton", "realtek,rtd1861b";
 	model = "Realtek Krypton EVB (8GB)";
 
-	memory@40000 {
+	memory@50000 {
 		device_type = "memory";
 		reg = <0x0 0x50000 0x0 0x7ffb0000>,
 		      <0x0 0x8a100000 0x0 0xdef0000>,
diff --git a/arch/arm64/boot/dts/realtek/rtd1920s-smallville-4gb.dts b/arch/arm64/boot/dts/realtek/rtd1920s-smallville-4gb.dts
index 9fd6976e0d9b..375c18322c3b 100644
--- a/arch/arm64/boot/dts/realtek/rtd1920s-smallville-4gb.dts
+++ b/arch/arm64/boot/dts/realtek/rtd1920s-smallville-4gb.dts
@@ -13,7 +13,7 @@ / {
 	compatible = "realtek,smallville", "realtek,rtd1920s";
 	model = "Realtek Smallville EVB (4GB)";
 
-	memory@40000 {
+	memory@50000 {
 		device_type = "memory";
 		reg = <0x0 0x50000 0x0 0x7ffb0000>,
 		      <0x0 0x8a100000 0x0 0xdef0000>,
-- 
2.34.1

Re: [PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[Krzysztof Kozlowski]

On 18/03/2026 12:40, Yu-Chun Lin wrote:
> The memory node unit-address should match the first address in the reg
> property. Correct the unit-address from @40000 to @50000 to align with the
> actual base address (0x50000) defined in the reg property.
> 
> Fixes: b095c27fc874 ("arm64: dts: realtek: Add Kent SoC and EVB device trees")
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> This patch series is sent to both Realtek and ARM SoC maintainers.
> While Andreas Färber is listed as the Realtek maintainer, there has been
> limited activity recently.

Unfortunately nothing new, likely two years ago I was also complaining
on lack of maintenance on Realtek, but the solution is not to send
patches to soc@.

Solution to that would be to remove the platform, for example. Or work
on maintainership.

Did anyone from Realtek offered reviews to my patches posted 3 and 2
years ago? I don't see that.

Kent SoC was accepted under condition this will improve.

I drop this from soc patchwork and please do not send code for review
there, but either fix the lack of involvement from Realtek or let's drop
the platform if Realtek does not care.

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[Arnd Bergmann]

On Wed, Mar 18, 2026, at 12:46, Krzysztof Kozlowski wrote:
> On 18/03/2026 12:40, Yu-Chun Lin wrote:
>> The memory node unit-address should match the first address in the reg
>> property. Correct the unit-address from @40000 to @50000 to align with the
>> actual base address (0x50000) defined in the reg property.
>> 
>> Fixes: b095c27fc874 ("arm64: dts: realtek: Add Kent SoC and EVB device trees")
>> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
>> ---
>> This patch series is sent to both Realtek and ARM SoC maintainers.
>> While Andreas Färber is listed as the Realtek maintainer, there has been
>> limited activity recently.
>
> Unfortunately nothing new, likely two years ago I was also complaining
> on lack of maintenance on Realtek, but the solution is not to send
> patches to soc@.
>
> Solution to that would be to remove the platform, for example. Or work
> on maintainership.

They have already offered to take over maintainership, see

https://lore.kernel.org/lkml/3ab263bfa4904b428245152b83340363@realtek.com/

> Did anyone from Realtek offered reviews to my patches posted 3 and 2
> years ago? I don't see that.
>
> Kent SoC was accepted under condition this will improve.
>
> I drop this from soc patchwork and please do not send code for review
> there, but either fix the lack of involvement from Realtek or let's drop
> the platform if Realtek does not care.

As Andreas has not replied to the MAINTAINERS updated, I would
prefer to merge both that and this patch in the bugfix branch
for 7.0.

Krzysztof, can you also dig out your older patches and resend
those to James and Yu-Chun for review?

       Arnd

Re: [PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[Krzysztof Kozlowski]

On 18/03/2026 15:28, Arnd Bergmann wrote:
> 
> As Andreas has not replied to the MAINTAINERS updated, I would
> prefer to merge both that and this patch in the bugfix branch
> for 7.0.
> 
> Krzysztof, can you also dig out your older patches and resend
> those to James and Yu-Chun for review?

My old stuff is already merged, I funneled it via my cleanup pulls. :)

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[Andreas Färber]

On 18.03.26 15:28, Arnd Bergmann wrote:
> On Wed, Mar 18, 2026, at 12:46, Krzysztof Kozlowski wrote:
>> On 18/03/2026 12:40, Yu-Chun Lin wrote:
>>> The memory node unit-address should match the first address in the reg
>>> property. Correct the unit-address from @40000 to @50000 to align with the
>>> actual base address (0x50000) defined in the reg property.
>>>
>>> Fixes: b095c27fc874 ("arm64: dts: realtek: Add Kent SoC and EVB device trees")
>>> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
>>> ---
>>> This patch series is sent to both Realtek and ARM SoC maintainers.
>>> While Andreas Färber is listed as the Realtek maintainer, there has been
>>> limited activity recently.
>>
>> Unfortunately nothing new, likely two years ago I was also complaining
>> on lack of maintenance on Realtek, but the solution is not to send
>> patches to soc@.
>>
>> Solution to that would be to remove the platform, for example. Or work
>> on maintainership.
> 
> They have already offered to take over maintainership, see
> 
> https://lore.kernel.org/lkml/3ab263bfa4904b428245152b83340363@realtek.com/
> 
>> Did anyone from Realtek offered reviews to my patches posted 3 and 2
>> years ago? I don't see that.
>>
>> Kent SoC was accepted under condition this will improve.
>>
>> I drop this from soc patchwork and please do not send code for review
>> there, but either fix the lack of involvement from Realtek or let's drop
>> the platform if Realtek does not care.
> 
> As Andreas has not replied to the MAINTAINERS updated, I would
> prefer to merge both that and this patch in the bugfix branch
> for 7.0.

Sorry for that, still lacking time, but at least receiving now...

I'm happy in general for someone with more time taking over.

Last week I spoke with Realtek (at EW) about testing the newer SoCs.
As a reminder, the mainline removal of TEXT_OFFSET broke my ability to 
test the older SoCs that I had access to. I hear that Kent and other 
recent SoCs do not have the same bootloader limitations anymore.

We would need to consider moving me from M to R and possibly changing my 
email from .de to .com due to recurring quota overflows.

I.e., new maintainers would need to queue patches and send pull requests 
to soc then. Are they set up with GPG keys / kernel.org tree to actually 
take over on their own?

As for review, there was one other review discussion about ISO/Misc 
areas that I found concerning: Those areas have been clearly documented 
and (on the older SoCs I know) contained registers wildly lumped 
together (from kernel PoV), so that having them in DT and accessing via 
regmap seemed the best way to me, compared to trying to map individual 
words to specific drivers. My old branches may contain some example 
usage in queued but non-merged drivers. (Amlogic may also have similar 
concepts of always-on vs. PD-controlled peripherals grouped in DT?)

Another open thing would be help with mailing list moderation, if we 
want to continue using it. Any review responses by non-subscribers add 
to its moderation queue (plus any spam).

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany
Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

Re: [PATCH] arm64: dts: realtek: Fix memory node unit-address mismatch

[Arnd Bergmann]

On Wed, Mar 18, 2026, at 16:27, Andreas Färber wrote:
> On 18.03.26 15:28, Arnd Bergmann wrote:
>>>
>>> I drop this from soc patchwork and please do not send code for review
>>> there, but either fix the lack of involvement from Realtek or let's drop
>>> the platform if Realtek does not care.
>> 
>> As Andreas has not replied to the MAINTAINERS updated, I would
>> prefer to merge both that and this patch in the bugfix branch
>> for 7.0.
>
> Sorry for that, still lacking time, but at least receiving now...
>
> I'm happy in general for someone with more time taking over.
>
> Last week I spoke with Realtek (at EW) about testing the newer SoCs.
> As a reminder, the mainline removal of TEXT_OFFSET broke my ability to 
> test the older SoCs that I had access to. I hear that Kent and other 
> recent SoCs do not have the same bootloader limitations anymore.
>
> We would need to consider moving me from M to R and possibly changing my 
> email from .de to .com due to recurring quota overflows.

Ok, sounds good. Yu-Chun, can you send an updated patch for the maintainers file doing this?

> I.e., new maintainers would need to queue patches and send pull requests 
> to soc then. Are they set up with GPG keys / kernel.org tree to actually 
> take over on their own?

As I understand, the MAINTAINERS entry is one of the prerequisites
for getting a kernel.org account, so I would start with that.
I don't know whether they have signatures from anyone on the keyring
yet, but I'm sure that can be arranged.

> As for review, there was one other review discussion about ISO/Misc 
> areas that I found concerning: Those areas have been clearly documented 
> and (on the older SoCs I know) contained registers wildly lumped 
> together (from kernel PoV), so that having them in DT and accessing via 
> regmap seemed the best way to me, compared to trying to map individual 
> words to specific drivers. My old branches may contain some example 
> usage in queued but non-merged drivers. (Amlogic may also have similar 
> concepts of always-on vs. PD-controlled peripherals grouped in DT?)

Right, that makes sense, and this is consistent with how we use syscon on many platforms.

> Another open thing would be help with mailing list moderation, if we 
> want to continue using it. Any review responses by non-subscribers add 
> to its moderation queue (plus any spam).

Maybe just drop Moderation altogether then?

   Arnd