On Wed, Mar 18, 2026, at 16:27, Andreas Färber wrote:

On 18.03.26 15:28, Arnd Bergmann wrote:

quoted

quoted

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