Hi,
I rely on KanjiMonster's script to adjust the patches, so they apply
cleanly. Without it, if you start a verbose build, you'd see 'patch
applied with fuzz 2' etc. With the amount of patches a project like
this one has, clean patches eliminate redundant output and allow you to
zoom in quicker on the correct lines in the source code (and the part
of the patch that breaks them).
https://gist.github.com/KanjiMonster/dfcd1af3190aa7b2941f1bdcb119f25e
Cheers
Stijn
Op di, 1 nov 2016 om 6:58 , schreef p.wa...@gmx.at:
This patch bumps the 4.4 kernel from .28 to .30 and refreshes the
patches.
A question regarding the 'patch refreshing' and my previous patch for
4.4.29.
I want to figure out where my workflow is erroneous, or what things I
did not
understand when refreshing a patch series during a kernel upgrade
like this.
For example let me take the first refreshing you submitted
(besides 4.4.28->30 in kernel-version.mk):
The file
'target/linux/bcm53xx/patches-4.4/405-mtd-spi-nor-detect-JEDEC-incompatible-w25q128-using-.patch'
patches the kernel driver 'drivers/mtd/spi-nor/spi-nor.c'
Now with your patch refreshing, you adjust the offsets in spi-nor.c
However, this file (spi-nor.c) was last changed back in July
(2016-07-14).
So why is it required to refresh this patch on 4.4.28 -> .30, when
this
file was last changed during 4.4.15 -> .16 ?
Don't get me wrong, I just want to understand where I have to adjust
my workflow.
Best regards,
P. Wassi
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
