Small correction below
On 2016-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
- Clean, rebuild & test on both targets
- 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.wa...@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.vandepu...@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.vandepu...@ncentric.com | +32499736158
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
