lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56530f64-6ddf-4d2a-a079-0578db260449@kernel.org>
Date: Wed, 12 Nov 2025 10:40:57 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Daniel Baluta <daniel.baluta@...il.com>
Cc: Fabio Estevam <festevam@...il.com>,
 Rogerio Pimentel <rpimentel.silva@...il.com>, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, shawnguo@...nel.org,
 s.hauer@...gutronix.de, kernel@...gutronix.de,
 alexander.stein@...tq-group.com, dario.binacchi@...rulasolutions.com,
 marex@...x.de, Markus.Niebel@...group.com, y.moog@...tec.de,
 joao.goncalves@...adex.com, frieder.schrempf@...tron.de,
 josua@...id-run.com, francesco.dolcini@...adex.com, primoz.fiser@...ik.com,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Xiaofeng Wei <xiaofeng.wei@....com>, Daniel Baluta <daniel.baluta@....com>,
 Joseph Guo <qijian.guo@....com>
Subject: Re: [PATCH v4 2/2] arm64: dts: add support for NXP i.MX8MP FRDM board

On 12/11/2025 10:32, Daniel Baluta wrote:
> On Wed, Nov 12, 2025 at 11:14 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 12/11/2025 10:08, Krzysztof Kozlowski wrote:
>>> On 12/11/2025 09:15, Daniel Baluta wrote:
>>>> On Tue, Nov 11, 2025 at 2:49 PM Daniel Baluta <daniel.baluta@...il.com> wrote:
>>>>>
>>>>> On Tue, Nov 11, 2025 at 1:50 PM Fabio Estevam <festevam@...il.com> wrote:
>>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On Tue, Nov 11, 2025 at 5:45 AM Daniel Baluta <daniel.baluta@...il.com> wrote:
>>>>>>
>>>>>>> In addition to that, Rogerio please read:
>>>>>>>
>>>>>>> https://docs.kernel.org/process/submitting-patches.html
>>>>>>>
>>>>>>> At this moment I think you should keep the original author of the
>>>>>>> patch.
>>>>>>
>>>>>> Right, but NXP makes a total mess with authorship.
>>>>>
>>>>> I cannot disagree with you on this, let me clarify it internally with
>>>>> NXP colleagues
>>>>> and sort everything out.
>>>>
>>>> Hi Fabio & Rogerio,
>>>>
>>>> Checked internally and to track the correct authorship and development work
>>>> here is how NXP would prefer to get credit.
>>>
>>> Sorry, but individual contributors do not need to give any credits to
>>> NXP. If NXP wanted to sent the patches to have credit, they would do it.
>>>
>>> Did sending happened?
>>>
>>> If not, then any contributor is rightful to take the patches from
>>> downstream and send them only, ONLY with their authorship. That's what
>>> DCO allows and that's what established practice as well.
>>>
>>> NXP had a chance to upstream. When they decided not to, they forfeit any
>>> rights to claim they want any authorship.
>>>
>>>
>>>>
>>>> #Use git commit --amend --author="Xiaofeng Wei <xiaofeng.wei@....com>"
>>>
>>> NAK, there is no single patch like that from above author:
>>>
>>> https://lore.kernel.org/all/?q=f%3Axiaofeng.wei%40nxp.com
>>>
>>> Remember, downstream code does not matter. Does not exist.
>>>
>>>
>>
>>
>> ... and because last two months there were two or three cases where
>> vendor companies bullied individual contributors, I will be quite strict
>> about that. Vendor company does not receive any authorship on patches
>> sent by independent contributors which the vendor NEVER submitted,
>> unless author really wants that. But I will treat any such insisting on
>> authorship by vendor like NXP as bullying and working AGAINST the community.
> 
> I'm sorry that people use "bully" in this context. We are just trying
> to help with
> the limited time we have and create a friendly environment around NXP
> upstream support.
> 
> We (NXP) immensely  appreciate individual contributions from everyone.
> 
> We need to be fair, the v1 of this patchset was taken from NXP
> downstream without
> respecting the Developer Certificate of Origin.

No, it wasn't. Please read carefully DCO. The chain here was not
correct, but that's the only thing.

> 
> E.g there were commits pulled in from our internal tree without
> keeping the S-o-B tags.

Read DCO, please. It is not mandatory to keep 3rd party SoB. It is
perfectly fine to skip it, if needed according to (b) of DCO certifying.

Otherwise please point me which aspect of certification was not kept or
was broken.

> As I said keeping the original author is a sign of respecting the
> initial work of NXP developers
> and a recommendation from NXP.

Which is purely up to the author. The NXP made their choice by not ever
sending it to upstream.

> 
> What is your suggestion on moving on with this? Would keeping the
> authorship from Rogerio
> and adding S-o-B and C-d-b tags as above work for everyone?
To me it is pretty simple and that's what I commented on - I expect
conforming to submitting patches and DCO, thus the sender's SoB MUST BE
ALWAYS the last.

This is the only issue with this patch.

Now, whom Rogerio wants to make the author I really do not care.
Although I care a lot about NXP coming to upstream and claiming they
have any authorship of their downstream code.

Assuming this was even taken from downstream, which was not proven yet,
although does not matter.

Again, whatever you have downstream absolutely does not matter, EXCEPT
THE LICENSE, for us.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ