linux-kernel - Re: [PATCH v2] spi: atmel-quadspi: Create `atmel_qspi

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: <2634dc58-84fc-429e-9e78-1b8a6a757483@linaro.org>
Date: Wed, 30 Oct 2024 12:49:49 +0000
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Csókás Bence <csokas.bence@...lan.hu>,
 linux-spi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Cc: Varshini Rajendran <varshini.rajendran@...rochip.com>,
 Mark Brown <broonie@...nel.org>, Nicolas Ferre
 <nicolas.ferre@...rochip.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>
Subject: Re: [PATCH v2] spi: atmel-quadspi: Create `atmel_qspi_ops` to support
 newer SoC families



On 10/30/24 12:37 PM, Csókás Bence wrote:
> Hi,

Hi!

> 
> On 2024. 10. 30. 12:09, Tudor Ambarus wrote:
>> I think it's fine to split sama7g5 addition in smaller steps. But please
>> add the sama7g5 support in the same patch set, otherwise this patch
>> doesn't make sense on its own.
> 
> Well, actually, we're using SAMA5D2. My goal was just to somewhat
> harmonize upstream with the vendor kernel so that we may contribute
> other patches that we have made on top of the latter, or in the future,
> take patches from upstream and apply it to our vendor kernel-based tree.
> This patch was only meant to lay the groundworks for future SAMA7G5
> support. I can of course send the "other half" of the original patch if
> needed, but I wouldn't want it to hold up this refactor.

Do you have a sama7g5 at hand? If not and unable to test it, it's
probably better to not touch that code, unless you get support from
someone to do the testing for you.

I still think that this patch on its own doesn't make sense without the
sama7g5 addition because nothing guarantees that sama7g5 will be added
on top of this. But I won't stand against your patch. Maybe others from
Cc find it fine.

> 
>> Also, if you think you significantly changed the code of authors, I
>> think it's fine to overwrite the authorship. Otherwise, try to keep the
>> authorship and specify your contributions above your S-o-b tag.
> 
> I don't know if it counts as "significantly changed", I split out parts
> of a patch that were relevant for our device, and made small adjustments
> to make it correctly apply to master. I didn't find a descriptive enough
> tag for this, so I just went with Cc:, but if so desired, I could change
> it to a S-o-b, Co-authored-by, Suggested-by etc.
> 
I think it's fine if you keep your authorship for this refactoring
patch, I was thinking more of the bulk of the sama7g5 changes.

Cheers and good luck!
ta