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 85F80C54FD2 for ; Thu, 30 Jul 2026 10:07: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=bhgfGVxAzqR0mTWet/KAV2CZ5d3qr5Av9Q0r1T6u3J8=; b=LhgaT9R2+sKIPm A0qvlij2chW0DPhhFNvxrMWZe7XpFqKzkXF20q8kYPNk3ErObX7IfMaX+ul0fbA3/M4OW9chLNhUk rgL0dhgoh3bCpKI8h96Ng9wY7SqGMIpkd5Qo1ImhGR/pbikiy/i4PBn58gF5YXLHujUeN+Fo7lzot TreWlqN2R68UR0KgiEjQnGEQY9EtGVU77vAx5aebcHmy78IyghVhJQQlQFPn7yBYCTkfwJ7TBOFzi kOswu8uzNvOF1uKdqmC73o8//ORAivzUsMP3honNXAv6YPXnIyh6eublQatCv1Ga4VaPnDqXycwhR 3bJTTVeQHhLFCXOVjZeg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wpNg5-0000000A8u0-14fV; Thu, 30 Jul 2026 10:07:49 +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 1wpNg3-0000000A8tk-3ag0 for linux-phy@lists.infradead.org; Thu, 30 Jul 2026 10:07:47 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 41EF6417B2; Thu, 30 Jul 2026 10:07:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB3F01F00A3D; Thu, 30 Jul 2026 10:07:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785406067; bh=+DdtGIGw5KisOkEqv6VLLhJyKxudfBrpLNeEuZR/x+8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ltXV8AddneWCj10H+yXmyOp1Ivd5uAPjM1XJSmyc/nozeWSTTjRqplIDONq7Z+00a guSMm8lizOkqxz4hZzYqtA8w54K5BzHeOMjTXCZ8cJRXCaAvvHFQCyqNG40DnLBCQB Wq58QIHE6JHlHrMnAFNyXesvlkww2S2iS5QzB+fqRauFZVoWv+BX8vc6KzD0JO6YU3 9aEpRyd1NvUr+b01xnDRgHmwKgRyzMPLeOekgpZVEjIiJ+HyxAhAHV/EI4B6HFSSna Tz3d0ChQ1DNAzipP9UUgBaxVKFSHJwXHUIeK39Yl+/9Y69xu4cxb3wuhWoH1cAZnJG GBzAZQEa2hhLQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v10 08/26] scsi: ufs: mediatek: Rework init function To: "Louis-Alexis Eyraud" Cc: neil.armstrong@linaro.org, devicetree@vger.kernel.org, vkoul@kernel.org, conor+dt@kernel.org, olteanv@gmail.com, robh@kernel.org, linux-phy@lists.infradead.org, linux-scsi@vger.kernel.org In-Reply-To: <20260730-mt8196-ufs-v10-8-bc5ecef202dc@collabora.com> References: <20260730-mt8196-ufs-v10-0-bc5ecef202dc@collabora.com> <20260730-mt8196-ufs-v10-8-bc5ecef202dc@collabora.com> Date: Thu, 30 Jul 2026 10:07:46 +0000 Message-Id: <20260730100746.AB3F01F00A3D@smtp.kernel.org> X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list 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-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtIaWdoXSBUaGUgcmV0dXJuIHZhbHVlIG9mIGB1ZnNfbXRrX21waHlfcG93ZXJfb24oKWAgaXMg aWdub3JlZCBkdXJpbmcgaG9zdCBpbml0aWFsaXphdGlvbi4KLSBbSGlnaF0gVXNlLUFmdGVyLUZy ZWUgcmlzayBkdWUgdG8gc2F2aW5nIGEgcmVsZWFzZWQgZGV2aWNlIHBvaW50ZXIgaW4gYGhvc3Qt PnBoeV9kZXZgLgotLQoKLS0tIFBhdGNoIFs4XTogW1BBVENIIHYxMCAwOC8yNl0gc2NzaTogdWZz OiBtZWRpYXRlazogUmV3b3JrIGluaXQgZnVuY3Rpb24gLS0tCmNvbW1pdCA1ZDc5MjY4YWMxNTU5 ZGQ0YzZjNjE1NjAxYWUxYjk4MzhlNGI3N2JjCkF1dGhvcjogTmljb2xhcyBGcmF0dGFyb2xpIDxu aWNvbGFzLmZyYXR0YXJvbGlAY29sbGFib3JhLmNvbT4KCnNjc2k6IHVmczogbWVkaWF0ZWs6IFJl d29yayBpbml0IGZ1bmN0aW9uCgpUaGlzIGNvbW1pdCByZXdvcmtzIHRoZSBpbml0aWFsaXphdGlv biBmdW5jdGlvbiBmb3IgdGhlIE1lZGlhVGVrIFVGUyBkcml2ZXIuCkl0IHJlbW92ZXMgdW5uZWNl c3NhcnkgZXJyb3IgcHJpbnRzIGZvciBtZW1vcnkgYWxsb2NhdGlvbiBmYWlsdXJlcyBhbmQgcmVt b3ZlcwpyZWR1bmRhbnQgZGV2aWNlIHRyZWUgbWF0Y2hpbmcuIEl0IGFsc28gc2ltcGxpZmllcyB0 aGUgZXJyb3IgaGFuZGxpbmcgcGF0aApieSByZW1vdmluZyB1bm5lY2Vzc2FyeSBnb3RvIHN0YXRl bWVudHMgYW5kIHJldHVybmluZyBkaXJlY3RseSBvbiBzdWNjZXNzLgoKPiBkaWZmIC0tZ2l0IGEv ZHJpdmVycy91ZnMvaG9zdC91ZnMtbWVkaWF0ZWsuYyBiL2RyaXZlcnMvdWZzL2hvc3QvdWZzLW1l ZGlhdGVrLmMKPiBpbmRleCBmNjg1OWNkMGIxZDRkLi41MGU3NzAxZDc5NDNiIDEwMDY0NAo+IC0t LSBhL2RyaXZlcnMvdWZzL2hvc3QvdWZzLW1lZGlhdGVrLmMKPiArKysgYi9kcml2ZXJzL3Vmcy9o b3N0L3Vmcy1tZWRpYXRlay5jClsgLi4uIF0KPiBAQCAtMTM1NiwxMSArMTMzNCwxMCBAQCBzdGF0 aWMgaW50IHVmc19tdGtfaW5pdChzdHJ1Y3QgdWZzX2hiYSAqaGJhKQo+ICAKPiAgCXVmc19tdGtf Z2V0X2h3X2lwX3ZlcnNpb24oaGJhKTsKPiAgCj4gLQlnb3RvIG91dDsKPiArCXJldHVybiAwOwo+ ICAKPiAgb3V0X3ZhcmlhbnRfY2xlYXI6Cj4gIAl1ZnNoY2Rfc2V0X3ZhcmlhbnQoaGJhLCBOVUxM KTsKPiAtb3V0Ogo+ICAJcmV0dXJuIGVycjsKPiAgfQoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlz bid0IGEgYnVnIGludHJvZHVjZWQgYnkgdGhpcyBwYXRjaCwgYnV0IGRvZXMgdGhpcyBjb2RlIGln bm9yZSB0aGUKcmV0dXJuIHZhbHVlIG9mIHVmc19tdGtfbXBoeV9wb3dlcl9vbigpIGVhcmxpZXIg aW4gdWZzX210a19pbml0KCk/CgpMb29raW5nIGF0IHVmc19tdGtfaW5pdCgpOgoKCWVyciA9IHVm c19tdGtfZ2V0X3N1cHBsaWVzKGhvc3QpOwoJaWYgKGVycikKCQlnb3RvIG91dF92YXJpYW50X2Ns ZWFyOwoKCS8qCgkgKiB1ZnNoY2Rfdm9wc19pbml0KCkgaXMgaW52b2tlZCBhZnRlcgoJICogdWZz aGNkX3NldHVwX2Nsb2NrKHRydWUpIGluIHVmc2hjZF9oYmFfaW5pdCgpIHRodXMKCSAqIHBoeSBj bG9jayBzZXR1cCBpcyBza2lwcGVkLgoJICoKCSAqIEVuYWJsZSBwaHkgY2xvY2tzIHNwZWNpZmlj YWxseSBoZXJlLgoJICovCgl1ZnNfbXRrX21waHlfcG93ZXJfb24oaGJhLCB0cnVlKTsKCglpZiAo dWZzX210a19pc19ydGZmX210Y21vcyhoYmEpKSB7CgpJZiB1ZnNfbXRrX21waHlfcG93ZXJfb24o KSBmYWlscyAoZS5nLiByZWd1bGF0b3JfZW5hYmxlIGZhaWxzIGluCnVmc19tdGtfMDl2X29uKSwg dGhlIGRyaXZlciB3aWxsIHByb2NlZWQgYXMgaWYgdGhlIFBIWSBwb3dlcmVkIG9uCnN1Y2Nlc3Nm dWxseS4gIFNob3VsZCB0aGlzIGNoZWNrIHRoZSByZXR1cm4gdmFsdWUgYW5kIGhhbmRsZSB0aGUg ZXJyb3I/CgpbIC4uLiBdCj4gQEAgLTI0MDIsNiArMjM3OSwxOCBAQCBzdGF0aWMgY29uc3Qgc3Ry dWN0IHVmc19oYmFfdmFyaWFudF9vcHMgdWZzX2hiYV9tdGtfdm9wcyA9IHsKPiAgCS5jb25maWdf c2NzaV9kZXYgICAgID0gdWZzX210a19jb25maWdfc2NzaV9kZXYsCj4gIH07Cj4gIAo+ICtzdGF0 aWMgY29uc3Qgc3RydWN0IHVmc19tdGtfc29jX2RhdGEgbXQ4MTgzX2RhdGEgPSB7Cj4gKwkuaGFz X2F2ZGQwOSA9IHRydWUsCj4gK307Cj4gKwo+ICtzdGF0aWMgY29uc3Qgc3RydWN0IG9mX2Rldmlj ZV9pZCB1ZnNfbXRrX29mX21hdGNoW10gPSB7Cj4gKwl7IC5jb21wYXRpYmxlID0gIm1lZGlhdGVr LG10ODE4My11ZnNoY2kiLCAuZGF0YSA9ICZtdDgxODNfZGF0YSB9LAo+ICsJeyAuY29tcGF0aWJs ZSA9ICJtZWRpYXRlayxtdDgxOTItdWZzaGNpIiB9LAo+ICsJeyAuY29tcGF0aWJsZSA9ICJtZWRp YXRlayxtdDgxOTUtdWZzaGNpIiB9LAo+ICsJe30sCj4gK307Cj4gK01PRFVMRV9ERVZJQ0VfVEFC TEUob2YsIHVmc19tdGtfb2ZfbWF0Y2gpOwo+ICsKPiAgLyoqCj4gICAqIHVmc19tdGtfcHJvYmUg LSBwcm9iZSByb3V0aW5lIG9mIHRoZSBkcml2ZXIKPiAgICogQHBkZXY6IHBvaW50ZXIgdG8gUGxh dGZvcm0gZGV2aWNlIGhhbmRsZQoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0 aW5nIGlzc3VlLCBidXQgaXMgdGhlcmUgYSB1c2UtYWZ0ZXItZnJlZSByaXNrIGluCnVmc19tdGtf cHJvYmUoKSB3aGVuIHNhdmluZyB0aGUgcmVsZWFzZWQgZGV2aWNlIHBvaW50ZXI/CgpMb29raW5n IGF0IHVmc19tdGtfcHJvYmUoKToKCglpZiAocGh5X25vZGUpIHsKCQlwaHlfcGRldiA9IG9mX2Zp bmRfZGV2aWNlX2J5X25vZGUocGh5X25vZGUpOwoJCWlmICghcGh5X3BkZXYpCgkJCWdvdG8gc2tp cF9waHk7CgkJcGh5X2RldiA9ICZwaHlfcGRldi0+ZGV2OwoKCQkuLi4KCQlwdXRfZGV2aWNlKHBo eV9kZXYpOwoJfQoJLi4uCnNraXBfcGh5OgoJZXJyID0gdWZzaGNkX3BsdGZybV9pbml0KHBkZXYs ICZ1ZnNfaGJhX210a192b3BzKTsKCS4uLgoJaWYgKHBoeV9ub2RlICYmIHBoeV9kZXYpIHsKCQlo b3N0ID0gdWZzaGNkX2dldF92YXJpYW50KGhiYSk7CgkJaG9zdC0+cGh5X2RldiA9IHBoeV9kZXY7 Cgl9CgpvZl9maW5kX2RldmljZV9ieV9ub2RlKCkgYWNxdWlyZXMgYSByZWZlcmVuY2UgdG8gdGhl IHBoeSBkZXZpY2UuIFRoaXMKcmVmZXJlbmNlIGlzIHVuY29uZGl0aW9uYWxseSBkcm9wcGVkIHZp YSBwdXRfZGV2aWNlKHBoeV9kZXYpLCBidXQgdGhlCnVucmVmZXJlbmNlZCBwb2ludGVyIGlzIHRo ZW4gc3RvcmVkIGluIGhvc3QtPnBoeV9kZXYuCgpJZiB0aGUgcGh5IGRldmljZSBpcyByZW1vdmVk IG9yIHVuYm91bmQgYW5kIHRoZSBtZW1vcnkgaXMgZnJlZWQsIHRoZSBVRlMKZHJpdmVyIGNvbnRp bnVlcyB0byBkZXJlZmVyZW5jZSBpdCBkdXJpbmcgcnVudGltZSBQTSBvcGVyYXRpb25zOgoKZHJp dmVycy91ZnMvaG9zdC91ZnMtbWVkaWF0ZWsuYzp1ZnNfbXRrX3J1bnRpbWVfc3VzcGVuZCgpIHsK ICAgIC4uLgoJaWYgKGhvc3QtPnBoeV9kZXYpCgkJcG1fcnVudGltZV9wdXRfc3luYyhob3N0LT5w aHlfZGV2KTsKICAgIC4uLgp9CgpTaG91bGQgdGhlIHJlZmVyZW5jZSBiZSBoZWxkIHVudGlsIHRo ZSBVRlMgaG9zdCBkZXZpY2UgaXMgdW5ib3VuZD8KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBo dHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA3MzAtbXQ4MTk2LXVmcy12MTAtMC1i YzVlY2VmMjAyZGNAY29sbGFib3JhLmNvbT9wYXJ0PTgKCi0tIApsaW51eC1waHkgbWFpbGluZyBs aXN0CmxpbnV4LXBoeUBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHBzOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXBoeQo= 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 A1CCE3F86F0; Thu, 30 Jul 2026 10:07:50 +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=1785406073; cv=none; b=uPWDTYSMvXpzYAnarRbxm330N1fyFNmjnPsrooIOpfA60Y2zn7SBEJkHrSXYkdCz9qlaH7mu0cT8RSk0wAQgAkTPGe/aqFRoLc1pmxLbdrD0F7cwS5kWbMdj7CMFvPsR4/reSVd2ByKNF1aUzKmaEOU96mHr601IJGz4aDGmxK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785406073; c=relaxed/simple; bh=zC2D5XcmFDI2jFeGKaTBpwDTFYjycIQ6TtoyR/9A2H8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Y+0EEK9NK9tj2wW5vl8mbfSdeWCk9HBHjSLpCJ57ivDfDj4yM4NkKfIouEo7BjBntl/jTVR48zGBscYBCMer2dBRfAfcXlHLtyuSSB+3hc38tmeHJ3kSPPxxttY9eLAKOWIsKvEEK69BsD8gsrpix0B188LFUgV44R7NaeKnxWg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ltXV8Add; 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="ltXV8Add" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB3F01F00A3D; Thu, 30 Jul 2026 10:07:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785406067; bh=+DdtGIGw5KisOkEqv6VLLhJyKxudfBrpLNeEuZR/x+8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ltXV8AddneWCj10H+yXmyOp1Ivd5uAPjM1XJSmyc/nozeWSTTjRqplIDONq7Z+00a guSMm8lizOkqxz4hZzYqtA8w54K5BzHeOMjTXCZ8cJRXCaAvvHFQCyqNG40DnLBCQB Wq58QIHE6JHlHrMnAFNyXesvlkww2S2iS5QzB+fqRauFZVoWv+BX8vc6KzD0JO6YU3 9aEpRyd1NvUr+b01xnDRgHmwKgRyzMPLeOekgpZVEjIiJ+HyxAhAHV/EI4B6HFSSna Tz3d0ChQ1DNAzipP9UUgBaxVKFSHJwXHUIeK39Yl+/9Y69xu4cxb3wuhWoH1cAZnJG GBzAZQEa2hhLQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v10 08/26] scsi: ufs: mediatek: Rework init function Reply-To: sashiko-reviews@lists.linux.dev To: "Louis-Alexis Eyraud" Cc: neil.armstrong@linaro.org, devicetree@vger.kernel.org, vkoul@kernel.org, conor+dt@kernel.org, olteanv@gmail.com, robh@kernel.org, linux-phy@lists.infradead.org, linux-scsi@vger.kernel.org In-Reply-To: <20260730-mt8196-ufs-v10-8-bc5ecef202dc@collabora.com> References: <20260730-mt8196-ufs-v10-0-bc5ecef202dc@collabora.com> <20260730-mt8196-ufs-v10-8-bc5ecef202dc@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2026 10:07:46 +0000 Message-Id: <20260730100746.AB3F01F00A3D@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 2 potential issue(= s) to consider: Pre-existing issues: - [High] The return value of `ufs_mtk_mphy_power_on()` is ignored during ho= st initialization. - [High] Use-After-Free risk due to saving a released device pointer in `ho= st->phy_dev`. -- --- Patch [8]: [PATCH v10 08/26] scsi: ufs: mediatek: Rework init function = --- commit 5d79268ac1559dd4c6c615601ae1b9838e4b77bc Author: Nicolas Frattaroli scsi: ufs: mediatek: Rework init function This commit reworks the initialization function for the MediaTek UFS driver. It removes unnecessary error prints for memory allocation failures and remo= ves redundant device tree matching. It also simplifies the error handling path by removing unnecessary goto statements and returning directly on success. > diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-media= tek.c > index f6859cd0b1d4d..50e7701d7943b 100644 > --- a/drivers/ufs/host/ufs-mediatek.c > +++ b/drivers/ufs/host/ufs-mediatek.c [ ... ] > @@ -1356,11 +1334,10 @@ static int ufs_mtk_init(struct ufs_hba *hba) > =20 > ufs_mtk_get_hw_ip_version(hba); > =20 > - goto out; > + return 0; > =20 > out_variant_clear: > ufshcd_set_variant(hba, NULL); > -out: > return err; > } [Severity: High] This isn't a bug introduced by this patch, but does this code ignore the return value of ufs_mtk_mphy_power_on() earlier in ufs_mtk_init()? Looking at ufs_mtk_init(): err =3D ufs_mtk_get_supplies(host); if (err) goto out_variant_clear; /* * ufshcd_vops_init() is invoked after * ufshcd_setup_clock(true) in ufshcd_hba_init() thus * phy clock setup is skipped. * * Enable phy clocks specifically here. */ ufs_mtk_mphy_power_on(hba, true); if (ufs_mtk_is_rtff_mtcmos(hba)) { If ufs_mtk_mphy_power_on() fails (e.g. regulator_enable fails in ufs_mtk_09v_on), the driver will proceed as if the PHY powered on successfully. Should this check the return value and handle the error? [ ... ] > @@ -2402,6 +2379,18 @@ static const struct ufs_hba_variant_ops ufs_hba_mt= k_vops =3D { > .config_scsi_dev =3D ufs_mtk_config_scsi_dev, > }; > =20 > +static const struct ufs_mtk_soc_data mt8183_data =3D { > + .has_avdd09 =3D true, > +}; > + > +static const struct of_device_id ufs_mtk_of_match[] =3D { > + { .compatible =3D "mediatek,mt8183-ufshci", .data =3D &mt8183_data }, > + { .compatible =3D "mediatek,mt8192-ufshci" }, > + { .compatible =3D "mediatek,mt8195-ufshci" }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, ufs_mtk_of_match); > + > /** > * ufs_mtk_probe - probe routine of the driver > * @pdev: pointer to Platform device handle [Severity: High] This is a pre-existing issue, but is there a use-after-free risk in ufs_mtk_probe() when saving the released device pointer? Looking at ufs_mtk_probe(): if (phy_node) { phy_pdev =3D of_find_device_by_node(phy_node); if (!phy_pdev) goto skip_phy; phy_dev =3D &phy_pdev->dev; ... put_device(phy_dev); } ... skip_phy: err =3D ufshcd_pltfrm_init(pdev, &ufs_hba_mtk_vops); ... if (phy_node && phy_dev) { host =3D ufshcd_get_variant(hba); host->phy_dev =3D phy_dev; } of_find_device_by_node() acquires a reference to the phy device. This reference is unconditionally dropped via put_device(phy_dev), but the unreferenced pointer is then stored in host->phy_dev. If the phy device is removed or unbound and the memory is freed, the UFS driver continues to dereference it during runtime PM operations: drivers/ufs/host/ufs-mediatek.c:ufs_mtk_runtime_suspend() { ... if (host->phy_dev) pm_runtime_put_sync(host->phy_dev); ... } Should the reference be held until the UFS host device is unbound? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730-mt8196-ufs= -v10-0-bc5ecef202dc@collabora.com?part=3D8