[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19b5f5e7bd5e7a41621ecad2239e4bd6@kernel.org>
Date: Mon, 26 Oct 2020 15:42:34 +0000
From: Marc Zyngier <maz@...nel.org>
To: Leo Li <leoyang.li@....com>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>,
"Biwen Li (OSS)" <biwen.li@....nxp.com>, shawnguo@...nel.org,
robh+dt@...nel.org, mark.rutland@....com,
"Z.q. Hou" <zhiqiang.hou@....com>, tglx@...utronix.de,
jason@...edaemon.net, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Jiafei Pan <jiafei.pan@....com>,
Xiaobo Xie <xiaobo.xie@....com>,
linux-arm-kernel@...ts.infradead.org, Biwen Li <biwen.li@....com>
Subject: Re: [RESEND 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external
interrupt
On 2020-10-26 15:06, Leo Li wrote:
>> -----Original Message-----
>> From: Marc Zyngier <maz@...nel.org>
>> Sent: Monday, October 26, 2020 4:23 AM
>> To: Rasmus Villemoes <linux@...musvillemoes.dk>
>> Cc: Biwen Li (OSS) <biwen.li@....nxp.com>; shawnguo@...nel.org;
>> robh+dt@...nel.org; mark.rutland@....com; Leo Li <leoyang.li@....com>;
>> Z.q. Hou <zhiqiang.hou@....com>; tglx@...utronix.de;
>> jason@...edaemon.net; devicetree@...r.kernel.org; linux-
>> kernel@...r.kernel.org; Jiafei Pan <jiafei.pan@....com>; Xiaobo Xie
>> <xiaobo.xie@....com>; linux-arm-kernel@...ts.infradead.org; Biwen Li
>> <biwen.li@....com>
>> Subject: Re: [RESEND 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A
>> external
>> interrupt
>>
>> On 2020-10-26 09:06, Rasmus Villemoes wrote:
>> > On 26/10/2020 09.44, Marc Zyngier wrote:
>> >> On 2020-10-26 08:01, Biwen Li wrote:
>> >>> From: Hou Zhiqiang <Zhiqiang.Hou@....com>
>> >>>
>> >>> Add an new IRQ chip declaration for LS1043A and LS1088A
>> >>> - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A
>> >>> - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
>> >>
>> >> Three things:
>> >> - This commit message doesn't describe the bit_reverse change
>> >
>> > Yeah, please elaborate on that, as the RM for 1043 or 1046 doesn't
>> > mention anything about bit reversal for the scfg registers - they
>> > don't seem to have the utter nonsense that is SCFG_SCFGREVCR, but
>> > perhaps, instead of removing it, that has just become a hard-coded
>> > part of the IP.
>> >
>> > Also, IANAL etc., but
>> >
>> >>> +// Copyright 2019-2020 NXP
>> >
>> > really? Seems to be a bit of a stretch.
>> >
>> > At the very least, cc'ing the original author and only person to ever
>> > touch that file would have been appreciated.
>>
>> Huh. Well spotted. That's definitely not on.
>> NXP people, please talk to your legal department.
>
> We do have an internal policy to require developer adding/updating NXP
> copyright on non-trivial changes. I'm not sure if this change should
> be considered trivial, but adding copyright claim on a file without
> prior copyright claims could causing confusion like in this case.
The copyright exists implicitly, and doesn't require a copyright claim
in the file itself. Please talk to your legal department.
> One
> potential solution is to add a more specific description on the NXP
> change together with the copyright claim. But maybe an easier
> solution is to add Rasmus your Copyright claim first if you are ok
> with it.
That's for Rasmus to decide whether he wants to add such a claim,
given that it exists implicitly. Adding copyright claims for any
odd change you make isn't acceptable either (your changes are already
unambiguously identified in git).
For the time being, I'm not taking any NXP patch carrying additional
copyright update until this is clarified.
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists