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 36311C55184 for ; Tue, 4 Aug 2026 15:15:11 +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=RE4c/XeZ4W2MeI1SLPzXpfP/G4fyKI3Czis2B3G8cqw=; b=tKIq0njlm2ZpnI dYxgQ68sj42z3n8x9nf+hFHOebRFpD8m+hGVJmCz+c753Jm2aMKzT/vpSC9w6B+Jl6dx3ZW/s3hka iKVGfwJQcXQ5M29TiFTo/FoWX6jQRhLjsUCuwiZHLwbzs59FvTpn+T2k8dq67xTJhi6sRENXBRhm0 b3kl2JA3IIdg6+XoE5MVLnou+FTbsnjpdXcaRi+ywqKhDwrsdSPusA8Xlm7SylmqMWpleulO+aW4v dg8Y+p4cIwLi1L3x5ZuHFzVzwvSS2KmqQ9KaP3bBKGbxlkAlzO2mQzOLFE+C3cRnxt4isIGWcH6hS /i8Ra3rODGqNRGKJJuPQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wrGrD-00000002BVO-0JKZ; Tue, 04 Aug 2026 15:15:07 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wrGrB-00000002BVI-20m6 for linux-amlogic@lists.infradead.org; Tue, 04 Aug 2026 15:15:05 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 72C6260A73; Tue, 4 Aug 2026 15:15:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEE6C1F000E9; Tue, 4 Aug 2026 15:15:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785856504; bh=FhI9BUnv192/80GxwF7+5RJlRO9MBYLxMpckriGiOSg=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=IImvvaMdLMs7HEc1lhxvH9v8YWZ4ISuHU/6haxSLei+36oYbYFFuOzmA9YLbHuW4k CCcz67igovkZ1E375M02NvPy1RMBo6GSoHdnhg6Oz/3Rldvxe8WPT/SclbzrrJn6RB 5Tx9mYVWmoLJeKLO1e+h8ZZ82ax7wsJ/Lq41KeMTtIDfuRM6iBs0O7RRgSRMsMNqw9 06PLPl5Zjcp8ogBhqd0RWoUamttJ/ZGjPjpUwPbzDtXvrItLg/f9hnbQhwQ4kYElJG 6kWOacY2pyNj6o4gWhyJhvDmzDtQXJesuk8DbL0NvtJWwBcsG41rmozKSfCZxbSWRM Uh/FgaDIKIx/g== From: sashiko-bot@kernel.org Subject: Re: [PATCH v5 3/3] nvmem: make all reg_write callbacks take const void * To: "Link Mauve" Cc: Frank.Li@kernel.org, neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org, imx@lists.linux.dev, ojeda@kernel.org In-Reply-To: <20260804135940.2378737-4-linkmauve@linkmauve.fr> References: <20260804135940.2378737-1-linkmauve@linkmauve.fr> <20260804135940.2378737-4-linkmauve@linkmauve.fr> Date: Tue, 04 Aug 2026 15:15:03 +0000 Message-Id: <20260804151503.CEE6C1F000E9@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 NSBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtDcml0aWNhbF0gS2VybmVsIHN0YWNrIG91dC1vZi1ib3VuZHMgcmVhZCBpbiBgc3ByZF9lZnVz ZV9yZWFkYCBhbmQgbG9naWMgZXJyb3IgaW4gYHNwcmRfZWZ1c2Vfd3JpdGVgLgotIFtIaWdoXSBO dm1lbSBvZmZzZXQgaXMgaW5jb3JyZWN0bHkgdHJlYXRlZCBhcyBhIHdvcmQgaW5kZXggaW5zdGVh ZCBvZiBhIGJ5dGUgb2Zmc2V0LgotIFtIaWdoXSBWYWxpZGF0aW9uIG9mIFBVRiB1c2VyIGZ1c2Vz IGNhbiBiZSBieXBhc3NlZCBkdXJpbmcgbXVsdGktd29yZCB3cml0ZXMuCi0gW0hpZ2hdIFRoZSBP Q09UUCBjb250cm9sbGVyIGlzIHBlcm1hbmVudGx5IGxlZnQgaW4gcHJvZ3JhbW1pbmcgbW9kZSBp ZiBhIHdyaXRlIG9yIHJlYWQgb3BlcmF0aW9uIGZhaWxzLgotIFtIaWdoXSBPUC1URUUgc2Vzc2lv biBpcyBsZWFrZWQgb24gaW52YWxpZCBhcmd1bWVudHMgaW4gc3RtMzJfYnNlY19vcHRlZV90YV93 cml0ZS4KLS0KCi0tLSBQYXRjaCBbM106IFtQQVRDSCB2NSAzLzNdIG52bWVtOiBtYWtlIGFsbCBy ZWdfd3JpdGUgY2FsbGJhY2tzIHRha2UgY29uc3Qgdm9pZCAqIC0tLQpjb21taXQgMDlmNGU2MWQ5 ZTgxZWU1YmUwZmQ5MGM5ZjUzZWM2ZDI5ZGE4YjQxMgpBdXRob3I6IExpbmsgTWF1dmUgPGxpbmtt YXV2ZUBsaW5rbWF1dmUuZnI+ClN1YmplY3Q6IG52bWVtOiBtYWtlIGFsbCByZWdfd3JpdGUgY2Fs bGJhY2tzIHRha2UgY29uc3Qgdm9pZCAqCgpUaGlzIGNvbW1pdCB1cGRhdGVzIHRoZSBudm1lbSBz dWJzeXN0ZW0gdG8gdXNlIGEgcG9pbnRlciB0byBpbW11dGFibGUgZGF0YQpmb3IgYWxsIHJlZ193 cml0ZSBjYWxsYmFja3MuIEl0IG1vZGlmaWVzIHRoZSB2YXJpb3VzIGRyaXZlcnMgdG8gY2hhbmdl IHRoZQpmdW5jdGlvbiBzaWduYXR1cmVzIGFjY29yZGluZ2x5LgoKPiBkaWZmIC0tZ2l0IGEvZHJp dmVycy9udm1lbS9iY20tb2NvdHAuYyBiL2RyaXZlcnMvbnZtZW0vYmNtLW9jb3RwLmMKPiBpbmRl eCAyNDkwZjQ0Y2FhNDA5Li4wMmFkZmQ3ODdkZTg1IDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvbnZt ZW0vYmNtLW9jb3RwLmMKPiArKysgYi9kcml2ZXJzL252bWVtL2JjbS1vY290cC5jClsgLi4uIF0K PiBAQCAtMTc5LDExICsxNzksMTEgQEAgc3RhdGljIGludCBiY21fb3RwY19yZWFkKHZvaWQgKmNv bnRleHQsIHVuc2lnbmVkIGludCBvZmZzZXQsIHZvaWQgKnZhbCwKPiAgCXJldHVybiAwOwo+ICB9 Cj4gIAo+IC1zdGF0aWMgaW50IGJjbV9vdHBjX3dyaXRlKHZvaWQgKmNvbnRleHQsIHVuc2lnbmVk IGludCBvZmZzZXQsIHZvaWQgKnZhbCwKPiAtCXNpemVfdCBieXRlcykKPiArc3RhdGljIGludCBi Y21fb3RwY193cml0ZSh2b2lkICpjb250ZXh0LCB1bnNpZ25lZCBpbnQgb2Zmc2V0LCBjb25zdCB2 b2lkICp2YWwsCj4gKwkJCSAgc2l6ZV90IGJ5dGVzKQo+ICB7Cj4gIAlzdHJ1Y3Qgb3RwY19wcml2 ICpwcml2ID0gY29udGV4dDsKPiAtCXUzMiAqYnVmID0gdmFsOwo+ICsJY29uc3QgdTMyICpidWYg PSB2YWw7Cj4gIAl1MzIgYnl0ZXNfd3JpdHRlbjsKCltTZXZlcml0eTogSGlnaF0KVGhpcyBpcyBh IHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGlmIGEgcmVhZCBvciB3cml0ZSBvcGVyYXRpb24gZmFp bHMgaW4KYmNtX290cGNfcmVhZCgpIG9yIGJjbV9vdHBjX3dyaXRlKCksIGRvZXMgdGhlIGNvbnRy b2xsZXIgZ2V0IHN0dWNrIGluCnByb2dyYW1taW5nIG1vZGU/CgpMb29raW5nIGF0IGJjbV9vdHBj X3dyaXRlKCksIGlmIHBvbGxfY3B1X3N0YXR1cygpIGZhaWxzLCBpdCByZXR1cm5zIGVhcmx5OgoK ICAgICAgICByZXQgPSBwb2xsX2NwdV9zdGF0dXMocHJpdi0+YmFzZSwgT1RQQ19TVEFUX0NNRF9E T05FKTsKICAgICAgICByZXNldF9zdGFydF9iaXQocHJpdi0+YmFzZSk7CiAgICAgICAgaWYgKHJl dCkgewogICAgICAgICAgICAgICAgZGV2X2Vycihwcml2LT5kZXYsICJvdHAgd3JpdGUgZXJyb3I6 IDB4JXgiLCByZXQpOwogICAgICAgICAgICAgICAgcmV0dXJuIC1FSU87CiAgICAgICAgfQoKVGhp cyBieXBhc3NlcyB0aGUgZGlzYWJsZV9vY290cF9wcm9ncmFtKCkgY2xlYW51cC4gQSBzaW1pbGFy IGVhcmx5IHJldHVybgppbiBiY21fb3RwY19yZWFkKCkgYnlwYXNzZXMgcmVzZXRfc3RhcnRfYml0 KCkuCgpDb3VsZCB0aGlzIGxlYXZlIHRoZSBoYXJkd2FyZSB3aXRoIHN0YXJ0IGJpdHMgc2V0IG9y IGluIHByb2dyYW1taW5nIG1vZGU/Cgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL252bWVtL2lteC1v Y290cC1zY3UuYyBiL2RyaXZlcnMvbnZtZW0vaW14LW9jb3RwLXNjdS5jCj4gaW5kZXggNTE3ZDgz ZTExYWYyYy4uNTcwMDgyMjgxMDBmNSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL252bWVtL2lteC1v Y290cC1zY3UuYwo+ICsrKyBiL2RyaXZlcnMvbnZtZW0vaW14LW9jb3RwLXNjdS5jClsgLi4uIF0K PiBAQCAtMTc4LDExICsxNzgsMTEgQEAgc3RhdGljIGludCBpbXhfc2N1X29jb3RwX3JlYWQodm9p ZCAqY29udGV4dCwgdW5zaWduZWQgaW50IG9mZnNldCwKPiAgfQo+ICAKPiAgc3RhdGljIGludCBp bXhfc2N1X29jb3RwX3dyaXRlKHZvaWQgKmNvbnRleHQsIHVuc2lnbmVkIGludCBvZmZzZXQsCj4g LQkJCSAgICAgICB2b2lkICp2YWwsIHNpemVfdCBieXRlcykKPiArCQkJICAgICAgIGNvbnN0IHZv aWQgKnZhbCwgc2l6ZV90IGJ5dGVzKQo+ICB7Cj4gIAlzdHJ1Y3Qgb2NvdHBfcHJpdiAqcHJpdiA9 IGNvbnRleHQ7Cj4gIAlzdHJ1Y3QgYXJtX3NtY2NjX3JlcyByZXM7Cj4gLQl1MzIgKmJ1ZiA9IHZh bDsKPiArCWNvbnN0IHUzMiAqYnVmID0gdmFsOwo+ICAJdTMyIHRtcDsKPiAgCXUzMiBpbmRleDsK CltTZXZlcml0eTogSGlnaF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMg dGhpcyBjb2RlIHRyZWF0IHRoZSBieXRlIG9mZnNldCBhcyBhCndvcmQgaW5kZXg/CgpJbiBib3Ro IGlteF9zY3Vfb2NvdHBfcmVhZCgpIGFuZCBpbXhfc2N1X29jb3RwX3dyaXRlKCksIHRoZSBieXRl IG9mZnNldCBpcwphc3NpZ25lZCBkaXJlY3RseSB0byBpbmRleCB3aXRob3V0IGRpdmlkaW5nIGJ5 IDQ6CgogICAgICAgIGluZGV4ID0gb2Zmc2V0OwoKSWYgYSBjbGllbnQgcmVxdWVzdHMgYSBieXRl IG9mZnNldCBsaWtlIDQsIHdvdWxkbid0IHRoaXMgcmVzdWx0IGluCmFjY2Vzc2luZyB3b3JkIDQg KHdoaWNoIGlzIGJ5dGUgb2Zmc2V0IDE2KSwgcG90ZW50aWFsbHkgcmVhZGluZyBvciB3cml0aW5n CmluY29ycmVjdCBmdXNlcz8KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbnZtZW0vc3ByZC1lZnVz ZS5jIGIvZHJpdmVycy9udm1lbS9zcHJkLWVmdXNlLmMKPiBpbmRleCAxYTdlNGU1ZDhiODZjLi5m OTYwZmE4Y2IyNWNmIDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvbnZtZW0vc3ByZC1lZnVzZS5jCj4g KysrIGIvZHJpdmVycy9udm1lbS9zcHJkLWVmdXNlLmMKWyAuLi4gXQo+IEBAIC0zMjEsNyArMzIx LDcgQEAgc3RhdGljIGludCBzcHJkX2VmdXNlX3JlYWQodm9pZCAqY29udGV4dCwgdTMyIG9mZnNl dCwgdm9pZCAqdmFsLCBzaXplX3QgYnl0ZXMpCj4gIAlyZXR1cm4gcmV0Owo+ICB9Cj4gIAo+IC1z dGF0aWMgaW50IHNwcmRfZWZ1c2Vfd3JpdGUodm9pZCAqY29udGV4dCwgdTMyIG9mZnNldCwgdm9p ZCAqdmFsLCBzaXplX3QgYnl0ZXMpCj4gK3N0YXRpYyBpbnQgc3ByZF9lZnVzZV93cml0ZSh2b2lk ICpjb250ZXh0LCB1MzIgb2Zmc2V0LCBjb25zdCB2b2lkICp2YWwsIHNpemVfdCBieXRlcykKPiAg ewo+ICAJc3RydWN0IHNwcmRfZWZ1c2UgKmVmdXNlID0gY29udGV4dDsKPiAgCWJvb2wgYmxrX2Rv dWJsZSA9IGVmdXNlLT5kYXRhLT5ibGtfZG91YmxlOwoKW1NldmVyaXR5OiBDcml0aWNhbF0KVGhp cyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGNhbiB0aGlzIGxlYWQgdG8gYW4gb3V0LW9m LWJvdW5kcyBrZXJuZWwKc3RhY2sgcmVhZCBpbiBzcHJkX2VmdXNlX3JlYWQoKSBhbmQgbG9naWMg ZXJyb3JzIGluIHNwcmRfZWZ1c2Vfd3JpdGUoKT8KCkluIHNwcmRfZWZ1c2VfcmVhZCgpLCB0aGVy ZSBpcyBhIDQtYnl0ZSBsb2NhbCB2YXJpYWJsZToKCiAgICAgICAgdTMyIGRhdGE7CgpJZiBhIGNh bGxlciByZXF1ZXN0cyBhIG11bHRpLWJ5dGUgcmVhZCB3aGVyZSBieXRlcyA+IDQsIHRoZSBtZW1j cHkgdXNlcyB0aGUKcmVxdWVzdGVkIHNpemU6CgogICAgICAgIG1lbWNweSh2YWwsICZkYXRhLCBi eXRlcyk7CgpEb2VzIHRoaXMgY29weSBvdXQtb2YtYm91bmRzIGtlcm5lbCBzdGFjayBtZW1vcnkg aW50byB0aGUgb3V0cHV0IGJ1ZmZlcj8KClNpbWlsYXJseSwgaW4gc3ByZF9lZnVzZV93cml0ZSgp LCBpdCBwYXNzZXMgdGhlIHJhdyBieXRlIG9mZnNldCBhcyBhIGJsb2NrCmluZGV4IGFuZCB3cml0 ZXMgd2l0aG91dCBsb29waW5nIG92ZXIgdGhlIHJlcXVlc3RlZCBieXRlczoKCiAgICAgICAgcmV0 ID0gc3ByZF9lZnVzZV9yYXdfcHJvZyhlZnVzZSwgb2Zmc2V0LCBibGtfZG91YmxlLCBsb2NrLCB2 YWwpOwoKV291bGQgdGhpcyB3cml0ZSB0byB0aGUgd3JvbmcgaGFyZHdhcmUgYmxvY2sgYW5kIGZh aWwgdG8gcHJvY2VzcyBzaXplcwpsYXJnZXIgdGhhbiBhIHNpbmdsZSB3b3JkPwoKPiBkaWZmIC0t Z2l0IGEvZHJpdmVycy9udm1lbS9zdG0zMi1ic2VjLW9wdGVlLXRhLmMgYi9kcml2ZXJzL252bWVt L3N0bTMyLWJzZWMtb3B0ZWUtdGEuYwo+IGluZGV4IGY4OWNlNzkxZGQxMmEuLjMxODRiOTc2YjFm OTEgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9udm1lbS9zdG0zMi1ic2VjLW9wdGVlLXRhLmMKPiAr KysgYi9kcml2ZXJzL252bWVtL3N0bTMyLWJzZWMtb3B0ZWUtdGEuYwpbIC4uLiBdCj4gQEAgLTIw Myw3ICsyMDMsNyBAQCBpbnQgc3RtMzJfYnNlY19vcHRlZV90YV9yZWFkKHN0cnVjdCB0ZWVfY29u dGV4dCAqY3R4LCB1bnNpZ25lZCBpbnQgb2Zmc2V0LAo+ICAKPiAgLyogc3RtMzJfYnNlY19vcHRl ZV90YV93cml0ZSgpIC0gbnZtZW0gd3JpdGUgYWNjZXNzIHVzaW5nIFBUQSBjbGllbnQgZHJpdmVy ICovCj4gIGludCBzdG0zMl9ic2VjX29wdGVlX3RhX3dyaXRlKHN0cnVjdCB0ZWVfY29udGV4dCAq Y3R4LCB1bnNpZ25lZCBpbnQgbG93ZXIsCj4gLQkJCSAgICAgIHVuc2lnbmVkIGludCBvZmZzZXQs IHZvaWQgKmJ1Ziwgc2l6ZV90IGJ5dGVzKQo+ICsJCQkgICAgICB1bnNpZ25lZCBpbnQgb2Zmc2V0 LCBjb25zdCB2b2lkICpidWYsIHNpemVfdCBieXRlcykKPiAgewlzdHJ1Y3QgdGVlX3NobSAqc2ht Owo+ICAJc3RydWN0IHRlZV9pb2N0bF9pbnZva2VfYXJnIGFyZzsKPiAgCXN0cnVjdCB0ZWVfcGFy YW0gcGFyYW1bMl07CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNz dWUsIGJ1dCBjb3VsZCB0aGlzIGxlYWsgYW4gT1AtVEVFIHNlc3Npb24gb24KaW52YWxpZCBhcmd1 bWVudHM/CgpJbiBzdG0zMl9ic2VjX29wdGVlX3RhX3dyaXRlKCksIHRoZSBzZXNzaW9uIGlzIG9w ZW5lZCwgYnV0IGlmIHRoZQphbGlnbm1lbnQgY2hlY2sgZmFpbHMsIGl0IHJldHVybnMgZWFybHk6 CgogICAgICAgIHJldCA9IHN0bTMyX2JzZWNfdGFfb3Blbl9zZXNzaW9uKGN0eCwgJnNlc3Npb25f aWQpOwogICAgICAgIGlmIChyZXQpCiAgICAgICAgICAgICAgICByZXR1cm4gcmV0OwoKICAgICAg ICAvKiBBbGxvdyBvbmx5IHdyaXRpbmcgY29tcGxldGUgMzItYml0cyBhbGlnbmVkIHdvcmRzICov CiAgICAgICAgaWYgKChieXRlcyAlIDQpIHx8IChvZmZzZXQgJSA0KSkKICAgICAgICAgICAgICAg IHJldHVybiAtRUlOVkFMOwoKRG9lcyByZXR1cm5pbmcgLUVJTlZBTCBieXBhc3Mgc3RtMzJfYnNl Y190YV9jbG9zZV9zZXNzaW9uKCkgYW5kIGV4aGF1c3QKT1AtVEVFIHNlc3Npb25zPwoKPiBkaWZm IC0tZ2l0IGEvZHJpdmVycy9udm1lbS96eW5xbXBfbnZtZW0uYyBiL2RyaXZlcnMvbnZtZW0venlu cW1wX252bWVtLmMKPiBpbmRleCBkMjk3ZmYxNTBkYzAyLi41NDkwNWE2MDgxNTdkIDEwMDY0NAo+ IC0tLSBhL2RyaXZlcnMvbnZtZW0venlucW1wX252bWVtLmMKPiArKysgYi9kcml2ZXJzL252bWVt L3p5bnFtcF9udm1lbS5jClsgLi4uIF0KPiBAQCAtMTgzLDcgKzE4Myw3IEBAIHN0YXRpYyBpbnQg enlucW1wX252bWVtX3JlYWQodm9pZCAqY29udGV4dCwgdW5zaWduZWQgaW50IG9mZnNldCwgdm9p ZCAqdmFsLCBzaXplCj4gIH0KPiAgCj4gIHN0YXRpYyBpbnQgenlucW1wX252bWVtX3dyaXRlKHZv aWQgKmNvbnRleHQsCj4gLQkJCSAgICAgIHVuc2lnbmVkIGludCBvZmZzZXQsIHZvaWQgKnZhbCwg c2l6ZV90IGJ5dGVzKQo+ICsJCQkgICAgICB1bnNpZ25lZCBpbnQgb2Zmc2V0LCBjb25zdCB2b2lk ICp2YWwsIHNpemVfdCBieXRlcykKPiAgewo+ICAJaW50IHB1ZmZsYWcgPSAwOwo+ICAKPiBAQCAt MTk0LDcgKzE5NCw3IEBAIHN0YXRpYyBpbnQgenlucW1wX252bWVtX3dyaXRlKHZvaWQgKmNvbnRl eHQsCj4gIAkJcHVmZmxhZyA9IDE7Cj4gIAo+ICAJcmV0dXJuIHp5bnFtcF9lZnVzZV9hY2Nlc3Mo Y29udGV4dCwgb2Zmc2V0LAo+IC0JCQkJICAgdmFsLCBieXRlcywgRUZVU0VfV1JJVEUsIHB1ZmZs YWcpOwo+ICsJCQkJICAgKHZvaWQgKil2YWwsIGJ5dGVzLCBFRlVTRV9XUklURSwgcHVmZmxhZyk7 Cj4gIH0KCltTZXZlcml0eTogSGlnaF0KVGhpcyBpc24ndCBhIGJ1ZyBpbnRyb2R1Y2VkIGJ5IHRo aXMgcGF0Y2gsIGJ1dCBjYW4gdGhlIFBVRiB1c2VyIGZ1c2UKdmFsaWRhdGlvbiBiZSBieXBhc3Nl ZCBkdXJpbmcgYSBtdWx0aS13b3JkIHdyaXRlPwoKSW4genlucW1wX2VmdXNlX2FjY2VzcygpLCB0 aGUgdmFsaWRhdGlvbiBsb2dpYyBjaGVja3MgdGhlIGZpcnN0IHdvcmQgYW5kCnJlbGllcyBvbiBh biBleGFjdCBtYXRjaCBvZiB0aGUgc3RhcnRpbmcgb2Zmc2V0OgoKICAgICAgICBpZiAocHVmZmxh ZyA9PSAxICYmIGZsYWcgPT0gRUZVU0VfV1JJVEUpIHsKICAgICAgICAgICAgICAgIG1lbWNweSgm dmFsdWUsIHZhbCwgc2l6ZW9mKHZhbHVlKSk7CiAgICAgICAgICAgICAgICBpZiAoKG9mZnNldCA9 PSBFRlVTRV9QVUZfU1RBUlRfT0ZGU0VUIHx8CiAgICAgICAgICAgICAgICAgICAgIG9mZnNldCA9 PSBFRlVTRV9QVUZfTUlEX09GRlNFVCkgJiYKICAgICAgICAgICAgICAgICAgICAgLi4uKQoKSWYg YSBtdWx0aS13b3JkIHdyaXRlIHN0YXJ0cyBiZWZvcmUgdGhlIHJlc3RyaWN0ZWQgb2Zmc2V0cywg aXQgYnlwYXNzZXMgdGhlCmV4YWN0LW1hdGNoIG9mZnNldCBjaGVja3MuIEluIHRoaXMgc2NlbmFy aW8sIHB1ZmZsYWcgZXZhbHVhdGVzIHRvIDAsIHdoaWNoCmNvbXBsZXRlbHkgZGlzYWJsZXMgdGhl IFBVRi1zcGVjaWZpYyB2YWxpZGF0aW9uIGxvZ2ljIGZvciB0aGUgb3ZlcmxhcHBpbmcKd29yZHMu CgpDb3VsZCB0aGlzIGFsbG93IGZvcmJpZGRlbiBiaXRzIGluIHRoZSBQVUYgZnVzZXMgdG8gYmUg cHJvZ3JhbW1lZD8KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2 LyMvcGF0Y2hzZXQvMjAyNjA4MDQxMzU5NDAuMjM3ODczNy0xLWxpbmttYXV2ZUBsaW5rbWF1dmUu ZnI/cGFydD0zCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVh ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1h bWxvZ2ljCg== 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 867D43290B7 for ; Tue, 4 Aug 2026 15:15: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=1785856512; cv=none; b=FEgXJQyAsbvehkYi63h2FcktA5GHB0qsIBQ8MWB/HggoQKPbqzkiarJ6nvRTOu/49gl45YoqbtPczCKpaGcXkRDPV0bcxwMN09N1SbLRJ9+3AsU5stA/IDY4JDv5yExSO7wOhX/5AOK6tCaYge+VOUCTJ9RrE55lH0XzevEgVTc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785856512; c=relaxed/simple; bh=qmZB4KhpUm4eDJ0imx/164KLkZTYeNHc46mRM9h+QfM=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=eyoBEb4H58JwlUcDXA8H8+87fRKLch8dCAGogZ7JUfvLBUeII1GXUjQuI6rzZ/sCDY0G1K23p7JmT6ikKerT2ACgekdl/3e4W+5QHvJpqgZJihiWD4GB0ccd7C82zbjHf0RAS5KDFPYqDIIdQzEQbQ+XZrQbd8REIPC+nQuVmvc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IImvvaMd; 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="IImvvaMd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEE6C1F000E9; Tue, 4 Aug 2026 15:15:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785856504; bh=FhI9BUnv192/80GxwF7+5RJlRO9MBYLxMpckriGiOSg=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=IImvvaMdLMs7HEc1lhxvH9v8YWZ4ISuHU/6haxSLei+36oYbYFFuOzmA9YLbHuW4k CCcz67igovkZ1E375M02NvPy1RMBo6GSoHdnhg6Oz/3Rldvxe8WPT/SclbzrrJn6RB 5Tx9mYVWmoLJeKLO1e+h8ZZ82ax7wsJ/Lq41KeMTtIDfuRM6iBs0O7RRgSRMsMNqw9 06PLPl5Zjcp8ogBhqd0RWoUamttJ/ZGjPjpUwPbzDtXvrItLg/f9hnbQhwQ4kYElJG 6kWOacY2pyNj6o4gWhyJhvDmzDtQXJesuk8DbL0NvtJWwBcsG41rmozKSfCZxbSWRM Uh/FgaDIKIx/g== From: sashiko-bot@kernel.org Subject: Re: [PATCH v5 3/3] nvmem: make all reg_write callbacks take const void * Reply-To: sashiko-reviews@lists.linux.dev To: "Link Mauve" Cc: Frank.Li@kernel.org, neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org, imx@lists.linux.dev, ojeda@kernel.org In-Reply-To: <20260804135940.2378737-4-linkmauve@linkmauve.fr> References: <20260804135940.2378737-1-linkmauve@linkmauve.fr> <20260804135940.2378737-4-linkmauve@linkmauve.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 04 Aug 2026 15:15:03 +0000 Message-Id: <20260804151503.CEE6C1F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 5 potential issue(= s) to consider: Pre-existing issues: - [Critical] Kernel stack out-of-bounds read in `sprd_efuse_read` and logic= error in `sprd_efuse_write`. - [High] Nvmem offset is incorrectly treated as a word index instead of a b= yte offset. - [High] Validation of PUF user fuses can be bypassed during multi-word wri= tes. - [High] The OCOTP controller is permanently left in programming mode if a = write or read operation fails. - [High] OP-TEE session is leaked on invalid arguments in stm32_bsec_optee_= ta_write. -- --- Patch [3]: [PATCH v5 3/3] nvmem: make all reg_write callbacks take cons= t void * --- commit 09f4e61d9e81ee5be0fd90c9f53ec6d29da8b412 Author: Link Mauve Subject: nvmem: make all reg_write callbacks take const void * This commit updates the nvmem subsystem to use a pointer to immutable data for all reg_write callbacks. It modifies the various drivers to change the function signatures accordingly. > diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c > index 2490f44caa409..02adfd787de85 100644 > --- a/drivers/nvmem/bcm-ocotp.c > +++ b/drivers/nvmem/bcm-ocotp.c [ ... ] > @@ -179,11 +179,11 @@ static int bcm_otpc_read(void *context, unsigned in= t offset, void *val, > return 0; > } > =20 > -static int bcm_otpc_write(void *context, unsigned int offset, void *val, > - size_t bytes) > +static int bcm_otpc_write(void *context, unsigned int offset, const void= *val, > + size_t bytes) > { > struct otpc_priv *priv =3D context; > - u32 *buf =3D val; > + const u32 *buf =3D val; > u32 bytes_written; [Severity: High] This is a pre-existing issue, but if a read or write operation fails in bcm_otpc_read() or bcm_otpc_write(), does the controller get stuck in programming mode? Looking at bcm_otpc_write(), if poll_cpu_status() fails, it returns early: ret =3D poll_cpu_status(priv->base, OTPC_STAT_CMD_DONE); reset_start_bit(priv->base); if (ret) { dev_err(priv->dev, "otp write error: 0x%x", ret); return -EIO; } This bypasses the disable_ocotp_program() cleanup. A similar early return in bcm_otpc_read() bypasses reset_start_bit(). Could this leave the hardware with start bits set or in programming mode? > diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c > index 517d83e11af2c..57008228100f5 100644 > --- a/drivers/nvmem/imx-ocotp-scu.c > +++ b/drivers/nvmem/imx-ocotp-scu.c [ ... ] > @@ -178,11 +178,11 @@ static int imx_scu_ocotp_read(void *context, unsign= ed int offset, > } > =20 > static int imx_scu_ocotp_write(void *context, unsigned int offset, > - void *val, size_t bytes) > + const void *val, size_t bytes) > { > struct ocotp_priv *priv =3D context; > struct arm_smccc_res res; > - u32 *buf =3D val; > + const u32 *buf =3D val; > u32 tmp; > u32 index; [Severity: High] This is a pre-existing issue, but does this code treat the byte offset as a word index? In both imx_scu_ocotp_read() and imx_scu_ocotp_write(), the byte offset is assigned directly to index without dividing by 4: index =3D offset; If a client requests a byte offset like 4, wouldn't this result in accessing word 4 (which is byte offset 16), potentially reading or writing incorrect fuses? > diff --git a/drivers/nvmem/sprd-efuse.c b/drivers/nvmem/sprd-efuse.c > index 1a7e4e5d8b86c..f960fa8cb25cf 100644 > --- a/drivers/nvmem/sprd-efuse.c > +++ b/drivers/nvmem/sprd-efuse.c [ ... ] > @@ -321,7 +321,7 @@ static int sprd_efuse_read(void *context, u32 offset,= void *val, size_t bytes) > return ret; > } > =20 > -static int sprd_efuse_write(void *context, u32 offset, void *val, size_t= bytes) > +static int sprd_efuse_write(void *context, u32 offset, const void *val, = size_t bytes) > { > struct sprd_efuse *efuse =3D context; > bool blk_double =3D efuse->data->blk_double; [Severity: Critical] This is a pre-existing issue, but can this lead to an out-of-bounds kernel stack read in sprd_efuse_read() and logic errors in sprd_efuse_write()? In sprd_efuse_read(), there is a 4-byte local variable: u32 data; If a caller requests a multi-byte read where bytes > 4, the memcpy uses the requested size: memcpy(val, &data, bytes); Does this copy out-of-bounds kernel stack memory into the output buffer? Similarly, in sprd_efuse_write(), it passes the raw byte offset as a block index and writes without looping over the requested bytes: ret =3D sprd_efuse_raw_prog(efuse, offset, blk_double, lock, val); Would this write to the wrong hardware block and fail to process sizes larger than a single word? > diff --git a/drivers/nvmem/stm32-bsec-optee-ta.c b/drivers/nvmem/stm32-bs= ec-optee-ta.c > index f89ce791dd12a..3184b976b1f91 100644 > --- a/drivers/nvmem/stm32-bsec-optee-ta.c > +++ b/drivers/nvmem/stm32-bsec-optee-ta.c [ ... ] > @@ -203,7 +203,7 @@ int stm32_bsec_optee_ta_read(struct tee_context *ctx,= unsigned int offset, > =20 > /* stm32_bsec_optee_ta_write() - nvmem write access using PTA client dri= ver */ > int stm32_bsec_optee_ta_write(struct tee_context *ctx, unsigned int lowe= r, > - unsigned int offset, void *buf, size_t bytes) > + unsigned int offset, const void *buf, size_t bytes) > { struct tee_shm *shm; > struct tee_ioctl_invoke_arg arg; > struct tee_param param[2]; [Severity: High] This is a pre-existing issue, but could this leak an OP-TEE session on invalid arguments? In stm32_bsec_optee_ta_write(), the session is opened, but if the alignment check fails, it returns early: ret =3D stm32_bsec_ta_open_session(ctx, &session_id); if (ret) return ret; /* Allow only writing complete 32-bits aligned words */ if ((bytes % 4) || (offset % 4)) return -EINVAL; Does returning -EINVAL bypass stm32_bsec_ta_close_session() and exhaust OP-TEE sessions? > diff --git a/drivers/nvmem/zynqmp_nvmem.c b/drivers/nvmem/zynqmp_nvmem.c > index d297ff150dc02..54905a608157d 100644 > --- a/drivers/nvmem/zynqmp_nvmem.c > +++ b/drivers/nvmem/zynqmp_nvmem.c [ ... ] > @@ -183,7 +183,7 @@ static int zynqmp_nvmem_read(void *context, unsigned = int offset, void *val, size > } > =20 > static int zynqmp_nvmem_write(void *context, > - unsigned int offset, void *val, size_t bytes) > + unsigned int offset, const void *val, size_t bytes) > { > int pufflag =3D 0; > =20 > @@ -194,7 +194,7 @@ static int zynqmp_nvmem_write(void *context, > pufflag =3D 1; > =20 > return zynqmp_efuse_access(context, offset, > - val, bytes, EFUSE_WRITE, pufflag); > + (void *)val, bytes, EFUSE_WRITE, pufflag); > } [Severity: High] This isn't a bug introduced by this patch, but can the PUF user fuse validation be bypassed during a multi-word write? In zynqmp_efuse_access(), the validation logic checks the first word and relies on an exact match of the starting offset: if (pufflag =3D=3D 1 && flag =3D=3D EFUSE_WRITE) { memcpy(&value, val, sizeof(value)); if ((offset =3D=3D EFUSE_PUF_START_OFFSET || offset =3D=3D EFUSE_PUF_MID_OFFSET) && ...) If a multi-word write starts before the restricted offsets, it bypasses the exact-match offset checks. In this scenario, pufflag evaluates to 0, which completely disables the PUF-specific validation logic for the overlapping words. Could this allow forbidden bits in the PUF fuses to be programmed? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804135940.2378= 737-1-linkmauve@linkmauve.fr?part=3D3