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 966E0C9832A for ; Tue, 29 Sep 2026 06:47:08 +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=GCmaZfdiunYY/pB285sd3KpSSVCWcc0qbJ823JHKtG8=; b=vTieZesJfyg546 nRd8579fbxLicrXr8SKL1rL50BPHbbYGFgLS3G2zZl7ZBaDvkYzIaEc8lAzkpnU+HIyRK3k1i/gvE Efeko4GYPeJSc36VdN5F5EMn5/HlBjeEld1sIf1hxmJDC5Ejtz21l92Vw1LSGNa+vtQuW3XhC4ndO eWqwBFL0mmSC14JSCD8pqXgEa5JnOwlAQrf5uOb8oQN4fTzVyljo1b1+CakQO/ISdMPlgYQ6xKIAm pgQiyPcLoKr22zGenvkCIyDhJtXxYORd9pITXz459ZQJMemhcNo5lm9LjpaIxkKFLacdkZIiWO4Oy zN5B7cnlHDFf+0H5pN4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xBRcK-00000002WXl-1XIh; Tue, 29 Sep 2026 06:47:08 +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 1xBRcJ-00000002WXb-1aQo for linux-i3c@lists.infradead.org; Tue, 29 Sep 2026 06:47:07 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 24A23404BC; Tue, 29 Sep 2026 06:47:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 750881F000FF; Tue, 29 Sep 2026 06:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790664427; bh=jHmXMhmblbm6tAvv+tcTE/uj35n6b+3UDALg5+OHpGg=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=NyXJGralibTSZisac7PfeSAECMeCC7dYDCKJQj+zqqi1SRWX47jghjbnwD/9zAN40 sBKsaehRXcGGqE5+TBMCZlGndrx+hPo3UrC+/nmJ6K6vFpWlSQsO7sTZvFLNgy2ptf odvikBBmteW62flSfN4I3+OqqeBK2xhuM71xUrlu5QkzvF3Qr4R3FUsar7mO7OJZZX Onq/LGzMtqPCgNR+yX/cEfbQ+fUqhj9qZWVmf2vQAe2bKHeXu9z6zskVKyWjUBA/Cd lWo7yxgssA/5udzdtsj5AdJyzRlmkfsmj2Tf+z7gt7Q+rJ4so3qeqNc8/aH/CHBOFT WVaWUcdjU6ePA== From: sashiko-bot@kernel.org Subject: Re: [PATCH 09/20] reset: add Synaptics SL261x reset support To: "Jisheng Zhang" Cc: robh@kernel.org, lee@kernel.org, "Alexandre Belloni" , mfd@lists.linux.dev, Frank.Li@kernel.org, conor+dt@kernel.org, linux-i3c@lists.infradead.org, linux-serial@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260929061417.20733-10-jszhang@kernel.org> References: <20260929061417.20733-1-jszhang@kernel.org> <20260929061417.20733-10-jszhang@kernel.org> Date: Tue, 29 Sep 2026 06:47:06 +0000 Message-Id: <20260929064706.750881F000FF@smtp.kernel.org> X-BeenThere: linux-i3c@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-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW01lZGl1bV0gcmVzZXQ6IHNsMjYx eDogcG90ZW50aWFsIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSBpbiBwcm9iZQotIFtNZWRpdW1d IHJlc2V0OiBzbDI2MXg6IHVuc2FmZSByZWFkLW1vZGlmeS13cml0ZSBvbiBub24tc3RpY2t5IHB1 bHNlIHRyaWdnZXJzCi0gW0xvd10gcmVzZXQ6IHNsMjYxeDogdHlwbyAnc2wyNjF4MicgaW4gZHJp dmVyIG5hbWUgYW5kIHByb2JlIGZ1bmN0aW9uCi0tCgpjb21taXQgNzg2MTZkOGE3YjY2YjBhYzY2 NWIzMTE3NzVkZDU2NmYyNDY5NDEyYQpBdXRob3I6IEppc2hlbmcgWmhhbmcgPGpzemhhbmdAa2Vy bmVsLm9yZz4KCnJlc2V0OiBhZGQgU3luYXB0aWNzIFNMMjYxeCByZXNldCBzdXBwb3J0CgpUaGlz IGNvbW1pdCBhZGRzIHN1cHBvcnQgZm9yIHRoZSByZXNldCBjb250cm9sbGVyIGluIFN5bmFwdGlj cyBTTDI2MVggU29Dcy4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvcmVzZXQvcmVzZXQtc2wyNjF4 LmMgYi9kcml2ZXJzL3Jlc2V0L3Jlc2V0LXNsMjYxeC5jCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQK PiAtLS0gL2Rldi9udWxsCj4gKysrIGIvZHJpdmVycy9yZXNldC9yZXNldC1zbDI2MXguYwoKWyAu Li4gXQoKPiArc3RhdGljIGludCBzbDI2MXhfcmVzZXRfcmVzZXQoc3RydWN0IHJlc2V0X2NvbnRy b2xsZXJfZGV2ICpyY2RldiwKPiArCQkJICAgICAgdW5zaWduZWQgbG9uZyBpZCkKPiArewo+ICsJ c3RydWN0IHNsMjYxeF9yZXNldF9wcml2ICpwcml2ID0gdG9fc2wyNjF4X3Jlc2V0X3ByaXYocmNk ZXYpOwo+ICsJY29uc3Qgc3RydWN0IHNsMjYxeF9yZXNldF9jZmcgKmNmZyA9ICZwcml2LT5jZmdz W2lkXTsKPiArCj4gKwlpZiAoY2ZnLT5zdGlja3kpIHsKPiArCQlyZWdtYXBfY2xlYXJfYml0cyhw cml2LT5yZWdtYXAsIGNmZy0+cmVnLCBjZmctPmJpdCk7Cj4gKwkJdXNsZWVwX3JhbmdlKDEwLCAx NSk7Cj4gKwkJcmV0dXJuIHJlZ21hcF9zZXRfYml0cyhwcml2LT5yZWdtYXAsIGNmZy0+cmVnLCBj ZmctPmJpdCk7Cj4gKwl9Cj4gKwo+ICsJcmV0dXJuIHJlZ21hcF9zZXRfYml0cyhwcml2LT5yZWdt YXAsIGNmZy0+cmVnLCBjZmctPmJpdCk7CgpbU2V2ZXJpdHk6IE1lZGl1bV0KQ291bGQgdGhpcyBy ZWFkLW1vZGlmeS13cml0ZSBvcGVyYXRpb24gZGlzcnVwdCBjb25jdXJyZW50IHJlc2V0cz8gCgpJ ZiB0aGUgbm9uLXN0aWNreSBoYXJkd2FyZSByZWdpc3RlcnMgYXJlIGFjdGl2ZS1oaWdoIHNlbGYt Y2xlYXJpbmcgcHVsc2UKdHJpZ2dlcnMgdGhhdCByZWFkIGFzIDEgd2hpbGUgYWN0aXZlLCB0aGUg cmVnbWFwX3NldF9iaXRzKCkgb3BlcmF0aW9uCm1pZ2h0IHJlYWQgMXMgZm9yIGNvbmN1cnJlbnRs eSBhY3RpdmUgcmVzZXRzIGFuZCB3cml0ZSB0aGVtIGJhY2ssCnVuaW50ZW50aW9uYWxseSBleHRl bmRpbmcgb3IgcmUtdHJpZ2dlcmluZyB0aGVtLgoKWyAuLi4gXQoKPiArc3RhdGljIGNvbnN0IHN0 cnVjdCByZXNldF9jb250cm9sX29wcyBzbDI2MXhfcmVzZXRfb3BzID0gewo+ICsJLnJlc2V0CT0g c2wyNjF4X3Jlc2V0X3Jlc2V0LAo+ICsJLmFzc2VydCA9IHNsMjYxeF9yZXNldF9hc3NlcnQsCj4g KwkuZGVhc3NlcnQgPSBzbDI2MXhfcmVzZXRfZGVhc3NlcnQsCj4gK307Cj4gKwo+ICtzdGF0aWMg aW50IHNsMjYxeDJfcmVzZXRfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKCltT ZXZlcml0eTogTG93XQpJcyB0aGUgInNsMjYxeDIiIGluIHRoZSBwcm9iZSBmdW5jdGlvbiBuYW1l IGludGVudGlvbmFsPyBJdCBsb29rcyBsaWtlIGEKdHlwby4KCj4gK3sKPiArCXN0cnVjdCBkZXZp Y2Vfbm9kZSAqcGFyZW50X25wOwo+ICsJc3RydWN0IHNsMjYxeF9yZXNldF9wcml2ICpwcml2Owo+ ICsJY29uc3Qgc3RydWN0IHNsMjYxeF9yZXNldF9kYXRhICpkYXRhID0gZGV2aWNlX2dldF9tYXRj aF9kYXRhKCZwZGV2LT5kZXYpOwo+ICsKPiArCXByaXYgPSBkZXZtX2t6YWxsb2MoJnBkZXYtPmRl diwgc2l6ZW9mKCpwcml2KSwgR0ZQX0tFUk5FTCk7Cj4gKwlpZiAoIXByaXYpCj4gKwkJcmV0dXJu IC1FTk9NRU07Cj4gKwo+ICsJcGFyZW50X25wID0gb2ZfZ2V0X3BhcmVudChwZGV2LT5kZXYub2Zf bm9kZSk7Cj4gKwlwcml2LT5yZWdtYXAgPSBzeXNjb25fbm9kZV90b19yZWdtYXAocGFyZW50X25w KTsKPiArCW9mX25vZGVfcHV0KHBhcmVudF9ucCk7Cj4gKwlpZiAoSVNfRVJSKHByaXYtPnJlZ21h cCkpCj4gKwkJcmV0dXJuIFBUUl9FUlIocHJpdi0+cmVnbWFwKTsKPiArCj4gKwlwcml2LT5yY2Rl di5vd25lciA9IFRISVNfTU9EVUxFOwo+ICsJcHJpdi0+cmNkZXYub3BzID0gJnNsMjYxeF9yZXNl dF9vcHM7Cj4gKwlwcml2LT5yY2Rldi5vZl9ub2RlID0gcGRldi0+ZGV2Lm9mX25vZGU7Cj4gKwlw cml2LT5yY2Rldi5vZl9yZXNldF9uX2NlbGxzID0gMTsKPiArCXByaXYtPnJjZGV2Lm5yX3Jlc2V0 cyA9IGRhdGEtPm51bTsKCltTZXZlcml0eTogTWVkaXVtXQpDYW4gZGF0YSBiZSBOVUxMIGhlcmU/ IAoKSWYgdGhlIGRyaXZlciBpcyBib3VuZCB2aWEgc3lzZnMgdG8gYSBkZXZpY2UgdGhhdCBoYXMg YSB2YWxpZCBzeXNjb24gcGFyZW50CmJ1dCBkb2VzIG5vdCBtYXRjaCB0aGUgT0YgY29tcGF0aWJs ZSBzdHJpbmdzLCBkZXZpY2VfZ2V0X21hdGNoX2RhdGEoKSB3aWxsCnJldHVybiBOVUxMLiBVbmNv bmRpdGlvbmFsbHkgZGVyZWZlcmVuY2luZyBkYXRhLT5udW0gaW4gdGhpcyBjYXNlIHdvdWxkCmNh dXNlIGEgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlLgoKPiArCXByaXYtPmNmZ3MgPSBkYXRhLT5j ZmdzOwo+ICsKPiArCXJldHVybiBkZXZtX3Jlc2V0X2NvbnRyb2xsZXJfcmVnaXN0ZXIoJnBkZXYt PmRldiwgJnByaXYtPnJjZGV2KTsKPiArfQo+ICsKPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9k ZXZpY2VfaWQgc2wyNjF4X3Jlc2V0X2R0X21hdGNoW10gPSB7Cj4gKwl7IC5jb21wYXRpYmxlID0g InN5bmEsc2wyNjF4LXJlc2V0IiwgLmRhdGEgPSAmc2wyNjF4X3Jlc2V0X2RhdGEgfSwKPiArCXsg LmNvbXBhdGlibGUgPSAic3luYSxzbDI2MXgtc3lzdGVtLXJlc2V0IiwgLmRhdGEgPSAmc2wyNjF4 X3N5c3RlbV9yZXNldF9kYXRhIH0sCj4gKwl7IH0sCj4gK307Cj4gK01PRFVMRV9ERVZJQ0VfVEFC TEUob2YsIHNsMjYxeF9yZXNldF9kdF9tYXRjaCk7Cj4gKwo+ICtzdGF0aWMgc3RydWN0IHBsYXRm b3JtX2RyaXZlciBzbDI2MXhfcmVzZXRfZHJpdmVyID0gewo+ICsJLnByb2JlCT0gc2wyNjF4Ml9y ZXNldF9wcm9iZSwKPiArCS5kcml2ZXIJPSB7Cj4gKwkJLm5hbWUgPSAic2wyNjF4Mi1yZXNldCIs CgpbU2V2ZXJpdHk6IExvd10KRG9lcyB0aGlzIGRyaXZlciBuYW1lIGludGVudGlvbmFsbHkgdXNl ICJzbDI2MXgyLXJlc2V0Ij8gRXhwb3NpbmcgYSBjb25mdXNpbmcKbmFtZSB0byB0aGUgcGxhdGZv cm0gYnVzIGFuZCBzeXNmcyBtaWdodCBicmVhayB1c2Vyc3BhY2Ugc2NyaXB0cyBleHBlY3Rpbmcg YQpjb25zaXN0ZW50ICJzbDI2MXgtcmVzZXQiIG5hbWUuCgo+ICsJCS5vZl9tYXRjaF90YWJsZSA9 IHNsMjYxeF9yZXNldF9kdF9tYXRjaCwKPiArCX0sCj4gK307CgotLSAKU2FzaGlrbyBBSSByZXZp ZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwOTI5MDYxNDE3LjIwNzMz LTEtanN6aGFuZ0BrZXJuZWwub3JnP3BhcnQ9OQoKLS0gCmxpbnV4LWkzYyBtYWlsaW5nIGxpc3QK bGludXgtaTNjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcv bWFpbG1hbi9saXN0aW5mby9saW51eC1pM2MK 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 616843909A2; Tue, 29 Sep 2026 06:47:07 +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=1790664428; cv=none; b=jQ0WvHmbvGnbVoaSEp5qOhKkH9pc14DZsK5+uALcQOg9tNBHvJRea54nlE7L3qzwHtpMcODrdoduXSTolobs5zTJHRYlTSBHBqUT64SiglYmXB1cIUU7KayC5iEG5BaTBzj6+ZJcxtZ3iYya0Y6JCFx/PjKTMESfQm2Md6Y+KJY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790664428; c=relaxed/simple; bh=8fQhdPYPuEHqf4Ru43ELndvM6YUy8t7Hz6ODo7dDhmI=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=oTI/s2MJ/xhakGDJNeGC3ybZri/mA+lZlc0U7tBnAOoP6BF2XZ1ygPYYdPEOa2hhJNdkMnb4dgLbsGWWgut07VWgP9F/tAqim/59Z9IjAG3fu4NzjlsmpC+NRg8AJjRUI7rcE7HlZ9sWI+ZE4yzlidzqXzw7y5whiWFmaUWmlgg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NyXJGral; 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="NyXJGral" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 750881F000FF; Tue, 29 Sep 2026 06:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790664427; bh=jHmXMhmblbm6tAvv+tcTE/uj35n6b+3UDALg5+OHpGg=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=NyXJGralibTSZisac7PfeSAECMeCC7dYDCKJQj+zqqi1SRWX47jghjbnwD/9zAN40 sBKsaehRXcGGqE5+TBMCZlGndrx+hPo3UrC+/nmJ6K6vFpWlSQsO7sTZvFLNgy2ptf odvikBBmteW62flSfN4I3+OqqeBK2xhuM71xUrlu5QkzvF3Qr4R3FUsar7mO7OJZZX Onq/LGzMtqPCgNR+yX/cEfbQ+fUqhj9qZWVmf2vQAe2bKHeXu9z6zskVKyWjUBA/Cd lWo7yxgssA/5udzdtsj5AdJyzRlmkfsmj2Tf+z7gt7Q+rJ4so3qeqNc8/aH/CHBOFT WVaWUcdjU6ePA== From: sashiko-bot@kernel.org Subject: Re: [PATCH 09/20] reset: add Synaptics SL261x reset support Reply-To: sashiko-reviews@lists.linux.dev To: "Jisheng Zhang" Cc: robh@kernel.org, lee@kernel.org, "Alexandre Belloni" , mfd@lists.linux.dev, Frank.Li@kernel.org, conor+dt@kernel.org, linux-i3c@lists.infradead.org, linux-serial@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260929061417.20733-10-jszhang@kernel.org> References: <20260929061417.20733-1-jszhang@kernel.org> <20260929061417.20733-10-jszhang@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Sep 2026 06:47:06 +0000 Message-Id: <20260929064706.750881F000FF@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-serial@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] reset: sl261x: potential NULL pointer dereference in probe - [Medium] reset: sl261x: unsafe read-modify-write on non-sticky pulse trig= gers - [Low] reset: sl261x: typo 'sl261x2' in driver name and probe function -- commit 78616d8a7b66b0ac665b311775dd566f2469412a Author: Jisheng Zhang reset: add Synaptics SL261x reset support This commit adds support for the reset controller in Synaptics SL261X SoCs. > diff --git a/drivers/reset/reset-sl261x.c b/drivers/reset/reset-sl261x.c > new file mode 100644 > --- /dev/null > +++ b/drivers/reset/reset-sl261x.c [ ... ] > +static int sl261x_reset_reset(struct reset_controller_dev *rcdev, > + unsigned long id) > +{ > + struct sl261x_reset_priv *priv =3D to_sl261x_reset_priv(rcdev); > + const struct sl261x_reset_cfg *cfg =3D &priv->cfgs[id]; > + > + if (cfg->sticky) { > + regmap_clear_bits(priv->regmap, cfg->reg, cfg->bit); > + usleep_range(10, 15); > + return regmap_set_bits(priv->regmap, cfg->reg, cfg->bit); > + } > + > + return regmap_set_bits(priv->regmap, cfg->reg, cfg->bit); [Severity: Medium] Could this read-modify-write operation disrupt concurrent resets?=20 If the non-sticky hardware registers are active-high self-clearing pulse triggers that read as 1 while active, the regmap_set_bits() operation might read 1s for concurrently active resets and write them back, unintentionally extending or re-triggering them. [ ... ] > +static const struct reset_control_ops sl261x_reset_ops =3D { > + .reset =3D sl261x_reset_reset, > + .assert =3D sl261x_reset_assert, > + .deassert =3D sl261x_reset_deassert, > +}; > + > +static int sl261x2_reset_probe(struct platform_device *pdev) [Severity: Low] Is the "sl261x2" in the probe function name intentional? It looks like a typo. > +{ > + struct device_node *parent_np; > + struct sl261x_reset_priv *priv; > + const struct sl261x_reset_data *data =3D device_get_match_data(&pdev->d= ev); > + > + priv =3D devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + parent_np =3D of_get_parent(pdev->dev.of_node); > + priv->regmap =3D syscon_node_to_regmap(parent_np); > + of_node_put(parent_np); > + if (IS_ERR(priv->regmap)) > + return PTR_ERR(priv->regmap); > + > + priv->rcdev.owner =3D THIS_MODULE; > + priv->rcdev.ops =3D &sl261x_reset_ops; > + priv->rcdev.of_node =3D pdev->dev.of_node; > + priv->rcdev.of_reset_n_cells =3D 1; > + priv->rcdev.nr_resets =3D data->num; [Severity: Medium] Can data be NULL here?=20 If the driver is bound via sysfs to a device that has a valid syscon parent but does not match the OF compatible strings, device_get_match_data() will return NULL. Unconditionally dereferencing data->num in this case would cause a NULL pointer dereference. > + priv->cfgs =3D data->cfgs; > + > + return devm_reset_controller_register(&pdev->dev, &priv->rcdev); > +} > + > +static const struct of_device_id sl261x_reset_dt_match[] =3D { > + { .compatible =3D "syna,sl261x-reset", .data =3D &sl261x_reset_data }, > + { .compatible =3D "syna,sl261x-system-reset", .data =3D &sl261x_system_= reset_data }, > + { }, > +}; > +MODULE_DEVICE_TABLE(of, sl261x_reset_dt_match); > + > +static struct platform_driver sl261x_reset_driver =3D { > + .probe =3D sl261x2_reset_probe, > + .driver =3D { > + .name =3D "sl261x2-reset", [Severity: Low] Does this driver name intentionally use "sl261x2-reset"? Exposing a confusi= ng name to the platform bus and sysfs might break userspace scripts expecting a consistent "sl261x-reset" name. > + .of_match_table =3D sl261x_reset_dt_match, > + }, > +}; --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260929061417.2073= 3-1-jszhang@kernel.org?part=3D9