[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b310b54-c215-40fa-b6d4-81faf75a8c9e@prolan.hu>
Date: Wed, 30 Oct 2024 13:37:52 +0100
From: Csókás Bence <csokas.bence@...lan.hu>
To: Tudor Ambarus <tudor.ambarus@...aro.org>, <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
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.
> 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.
Bence
Powered by blists - more mailing lists