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 79D92C531C9 for ; Sun, 26 Jul 2026 13:30:49 +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=4jUYnebB+14L0kGQOpCJvFkJhcCPfPnbUk+3ycEN+NY=; b=1B5h0pRixxCMxw D7/jepCsr5MfXzZm7ldKmtprCAh8ZMt/U8ACORI9Ht2g1i/GK2DrsVY8jYQTeLuZdxVuiTW0sDl9e u4V1V+pBrFrSWqdpHP9acQjeiDmJB1pXRfRIXA9RJm0fdrld8WPnw6LSuzkJT+cjVXvCSnIi9dPJc 9Tg0JVfJOPRHnBLDRvuj/stZM0svL5xk08jvFHzCU3B/Isiprl5qXWErD4M7nruJr1zLJ43nM02nV p2HBWAxe5/4WMxKJRFfR02IZfX1xBzXN3VyGV7npez7WGdp16bHLMqN2/AW5qJ3pH9MLoiOdtcMtY KQBJ8fzYKNOZqENCXgiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wnywF-00000001Czp-01L3; Sun, 26 Jul 2026 13:30:43 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wnywD-00000001CzT-2vqS for linux-amlogic@lists.infradead.org; Sun, 26 Jul 2026 13:30:41 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 52D7A40060; Sun, 26 Jul 2026 13:30:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF58C1F000E9; Sun, 26 Jul 2026 13:30:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785072640; bh=ygKL8b5S+/5opKlW5/5kSiAhU39LSuImXVnR8LGoXGU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=EzbhPfvqXszQ0+d0hzsUO/07oxZ2s9l4k3VFdRRqwKVfJ65VEYnvkcJcXScsFw+x9 K9j5vyaZde3xQlThfcGHwQFqTWarORzkI2zsM9CO4UzRPr6FtqZBX1E88ytASChQda xbb6SyZ0+U+L5EyxEP9cA/doiYvT38yjaBeKlf591x/22dLPNSbAqZK68XPYkPO5Jt cfTmIYeXbVd2kPQtTLNF4LQd/rtTaXHJIm4Oxw3G/NwqZDMf8R9qUwNaXCnZ8B4xw8 6vhcuYhoDds0Wi14LsbPnzX35N3R64S0Cv9cP4pMozD1WnwwoNvx271YLZ2W5mA+5N 7ghR/LC+L68EA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v4 3/3] nvmem: make all reg_write callbacks take const void * To: "Link Mauve" Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org, ojeda@kernel.org, imx@lists.linux.dev, Frank.Li@kernel.org In-Reply-To: <20260726131724.15299-4-linkmauve@linkmauve.fr> References: <20260726131724.15299-1-linkmauve@linkmauve.fr> <20260726131724.15299-4-linkmauve@linkmauve.fr> Date: Sun, 26 Jul 2026 13:30:39 +0000 Message-Id: <20260726133039.CF58C1F000E9@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtNZWRpdW1d IFRoZSBwYXRjaCBjbGFpbXMgdG8gJ21ha2UgYWxsIHJlZ193cml0ZSBjYWxsYmFja3MgdGFrZSBj b25zdCB2b2lkIConIGFuZCAnZml4IGFsbCB1c2VycyBvZiB0aGlzIEFQSScsIGJ1dCBpdCBmYWls cyB0byBtaWdyYXRlIG1hbnkgbnZtZW0gZHJpdmVycy4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0g W0NyaXRpY2FsXSBUaGUgYHNwcmRfZWZ1c2Vfd3JpdGVgIGZ1bmN0aW9uIHJlYWRzIG91dC1vZi1i b3VuZHMgZm9yIHNtYWxsIHdyaXRlcyBhbmQgc2lsZW50bHkgdHJ1bmNhdGVzIGxhcmdlIHdyaXRl cywgd2hpbGUgYHNwcmRfZWZ1c2VfcmVhZGAgc3VmZmVycyBmcm9tIGEgc3RhY2sgYnVmZmVyIG92 ZXJmbG93LgotIFtIaWdoXSBUaGUgYGJjbV9vdHBjX3dyaXRlYCBmdW5jdGlvbiBwZXJmb3JtcyBh biBvdXQtb2YtYm91bmRzIHJlYWQgd2hlbiBgYnl0ZXNgIGlzIG5vdCBhIG11bHRpcGxlIG9mIGBv dHBjX3Jvd19zaXplICogd29yZF9zaXplYC4KLSBbSGlnaF0gVGhlIGBscGMxOHh4X2VlcHJvbV9n YXRoZXJfd3JpdGVgIGFuZCBgbHBjMTh4eF9lZXByb21fcmVhZGAgZnVuY3Rpb25zIHdpbGwgZW50 ZXIgYW4gaW5maW5pdGUgbG9vcCBhbmQgY2F1c2UgT09CIG1lbW9yeSBhY2Nlc3MgaWYgYGJ5dGVz YCBpcyBub3QgYSBtdWx0aXBsZSBvZiA0LgotLQoKLS0tIFBhdGNoIFszXTogW1BBVENIIHY0IDMv M10gbnZtZW06IG1ha2UgYWxsIHJlZ193cml0ZSBjYWxsYmFja3MgdGFrZSBjb25zdCB2b2lkICog LS0tCmNvbW1pdCA0ZjFiZDk0ZGE5ZjhjNWJhM2UyMWM4NjlkMDg5YTFhNzFlZWNjYmM3CkF1dGhv cjogTGluayBNYXV2ZSA8bGlua21hdXZlQGxpbmttYXV2ZS5mcj4KCm52bWVtOiBtYWtlIGFsbCBy ZWdfd3JpdGUgY2FsbGJhY2tzIHRha2UgY29uc3Qgdm9pZCAqCgpUaGUgcHJldmlvdXMgY29tbWl0 IHN3aXRjaGVkIGZyb20gYSBwb2ludGVyIHRvIG11dGFibGUgZGF0YSB0byBhIHBvaW50ZXIKdG8g aW1tdXRhYmxlIGRhdGEsIHNvIGxldOKAmXMgZml4IGFsbCB1c2VycyBvZiB0aGlzIEFQSS4KCj4g bnZtZW06IG1ha2UgYWxsIHJlZ193cml0ZSBjYWxsYmFja3MgdGFrZSBjb25zdCB2b2lkICoKPgo+ IFRoZSBwcmV2aW91cyBjb21taXQgc3dpdGNoZWQgZnJvbSBhIHBvaW50ZXIgdG8gbXV0YWJsZSBk YXRhIHRvIGEgcG9pbnRlcgo+IHRvIGltbXV0YWJsZSBkYXRhLCBzbyBsZXTigJlzIGZpeCBhbGwg dXNlcnMgb2YgdGhpcyBBUEkuCgpbU2V2ZXJpdHk6IE1lZGl1bV0KSXMgdGhpcyBjb21taXQgbWVz c2FnZSBhY2N1cmF0ZSByZWdhcmRpbmcgZml4aW5nIGFsbCB1c2Vycz8KCkFsdGhvdWdoIG1hbnkg ZmlsZXMgYXJlIHVwZGF0ZWQsIHByb21pbmVudCBkcml2ZXJzIGxpa2UgYXQyNC5jIGFuZCBhdDI1 LmMKKGFuZCBvdGhlcnMgb3V0c2lkZSBkcml2ZXJzL252bWVtLykgc3RpbGwgYXBwZWFyIHRvIHVz ZSB0aGUgbGVnYWN5Ci5yZWdfd3JpdGUgY2FsbGJhY2sgd2l0aCB0aGUgbXV0YWJsZSB2b2lkICog c2lnbmF0dXJlLgoKQ291bGQgdGhlIGNvbW1pdCBtZXNzYWdlIGJlIGNsYXJpZmllZCB0byBzdGF0 ZSB0aGF0IGl0IG9ubHkgdXBkYXRlcyBhIHN1YnNldApvZiBkcml2ZXJzPwoKPiBkaWZmIC0tZ2l0 IGEvZHJpdmVycy9udm1lbS9iY20tb2NvdHAuYyBiL2RyaXZlcnMvbnZtZW0vYmNtLW9jb3RwLmMK PiBpbmRleCAyNDkwZjQ0Y2FhNDA5Li4wMmFkZmQ3ODdkZTg1IDEwMDY0NAo+IC0tLSBhL2RyaXZl cnMvbnZtZW0vYmNtLW9jb3RwLmMKPiArKysgYi9kcml2ZXJzL252bWVtL2JjbS1vY290cC5jClsg Li4uIF0KPiBAQCAtMTc5LDExICsxNzksMTEgQEAgc3RhdGljIGludCBiY21fb3RwY19yZWFkKHZv aWQgKmNvbnRleHQsIHVuc2lnbmVkIGludCBvZmZzZXQsIHZvaWQgKnZhbCwKPiAgCXJldHVybiAw Owo+ICB9Cj4gIAo+IC1zdGF0aWMgaW50IGJjbV9vdHBjX3dyaXRlKHZvaWQgKmNvbnRleHQsIHVu c2lnbmVkIGludCBvZmZzZXQsIHZvaWQgKnZhbCwKPiAtCXNpemVfdCBieXRlcykKPiArc3RhdGlj IGludCBiY21fb3RwY193cml0ZSh2b2lkICpjb250ZXh0LCB1bnNpZ25lZCBpbnQgb2Zmc2V0LCBj b25zdCB2b2lkICp2YWwsCj4gKwkJCSAgc2l6ZV90IGJ5dGVzKQo+ICB7Cj4gIAlzdHJ1Y3Qgb3Rw Y19wcml2ICpwcml2ID0gY29udGV4dDsKPiAtCXUzMiAqYnVmID0gdmFsOwo+ICsJY29uc3QgdTMy ICpidWYgPSB2YWw7Cj4gIAl1MzIgYnl0ZXNfd3JpdHRlbjsKCltTZXZlcml0eTogSGlnaF0KVGhp cyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMgYmNtX290cGNfd3JpdGUoKSBoYXZl IGFuIG91dC1vZi1ib3VuZHMKcmVhZCBpZiBieXRlcyBpcyBub3QgYSBtdWx0aXBsZSBvZiBvdHBj X3Jvd19zaXplICogd29yZF9zaXplPwoKSWYgb3RwY19yb3dfc2l6ZSA+IDEgKGxpa2UgMiBmb3Ig dGhlIHYyIG1hcCkgYW5kIHRoZSBudm1lbSBjb3JlIHBhc3NlcwpieXRlcyA9IDQsIHRoZSBpbm5l ciBsb29wIGl0ZXJhdGVzIHR3aWNlOgoKICAgIGZvciAoaSA9IDA7IGkgPCBwcml2LT5tYXAtPm90 cGNfcm93X3NpemU7IGkrKykgewogICAgICAgIHdyaXRlbCgqYnVmLCBwcml2LT5iYXNlICsgcHJp di0+bWFwLT5kYXRhX3dfb2Zmc2V0W2ldKTsKICAgICAgICBidWYrKzsKICAgICAgICBieXRlc193 cml0dGVuICs9IHNpemVvZigqYnVmKTsKICAgIH0KCkRvZXMgdGhpcyBjYXVzZSBidWYgdG8gYWR2 YW5jZSBiZXlvbmQgdGhlIHByb3ZpZGVkIGxlbmd0aCBhbmQgcmVhZAp1bmluaXRpYWxpemVkIGtl cm5lbCBtZW1vcnkgaW50byB0aGUgaGFyZHdhcmU/CgpbIC4uLiBdCj4gZGlmZiAtLWdpdCBhL2Ry aXZlcnMvbnZtZW0vbHBjMTh4eF9lZXByb20uYyBiL2RyaXZlcnMvbnZtZW0vbHBjMTh4eF9lZXBy b20uYwo+IGluZGV4IDUwNDE1NWUzMGJhYjIuLjc4YTM1ZWYwOTVmYmQgMTAwNjQ0Cj4gLS0tIGEv ZHJpdmVycy9udm1lbS9scGMxOHh4X2VlcHJvbS5jCj4gKysrIGIvZHJpdmVycy9udm1lbS9scGMx OHh4X2VlcHJvbS5jClsgLi4uIF0KPiBAQCAtMTA5LDcgKzEwOSw3IEBAIHN0YXRpYyBpbnQgbHBj MTh4eF9lZXByb21fZ2F0aGVyX3dyaXRlKHZvaWQgKmNvbnRleHQsIHVuc2lnbmVkIGludCByZWcs Cj4gIAl1c2xlZXBfcmFuZ2UoMTAwLCAyMDApOwo+ICAKPiAgCXdoaWxlIChieXRlcykgewo+IC0J CXdyaXRlbCgqKHUzMiAqKXZhbCwgZWVwcm9tLT5tZW1fYmFzZSArIG9mZnNldCk7Cj4gKwkJd3Jp dGVsKCooY29uc3QgdTMyICopdmFsLCBlZXByb20tPm1lbV9iYXNlICsgb2Zmc2V0KTsKPiAgCQly ZXQgPSBscGMxOHh4X2VlcHJvbV9idXN5d2FpdF91bnRpbF9wcm9nKGVlcHJvbSk7CgpbU2V2ZXJp dHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBjYW4gdGhpcyBsb29w IHJ1biBpbmZpbml0ZWx5IGlmIGJ5dGVzIGlzCm5vdCBhIG11bHRpcGxlIG9mIDQ/CgpUaGUgbG9v cCBkZWNyZW1lbnRzIHRoZSB1bnNpZ25lZCBieXRlcyB2YXJpYWJsZSB1bmNvbmRpdGlvbmFsbHkg YnkgNDoKCiAgICBieXRlcyAtPSBlZXByb20tPnZhbF9ieXRlczsKCklmIHRoZSBudm1lbSBjb3Jl IHBhc3NlcyBhbiB1bmFsaWduZWQgYnl0ZXMgdmFsdWUsIGRvZXMgdGhpcyBzdWJ0cmFjdGlvbgp1 bmRlcmZsb3cgYW5kIGNhdXNlIHRoZSBsb29wIHRvIHJ1biBpbmRlZmluaXRlbHksIGxlYWRpbmcg dG8gb3V0LW9mLWJvdW5kcwptZW1vcnkgYWNjZXNzPyBJdCBhcHBlYXJzIGxwYzE4eHhfZWVwcm9t X3JlYWQoKSBzaGFyZXMgdGhpcyBiZWhhdmlvci4KClsgLi4uIF0KPiBkaWZmIC0tZ2l0IGEvZHJp dmVycy9udm1lbS9zcHJkLWVmdXNlLmMgYi9kcml2ZXJzL252bWVtL3NwcmQtZWZ1c2UuYwo+IGlu ZGV4IDFhN2U0ZTVkOGI4NmMuLmY5NjBmYThjYjI1Y2YgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9u dm1lbS9zcHJkLWVmdXNlLmMKPiArKysgYi9kcml2ZXJzL252bWVtL3NwcmQtZWZ1c2UuYwo+IEBA IC0xOTIsNyArMTkyLDcgQEAgc3RhdGljIHZvaWQgc3ByZF9lZnVzZV9zZXRfcHJvZ19lbihzdHJ1 Y3Qgc3ByZF9lZnVzZSAqZWZ1c2UsIGJvb2wgZW4pCj4gIH0KPiAgCj4gIHN0YXRpYyBpbnQgc3By ZF9lZnVzZV9yYXdfcHJvZyhzdHJ1Y3Qgc3ByZF9lZnVzZSAqZWZ1c2UsIHUzMiBibGssIGJvb2wg ZG91YiwKPiAtCQkJICAgICAgIGJvb2wgbG9jaywgdTMyICpkYXRhKQo+ICsJCQkgICAgICAgYm9v bCBsb2NrLCBjb25zdCB1MzIgKmRhdGEpCj4gIHsKCltTZXZlcml0eTogQ3JpdGljYWxdClRoaXMg aXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIHNwcmRfZWZ1c2VfcmF3X3Byb2coKSBy ZWFkIG91dCBvZgpib3VuZHMgZm9yIHNtYWxsIHdyaXRlcz8KCkJ5IGRlcmVmZXJlbmNpbmcgZGF0 YSBhcyBhIDMyLWJpdCBpbnRlZ2VyOgoKICAgIHdyaXRlbCgqZGF0YSwgZWZ1c2UtPmJhc2UgKyBT UFJEX0VGVVNFX01FTShibGspKTsKCkNvdWxkIHRoaXMgY2F1c2UgYW4gb3V0LW9mLWJvdW5kcyBy ZWFkIGlmIHRoZSBpbmNvbWluZyBidWZmZXIgaXMgbGVzcyB0aGFuCjQgYnl0ZXMgbG9uZz8KClsg Li4uIF0KPiBAQCAtMzIxLDcgKzMyMSw3IEBAIHN0YXRpYyBpbnQgc3ByZF9lZnVzZV9yZWFkKHZv aWQgKmNvbnRleHQsIHUzMiBvZmZzZXQsIHZvaWQgKnZhbCwgc2l6ZV90IGJ5dGVzKQo+ICAJcmV0 dXJuIHJldDsKPiAgfQo+ICAKPiAtc3RhdGljIGludCBzcHJkX2VmdXNlX3dyaXRlKHZvaWQgKmNv bnRleHQsIHUzMiBvZmZzZXQsIHZvaWQgKnZhbCwgc2l6ZV90IGJ5dGVzKQo+ICtzdGF0aWMgaW50 IHNwcmRfZWZ1c2Vfd3JpdGUodm9pZCAqY29udGV4dCwgdTMyIG9mZnNldCwgY29uc3Qgdm9pZCAq dmFsLCBzaXplX3QgYnl0ZXMpCj4gIHsKCltTZXZlcml0eTogQ3JpdGljYWxdClRoaXMgaXMgYSBw cmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBpcyB0aGVyZSBhIHN0YWNrIG1lbW9yeSBsZWFrIGluCnNw cmRfZWZ1c2VfcmVhZCgpPwoKV2hlbiB0aGUgbnZtZW0gY29yZSBwYXNzZXMgYSBsZW5ndGggdXAg dG8gUEFHRV9TSVpFICg0MDk2KSBmb3Igc3lzZnMgcmVhZHMsCnNwcmRfZWZ1c2VfcmVhZCgpIGFs bG9jYXRlcyBhIGxvY2FsIDQtYnl0ZSBkYXRhIHZhcmlhYmxlIG9uIHRoZSBzdGFjazoKCiAgICB1 MzIgZGF0YTsKICAgIC4uLgogICAgbWVtY3B5KHZhbCwgJmRhdGEsIGJ5dGVzKTsKCklmIGJ5dGVz ID4gNCwgd291bGQgdGhpcyBjb3B5IHVwIHRvIDQwOTIgYnl0ZXMgb2Ygc3RhY2sgbWVtb3J5IHRv IHRoZQpvdXRwdXQgYnVmZmVyPwoKLS0gClNhc2hpa28gQUkgcmV2aWV3IMK3IGh0dHBzOi8vc2Fz aGlrby5kZXYvIy9wYXRjaHNldC8yMDI2MDcyNjEzMTcyNC4xNTI5OS0xLWxpbmttYXV2ZUBsaW5r bWF1dmUuZnI/cGFydD0zCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmlu ZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9s aW51eC1hbWxvZ2ljCg== 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 7439039A4A4 for ; Sun, 26 Jul 2026 13:30:40 +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=1785072641; cv=none; b=Ed0yTYfnvdSD5r4wVtWoZZ8B9NYtz73LixtGsZfaKG4GGXJbdFjNoZTA/3G/yZcP7MGWaMzrGiYtwQGzETWvC8M7LKJjeiij/p9StrK+pEy1CIa4VOcgg9m0isaLaisvquV6jsqIGqgZ6x2121HlbpOVUPIcBqUQsmhGKr5n5Aw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785072641; c=relaxed/simple; bh=GXW05UTF86nuhwqY3GktSUk08spHdAdTdQIY1yp7Thg=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=IsGbxHETCkNVXvTauHehxTAzfxqLvXCD87R8vfkWsnu7pJ/UqUUJH66cXiOKV4FHfq3o/DEIKEstLvCww6UCsckDBl1uz5HThnnYyrvEzmUDNr2Y4s2CP1W0Awc8e+hEjRj1sRtIAhee+jP8c4YoXND3dMiEg5ykYuSnoqpTWQY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EzbhPfvq; 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="EzbhPfvq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF58C1F000E9; Sun, 26 Jul 2026 13:30:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785072640; bh=ygKL8b5S+/5opKlW5/5kSiAhU39LSuImXVnR8LGoXGU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=EzbhPfvqXszQ0+d0hzsUO/07oxZ2s9l4k3VFdRRqwKVfJ65VEYnvkcJcXScsFw+x9 K9j5vyaZde3xQlThfcGHwQFqTWarORzkI2zsM9CO4UzRPr6FtqZBX1E88ytASChQda xbb6SyZ0+U+L5EyxEP9cA/doiYvT38yjaBeKlf591x/22dLPNSbAqZK68XPYkPO5Jt cfTmIYeXbVd2kPQtTLNF4LQd/rtTaXHJIm4Oxw3G/NwqZDMf8R9qUwNaXCnZ8B4xw8 6vhcuYhoDds0Wi14LsbPnzX35N3R64S0Cv9cP4pMozD1WnwwoNvx271YLZ2W5mA+5N 7ghR/LC+L68EA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v4 3/3] nvmem: make all reg_write callbacks take const void * Reply-To: sashiko-reviews@lists.linux.dev To: "Link Mauve" Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org, ojeda@kernel.org, imx@lists.linux.dev, Frank.Li@kernel.org In-Reply-To: <20260726131724.15299-4-linkmauve@linkmauve.fr> References: <20260726131724.15299-1-linkmauve@linkmauve.fr> <20260726131724.15299-4-linkmauve@linkmauve.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Jul 2026 13:30:39 +0000 Message-Id: <20260726133039.CF58C1F000E9@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 4 potential issue(= s) to consider: New issues: - [Medium] The patch claims to 'make all reg_write callbacks take const voi= d *' and 'fix all users of this API', but it fails to migrate many nvmem dr= ivers. Pre-existing issues: - [Critical] The `sprd_efuse_write` function reads out-of-bounds for small = writes and silently truncates large writes, while `sprd_efuse_read` suffers= from a stack buffer overflow. - [High] The `bcm_otpc_write` function performs an out-of-bounds read when = `bytes` is not a multiple of `otpc_row_size * word_size`. - [High] The `lpc18xx_eeprom_gather_write` and `lpc18xx_eeprom_read` functi= ons will enter an infinite loop and cause OOB memory access if `bytes` is n= ot a multiple of 4. -- --- Patch [3]: [PATCH v4 3/3] nvmem: make all reg_write callbacks take cons= t void * --- commit 4f1bd94da9f8c5ba3e21c869d089a1a71eeccbc7 Author: Link Mauve nvmem: make all reg_write callbacks take const void * The previous commit switched from a pointer to mutable data to a pointer to immutable data, so let=E2=80=99s fix all users of this API. > nvmem: make all reg_write callbacks take const void * > > The previous commit switched from a pointer to mutable data to a pointer > to immutable data, so let=E2=80=99s fix all users of this API. [Severity: Medium] Is this commit message accurate regarding fixing all users? Although many files are updated, prominent drivers like at24.c and at25.c (and others outside drivers/nvmem/) still appear to use the legacy .reg_write callback with the mutable void * signature. Could the commit message be clarified to state that it only updates a subset of drivers? > 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 does bcm_otpc_write() have an out-of-boun= ds read if bytes is not a multiple of otpc_row_size * word_size? If otpc_row_size > 1 (like 2 for the v2 map) and the nvmem core passes bytes =3D 4, the inner loop iterates twice: for (i =3D 0; i < priv->map->otpc_row_size; i++) { writel(*buf, priv->base + priv->map->data_w_offset[i]); buf++; bytes_written +=3D sizeof(*buf); } Does this cause buf to advance beyond the provided length and read uninitialized kernel memory into the hardware? [ ... ] > diff --git a/drivers/nvmem/lpc18xx_eeprom.c b/drivers/nvmem/lpc18xx_eepro= m.c > index 504155e30bab2..78a35ef095fbd 100644 > --- a/drivers/nvmem/lpc18xx_eeprom.c > +++ b/drivers/nvmem/lpc18xx_eeprom.c [ ... ] > @@ -109,7 +109,7 @@ static int lpc18xx_eeprom_gather_write(void *context,= unsigned int reg, > usleep_range(100, 200); > =20 > while (bytes) { > - writel(*(u32 *)val, eeprom->mem_base + offset); > + writel(*(const u32 *)val, eeprom->mem_base + offset); > ret =3D lpc18xx_eeprom_busywait_until_prog(eeprom); [Severity: High] This is a pre-existing issue, but can this loop run infinitely if bytes is not a multiple of 4? The loop decrements the unsigned bytes variable unconditionally by 4: bytes -=3D eeprom->val_bytes; If the nvmem core passes an unaligned bytes value, does this subtraction underflow and cause the loop to run indefinitely, leading to out-of-bounds memory access? It appears lpc18xx_eeprom_read() shares this behavior. [ ... ] > 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 > @@ -192,7 +192,7 @@ static void sprd_efuse_set_prog_en(struct sprd_efuse = *efuse, bool en) > } > =20 > static int sprd_efuse_raw_prog(struct sprd_efuse *efuse, u32 blk, bool d= oub, > - bool lock, u32 *data) > + bool lock, const u32 *data) > { [Severity: Critical] This is a pre-existing issue, but does sprd_efuse_raw_prog() read out of bounds for small writes? By dereferencing data as a 32-bit integer: writel(*data, efuse->base + SPRD_EFUSE_MEM(blk)); Could this cause an out-of-bounds read if the incoming buffer is less than 4 bytes long? [ ... ] > @@ -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) > { [Severity: Critical] This is a pre-existing issue, but is there a stack memory leak in sprd_efuse_read()? When the nvmem core passes a length up to PAGE_SIZE (4096) for sysfs reads, sprd_efuse_read() allocates a local 4-byte data variable on the stack: u32 data; ... memcpy(val, &data, bytes); If bytes > 4, would this copy up to 4092 bytes of stack memory to the output buffer? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260726131724.1529= 9-1-linkmauve@linkmauve.fr?part=3D3