sunxi-6.6: Switch to v6.6.70

[The-going]

Description

• Re-extract all patches to v6.6.70
• Switch to v6.6.70

[rpardini]

Hey @The-going welcome back!

Could you experiment with running ./compile.sh BOARD=bananapi BRANCH=current rewrite-kernel-patches ?

This should normalize all patches again (From stanzas, Index ... stanzas, shortdiff format, signature, etc).

If you like the result you can squash it with the first commit -- that would reveal the diff-of-diffs to be much smaller.

In general, I don't mind the format sunxi follows, but since we've recently rewritten all the patches for all the families keeping it this way might make for easier PR reviews, as there would be less noise (changes to index stanzas, mostly).

If you don't like it, no problem -- I won't insist.

(To check, I did it for you, here's the commit -- it mostly adapts some patches but you can tell that most of the patches are actually unchanged if you normalize them.)

[The-going]

Could you experiment with running ./compile.sh BOARD=bananapi BRANCH=current rewrite-kernel-patches ?

I already tried to use this at the moment when significant changes were made in the mainline kernel in the files that we are changing with the help of patches.

The result was unsatisfactory.

I think I need to write a little explanation.
I use two scripts.
The first one is very simple. It reads the series file and applies the patches in a loop as a "git am" command.
If the command has not been applied or some patch pieces have been applied with an offset of more than 13 lines,
then the script stops and opens the patch file in a simple editor for viewing.
And I'm manually redoing the patch.
This saves me 99% of my mistakes.
This is almost the same as if we have a kernel repository with patches already applied and we do the command "git pull --rebase=true".

When all the patches are applied to the new kernel version, I extract them using the mk_format_patch script.

In order not to create noise, the script uses intelligent copying.
That is, it copies only those patch files that have real changes to the target folder.

I've been using this for about ten years to work with a large number of fixes (several thousand).

[The-going]

(To check, I did it for you, here's the commit -- it mostly adapts some patches but you can tell that most of the patches are actually unchanged if you normalize them.)

Some of these changes raise questions and doubts for me when simply viewing them.
But I don't usually do that.
I am applying patches to the core in one branch.
I apply another set in the same repository, but to a different branch, and then compare the two branches with the patches already applied.

My deep conviction is that it is impossible to automate the part of the work that requires human attention.

[rpardini]

Well, I tried -- good luck!