Upstream Linux TH1520 patch series

BeagleV
1

Maintainer Git Repos:

Palmer Dabbelt - (RISCV) - kernel/git/palmer/linux.git - palmer kernel tree - (v6.7.x-rc)
Conor Dooley - (dt) - kernel/git/conor/linux.git - conor's fork of linux.git - (v6.6-rc)

Mainline patch series:

Version SubSystem Patch series Notes
Patch v2 MMC [PATCH v2 0/7] RISC-V: Add eMMC support for TH1520 boards Todo: update to support microSD and SDIO
RFC 0 THEAD Clock [PATCH 0/3] Add T-HEAD th1520 soc clock support - Yangtao Li
RFC 2 dwmac driver [PATCH net-next v2 0/3] add the dwmac driver for T-HEAD TH1520 SoC - Jisheng Zhang
RFC 2 riscv: errata: improve T-Head CMO [PATCH v2 0/2] riscv: errata: improve T-Head CMO - Jisheng Zhang
RFC 0 riscv: dts: thead: set dma-noncoherent to soc bus [PATCH] riscv: dts: thead: set dma-noncoherent to soc bus - Jisheng Zhang
RFC 0 riscv: mm: update T-Head memory type definitions [PATCH] riscv: mm: update T-Head memory type definitions - Jisheng Zhang
RFC 0 Reset [RFC PATCH 0/3] Introduce reset driver for T-HEAD th1520 SoC

Staged for Mainline:

Version SubSystem Commit
x x x

Mainline Status:

Version SubSystem Commit
v6.6-rc1 riscv: dts: thead: add BeagleV Ahead board device tree kernel/git/torvalds/linux.git - Linux kernel source tree
v6.5 riscv: dts: add initial T-HEAD TH1520 SoC device tree kernel/git/torvalds/linux.git - Linux kernel source tree
3 Likes
2

4 posts were split to a new topic: Licheepi4a - 6.5.x mainline

4

Hey Drew, I would like to better understand the current upstream status. I am not so much familiar with the kernel development process, so I am going to ask you some very stupid questions now - feel free to answer, whenever you have the time and leisure

So first of all, why did you post Palmer Dabbelt’s and Conor Dooley’s Git repos here? Because they are maintainser of RISC-V ARCHITECTURE, and device tree, RISC-V MISC SOC SUPPORT respectively? So if anyone would want to submit patches, they should base these patches on Palmer’s and Conor’s repositories, because they have the most current status regarding the TH1520 support?

Then you post some “mainline patch series”, which I guess are patches commited to the mailing list, which are currently discussed and not yet accepted? So if anybody would want to know their current status, they would have to observer the patches’s threads on the mailing list? Then you also post some patches which are now mainline? I tried to retrace one of your patch series:

So for example here is the v3 of your patches, which add a minimal device tree for the TH1520: [PATCH v3 0/2] riscv: Add BeagleV Ahead board support

You submitted them to the mailing lists “linux-riscv, devicetree, linux-kernel”, correct? A few days later, Conor Dooley did then commit the v3 of your patch series into his git repository: kernel/git/conor/linux.git - conor's fork of linux.git

Again a few days later, Arnd Bergmann takes you changes and combines them with other changes to this here, again in Conor Dooley’s repository: kernel/git/conor/linux.git - conor's fork of linux.git What exactly is that? A new commit, I guess, with a specific preamble (“Merge Tag”) to mark this as “to be merged” into the linux kernel?

And again a few days later, Linux Torvalds commits these changes combined with even more changes into his kernel git repository: kernel/git/conor/linux.git - conor's fork of linux.git

So this is then the point where your changes are considered really being “upstream”? So from the “6.6” in the commit title, I can assume that means, those changes are then inside Kernel version 6.6? At least if I double check that via elixir (th1520-beaglev-ahead.dts - arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts - Linux source code (v6.6) - Bootlin) your dts file is there, but in 6.5 “This file does not exist.”

5

These all good questions and the flow of patches into the final release from Linus is quite complex. Also, I have done a bad job keeping this page updated. Furthermore, upon revisiting this page, I think this are changes I can make to make it more useful and easier to understand.

Also, I wrote a more recent post that covers some upstreaming aspects:

I should pull some of that into this post.

First, I should not have used Palmer’s repo. The riscv repo that Palmer maintains is:
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/

For patches that Palmer would apply (like /arch/riscv), it can be good to base them on kernel/git/riscv/linux.git - RISC-V Linux kernel tree

Altnernatively, you could based patches on linux-next:L
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/

This is general advice though. There may be situations in which it is simpler to base a patch series on some other public branch because it has prerequisite patches.

Conor’s repo can be helpful to base patches on depending on the type work being done. Conor does have:
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/log/?h=riscv-soc-for-next
and
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/log/?h=riscv-dt-for-next

Anyways, maintainers like Conor and Palmer will probably reply that one needs to rebase their patches if the currently used base for the patches is causing problems.

I’ve done a bad job updating the table. It should be more clear which have just been posted, which have been applied by a maintainer, and which are actually in a kernel release now.

That is a merge commit which shows what patches were pulled in by the sub-maintainers. In this case, Conor took the individual patches from the mailing list and applied them to their tree they use for pull requests. Then Conor sends a pull request to Arnd. Arnd ultimately does a pull request for all of SoC to Linus Torvalds.

Yes, I would it is “upstream” once Linus accepts a pull request containing the commit(s) and merges it into his master branch.

The main time when this takes place is during the merge window. This is the 2 weeks following the release of a new linux kernel.

The first release candidate (rc) should happen at the end of the merge window. The marks the first real release that contains the new commits. Technically, the new commits are not officially in Linux until the release candidate (rc) releases conclude and Linus officially releases the new kernel.