[LEDE-DEV] merging the layerscape target

[Y.T. Jiang]

Hi Rafał and John,

Thank you for your review and suggestion.
Please see inline comments.

Thanks & Best Regards
Jiang Yutang

-----Original Message-----
From: Rafał Miłecki [mailto:zajec5 at gmail.com] 
Sent: Monday, September 19, 2016 4:01 PM
To: John Crispin
Cc: LEDE Development List; Y.T. Jiang
Subject: Re: [LEDE-DEV] merging the layerscape target

On 18 September 2016 at 14:24, John Crispin <john at phrozen.org> wrote:
> i have just spent some time reviewing the layerscape PR [1] and 
> started a full build of it. its starting to look good and i cannot see 
> any blockers. if anyone has any hold on this please let me know in the 
> next couple of days. if i dont get any vetos i will merge it.

I can see following Copyright line over and over:
Copyright (C) 2016 OpenWrt.org
Yutang: did you really sign a contract with OpenWrt that included passing your copyrights to the OpenWrt project? If not, you should just keep Copyrights assigned to yourself.
I really would like assigning copyrights to projects where it doesn't apply.
[I do not sign a contract with OpenWrt indeed. I refer to some others target while developing/backporting layerscape, I find almost of targets included OpenWrt.org Copyright, so I also put it in my code files. Now should I replace " Copyright (C) 2016 OpenWrt.org" with " Copyright (C) 2016 Jiang Yutang <yutang.jiang at nxp.com>" ? or retain the both copyright: "Copyright (C) LEDE project, Jiang Yutang <yutang.jiang at nxp.com>" ?] 

What about using some generic profile only and then using DEVICE_TITLE DEVICE_PACKAGES to specify modules that should be included on rootfs?
[I will try to use the two variables.] 

Would that be possible to split patches into accepted ones (backports) and LEDE-specific ones?
[The kernel patches: dpaa/qbman/fman/etc. it is really too big and interference review LEDE-specially code. I will split those kernel patches in folder patches-4.4 as the second, and keep the rest as fist LEDE-specific,  what do you think about it?]

Please refresh all target patches, right now I can see they contain all these things like:
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 4cb98aa..a8a97bd 100644
1.7.9.5
[I found it have conflicts in current kernel version with two patches(arm64/mm related, 0060 and 0061) while backporting the dpaa/qbman/fman driver, but I'm unacquainted with both mm and dpaa, our dpaa team are engaged in do upstream work and can't help me. So I revert the two patch to bypass this issue temporary, I would like to wait for more leisure time then to thorough investigate and solve it.]


--
Rafał