[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

[Hannu Nyman]

p.wassi at gmx.at wrote on Wed Nov 2 03:12:32 PDT 2016:
 > What may be my problem here is, that I'm totally stuck to the kernel 
changelog, which leads to my question: is it the case, that the patches 
getting refreshed here are not directly related to the upstream kernel changes.

Being "stuck to the upstream kernel changelog" is not enough. From 
Openwrt/LEDE perspective, the kernel source is the original kernel source + 
the ~100 generic (=common to all platforms) local patches + the 10-50 
platform-specific patches for each of the ~50 supported platforms (ar71xx, 
mvebu, ...). So a lot of local patches in several separate quilt chains.

When doing a kernel version bump, you need to adjust the generic & platform 
patches for the upstream changes in the upstream kernel. Some features may 
also have been accepted/changed upstream in the main kernel, so the 
Openwrt/LEDE patch needs to be removed/changed etc.

It is also possible that some local features have been added in a not-perfect 
way since the last kernel bump, so that all local patches have not been 
adjusted correctly.

The patches in the quilt chain can be left unrefreshed for some time, and 
patches still apply with fuzz. But it is good practice to refresh them every 
now and then. That should be done latest at the next kernel version bump, 
like here.

Looks like this time 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=3764caa93478e3472df3128b79b6d0f6b0fb999c
changed target/linux/mvebu/patches-4.4/010-build_new_dtbs.patch (by adding 
the rango device) but did not adjust the later 
053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch accordingly (to 
take the added one new line into account). So, that patch 053- got refreshed 
now to match the new reality (of the added rango line by the current 010- ).

Yeah, there could be a separate "refresh patches for earlier changes" patch 
before the kernel bump, but that would just be additional work as the patches 
should be refreshed in any case at the kernel bump.