[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 at 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 at .
>>
>> 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)