WIP sunxi 6.6: Cleaning up the patches before the changes. Swith to v6.6.72

[The-going]

Description

• revert commit changes e103e2e1daa2d
  Undo changes that are made massively and create a lot of noise.

• Remove unnecessary patch fixes, and also move the time-tested patch to the armbian series as permanently supported.

• Swith to v6.6.72

How Has This Been Tested?

• Test build for sunxi
• Test work on board
• Test build for sunxi64
• Test work on board Bananapi-M64 successful

[amazingfate]

I wonder why e103e2e is creating a lot of noise. Now the patches are looking worse after the revert.

[The-going]

I wonder why e103e2e is creating a lot of noise.

diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
index e9e828b6bb30..f003867f085a 100644
index 111111111111..222222222222 100644
--- a/arch/arm/kernel/patch.c
+++ b/arch/arm/kernel/patch.c

It's a noise. There are no changes.

Now the patches are looking worse after the revert.

Please provide an example.

[JohnTheCoolingFan]

I think @rpardini should should also be asked about this as the author of the PR that made that commit: #7651. There is a reason that PR was made and merged, though I do not have much experience with patches to understand the details, pros and cons.

We should decide which form is better and should be used, or else we could get stuck in going back-and-forth reverting and reapplying the same processes.

And also i think working with patches right now is a bit complicated, everyone has their own different workflow. Making a guide or just a page describing the best process in armbian documentation would help.

[amazingfate]

diff index hash in patch file is meaningless. If you use git am command to apply the patch, and then use command git format-patch to re-generate the patch, the hash value always changes when the base repo is updated. That's why rewrite-kernel-patches is always replacing the hash value to 000000000000, 111111111111 or 222222222222.

Armbian's build framework runs on many distributions with different git version, and the git version at the end of patch file is meaningless, so we replace it with Armbian.

It's recommendded that all patches should be re-formatted with rewrite-kernel-patches.

[The-going]

Explanations:
I don't like this patch format, but that's not the point.
Firstly, I am against any massive changes without subsequent testing.
The mechanism (rewrite-kernel-patches) by which these noisy changes were made sometimes misses, i.e. it applies changes to the wrong function or the wrong node for the DTS.
I've noticed this when the jump is long.
For example, 6.11.7 to 6.12.
These changes are very difficult to track and fix. In other words, spend a lot of time.
I've noticed this before for sunxi and rockchip64.
In this particular case, I was lucky.
There are no significant changes, only noise.
So I just go back before making my changes.

Maybe I just want to draw someone's attention to the problem
and at the same time not impose my patch technology on anyone.

If you use git am command to apply the patch, and then use command git format-patch to re-generate the patch

In order not to create noise, my script uses intelligent copying.
mk_format_patch ii_cp
call ii_cp

Explanations are here

[amazingfate]

Explanations:
I don't like this patch format, but that's not the point.
Firstly, I am against any massive changes without subsequent testing.
The mechanism (rewrite-kernel-patches) by which these noisy changes were made sometimes misses, i.e. it applies changes to the wrong function or the wrong node for the DTS.
I've noticed this when the jump is long.
For example, 6.11.7 to 6.12.
These changes are very difficult to track and fix. In other words, spend a lot of time.
I've noticed this before for sunxi and rockchip64.
In this particular case, I was lucky.
There are no significant changes, only noise.
So I just go back before making my changes.

Maybe I just want to draw someone's attention to the problem
and at the same time not impose my patch technology on anyone.

If you use git am command to apply the patch, and then use command git format-patch to re-generate the patch

In order not to create noise, my script uses intelligent copying.
mk_format_patch ii_cp
call ii_cp

Explanations are here

Your script ignores lines what rewrite- kernel-patches is overwriting, which should work exactly the same as rewrite-kernel-patches to show only the real changes of patch files.

Here is my opinion on whether overwriting or ignore hash values in patch files:
Hash values changes on every rebase, which make no sense when we keep updating the base kernel/uboot version. When adding/deleting patches the hash values also change. They only show the status of one series of patches for one specific source version. It's better to overwrite them in case they confuse anyone.

[The-going]

The first test build.
The linux-kernel-worktree/6.6__sunxi64__arm64 catalog size is 9 GB.
After cleaning (make ARCH=arm64 clean), the folder size is 1.3 GB.
If add EXTRAWIFI the linux-kernel-worktree/6.6__sunxi64__arm64 catalog size is 10.2 GB.