From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 02073E7718B for ; Mon, 23 Dec 2024 19:08:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bwJVO4l3PuuI4ISLo4ozivDS/tvclvssbl+uR53vAow=; b=sIX6n5wGx1ygjm JxwfZ0HhbjsGQ4C/id1btzii19aIWNQzW1aUDUs7AhhkVDZNXwE3HvMoQDOHFpU6reLhY3EifE1bf aGWXW3OHRqYbUPucX3ytudscF3cCRYwQKBfkOaMnqPDev4rkTmC/YHxYMXcN0BVt+yWr9Nq67/+uU vnhYGtBeT8tkHGvrlB6CMoW7Lxi1+TWHgUHznjJk7xGMPELZTsKgN5sKwAFI+82+mTle9tG9tiU8q fHgJJNDsqQadQj2mje4Il65bjr/HOTf3TpaSelhLmsRDLn6xxzP2jR74k9balArRxwT08tmYUDP1O N4RXixMJ9zT/c1XtQWDg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tPnnI-0000000AbFj-0WsN; Mon, 23 Dec 2024 19:08:44 +0000 Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tPnnE-0000000AbF1-3JAd for linux-mtd@lists.infradead.org; Mon, 23 Dec 2024 19:08:42 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 4668FC0004; Mon, 23 Dec 2024 19:08:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1734980918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dqURXi3l46EDvS3X4w9AsKnpPDUaild06xBnrpCyckU=; b=if2ua8W6RHeDTM+5FSbytQdCWM4SlaT8RVKn8OTnrOSFEb0lq/cjCbrhlAcprQYjIiRSs1 9rYUupBKoUauJABn7lkq53QF2iEX1s7+EwiZp6nhda+WJii5HWv+WtMLBT1H6bwlKRuDqf ug/5GlsaMHUWA0DDnrFM86S9eJd5JthB9vMY5QKOAoV4CsvVhRBtCgyv7kPDRvhqrMcRap EuPPmp0vR4caJvzNVfOcZ5bszW6qtslwdJZ2eO+zHj6swSpv0Pe1S8Bph9sAJRonw0FLQe 1zZgaGxjk/sHPFbTMhxfKBVAoj8AxJhhVq3Rbmi2bYqc9L3t128JI5EmvIXFAA== From: Miquel Raynal To: Tudor Ambarus Cc: Richard Weinberger , Vignesh Raghavendra , Pratyush Yadav , Michael Walle , linux-mtd@lists.infradead.org, Mark Brown , linux-spi@vger.kernel.org, Steam Lin , Thomas Petazzoni , Sanjay R Mehta , Han Xu , Conor Dooley , Daire McNamara , Matthias Brugger , AngeloGioacchino Del Regno , Haibo Chen , Yogesh Gaur , Heiko Stuebner , Michal Simek Subject: Re: [PATCH 01/24] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency In-Reply-To: <8738dbbc-e2a9-49dc-9234-65de6435bc45@linaro.org> (Tudor Ambarus's message of "Wed, 18 Dec 2024 10:13:39 +0000") References: <20241025161501.485684-1-miquel.raynal@bootlin.com> <20241025161501.485684-2-miquel.raynal@bootlin.com> <87jzc3oo6g.fsf@bootlin.com> <01f1bddd-7aee-4c90-9fa0-3b94c87eb469@linaro.org> <878qsde3i4.fsf@bootlin.com> <8738dbbc-e2a9-49dc-9234-65de6435bc45@linaro.org> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Mon, 23 Dec 2024 20:08:35 +0100 Message-ID: <878qs6rzd8.fsf@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241223_110841_100653_8EED98C2 X-CRM114-Status: GOOD ( 21.75 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SGVsbG8sCgpPbiAxOC8xMi8yMDI0IGF0IDEwOjEzOjM5IEdNVCwgVHVkb3IgQW1iYXJ1cyA8dHVk b3IuYW1iYXJ1c0BsaW5hcm8ub3JnPiB3cm90ZToKCj4gT24gMTIvMTgvMjQgMTA6MDMgQU0sIFR1 ZG9yIEFtYmFydXMgd3JvdGU6Cj4+IAo+PiAKPj4gT24gMTIvMTgvMjQgOTozNyBBTSwgTWlxdWVs IFJheW5hbCB3cm90ZToKPj4+IE9uIDE4LzEyLzIwMjQgYXQgMDg6MDc6MjQgR01ULCBUdWRvciBB bWJhcnVzIDx0dWRvci5hbWJhcnVzQGxpbmFyby5vcmc+IHdyb3RlOgo+Pj4KPj4+PiBPbiAxMi8x My8yNCAxMDo0NiBBTSwgTWlxdWVsIFJheW5hbCB3cm90ZToKPj4+Pj4gSGVsbG8gVHVkb3IsCj4+ Pj4+Cj4+Pj4KPj4+PiBIaSEKPj4+Pgo+Pj4+PiBPbiAxMS8xMS8yMDI0IGF0IDEzOjA3OjA5IEdN VCwgVHVkb3IgQW1iYXJ1cyA8dHVkb3IuYW1iYXJ1c0BsaW5hcm8ub3JnPiB3cm90ZToKPj4+Pj4K Pj4+Pj4+IE9uIDEwLzI1LzI0IDU6MTQgUE0sIE1pcXVlbCBSYXluYWwgd3JvdGU6Cj4+Pj4+Pgo+ Pj4+Pj4gY3V0Cj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3Bp L3NwaS1tZW0uYyBiL2RyaXZlcnMvc3BpL3NwaS1tZW0uYwo+Pj4+Pj4+IGluZGV4IDE3YjhiYWY3 NDllNi4uYWI2NTBhZTk1M2JiIDEwMDY0NAo+Pj4+Pj4+IC0tLSBhL2RyaXZlcnMvc3BpL3NwaS1t ZW0uYwo+Pj4+Pj4+ICsrKyBiL2RyaXZlcnMvc3BpL3NwaS1tZW0uYwo+Pj4+Cj4+Pj4gY3V0Cj4+ Pj4KPj4+Pj4+PiArCWlmICghb3AtPm1heF9mcmVxIHx8IG9wLT5tYXhfZnJlcSA+IG1lbS0+c3Bp LT5tYXhfc3BlZWRfaHopCj4+Pj4+Pj4gKwkJKChzdHJ1Y3Qgc3BpX21lbV9vcCAqKW9wKS0+bWF4 X2ZyZXEgPSBtZW0tPnNwaS0+bWF4X3NwZWVkX2h6Owo+Pj4+Pj4KPj4+Pj4+IG5vdCBhIGJpZyBm YW4gb2YgY2FzdGluZyB0aGUgY29uc3Qgb3V0LiBIb3cgYWJvdXQgaW50cm9kdWNpbmcgYQo+Pj4+ Pj4gc3BpX21lbV9hZGp1c3Rfb3BfZnJlcSgpPyBUaGUgdXBwZXIgbGF5ZXJzIHdpbGwgdXNlIHRo YXQgd2VyZSBuZWVkZWQsCj4+Pj4+PiBhbmQgeW91J2xsIHN0aWxsIGJlIGFibGUgdG8gcGFzcyBh IGNvbnN0IG9wIHRvIHNwaV9tZW1fZXhlY19vcCgpCj4+Pj4+Cj4+Pj4+IEkga25vdyBpdCBpcyBu b3QgaWRlYWwgc28gdG8gZm9sbG93IHlvdXIgaWRlYSBJIGRyYWZ0ZWQgdGhlIHVzZSBvZgo+Pj4+ PiBzcGlfbWVtX2FkanVzdF9vcF9mcmVxKCkuIEluIG9yZGVyIHRvIGF2b2lkIHRoZSBjYXN0LCB3 ZSBhY3R1YWxseSBuZWVkCj4+Pj4+IHRvIGNhbGwgdGhpcyBmdW5jdGlvbiBldmVyeXdoZXJlIGlu IHRoZSBjb3JlIGFuZCB0aGUgZHJpdmVycyB0byBtYWtlCj4+Pj4+IHN1cmUgd2UgbmV2ZXIgZ2V0 IG91dCBvZiBib3VuZHMsIGJ1dCBoZXJlIGlzIHRoZSBwcm9ibGVtOgo+Pj4+Pgo+Pj4+PiAgICAg JCBnaXQgZ3JlcCAtdyBzcGlfbWVtX2V4ZWNfb3AgLS0gZHJpdmVycy8gfCB3YyAtbAo+Pj4+PiAg ICAgNDIKPj4+Pj4KPj4+Pj4gVGhpcyBhcHByb2FjaCByZXF1aXJlcyB0byBhZGQgYSBjYWxsIHRv IHNwaV9tZW1fYWRqdXN0X29wX2ZyZXEoKSBiZWZvcmUKPj4+Pj4gKmV2ZXJ5KiBzcGlfbWVtX2V4 ZWNfb3AoKS4gWWVzIEkgY2FuIGRvIHRoYXQgYnV0IHRoYXQgbWVhbnMgdG8gYmUgdmVyeQo+Pj4+ PiBhdHRlbnRpdmUgdG8gdGhlIGZhY3QgdGhhdCB0aGVzZSB0d28gZnVuY3Rpb25zIGFyZSBhbHdh eXMgY2FsbGVkCj4+Pj4+IHRvZ2V0aGVyLiBJIGFtIG5vdCBzdXJlIGl0IGlzIGEgZ29vZCBpZGVh Lgo+Pj4+Pgo+Pj4+PiBXaGF0IGFib3V0IGRvaW5nIHRoZSBmb2xsb3dpbmcgb25jZSBpbiBzcGlf bWVtX2V4ZWNfb3AoKSBpbnN0ZWFkPwo+Pj4+Pgo+Pj4+PiAgICAgc3BpX21lbV9hZGp1c3Rfb3Bf ZnJlcShkZXNjLT5tZW0sIChzdHJ1Y3Qgc3BpX21lbV9vcCAqKW9wKTsKPj4+Pj4KPj4+Pj4gSSBr bm93IHdlIHN0aWxsIGhhdmUgYSBjYXN0LCBidXQgaXQgZmVlbHMgbW9yZSBhY2NlcHRhYmxlIHRo YW4gdGhlIG9uZSBJCj4+Pj4+IGluaXRpYWxseSBwcm9wb3NlZCBhbmQgY292ZXJzIGFsbCBjYXNl cy4gSSB3b3VsZCBub3QgYWNjZXB0IHRoYXQgaW4gYQo+Pj4+PiBkcml2ZXIsIGJ1dCBoZXJlIHdl IGFyZSBpbiB0aGUgY29yZSwgc28gdGhhdCBzb3VuZHMgYWNjZXB0YWJsZS4KPj4+Pj4KPj4+Pj4g QW5vdGhlciBwb3NzaWJpbGl0eSBvdGhlcndpc2Ugd291bGQgYmUgdG8gZHJvcCB0aGUgY29uc3Qg ZnJvbSB0aGUKPj4+Pj4gc3BpX21lbV9vcCBzdHJ1Y3R1cmUgZW50aXJlbHkuIEJ1dCBJIHByZWZl ciB0aGUgYWJvdmUgZnVuY3Rpb24gY2FsbC4KPj4+Pgo+Pj4+IEhvdyBhYm91dCBpbnRyb2R1Y2lu ZyBhIHNwaV9uYW5kX3NwaW1lbV9leGVjX29wKCkgd2hlcmUgeW91IGNhbGwKPj4+PiBzcGlfbWVt X2FkanVzdF9vcF9mcmVxKCkgYW5kIHNwaV9tZW1fZXhlY19vcCgpPwo+Pj4KPj4+IFRoYXQgd291 bGQgd29yayB0byBtYWtlIHRoZSBjYXN0IGRpc2FwcGVhciBidXQgVEJIIHdvdWxkIG5vdCBiZSB0 b3RhbGx5Cj4+PiByZWxldmFudCBhcyBhZGp1c3RpbmcgdGhlIGZyZXF1ZW5jeSBpcyB0eXBpY2Fs bHkgc29tZXRoaW5nIHRoYXQgd291bGQKPj4+IGJlbmVmaXQgdG8gc3BpLW5vciBhcyB3ZWxsICht YXliZSBpbiB0aGUgZnV0dXJlKSBhbmQgdGhlcmVmb3JlIHdvdWxkCj4+IAo+PiBSaWdodCwgU1BJ IE5PUiB3aWxsIGJlbmVmaXQgb2YgdGhpcyB0b28uCj4+IAo+Pj4gZnVsbHkgYXBwbHkgdG8gc3Bp IG1lbW9yaWVzIGFzIGEgd2hvbGUsIG5vdCBqdXN0IHNwaS1uYW5kLiBXZSBjYW4gdGhpbmsKPj4+ IGFib3V0IGFub3RoZXIgbmFtaW5nIG1heWJlLCBidXQgSSBmaW5kIGxpa2Ugc3BpX21lbV9leGVj X29wKCkgaXMgdGhlCj4+PiByaWdodCBsb2NhdGlvbiB0byBkbyB0aGlzLgo+Pj4KPj4gCj4+IEl0 J3Mgbm90IHRoZSBmaXJzdCB0aW1lIHRoYXQgd2UgYWRqdXN0IHNwaV9tZW1fb3AgcGFyYW1ldGVy cywgc2VlOgo+PiBodHRwczovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dp dC9tdGQvbGludXguZ2l0L3RyZWUvZHJpdmVycy9tdGQvc3BpLW5vci9jb3JlLmM/aD1zcGktbm9y L25leHQjbjE1Mwo+PiAKPj4gRG9lcyBTUEkgTkFORCBuZWVkIHRvIGNhbGwgc3BpX21lbV9hZGp1 c3Rfb3Bfc2l6ZSBhcyB3ZWxsPyBJIHNlZSBpdAo+PiBjYWxscyBpdCB3aGVuIHVzaW5nIGRpcm1h cCwgYnV0IG5vdCB3aXRoIGEgcGxhaW4gc3BpX21lbV9leGVjX29wKCkuCj4+IAo+Cj4gSSBhc2sg YmVjYXVzZSBJJ20gdGhpbmtpbmcgb2YgYWRkaW5nIGluIHRoZSBTUElNRU0gY29yZSBhIHByZXBh cmUoKQo+IG1ldGhvZCwgYW5kIG1heWJlIHJlbmFtZSBleGVjX29wKCkgdG8gZXhlYygpLiBBbmQg dGhlbiBpbnRyb2R1Y2UgYQo+IHByZXBhcmVfZXhlYygpIG1ldGhvZCB0aGF0IHRoZSB1cHBlciBs YXllcnMgd291bGQgY2FsbD8gU2ltaWxhciB0bwo+IGNsa19wcmVwYXJlX2VuYWJsZS4KCkRvIHlv dSBoYXZlIHNvbWV0aGluZyBlbHNlIGluIG1pbmQgeW91IHdvdWxkIGxpa2UgdG8gcHV0IGluIHRo ZSBwcmVwYXJlCnN0ZXA/IEkgYW0gbm90IGF0IGFsbCBvcHBvc2VkIHRvIGl0LCBidXQgSSBmZWVs IGxpa2UgZm9yIG5vdyB0aGUKc3BpX21lbV9leGVjX29wKCkgaXMgYSBmaW5lIHBhdGggZm9yIHRo YXQsIGVzcGVjaWFsbHkgc2luY2UgdGhlcmUgYXJlCnZlcnkgbGl0dGxlIHRoaW5ncyB0byAicHJl cGFyZSIgKGZvciBub3cpLgoKRG8geW91IG1pbmQgaWYgSSBrZWVwIHRoZSBjYXN0IChub3QgdGhl IG9uZSBmcm9tIHRoZSBzZXJpZXMsIEkgY2xlYW5lZAp0aGF0IHVwIHRvIGhhdmUgYW4gYWRqdXN0 X29wIGZ1bmN0aW9uIGFzIGRpc2N1c3NlZCkgZm9yIG5vdywgYW5kIGlmIHlvdQpldmVyIGdvIHRo ZSBwcmVwYXJlL2V4ZWMgcGF0aCB3ZSB3b3VsZCBnZXQgdGhpcyBjb252ZXJ0ZWQgdG8gdXNlIHRo ZSBuZXcKQVBJPyBJJ2QgbGlrZSB0byBtYWtlIHByb2dyZXNzZXMgb24gb3RoZXIgdG9waWNzIGlu IHRoZSBzcGktbmFuZCBjb3JlCmFuZCBhdm9pZCBiZWluZyBibG9ja2VkIGJ5IGEgYmlnZ2VyIHRh c2sgdGhhdCB3ZSBuZWVkIHRvIGRpc2N1c3MgZmlyc3QuCgpDaGVlcnMsCk1pcXXDqGwKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eCBN VEQgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1tdGQvCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED72B1C3BF7 for ; Mon, 23 Dec 2024 19:08:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734980922; cv=none; b=OZlLNxy1oxSPp42nfpscNC5a9D0RSE3Wv04ZoGCBlhvw4VZn9qt6FgyVxPbBleYZuT9xcPEKdOvcGztCIllErzLumouKUeO7cuz4dq6+jWFXrzNOIHCulaQfQ+dNkECkdU1ehstmUi1KKZ5328ZZrozBORJL31c1MgG9BxrODfw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734980922; c=relaxed/simple; bh=iRe+JXhtAfPFQN5Mx0KSzFJxJkvoZN6LR6pgoVr3jpg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=X4clRGHI89VN3c03POmy4bHMtbBkzuXe8ijchjVxhsxmeVApYzOE5bWXMhEfWj/Cy8kJHMqzkOTM5cuWyztJpR5GF1PJY7cb4XefqGIxijgjwGRo8AegopRI45oYQn73rcapGTbVg9+TFr/2MTlI+AnJUWaFHQqSpbbWGThdvZ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=if2ua8W6; arc=none smtp.client-ip=217.70.183.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="if2ua8W6" Received: by mail.gandi.net (Postfix) with ESMTPSA id 4668FC0004; Mon, 23 Dec 2024 19:08:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1734980918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dqURXi3l46EDvS3X4w9AsKnpPDUaild06xBnrpCyckU=; b=if2ua8W6RHeDTM+5FSbytQdCWM4SlaT8RVKn8OTnrOSFEb0lq/cjCbrhlAcprQYjIiRSs1 9rYUupBKoUauJABn7lkq53QF2iEX1s7+EwiZp6nhda+WJii5HWv+WtMLBT1H6bwlKRuDqf ug/5GlsaMHUWA0DDnrFM86S9eJd5JthB9vMY5QKOAoV4CsvVhRBtCgyv7kPDRvhqrMcRap EuPPmp0vR4caJvzNVfOcZ5bszW6qtslwdJZ2eO+zHj6swSpv0Pe1S8Bph9sAJRonw0FLQe 1zZgaGxjk/sHPFbTMhxfKBVAoj8AxJhhVq3Rbmi2bYqc9L3t128JI5EmvIXFAA== From: Miquel Raynal To: Tudor Ambarus Cc: Richard Weinberger , Vignesh Raghavendra , Pratyush Yadav , Michael Walle , linux-mtd@lists.infradead.org, Mark Brown , linux-spi@vger.kernel.org, Steam Lin , Thomas Petazzoni , Sanjay R Mehta , Han Xu , Conor Dooley , Daire McNamara , Matthias Brugger , AngeloGioacchino Del Regno , Haibo Chen , Yogesh Gaur , Heiko Stuebner , Michal Simek Subject: Re: [PATCH 01/24] spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequency In-Reply-To: <8738dbbc-e2a9-49dc-9234-65de6435bc45@linaro.org> (Tudor Ambarus's message of "Wed, 18 Dec 2024 10:13:39 +0000") References: <20241025161501.485684-1-miquel.raynal@bootlin.com> <20241025161501.485684-2-miquel.raynal@bootlin.com> <87jzc3oo6g.fsf@bootlin.com> <01f1bddd-7aee-4c90-9fa0-3b94c87eb469@linaro.org> <878qsde3i4.fsf@bootlin.com> <8738dbbc-e2a9-49dc-9234-65de6435bc45@linaro.org> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Mon, 23 Dec 2024 20:08:35 +0100 Message-ID: <878qs6rzd8.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-spi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Hello, On 18/12/2024 at 10:13:39 GMT, Tudor Ambarus wro= te: > On 12/18/24 10:03 AM, Tudor Ambarus wrote: >>=20 >>=20 >> On 12/18/24 9:37 AM, Miquel Raynal wrote: >>> On 18/12/2024 at 08:07:24 GMT, Tudor Ambarus = wrote: >>> >>>> On 12/13/24 10:46 AM, Miquel Raynal wrote: >>>>> Hello Tudor, >>>>> >>>> >>>> Hi! >>>> >>>>> On 11/11/2024 at 13:07:09 GMT, Tudor Ambarus wrote: >>>>> >>>>>> On 10/25/24 5:14 PM, Miquel Raynal wrote: >>>>>> >>>>>> cut >>>>>> >>>>>>> >>>>>>> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c >>>>>>> index 17b8baf749e6..ab650ae953bb 100644 >>>>>>> --- a/drivers/spi/spi-mem.c >>>>>>> +++ b/drivers/spi/spi-mem.c >>>> >>>> cut >>>> >>>>>>> + if (!op->max_freq || op->max_freq > mem->spi->max_speed_hz) >>>>>>> + ((struct spi_mem_op *)op)->max_freq =3D mem->spi->max_speed_hz; >>>>>> >>>>>> not a big fan of casting the const out. How about introducing a >>>>>> spi_mem_adjust_op_freq()? The upper layers will use that were needed, >>>>>> and you'll still be able to pass a const op to spi_mem_exec_op() >>>>> >>>>> I know it is not ideal so to follow your idea I drafted the use of >>>>> spi_mem_adjust_op_freq(). In order to avoid the cast, we actually need >>>>> to call this function everywhere in the core and the drivers to make >>>>> sure we never get out of bounds, but here is the problem: >>>>> >>>>> $ git grep -w spi_mem_exec_op -- drivers/ | wc -l >>>>> 42 >>>>> >>>>> This approach requires to add a call to spi_mem_adjust_op_freq() befo= re >>>>> *every* spi_mem_exec_op(). Yes I can do that but that means to be very >>>>> attentive to the fact that these two functions are always called >>>>> together. I am not sure it is a good idea. >>>>> >>>>> What about doing the following once in spi_mem_exec_op() instead? >>>>> >>>>> spi_mem_adjust_op_freq(desc->mem, (struct spi_mem_op *)op); >>>>> >>>>> I know we still have a cast, but it feels more acceptable than the on= e I >>>>> initially proposed and covers all cases. I would not accept that in a >>>>> driver, but here we are in the core, so that sounds acceptable. >>>>> >>>>> Another possibility otherwise would be to drop the const from the >>>>> spi_mem_op structure entirely. But I prefer the above function call. >>>> >>>> How about introducing a spi_nand_spimem_exec_op() where you call >>>> spi_mem_adjust_op_freq() and spi_mem_exec_op()? >>> >>> That would work to make the cast disappear but TBH would not be totally >>> relevant as adjusting the frequency is typically something that would >>> benefit to spi-nor as well (maybe in the future) and therefore would >>=20 >> Right, SPI NOR will benefit of this too. >>=20 >>> fully apply to spi memories as a whole, not just spi-nand. We can think >>> about another naming maybe, but I find like spi_mem_exec_op() is the >>> right location to do this. >>> >>=20 >> It's not the first time that we adjust spi_mem_op parameters, see: >> https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/drive= rs/mtd/spi-nor/core.c?h=3Dspi-nor/next#n153 >>=20 >> Does SPI NAND need to call spi_mem_adjust_op_size as well? I see it >> calls it when using dirmap, but not with a plain spi_mem_exec_op(). >>=20 > > I ask because I'm thinking of adding in the SPIMEM core a prepare() > method, and maybe rename exec_op() to exec(). And then introduce a > prepare_exec() method that the upper layers would call? Similar to > clk_prepare_enable. Do you have something else in mind you would like to put in the prepare step? I am not at all opposed to it, but I feel like for now the spi_mem_exec_op() is a fine path for that, especially since there are very little things to "prepare" (for now). Do you mind if I keep the cast (not the one from the series, I cleaned that up to have an adjust_op function as discussed) for now, and if you ever go the prepare/exec path we would get this converted to use the new API? I'd like to make progresses on other topics in the spi-nand core and avoid being blocked by a bigger task that we need to discuss first. Cheers, Miqu=C3=A8l