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: <20241104-vanilla-operating-de19b033f0a8@thorsis.com>
Date: Mon, 4 Nov 2024 13:48:12 +0100
From: Alexander Dahl <ada@...rsis.com>
To: Csókás Bence <csokas.bence@...lan.hu>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>, linux-spi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Varshini Rajendran <varshini.rajendran@...rochip.com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Mark Brown <broonie@...nel.org>,
	Claudiu Beznea <claudiu.beznea@...on.dev>
Subject: Re: [PATCH v2] spi: atmel-quadspi: Create `atmel_qspi_ops` to
 support newer SoC families

Hi,

Am Wed, Oct 30, 2024 at 01:37:52PM +0100 schrieb Csókás Bence:
> 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.

It would actually be better if vendor would bring their stuff
upstream, so there's no need for a vendor kernel.  Did you talk to
Microchip about their upstreaming efforts?  What was the answer?

Greets
Alex

> 
> > 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
> 
>