Hi Linus,

Am Donnerstag, 7. Mai 2026, 15:24:38 Ostafrikanische Zeit schrieb Linus 
Walleij:
> Hi Stefan,
> 
> On Wed, May 6, 2026 at 7:39 PM Stefan Dösinger
> 
> <stefandoesinger@gmail.com> wrote:
> > I'll send a v8 with some of Sashiko's (very impressive)
> > findings but keep the defconfig.
> 
> Maybe not send all patches to soc@kernel.org right now because they
> end up in the patch tracker.

I meant send them to linux-arm-kernel@, not soc@ just yet.

I propose to hold off on adding the new SoC upstream until the clk and pinctrl 
drivers had at least an initial review. They are more complicated than this 
current patchset and they will be necessary to do anything useful with this 
SoC. I expect to send a first version of the clock driver over the weekend.

The important thing with the submission to this mailing list was to get 
feedback, so I avoid building a long set of patches on a shaky foundation.

> For a new platform that may be OK though...
> 
> Nominall it should be three pull requests:
> 1. Platform
> 2. DTS files
> 3. Defconfig

So I read https://docs.kernel.org/process/maintainer-soc.html a few times. If 
I understand it correctly at this point "pull request" still means emails sent 
with p4, correct? Or does someone create a git repository on git.kernel.org 
for me that I can use to send actual pull requests?

As I understand it, my 6 patches then go to the 4 corners of the kernel:

Patch 1 (dt binding) to devicetree@vger.kernel.org
Patches 2 (platform), 5 (DTS) and 6 (defconfig) to soc@kernel.org, but not in 
one series but 3 independent ones
Patches 3 and 4 (UART) to linux-serial@vger.kernel.org. I think this can and 
should be a series of both patches belonging together

It might make sense to send the DT binding on its way so it is in place when 
the SoC maintainers look at the patch that adds the new platform.

Do I understand the mechanics correctly?

Thanks,
Stefan