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 C8BC0C44507 for ; Fri, 17 Jul 2026 08:01:10 +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:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=laG7FEZBU7uuoSz4l3AEoiA3ilvkGr/5HHUTbV4lOaY=; b=3YqmrBoYHQHcKy mJCMgvBq3ENSt3jA7+LfUqtyMM5Jwd7LrcJHqodH9S33VROi0G9x/2E22iwptRfuRvtqEDSeqcCtr D4SYl82AzRek6sahFkTg5LYV0kdTsWasFZEMQu2JaQ+7CZDQjKX8I2edq2fTI+VYQQhnrlpQBT9Q+ GADSTL4Ot00aB+ezcYfW0RVMS7VEAE0bvDlJCZw6+2V3hNJV/7pXkd2MiVAPfV422Em2QLDKUsrGq RYvvLDfbKbLICjuGg2vedGoeBhz5/uyvwWjNLYFSacsROOrwnYeWT0bd9bWxMbdXpLDj26ATbawQr SJnFDyd5Y4WvRwwvIm+w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wkdVL-00000001XcO-1ZuG; Fri, 17 Jul 2026 08:01:07 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wkdVK-00000001Xc6-3kR6 for linux-amlogic@lists.infradead.org; Fri, 17 Jul 2026 08:01:06 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 62871418DC; Fri, 17 Jul 2026 08:01:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA9F51F000E9; Fri, 17 Jul 2026 08:01:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784275266; bh=Uu0wTGd+OyPGInm31ZdHqR2IOPXBZooPDxLPi8J3bTY=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=MYz8vQ1ELp4H3leqvJQE2fVrTtze647R5VWnOmzIMj260HiJB7r83KFxNB7DqReej IIOUJu6ZODqigChHf894NHWaOpB4Fx+zeKHlghcnnYq/9EifUKgekthv4tqtmleOc3 9UEUtPoStrZu48EH4e+2iEoQdf9OsvGbEjRXWQcw0/f2+kZukQDzf0WO8WoVHsX8Oy 920We/b8tPSeYN/9i9JzZLPIn4b0KTfbIzoQDvWIVB3z8L4WiNbz84jRAMEN5z3fzF SmFJBFqgE+Jru4B5rQkFgwBMyswAtctrLOU+2DvPVIuG2ChJXsWIitfJXh38VNm14F n96E93tnbx2Zw== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/3] spi: amlogic: spisg: Fix the incorrect keep_ss of the last descriptor To: "Xianwei Zhao" Cc: linux-amlogic@lists.infradead.org, devicetree@vger.kernel.org, conor+dt@kernel.org, neil.armstrong@linaro.org, robh@kernel.org In-Reply-To: <20260717-a9-spisg-v1-2-2eeea77be19f@amlogic.com> References: <20260717-a9-spisg-v1-0-2eeea77be19f@amlogic.com> <20260717-a9-spisg-v1-2-2eeea77be19f@amlogic.com> Date: Fri, 17 Jul 2026 08:01:05 +0000 Message-Id: <20260717080105.EA9F51F000E9@smtp.kernel.org> X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtDcml0aWNhbF0gTWlzc2luZyBoYXJkd2FyZSBhYm9ydCBvbiBTUEkgdHJhbnNmZXIgdGltZW91 dCBsZWFkcyB0byBETUEgVXNlLUFmdGVyLUZyZWUgYW5kIG1lbW9yeSBjb3JydXB0aW9uLgotIFtI aWdoXSAzMi1iaXQgaW50ZWdlciBvdmVyZmxvdyBpbiBgc3BpX2RlbGF5X3RvX3NjbGtgIGxlYWRz IHRvIHNldmVyZWx5IHRydW5jYXRlZCBTUEkgZGVsYXlzLgotIFtIaWdoXSBgU1BJU0dfQkxPQ0tf TUFYYCBleGNlZWRzIHRoZSBoYXJkd2FyZSBtYXNrIHNpemUsIGNhdXNpbmcgbWF4aW11bS1sZW5n dGggdHJhbnNmZXJzIHRvIGJlIHByb2Nlc3NlZCBhcyB6ZXJvLWxlbmd0aC4KLSBbSGlnaF0gSGFy ZHdhcmUgbGltaXRzIGZvciBgY3Nfc2V0dXBgIGFuZCBgY3NfaG9sZGAgZGVsYXlzIGFyZSBub3Qg Y2xhbXBlZCBiZWZvcmUgYmVpbmcgcGFja2VkIGludG8gcmVnaXN0ZXIgZmllbGRzLCBjYXVzaW5n IGxvbmcgZGVsYXlzIHRvIHNpbGVudGx5IHdyYXAgYXJvdW5kIHRvIHNob3J0IHZhbHVlcy4KLS0K Ci0tLSBQYXRjaCBbMl06IFtQQVRDSCAyLzNdIHNwaTogYW1sb2dpYzogc3Bpc2c6IEZpeCB0aGUg aW5jb3JyZWN0IGtlZXBfc3Mgb2YgdGhlIGxhc3QgZGVzY3JpcHRvciAtLS0KY29tbWl0IDA3ZjNj Nzg5M2NkOGJkZDM5NDEzMDAyYjVmNjE3YTIyZTkzZTA4NDIKQXV0aG9yOiBTdW5ueSBMdW8gPHN1 bm55Lmx1b0BhbWxvZ2ljLmNvbT4KCnNwaTogYW1sb2dpYzogc3Bpc2c6IEZpeCB0aGUgaW5jb3Jy ZWN0IGtlZXBfc3Mgb2YgdGhlIGxhc3QgZGVzY3JpcHRvcgoKVGhpcyBwYXRjaCBmaXhlcyBhbiBp c3N1ZSB3aGVyZSB0aGUgQ0ZHX0tFRVBfU1MgZmxhZyBpcyB1bmNvbmRpdGlvbmFsbHkKY2xlYXJl ZCBvbiB0aGUgbGFzdCBTUEkgZGVzY3JpcHRvci4gSXQgcmVjb3JkcyB0aGUgY3NfY2hhbmdlIHZh bHVlIG9mCnRoZSBsYXN0IHRyYW5zZmVyIGFuZCBwcm9wZXJseSBwcm9ncmFtcyBDRkdfS0VFUF9T UyBvbiB0aGUgZmluYWwgZGVzY3JpcHRvci4KV2hlbiBhIG51bGwgZGVzY3JpcHRvciBpcyB1c2Vk IGZvciBjcy1ob2xkLCB0aGUgZmxhZyBpcyBrZXB0IG9uIHRoZQpwcmVjZWRpbmcgZGVzY3JpcHRv ciBhbmQgdGhlIHJlY29yZGVkIHZhbHVlIGlzIGFwcGxpZWQgYXQgdGhlIGVuZC4KCj4gZGlmZiAt LWdpdCBhL2RyaXZlcnMvc3BpL3NwaS1hbWxvZ2ljLXNwaXNnLmMgYi9kcml2ZXJzL3NwaS9zcGkt YW1sb2dpYy1zcGlzZy5jCj4gaW5kZXggYWZjOGFmMDQ2MzhkMy4uMGYwMjZkM2U0M2UwYiAxMDA2 NDQKPiAtLS0gYS9kcml2ZXJzL3NwaS9zcGktYW1sb2dpYy1zcGlzZy5jCj4gKysrIGIvZHJpdmVy cy9zcGkvc3BpLWFtbG9naWMtc3Bpc2cuYwo+IEBAIC01MjksOSArNTMwLDExIEBAIHN0YXRpYyBp bnQgYW1sX3NwaXNnX3RyYW5zZmVyX29uZV9tZXNzYWdlKHN0cnVjdCBzcGlfY29udHJvbGxlciAq Y3RsciwKPiAgCQkJCXNwaV9kZWxheV90b19zY2xrKHhmZXItPmVmZmVjdGl2ZV9zcGVlZF9oeiwg Jm1zZy0+c3BpLT5jc19zZXR1cCkpOwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzbid0IGEgYnVn IGludHJvZHVjZWQgYnkgdGhpcyBwYXRjaCwgYnV0IGNhbiB0aGUgMzItYml0IG11bHRpcGxpY2F0 aW9uCmluIHNwaV9kZWxheV90b19zY2xrKCkgb3ZlcmZsb3cgaGVyZT8KCklmIGEgcmVxdWVzdGVk IGRlbGF5IGluIG5hbm9zZWNvbmRzIGFuZCB0aGUgU1BJIGNsb2NrIGZyZXF1ZW5jeSBpbiBIeiBh cmUKbXVsdGlwbGllZCB0b2dldGhlciwgaXQgZXZhbHVhdGVzIGFzIGEgMzItYml0IHVuc2lnbmVk IG9wZXJhdGlvbiBiZWZvcmUgYmVpbmcKY2FzdCB0byA2NC1iaXQgZm9yIHRoZSBkaXZpc2lvbjoK CmRyaXZlcnMvc3BpL3NwaS1hbWxvZ2ljLXNwaXNnLmM6c3BpX2RlbGF5X3RvX3NjbGsoKSB7CiAg ICAuLi4KCXJldHVybiBESVZfUk9VTkRfVVBfVUxMKHNsY2tfc3BlZWRfaHogKiBucywgTlNFQ19Q RVJfU0VDKTsKfQoKRm9yIGV4YW1wbGUsIGF0IGEgMTAwTUh6IGNsb2NrLCBhIGRlbGF5IGdyZWF0 ZXIgdGhhbiA0Mi45dXMgd2lsbCB3cmFwIGFyb3VuZCwKY2F1c2luZyBoYXJkd2FyZSBzZXR1cCBv ciBob2xkIGRlbGF5cyB0byBiZWNvbWUgZXh0cmVtZWx5IHNob3J0IG9yIHplcm8uCgpbU2V2ZXJp dHk6IEhpZ2hdClRoaXMgaXMgYWxzbyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGFyZSB0aGUg aGFyZHdhcmUgbGltaXRzIGZvciBjc19zZXR1cAphbmQgY3NfaG9sZCBkZWxheXMgY2xhbXBlZCBi ZWZvcmUgYmVpbmcgcGFja2VkIGludG8gdGhlIHJlZ2lzdGVyIGZpZWxkcz8KCkNGR19DU19TRVRV UCBpcyBhIDQtYml0IGZpZWxkIChtYXggMTUpLiBJZiBzcGlfZGVsYXlfdG9fc2NsaygpIHJldHVy bnMKYSB2YWx1ZSBncmVhdGVyIHRoYW4gMTUsIEZJRUxEX1BSRVAoKSB3aWxsIHNpbGVudGx5IHRy dW5jYXRlIHRoZSB1cHBlcgpiaXRzLCByZXN1bHRpbmcgaW4gYW4gaW5jb3JyZWN0LCBkcmFzdGlj YWxseSBzaG9ydGVyIGRlbGF5LgoKPiAgCQkvKiBjYWxjdWxhdGUgY3MtaG9sZCBkZWxheSB3aXRo IHRoZSBsYXN0IHhmZXIgc3BlZWQgKi8KPiAtCQlpZiAobGlzdF9pc19sYXN0KCZ4ZmVyLT50cmFu c2Zlcl9saXN0LCAmbXNnLT50cmFuc2ZlcnMpKQo+ICsJCWlmIChsaXN0X2lzX2xhc3QoJnhmZXIt PnRyYW5zZmVyX2xpc3QsICZtc2ctPnRyYW5zZmVycykpIHsKPiAgCQkJY3NfaG9sZF9pbl9zY2xr ID0KPiAgCQkJCXNwaV9kZWxheV90b19zY2xrKHhmZXItPmVmZmVjdGl2ZV9zcGVlZF9oeiwgJm1z Zy0+c3BpLT5jc19ob2xkKTsKPiArCQkJbGFzdF94ZmVyX2tlZXBfc3MgPSB4ZmVyLT5jc19jaGFu Z2U7Cj4gKwkJfQoKWyAuLi4gXQoKW1NldmVyaXR5OiBDcml0aWNhbF0KVGhpcyBpcyBhIHByZS1l eGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMgdGhlIGVycm9yIGhhbmRsaW5nIHBhdGggZm9yIHRpbWVv dXRzIGluCmFtbF9zcGlzZ190cmFuc2Zlcl9vbmVfbWVzc2FnZSgpIGxhY2sgYSBoYXJkd2FyZSBh Ym9ydD8KCklmIGEgaGFyZHdhcmUgdHJhbnNmZXIgdGltZXMgb3V0LCB0aGUgZHJpdmVyIHVubWFw cyBETUEgYnVmZmVycyBhbmQgZnJlZXMgdGhlCnRyYW5zZmVyIGRlc2NyaXB0b3JzIHdpdGhvdXQg c3RvcHBpbmcgdGhlIFNQSSBjb250cm9sbGVyIGhhcmR3YXJlOgoKZHJpdmVycy9zcGkvc3BpLWFt bG9naWMtc3Bpc2cuYzphbWxfc3Bpc2dfdHJhbnNmZXJfb25lX21lc3NhZ2UoKSB7CiAgICAuLi4K CWlmICh3YWl0X2Zvcl9jb21wbGV0aW9uX3RpbWVvdXQoJnNwaXNnLT5jb21wbGV0aW9uLCAuLi4p KQoJCXJldCA9IHNwaXNnLT5zdGF0dXMgPyAtRUlPIDogMDsKCWVsc2UKCQlyZXQgPSAtRVRJTUVE T1VUOwoKCWRtYV91bm1hcF9zaW5nbGUoZGV2LCBkZXNjc19wYWRkciwgZGVzY3NfbGVuLCBETUFf VE9fREVWSUNFKTsKZW5kOgogICAgLi4uCn0KCkNvdWxkIHRoaXMgbGVhZCB0byB0aGUgaGFyZHdh cmUgY29udGludWluZyB0byB3cml0ZSB0byBvciByZWFkIGZyb20gZnJlZWQgbWVtb3J5CnBhZ2Vz IChETUEgVXNlLUFmdGVyLUZyZWUpIHNpbmNlIHRoZSBoYXJkd2FyZSBpc24ndCBzdG9wcGVkPwoK W1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgY2FuIHRo ZSBtYXhpbXVtIGJsb2NrcyBjb3VudCBleGNlZWQgdGhlCmhhcmR3YXJlIG1hc2sgc2l6ZSBpbiBh bWxfc3Bpc2dfc2V0dXBfdHJhbnNmZXIoKT8KClRoZSBibG9ja3MgY291bnQgaXMgY2FwcGVkIGF0 IFNQSVNHX0JMT0NLX01BWCAoMHgxMDAwMDApOgoKZHJpdmVycy9zcGkvc3BpLWFtbG9naWMtc3Bp c2cuYzphbWxfc3Bpc2dfc2V0dXBfdHJhbnNmZXIoKSB7CiAgICAuLi4KCQlibG9ja3MgPSBtaW5f dChpbnQsIGJsb2NrcywgU1BJU0dfQkxPQ0tfTUFYKTsKCQlkZXNjLT5jZmdfc3RhcnQgfD0gRklF TERfUFJFUChDRkdfQkxPQ0tfU0laRSwgYmxvY2tfc2l6ZSAmIDB4NykgfAoJCQkJICAgRklFTERf UFJFUChDRkdfQkxPQ0tfTlVNLCBibG9ja3MpOwogICAgLi4uCn0KClNpbmNlIENGR19CTE9DS19O VU0gdXNlcyBhIDIwLWJpdCBtYXNrIChHRU5NQVNLKDE5LCAwKSksIGEgdHJhbnNmZXIgYm91bmRl ZApleGFjdGx5IGF0IFNQSVNHX0JMT0NLX01BWCAoMHgxMDAwMDApIHdpbGwgYmUgc2lsZW50bHkg emVyb2VkIG91dCB3aGVuIG1hc2tlZCwKY2F1c2luZyBpdCB0byBiZSBwcm9jZXNzZWQgYXMgYSB6 ZXJvLWxlbmd0aCB0cmFuc2Zlci4KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nh c2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA3MTctYTktc3Bpc2ctdjEtMC0yZWVlYTc3YmUxOWZA YW1sb2dpYy5jb20/cGFydD0yCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3Rz LmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5m by9saW51eC1hbWxvZ2ljCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 B103F3328FA for ; Fri, 17 Jul 2026 08:01:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784275267; cv=none; b=qU29iY+k7BnUkavifsurvzkp1CrV0el3RUy4L2AJthK8jWQ+7BunlkgjxKv6nefDf5nzTOhNpBU5cHBg21dOUcdbEGbix9AdLsDWO6MvCwnjsR3dydX0HORoYp+PVLYSVodIszVzg5wu+aZbu5KMukmbmNEVL58NZ9ixwjKL/JU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784275267; c=relaxed/simple; bh=nQaWCPt1P7z1yRrFDCW/WImJ+ZcDX3SQQr4xMEW1bQg=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=EeQLl3pP3kfc1u5b4B4gH+0n82QGniVs8qQ35gF5r+q3f7lVJLSCASX23gXsvlTTnPcLNaESRVk3rtDcYgZa2NeeH4KJJP4RQyNlR+YNYwokEGSc+8g1OxVQzxVs7CjYmBXAu2h9Yp9JCYWhfbvQM2c62zsGRqswSytv67El/bI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MYz8vQ1E; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MYz8vQ1E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA9F51F000E9; Fri, 17 Jul 2026 08:01:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784275266; bh=Uu0wTGd+OyPGInm31ZdHqR2IOPXBZooPDxLPi8J3bTY=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=MYz8vQ1ELp4H3leqvJQE2fVrTtze647R5VWnOmzIMj260HiJB7r83KFxNB7DqReej IIOUJu6ZODqigChHf894NHWaOpB4Fx+zeKHlghcnnYq/9EifUKgekthv4tqtmleOc3 9UEUtPoStrZu48EH4e+2iEoQdf9OsvGbEjRXWQcw0/f2+kZukQDzf0WO8WoVHsX8Oy 920We/b8tPSeYN/9i9JzZLPIn4b0KTfbIzoQDvWIVB3z8L4WiNbz84jRAMEN5z3fzF SmFJBFqgE+Jru4B5rQkFgwBMyswAtctrLOU+2DvPVIuG2ChJXsWIitfJXh38VNm14F n96E93tnbx2Zw== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/3] spi: amlogic: spisg: Fix the incorrect keep_ss of the last descriptor Reply-To: sashiko-reviews@lists.linux.dev To: "Xianwei Zhao" Cc: linux-amlogic@lists.infradead.org, devicetree@vger.kernel.org, conor+dt@kernel.org, neil.armstrong@linaro.org, robh@kernel.org In-Reply-To: <20260717-a9-spisg-v1-2-2eeea77be19f@amlogic.com> References: <20260717-a9-spisg-v1-0-2eeea77be19f@amlogic.com> <20260717-a9-spisg-v1-2-2eeea77be19f@amlogic.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2026 08:01:05 +0000 Message-Id: <20260717080105.EA9F51F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: Pre-existing issues: - [Critical] Missing hardware abort on SPI transfer timeout leads to DMA Us= e-After-Free and memory corruption. - [High] 32-bit integer overflow in `spi_delay_to_sclk` leads to severely t= runcated SPI delays. - [High] `SPISG_BLOCK_MAX` exceeds the hardware mask size, causing maximum-= length transfers to be processed as zero-length. - [High] Hardware limits for `cs_setup` and `cs_hold` delays are not clampe= d before being packed into register fields, causing long delays to silently= wrap around to short values. -- --- Patch [2]: [PATCH 2/3] spi: amlogic: spisg: Fix the incorrect keep_ss o= f the last descriptor --- commit 07f3c7893cd8bdd39413002b5f617a22e93e0842 Author: Sunny Luo spi: amlogic: spisg: Fix the incorrect keep_ss of the last descriptor This patch fixes an issue where the CFG_KEEP_SS flag is unconditionally cleared on the last SPI descriptor. It records the cs_change value of the last transfer and properly programs CFG_KEEP_SS on the final descriptor. When a null descriptor is used for cs-hold, the flag is kept on the preceding descriptor and the recorded value is applied at the end. > diff --git a/drivers/spi/spi-amlogic-spisg.c b/drivers/spi/spi-amlogic-sp= isg.c > index afc8af04638d3..0f026d3e43e0b 100644 > --- a/drivers/spi/spi-amlogic-spisg.c > +++ b/drivers/spi/spi-amlogic-spisg.c > @@ -529,9 +530,11 @@ static int aml_spisg_transfer_one_message(struct spi= _controller *ctlr, > spi_delay_to_sclk(xfer->effective_speed_hz, &msg->spi->cs_setup)); [Severity: High] This isn't a bug introduced by this patch, but can the 32-bit multiplication in spi_delay_to_sclk() overflow here? If a requested delay in nanoseconds and the SPI clock frequency in Hz are multiplied together, it evaluates as a 32-bit unsigned operation before bei= ng cast to 64-bit for the division: drivers/spi/spi-amlogic-spisg.c:spi_delay_to_sclk() { ... return DIV_ROUND_UP_ULL(slck_speed_hz * ns, NSEC_PER_SEC); } For example, at a 100MHz clock, a delay greater than 42.9us will wrap aroun= d, causing hardware setup or hold delays to become extremely short or zero. [Severity: High] This is also a pre-existing issue, but are the hardware limits for cs_setup and cs_hold delays clamped before being packed into the register fields? CFG_CS_SETUP is a 4-bit field (max 15). If spi_delay_to_sclk() returns a value greater than 15, FIELD_PREP() will silently truncate the upper bits, resulting in an incorrect, drastically shorter delay. > /* calculate cs-hold delay with the last xfer speed */ > - if (list_is_last(&xfer->transfer_list, &msg->transfers)) > + if (list_is_last(&xfer->transfer_list, &msg->transfers)) { > cs_hold_in_sclk =3D > spi_delay_to_sclk(xfer->effective_speed_hz, &msg->spi->cs_hold); > + last_xfer_keep_ss =3D xfer->cs_change; > + } [ ... ] [Severity: Critical] This is a pre-existing issue, but does the error handling path for timeouts= in aml_spisg_transfer_one_message() lack a hardware abort? If a hardware transfer times out, the driver unmaps DMA buffers and frees t= he transfer descriptors without stopping the SPI controller hardware: drivers/spi/spi-amlogic-spisg.c:aml_spisg_transfer_one_message() { ... if (wait_for_completion_timeout(&spisg->completion, ...)) ret =3D spisg->status ? -EIO : 0; else ret =3D -ETIMEDOUT; dma_unmap_single(dev, descs_paddr, descs_len, DMA_TO_DEVICE); end: ... } Could this lead to the hardware continuing to write to or read from freed m= emory pages (DMA Use-After-Free) since the hardware isn't stopped? [Severity: High] This is a pre-existing issue, but can the maximum blocks count exceed the hardware mask size in aml_spisg_setup_transfer()? The blocks count is capped at SPISG_BLOCK_MAX (0x100000): drivers/spi/spi-amlogic-spisg.c:aml_spisg_setup_transfer() { ... blocks =3D min_t(int, blocks, SPISG_BLOCK_MAX); desc->cfg_start |=3D FIELD_PREP(CFG_BLOCK_SIZE, block_size & 0x7) | FIELD_PREP(CFG_BLOCK_NUM, blocks); ... } Since CFG_BLOCK_NUM uses a 20-bit mask (GENMASK(19, 0)), a transfer bounded exactly at SPISG_BLOCK_MAX (0x100000) will be silently zeroed out when mask= ed, causing it to be processed as a zero-length transfer. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260717-a9-spisg-v= 1-0-2eeea77be19f@amlogic.com?part=3D2