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

[Stijn Tintel]

On 16-11-16 09:54, Koen Vandeputte wrote:
> 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)
>
You should use the script, and trust the refresh mechanism over yourself.
>
>
> 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.

We already have this script, it was mentioned in a previous thread about
the subject.
> --> Huge workload for 1 person
> --> Would still leave some targets untested (unless someone has all
> the time + hardware? :) )
I've done this before, https://git.lede-project.org/8072264b. It took a
long time, but it's doable.
>
> 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(-)
>
I started the script to do this for 4.4.31, and I already have more
changes than you, so NAK. While I appreciate the effort, I would like to
ask you to not send these kind of patches anymore until you are sure you
completely understand what you are doing.

Thanks,
Stijn