[U-Boot] Individual files dual licenses

[Tom Rini]

On Thu, Jan 18, 2018 at 06:14:07PM +0000, York Sun wrote:
> On 01/18/2018 10:11 AM, Tom Rini wrote:
> > On Thu, Jan 18, 2018 at 06:09:22PM +0000, York Sun wrote:
> >> On 01/18/2018 10:04 AM, Tom Rini wrote:
> >>>>>
> >>>>> With regards to dts files, this is another reason I would like to see
> >>>>> that done as a strict re-sync with Linux rather than a stand-alone
> >>>>> change.  Saying we're importing file X from the kernel at revision Y
> >>>>> makes the license change pretty easy to spot and justify.
> >>>>>
> >>>>
> >>>> For the dts files, they already exist in U-Boot. Can the team still say
> >>>> "importing" from Linux? The files in U-Boot is only a small subset of
> >>>> those in Linux.
> >>>
> >>> Yes, if it's a strict replace file A with contents of the same file from
> >>> Linux, it's re-importing.  I thought these boards had already re-synced
> >>> before but perhaps not?  It's something we do from time to time on other
> >>> platforms.
> >>
> >> In this case, the contents of dts files are different from those in
> >> Linux. The only thing imported this time is the dual license. Is it
> >> still considered a re-sync?
> > 
> > They should not be different at all.  Anything U-Boot centric should be
> > in an appropriately named -u-boot.dtsi file.  This facilitates keeping
> > the rest of the dts/dtsi files as exact copies of the ones in the
> > kernel.
> > 
> > To put it another way, what is the reason they differ from the kernel?
> > And could they be changed to not, and use a -u-boot.dtsi (or several) so
> > that they can be kept in-sync with the kernel?
> 
> The dts files in Linux are much much bigger. U-Boot only uses a small
> subset. There are many nodes not used by U-Boot.

For SPL where we care about size in that regard we have
CONFIG_OF_SPL_REMOVE_PROPS to trim things down as needed, and it
shouldn't be a concern for full U-Boot.  

If your really want to maintain two distinct dts/dtsi files because
there's some value you see in that, I won't stop you from doing it.  But
I don't see a unique challenge posed by the NXP platforms just yet
either.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180118/1d458997/attachment.sig>