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 87F78C88E64 for ; Mon, 14 Sep 2026 13:03:09 +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=sMxoV9PPYegv1QHhdxLBKB+k/gx2GPFHRp3X1feX7TE=; b=irCy/u97w60qrC BHGAUZw8RLnNdtA2NnqAGqvaLFESNcWYWkACsdbZfU1UleCwgwBI/yzCyyjfVhdqhVYuaXk6CzDb5 AmK5onDsPeMIUwySR+BU8aqK1u6gl0+5ZsuInt1j+ZQiOVMyhlDaDfYIAupaF6MnG7e1Y2ym9uy6x UP0Xg5Jpt59wW/Mj089gPifTmNj2aWsJALqcrZ7qhdONZfNoCkfxs8jdgCu5kJKOJb8Z/Jny8LKKd dOQR7+a6GGDOHW7B0n4W2sSKOCEFi0C9w7f1vOa9LyuwyfycLS1Us8kCQHTgbinugaMGmr+/2yvyE JdvCoAlBNFFMXkj95fLQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x66Kz-00000003gbk-0FRv; Mon, 14 Sep 2026 13:03:09 +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 1x66Kt-00000003gbM-45gh for linux-phy@lists.infradead.org; Mon, 14 Sep 2026 13:03:04 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 6439F402CB; Mon, 14 Sep 2026 13:03:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA7381F000FF; Mon, 14 Sep 2026 13:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789390983; bh=ES7FJM+Izh3s5krxUmK4wJgOmhiK/PFbKS8ZGjTEiNU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=jxdbFdXeZeZc+qFyuzBLG/Hazm8BvbHCaxKSiYcxfFwa0tiowAA2vyA8jXm+5kWNr G3ZmAuol4ReRoUi0wNFb8FoxJ5Lk1NA14csRtPiKO+7H6qnaXZNq9w53PJYBMOSezo yPqSX5ZVS3lNYDRrRbPRFNtdbtmrN89qet/Q2SP/k0F0NyJDMLaXdAn2WVa+DoL1Zq EDISPe89xfpGIfqCELxZKePaw9oF4sEJgcI9r/EqjbBpp0oUcrjZv42ADT484pjyjl 53/xusRUawbQZrBmyDralkaLs/IQ37PkDFPfk1pdUfSbqJIrDZpDgAtv8wgmN8/s7g unRNUIRX/AQkQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v12 16/24] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths To: "Louis-Alexis Eyraud" Cc: vkoul@kernel.org, linux-phy@lists.infradead.org, olteanv@gmail.com, linux-scsi@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260914-mt8196-ufs-v12-16-9279d7ef814d@collabora.com> References: <20260914-mt8196-ufs-v12-0-9279d7ef814d@collabora.com> <20260914-mt8196-ufs-v12-16-9279d7ef814d@collabora.com> Date: Mon, 14 Sep 2026 13:03:02 +0000 Message-Id: <20260914130302.CA7381F000FF@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 IFtIaWdoXSBUaGUgaW50ZXJuYWwgY2xvY2sgc2NhbGluZyBmdW5jdGlvbiBgX3Vmc19tdGtfY2xr X3NjYWxlKClgIHJldHVybnMgYHZvaWRgIGFuZCBkb2VzIG5vdCBwcm9wYWdhdGUgaGFyZHdhcmUg Y29uZmlndXJhdGlvbiBmYWlsdXJlcyB0byBpdHMgY2FsbGVyLCBjYXVzaW5nIHNpbGVudCBzb2Z0 d2FyZSBzdGF0ZSBkZXN5bmNocm9uaXphdGlvbi4KLSBbSGlnaF0gQ2xvY2sgc2NhbGluZyBpcyBz aWxlbnRseSBkaXNhYmxlZCBhbmQgdHJpZ2dlcnMgY2xvY2sgdHJlZSBjb3JydXB0aW9uIGlmIHRo ZSBvcHRpb25hbCBGREUgY2xvY2sgaXMgbWlzc2luZyBmcm9tIHRoZSBkZXZpY2UgdHJlZS4KLS0K CmNvbW1pdCA2OTU0NzQwYWU2MDExY2Y4M2Q1MTVlMThhNTQ0MDZlOTI5NDJlYzc2CkF1dGhvcjog Tmljb2xhcyBGcmF0dGFyb2xpIDxuaWNvbGFzLmZyYXR0YXJvbGlAY29sbGFib3JhLmNvbT4KCiAg ICBzY3NpOiB1ZnM6IG1lZGlhdGVrOiBSZXdvcmsgX3Vmc19tdGtfY2xrX3NjYWxlIGVycm9yIHBh dGhzCgpUaGlzIGNvbW1pdCByZXdvcmtzIGVycm9yIHBhdGhzIGluIF91ZnNfbXRrX2Nsa19zY2Fs ZSgpIHRvIHVzZSB0aGUgY29ycmVjdApsb2dnaW5nIGxldmVscyB2aWEgZGV2X2VycigpLiBJdCBh bHNvIGFkZHMgbWlzc2luZyBnb3RvIG91dCBzdGF0ZW1lbnRzIGluIHRoZQpzY2FsZSB1cCBjYXNl IGZvciBjb25zaXN0ZW5jeSB3aXRoIHRoZSBzY2FsZSBkb3duIGJyYW5jaC4KCj4gZGlmZiAtLWdp dCBhL2RyaXZlcnMvdWZzL2hvc3QvdWZzLW1lZGlhdGVrLmMgYi9kcml2ZXJzL3Vmcy9ob3N0L3Vm cy1tZWRpYXRlay5jCj4gaW5kZXggOGUyYWViODc3ZGU4My4uYjViMTM0NDRkMjdjYiAxMDA2NDQK PiAtLS0gYS9kcml2ZXJzL3Vmcy9ob3N0L3Vmcy1tZWRpYXRlay5jCj4gKysrIGIvZHJpdmVycy91 ZnMvaG9zdC91ZnMtbWVkaWF0ZWsuYwoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzbid0IGEgYnVn IGludHJvZHVjZWQgYnkgdGhpcyBwYXRjaCwgYnV0IEkgd2FudGVkIHRvIGFzayBhYm91dCB0aGUK ZWFybHkgcmV0dXJuIGp1c3QgYWJvdmUgdGhpcyBmaXJzdCBodW5rIGluIF91ZnNfbXRrX2Nsa19z Y2FsZSgpOgoKCWlmICghY2xraSB8fCAhZmRlX2Nsa2kpCgkJcmV0dXJuOwoKU2luY2UgdWZzX210 a19pc19jbGtfc2NhbGVfcmVhZHkoKSBkb2VzIG5vdCByZXF1aXJlIHRoZSBGREUgY2xvY2sgdG8g YmUKcHJlc2VudCwgZG9lcyB0aGlzIGVhcmx5IHJldHVybiBpbmNvcnJlY3RseSBza2lwIG1haW4g Y2xvY2sgc2NhbGluZyBvbgpwbGF0Zm9ybXMgd2l0aG91dCBhbiBGREUgY2xvY2s/CgpJZiB0aGlz IHJldHVybnMgZWFybHksIHVmc19tdGtfY2xrX3NjYWxlKCkgd2lsbCB1bmNvbmRpdGlvbmFsbHkg dXBkYXRlIHRoZQpjbGtpLT5jdXJyX2ZyZXEgc3RhdGUsIGFuZCB0aGUgVUZTIGNvcmUgbWlnaHQg YXBwbHkgdGhlIG5ldyBmcmVxdWVuY3kgdG8gdGhlCnVuc3dpdGNoZWQgcGFyZW50IGNsb2NrLgoK PiBAQCAtMjAyMCwxNiArMjAyMCwxNiBAQCBzdGF0aWMgdm9pZCBfdWZzX210a19jbGtfc2NhbGUo c3RydWN0IHVmc19oYmEgKmhiYSwgYm9vbCBzY2FsZV91cCkKPiAgCj4gIAlyZXQgPSBjbGtfcHJl cGFyZV9lbmFibGUoY2xraS0+Y2xrKTsKPiAgCWlmIChyZXQpIHsKPiAtCQlkZXZfaW5mbyhoYmEt PmRldiwKPiAtCQkJICJjbGtfcHJlcGFyZV9lbmFibGUoKSBmYWlsLCByZXQ6ICVkXG4iLCByZXQp Owo+ICsJCWRldl9lcnIoaGJhLT5kZXYsICIlczogRmFpbGVkIHRvIGVuYWJsZSBjbG9jazogJXBl XG4iLCBfX2Z1bmNfXywgRVJSX1BUUihyZXQpKTsKPiAgCQlyZXR1cm47Cj4gIAl9CgpbIC4uLiBd Cgo+IEBAIC0yMDM4LDUxICsyMDM4LDQ4IEBAIHN0YXRpYyB2b2lkIF91ZnNfbXRrX2Nsa19zY2Fs ZShzdHJ1Y3QgdWZzX2hiYSAqaGJhLCBib29sIHNjYWxlX3VwKQo+ICAJCWlmIChjbGtfYmluZF92 Y29yZSkgewo+ICAJCQlyZXQgPSByZWd1bGF0b3Jfc2V0X3ZvbHRhZ2UocmVnLCB2b2x0LCBJTlRf TUFYKTsKPiAgCQkJaWYgKHJldCkgewo+IC0JCQkJZGV2X2luZm8oaGJhLT5kZXYsCj4gLQkJCQkJ IkZhaWxlZCB0byBzZXQgdmNvcmUgdG8gJWRcbiIsIHZvbHQpOwo+ICsJCQkJZGV2X2VycihoYmEt PmRldiwgIkZhaWxlZCB0byBzZXQgdmNvcmUgdG8gJWRcbiIsIHZvbHQpOwo+ICAJCQkJZ290byBv dXQ7Cj4gIAkJCX0KPiAgCQl9Cj4gIAo+ICAJCXJldCA9IGNsa19zZXRfcGFyZW50KGNsa2ktPmNs aywgbWNsay0+dWZzX3NlbF9tYXhfY2xraS0+Y2xrKTsKPiAgCQlpZiAocmV0KSB7Cj4gLQkJCWRl dl9pbmZvKGhiYS0+ZGV2LCAiRmFpbGVkIHRvIHNldCBjbGsgbXV4LCByZXQgPSAlZFxuIiwKPiAt CQkJCXJldCk7Cj4gKwkJCWRldl9lcnIoaGJhLT5kZXYsICIlczogRmFpbGVkIHRvIHNldCBjbG9j ayBtdXg6ICVwZVxuIiwKPiArCQkJCV9fZnVuY19fLCBFUlJfUFRSKHJldCkpOwo+ICsJCQlnb3Rv IG91dDsKPiAgCQl9CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNz dWUsIGJ1dCBzaG91bGQgX3Vmc19tdGtfY2xrX3NjYWxlKCkgcHJvcGFnYXRlCnRoZXNlIGVycm9y cyBiYWNrIHRvIHRoZSBjYWxsZXIgaW5zdGVhZCBvZiByZXR1cm5pbmcgdm9pZD8KCldoZW4gdGhp cyB0YWtlcyB0aGUgImdvdG8gb3V0IiBwYXRoIG9uIGZhaWx1cmUsIHRoZSBjYWxsZXIKdWZzX210 a19jbGtfc2NhbGUoKSBhc3N1bWVzIHN1Y2Nlc3MgYW5kIHVuY29uZGl0aW9uYWxseSBhcHBsaWVz IHRoZSB0YXJnZXQKZnJlcXVlbmN5IHRvIHRoZSBzb2Z0d2FyZSBzdGF0ZToKCnVmc19tdGtfY2xr X3NjYWxlKCkgewogICAgLi4uCglpZiAoc2NhbGVfdXApCgkJX3Vmc19tdGtfY2xrX3NjYWxlKGhi YSwgdHJ1ZSk7CgllbHNlCgkJX3Vmc19tdGtfY2xrX3NjYWxlKGhiYSwgZmFsc2UpOwoKCWhvc3Qt PmNsa19zY2FsZV91cCA9IHNjYWxlX3VwOwoKCS8qIE11c3QgYWx3YXlzIHNldCBiZWZvcmUgY2xr X3NldF9yYXRlKCkgKi8KCWlmIChzY2FsZV91cCkKCQljbGtpLT5jdXJyX2ZyZXEgPSBjbGtpLT5t YXhfZnJlcTsKCWVsc2UKCQljbGtpLT5jdXJyX2ZyZXEgPSBjbGtpLT5taW5fZnJlcTsKICAgIC4u Lgp9CgpCZWNhdXNlIHVmc19tdGtfY2xrX3NjYWxlX25vdGlmeSgpIHRoZW4gcmV0dXJucyAwLCB0 aGUgVUZTIGNvcmUgcHJvY2VlZHMgdG8KY2FsbCBjbGtfc2V0X3JhdGUoKSBvbiB0aGUgbXV4IGNs b2NrLiBJZiB0aGUgcGFyZW50IHdhcyBuZXZlciBzd2l0Y2hlZCwKZG9lcyB0aGlzIGFwcGx5IHRo ZSByYXRlIGNoYW5nZSB0byB0aGUgb3JpZ2luYWwgcGFyZW50IGNsb2NrLCBwb3RlbnRpYWxseQpj b3JydXB0aW5nIHRoZSBjbG9jayB0cmVlPwoKWyAuLi4gXQoKLS0gClNhc2hpa28gQUkgcmV2aWV3 IMK3IGh0dHBzOi8vc2FzaGlrby5kZXYvIy9wYXRjaHNldC8yMDI2MDkxNC1tdDgxOTYtdWZzLXYx Mi0wLTkyNzlkN2VmODE0ZEBjb2xsYWJvcmEuY29tP3BhcnQ9MTYKCi0tIApsaW51eC1waHkgbWFp bGluZyBsaXN0CmxpbnV4LXBoeUBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHBzOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXBoeQo= 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 963FA4718DA; Mon, 14 Sep 2026 13:03:03 +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=1789390984; cv=none; b=OTvbD48E7y3gPADA7T5bpqAKQ/V87WQYlHQqv9Te4BJFFJcMa/Ptxd8rq24E2Q6Es9Db63pWUVJw0P90lx8HW6oXs5JdHEXYvG4OayM6lplbAYRgyYY2VnZ8j88R7C2eJSBB5uc5J/Szk8ElQ6hq9jnzTFAzSFNtx9Y/sGdhb6o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789390984; c=relaxed/simple; bh=h4+g314dISLc4nmNK6lN+nc5NS+KtRZhN74qYEKIaGc=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=MxkxTxUBvj48oJh8QHajr8yXsqgPzHid+hnzgJihe9jVz1IsdXzBJLRwDSlPtBYgWhgRlhnIuMlX92jTXcFasdU0ldn6j3SA/LE2kJuAWm9Oa++Ds9cUMSqs6vIx9YenELSQBINIVrsRoSXEn5YBQ99fVexYKQrBeksrYZCspmA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jxdbFdXe; 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="jxdbFdXe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA7381F000FF; Mon, 14 Sep 2026 13:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789390983; bh=ES7FJM+Izh3s5krxUmK4wJgOmhiK/PFbKS8ZGjTEiNU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=jxdbFdXeZeZc+qFyuzBLG/Hazm8BvbHCaxKSiYcxfFwa0tiowAA2vyA8jXm+5kWNr G3ZmAuol4ReRoUi0wNFb8FoxJ5Lk1NA14csRtPiKO+7H6qnaXZNq9w53PJYBMOSezo yPqSX5ZVS3lNYDRrRbPRFNtdbtmrN89qet/Q2SP/k0F0NyJDMLaXdAn2WVa+DoL1Zq EDISPe89xfpGIfqCELxZKePaw9oF4sEJgcI9r/EqjbBpp0oUcrjZv42ADT484pjyjl 53/xusRUawbQZrBmyDralkaLs/IQ37PkDFPfk1pdUfSbqJIrDZpDgAtv8wgmN8/s7g unRNUIRX/AQkQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v12 16/24] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths Reply-To: sashiko-reviews@lists.linux.dev To: "Louis-Alexis Eyraud" Cc: vkoul@kernel.org, linux-phy@lists.infradead.org, olteanv@gmail.com, linux-scsi@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260914-mt8196-ufs-v12-16-9279d7ef814d@collabora.com> References: <20260914-mt8196-ufs-v12-0-9279d7ef814d@collabora.com> <20260914-mt8196-ufs-v12-16-9279d7ef814d@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Sep 2026 13:03:02 +0000 Message-Id: <20260914130302.CA7381F000FF@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-scsi@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 internal clock scaling function `_ufs_mtk_clk_scale()` returns= `void` and does not propagate hardware configuration failures to its calle= r, causing silent software state desynchronization. - [High] Clock scaling is silently disabled and triggers clock tree corrupt= ion if the optional FDE clock is missing from the device tree. -- commit 6954740ae6011cf83d515e18a54406e92942ec76 Author: Nicolas Frattaroli scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths This commit reworks error paths in _ufs_mtk_clk_scale() to use the correct logging levels via dev_err(). It also adds missing goto out statements in t= he scale up case for consistency with the scale down branch. > diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-media= tek.c > index 8e2aeb877de83..b5b13444d27cb 100644 > --- a/drivers/ufs/host/ufs-mediatek.c > +++ b/drivers/ufs/host/ufs-mediatek.c [Severity: High] This isn't a bug introduced by this patch, but I wanted to ask about the early return just above this first hunk in _ufs_mtk_clk_scale(): if (!clki || !fde_clki) return; Since ufs_mtk_is_clk_scale_ready() does not require the FDE clock to be present, does this early return incorrectly skip main clock scaling on platforms without an FDE clock? If this returns early, ufs_mtk_clk_scale() will unconditionally update the clki->curr_freq state, and the UFS core might apply the new frequency to the unswitched parent clock. > @@ -2020,16 +2020,16 @@ static void _ufs_mtk_clk_scale(struct ufs_hba *hb= a, bool scale_up) > =20 > ret =3D clk_prepare_enable(clki->clk); > if (ret) { > - dev_info(hba->dev, > - "clk_prepare_enable() fail, ret: %d\n", ret); > + dev_err(hba->dev, "%s: Failed to enable clock: %pe\n", __func__, ERR_P= TR(ret)); > return; > } [ ... ] > @@ -2038,51 +2038,48 @@ static void _ufs_mtk_clk_scale(struct ufs_hba *hb= a, bool scale_up) > if (clk_bind_vcore) { > ret =3D regulator_set_voltage(reg, volt, INT_MAX); > if (ret) { > - dev_info(hba->dev, > - "Failed to set vcore to %d\n", volt); > + dev_err(hba->dev, "Failed to set vcore to %d\n", volt); > goto out; > } > } > =20 > ret =3D clk_set_parent(clki->clk, mclk->ufs_sel_max_clki->clk); > if (ret) { > - dev_info(hba->dev, "Failed to set clk mux, ret =3D %d\n", > - ret); > + dev_err(hba->dev, "%s: Failed to set clock mux: %pe\n", > + __func__, ERR_PTR(ret)); > + goto out; > } [Severity: High] This is a pre-existing issue, but should _ufs_mtk_clk_scale() propagate these errors back to the caller instead of returning void? When this takes the "goto out" path on failure, the caller ufs_mtk_clk_scale() assumes success and unconditionally applies the target frequency to the software state: ufs_mtk_clk_scale() { ... if (scale_up) _ufs_mtk_clk_scale(hba, true); else _ufs_mtk_clk_scale(hba, false); host->clk_scale_up =3D scale_up; /* Must always set before clk_set_rate() */ if (scale_up) clki->curr_freq =3D clki->max_freq; else clki->curr_freq =3D clki->min_freq; ... } Because ufs_mtk_clk_scale_notify() then returns 0, the UFS core proceeds to call clk_set_rate() on the mux clock. If the parent was never switched, does this apply the rate change to the original parent clock, potentially corrupting the clock tree? [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260914-mt8196-ufs= -v12-0-9279d7ef814d@collabora.com?part=3D16