Re: [PATCH v2 3/4] dt-bindings: misc: tmr-inject: Add device-tree binding for TMR Inject

From: "Rao, Appana Durga Kedareswara"  <appana.durga.kedareswara.rao@amd.com>
To: "Simek, Michal" <michal.simek@amd.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	"Rao,
	Appana Durga Kedareswara"  <appana.durga.kedareswara.rao@amd.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
	"derek.kiernan@xilinx.com" <derek.kiernan@xilinx.com>,
	"dragan.cvetic@xilinx.com" <dragan.cvetic@xilinx.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"git (AMD-Xilinx)" <git@amd.com>,
	"git@xilinx.com" <git@xilinx.com>,
	Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Subject: Re: [PATCH v2 3/4] dt-bindings: misc: tmr-inject: Add device-tree binding for TMR Inject
Date: Wed, 20 Jul 2022 13:21:47 +0000	[thread overview]
Message-ID: <7acd93f9-dc5f-3b30-2d7a-4042246e1984@amd.com> (raw)
In-Reply-To: 259a1808-934b-359c-a95f-50d654a48816@amd.com

Hi,

Thanks for the review Krzysztof

On 20/07/22 5:39 pm, Michal Simek wrote:
> 
> 
> On 7/20/22 11:35, Krzysztof Kozlowski wrote:
>> On 20/07/2022 10:26, Michal Simek wrote:
>>>
>>>
>>> On 7/20/22 08:15, Krzysztof Kozlowski wrote:
>>>> On 20/07/2022 08:00, Appana Durga Kedareswara rao wrote:
>>>>> From: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
>>>>>
>>>>> The Triple Modular Redundancy(TMR) Inject core provides functional 
>>>>> fault
>>>>> injection by changing selected MicroBlaze instructions, which 
>>>>> provides the
>>>>> possibility to verify that the TMR subsystem error detection and fault
>>>>> recovery logic is working properly.
>>>>>
>>>>> Signed-off-by: Appana Durga Kedareswara rao 
>>>>> <appana.durga.kedareswara.rao@amd.com>
>>>>> Signed-off-by: Appana Durga Kedareswara rao 
>>>>> <appana.durga.rao@xilinx.com>
>>>>
>>>> Keep only one SoB.
Surce Krzysztof will take care of it next patch series onwards.
>>>
>>> nit: First of all it is from xilinx.com that's why xilinx.com should 
>>> be the first.
>>>
>>> Just for my understanding about guidance here.
>>> Code was developed by Xilinx before acquisition with AMD. And because 
>>> it was
>>> picked from vendor tree origin xilinx.com was there to keep origin 
>>> author there.
>>> And upstreaming is done by new company. I can't see nothing wrong on 
>>> keeping
>>> both emails there but that's why my opinion. Definitely not a problem 
>>> to remove
>>> one of them but wanted to make sure that we do it properly for all 
>>> our submissions.
>>
>> It's the same person. No need for two SoBs from the same person. Since
>> AMD acquired Xilinx, it holds all copyrights thus @amd.com person does
>> not have to include previous SoB. He/She/They has the permission from
>> employer to submit it. The second SoB is just redundant - brings no
>> actual information. Otherwise please tell me which piece of DCO the
>> additional SoB adds/solves (comparing to single SoB - @amd.com)?
> 
> ok. It means enough to choose one now. I am aware about some IT issues 
> in progress that's why that patches can come from xilinx.com or amd.com 
> for some time time.
> Kedar: please just choose one.
> 

Sure Michal

Regards,
Kedar.
> 
>> Similarly when you change jobs while resending your patch - you do not
>> add new SoB but just keep SoB from @previous-company.com.
> 
> IMHO That would be more questionable when you create changes in origin 
> series and new employer pays you to do the work.
> 
> If it is 3rd party company picking series where upstreaming is not 
> finished you will expect that 3rd party will add their sob lines there too.
> 
> Thanks,
> Michal