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