Hi Conor and Krzysztof, On Wed, 2023-05-17 at 13:37 +0100, Conor Dooley wrote: > Hey, > > On Wed, May 17, 2023 at 02:10:53PM +0200, Krzysztof Kozlowski wrote: > > On 17/05/2023 13:38, Steen Hegelund wrote: > > > Hi Krzysztof, > > > > > > I would love to do that, but I am not familiar with the procedure, so > > > maybe you > > > could help me out? > > > > Hm, there is no dedicated maintainer for Microchip ARM64 platforms? I > > mean one which actually handles the patches? > > > > It looks like it, because my recent changes were going through me. This > > also means that maybe several other changes got ignored. For example: > > Aye and the branches etc in the repo itself are all a wee bit stale. > > > > This is my understanding of what I need to do: > > > > > > Clone the upstream repo listed in MAINTAINERS: > > > > > > git clone git@xxxxxxxxxx:microchip-ung/linux-upstream.git > > > cd linux-upstream > > > git checkout sparx5-next > > > > > > Fetch the latest mainline tag from upstream: > > > > > > git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > tag\ > > > v6.4-rc2 --no-tags > > > > > > Rebase the current branch on top of that tag: > > > > > > git rebase v6.4-rc2 > > > > > > Use b4 to fetch and apply the mail thread patch series: > > > > > > b4 shazam -tsl 20230421223155.115339-1-krzysztof.kozlowski@xxxxxxxxxx > > > > You should collect some more patches... For one patch it is probably too > > much effort. I can take it instead. > > > > > Tag the current work for inclusion in the next kernel version with a > > > decription: > > > > > > git tag -s sparx5-dt-6.5 > > > > git tag -a -s sparx5-dt-6.5 > > > > Because you need to provide some explanation. Take a look at examples > > from other sub-arch maintainers what to write in the tag: > > > > https://lore.kernel.org/soc/20230410170233.5931-1-andersson@xxxxxxxxxx/T/#u > > > > https://lore.kernel.org/soc/20230405080438.156805-1-krzysztof.kozlowski@xxxxxxxxxx/T/ > > > > > > > > Push work that to the public repo: > > > > > > git push origin sparx5-dt-6.5 > > > > > > Create a pull request (to stdout) to be included in an email to the > > > maintainers: > > > > > > git request-pull v6.4-rc2 origin sparx5-dt-6.5 > > > > > > Send this PR to the maintainers and CC co-maintainers. > > > > > > Is this the correct procedure? > > > Who should I send the PR email to (is there a list somewhere)? > > > > Yes, it's correct with few nits I mentioned. > > > > You send it to arm@, soc@, Olof and Arnd. Addresses are in examples above. > > > > I will be preparing today the pull with various cleanups for arm-soc, so > > I will take the patch if you do not mind. Absolutely - and I am glad that I at least got to a point where I understand the procedure, but as changes are far between, I was not aware that I had some responsibilities here. Thanks for the clarification! > > > > For future (and all previous patches), please think what do you > > (you=Microchip) want to do with it. If you do not handle the patches, > > then someone should or the platform should be marked as "Odd fixes". > > If noone is set up to actually be the maintainer of the tree, and the > patch volume is low, it might be a good idea to combine its maintenance > with some of the other microchip trees. > > I've added Nicolas to CC here, since he is the main maintainer for the > 32-bit ARM Microchip stuff. For some context, I maintain the RISC-V > Microchip bits and a few other things like dt-bindings and some > non-microchip RISC-V platforms. > > If you like, I could easily pick up patches for > arch/arm64/boot/dts/microchip/* as I am already sending PRs to Arnd for > other trees and another branch would not be much overhead! > > Clearly I do not know the hardware at all, and reviewing the patches > would still be up to you, but I could handle the "administrative" side > of things (applying the patches & sending PRs) if that would be helpful? > > Otherwise, Nicolas & I could probably help you through setting things up > to send PRs without taking up Krzysztof's time? > > Either works for me! It would be preferable for me if you (Conor) would handle the arch/arm64/boot/dts/microchip/* tree as you suggested. It is not often we update it, so it will hopefully be low overhead for you. > > Thanks, > Conor. Thanks to both of you for the assistance. Best Regards Steen
