Upstream Linux TH1520 patch series

[DrewFustini]

@Kilian

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

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:

BeagleV Ahead development links

Hi, Do any of the above address the slow video driver when running Ubuntu?

I should pull some of that into this post.

@Kilian

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?

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.

@Kilian

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:

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.

@Kilian

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: riscv: dts: thead: add BeagleV Ahead board device tree - 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: Merge tag 'riscv-dt-for-v6.6-pt2' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/dt - 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?

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.

@Kilian

And again a few days later, Linux Torvalds commits these changes combined with even more changes into his kernel git repository: Merge tag 'soc-dt-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc - 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?

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.

@Kilian

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.”