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

[Koen Vandeputte]

Hi Paul,

First of all, thank you for reviewing and testing the patch.


Let me share in detail how I prepare the kernel update patch:

- Pull the latest git state 3 times
- On two of them, I apply my custom .config and feeds for the hardware 
targets I use (1 for cns3xxx, 1 for imx6)
- On each of the 2 targets: Adapt the kernel-version.mk file to include 
the new kernel
- Do a full build (tools, toolchain, packages, ...)
- Run the following command: |"make target/linux/refresh V=s"|
--> which is instructed here: 
https://wiki.openwrt.org/doc/devel/patches#refreshing_patches
- From one of the build, copy all pathes from 
"target/linux/generic/patches-4.4" to the unused git source clone
- From each seperate build, copy all pathes from 
target/linux/"target"/patches-4.4 to the unused git source clone 
("target" being cns3xxx or imx6)
- Read all changes in git
- Commit + clearly specifiy it has been compiled/tested only on my 2 
targets.

(If anyone thinks this is not the correct approach, please provide 
feedback by all means!)


To be honest .. I share your opinion that it sometimes feels .. dangerous.
- Will it build on other targets except my 2?
- As some patches appear to lack refreshes, is something wrong with the 
refresh system? (I followed the previous discussion with the jump to 
kernel .30 extensively)



Personal thoughts regarding possible solutions:

1)
- Having a separate staging tree which is a copy of the main Source 
tree, but only used for updating/testing kernel updates.
This way different people using different targets could easily test a 
kernel update on their targets and reply if it's working or not. (and 
supply refresh-patches for target-specific kernel patches)
If all major targets are refreshed, tested & confirmed, it should be 
safer to merge it to main.

2)
- An alternate approach would be to create a script which auto-builds & 
refresh every possible target.
--> Huge workload for 1 person
--> Would still leave some targets untested (unless someone has all the 
time + hardware? :) )

3)
- When a kernel update patch is posted, it requires at least 2 
additional "tested-by"'s on different targets before it can be 
considered for merging. (Covering 5 .. 6 targets in total)


Any other ideas? anyone?



Thanks again,

Koen



On 2016-11-16 08:00, p.wassi at gmx.at wrote:
> As I've just sent in 4.4.32, I came across other changes from which
> I think they should have already been done in 4.4.31:
> /apm821xx/patches-4.4/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch
> /apm821xx/patches-4.4/802-usb-xhci-force-msi-renesas-xhci.patch
>
> Changes to xhci-pci.c were made upstream during release of 4.4.31 [1], which introduce
> two lines offset. Of course I know, that missing this refreshing doesn't break anything.
> However, it's not clear for me why some patches are refreshed, while others are not. This
> looks so indeterministic to me. Or am I still producing false positives?
>
> Best regards,
> P. Wassi
>
> [1]:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.31&id2=v4.4.30&dt=2
>
>> + Refresh patches
>> compile/run-tested on cns3xxx & imx6.
>>
>> Signed-off-by: Koen Vandeputte <koen.vandeputte at ncentric.com>
>> ---
>>   include/kernel-version.mk                                  |  4 ++--
>>   ...-override-creds-with-the-ones-from-the-superblock.patch |  6 +++---
>>   .../patches-4.4/052-01-ubifs-Implement-O_TMPFILE.patch     |  2 +-
>>   .../052-02-ubifs-Implement-RENAME_WHITEOUT.patch           | 14 +++++++-------
>>   .../052-03-ubifs-Implement-RENAME_EXCHANGE.patch           |  6 +++---
>>   ...ac-stop-clearing-DMA-receive-control-register-rig.patch |  9 ++-------
>>   .../linux/generic/patches-4.4/201-extra_optimization.patch |  4 ++--
>>   7 files changed, 20 insertions(+), 25 deletions(-)

-- 
Koen Vandeputte - Software Developer
koen.vandeputte at ncentric.com | +32499736158