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 1D10FC79FAD for ; Wed, 9 Sep 2026 09:54:24 +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=TQucSYB6fMUb901CUwwz7kNClHMnRxAMesiunsMALLI=; b=zy6HOSPezHQ6AE FaCpXuuJ9UkQdrxveAlKEq8cpKBQQW7l4Vnf5zFDqRlmBuO2iVetVQD+I0o2+VNrSSpCjeI7biDDg w35f9McVQhHQ1U9GMOWgZSm64V3B9yTeqXMjs7b6dSNVN7udKgk3GIu/I9cs9vStgLJH8Wh6ygbB9 1TIcfXPwLM+QuigHiw65473GSiI0HjHhPXiJgvRToKV60woThgoC2/l5Sdt5QD5oI473KrXMzUq7g Rulrghv7BknMX2cNAxk1OaZrWouu+RLVht5b2hHMBsndKppwcRq8mxOJWUnNyhlbqHfjsZVy2eYa+ 9EbGkD05u54Ovnpiqiqw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x4F0Z-0000000BMO7-1z3H; Wed, 09 Sep 2026 09:54:23 +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 1x4F0X-0000000BMNF-11p8 for linux-phy@lists.infradead.org; Wed, 09 Sep 2026 09:54:21 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 878E66022D; Wed, 9 Sep 2026 09:54:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C30C81F00A3D; Wed, 9 Sep 2026 09:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788947660; bh=WIuUZcVe2UXewNV0LRzVMQyS4T34o/IpvI/Gf9Rv474=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=nHwxHSBFm5HdcGDYoGKXmTHExwPbkP+vHb5D8t7mZJf1y9GV6LrLZF7adL4djEXa7 Kq57E3S6jjUiPxuKuuEVOT9f316gMHfI+COa5UrO2qjDRsjr9XPJlE6MZyIZ+pyOgI YMoId8PezDCzpMwQHUx3GgBnjohxgHAUMWd3/MsI4Uj2ZGo2rBoEBe1jZivDwzR2PV 7X9/VORUaXzizQ6YdtnGoK32dEgg22eiZ8aR0OjetHUWd+oEROt17+XltB0mydKKJa ijak89K1/e9TpNlKJVb7LElxlCogMUlbSDqZkCYa6BtaZBYO84WLUCCRc7EAnsXaA3 2iPL/8m3CA8bg== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/2] phy: tegra: Add Tegra264 MPHY driver To: "Kartik Rajput" Cc: robh@kernel.org, olteanv@gmail.com, neil.armstrong@linaro.org, linux-phy@lists.infradead.org, conor+dt@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org In-Reply-To: <20260909-tegra264-mphy-v1-2-ce61a80dc065@nvidia.com> References: <20260909-tegra264-mphy-v1-0-ce61a80dc065@nvidia.com> <20260909-tegra264-mphy-v1-2-ce61a80dc065@nvidia.com> Date: Wed, 09 Sep 2026 09:54:19 +0000 Message-Id: <20260909095419.C30C81F00A3D@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIERhdGEgcmFjZSBvbiBz aGFyZWQgYG1waHktPnBvd2VyX2NvdW50YCBhbmQgY2xvY2sgc3RhdGUgYWNyb3NzIG11bHRpcGxl IFBIWSBpbnN0YW5jZXMuCi0gW0hpZ2hdIFRYIFBIWSBsYWNrcyBwb3dlciBtYW5hZ2VtZW50IG9w ZXJhdGlvbnMsIGNyZWF0aW5nIGEgZnJhZ2lsZSBBUEkgY29udHJhY3QgdGhhdCByaXNrcyBzeXN0 ZW0gY3Jhc2hlcy4KLSBbSGlnaF0gV3JvbmcgYmFzZSBhZGRyZXNzIHBvaW50ZXIgdXNlZCBmb3Ig YE1QSFlfUlhfQVBCX0NBUEFCSUxJVFlgIHJlZ2lzdGVycy4KLSBbTWVkaXVtXSBNaXNzaW5nIHJl c2V0IGFzc2VydGlvbiBmb3IgYG1waHktPnJzdF9jbGtfY3RsYCBpbiB0aGUgbm9ybWFsIGB0ZWdy YV9tcGh5X3J4X3Bvd2VyX29mZmAgcGF0aC4KLS0KCmNvbW1pdCBiY2ViMDgzODBlMDM4NDdhODBj ZTc3ZGIzOWMzZmYyNzFjYmNjYjBjCkF1dGhvcjogS2FydGlrIFJhanB1dCA8a2thcnRpa0Budmlk aWEuY29tPgoKcGh5OiB0ZWdyYTogQWRkIFRlZ3JhMjY0IE1QSFkgZHJpdmVyCgpBZGQgYSBkcml2 ZXIgZm9yIHRoZSBNSVBJIE0tUEhZIGZvdW5kIG9uIE5WSURJQSBUZWdyYTI2NCBTb0NzLiBUaGUK TS1QSFkgaGFzIHR3byBsYW5lcywgZWFjaCB3aXRoIGEgdHJhbnNtaXQgYW5kIGEgcmVjZWl2ZSBk aXJlY3Rpb24sCmV4cG9zZWQgYXMgZm91ciBQSFlzIHRvIHRoZSBVRlMgaG9zdCBjb250cm9sbGVy LgoKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9waHkvdGVncmEvcGh5LXRlZ3JhLW1waHkuYyBiL2Ry aXZlcnMvcGh5L3RlZ3JhL3BoeS10ZWdyYS1tcGh5LmMKPiBpbmRleCAwMDAwMDAwMDAwMDAwLi4w MWNhZmUxYzc0NzdmCj4gLS0tIC9kZXYvbnVsbAo+ICsrKyBiL2RyaXZlcnMvcGh5L3RlZ3JhL3Bo eS10ZWdyYS1tcGh5LmMKClsgLi4uIF0KCj4gK3N0YXRpYyBpbnQgdGVncmFfbXBoeV9yeF9wb3dl cl9vbihzdHJ1Y3QgcGh5ICpwaHkpCj4gK3sKPiArCXN0cnVjdCB0ZWdyYV9tcGh5ICptcGh5ID0g ZGV2X2dldF9kcnZkYXRhKHBoeS0+ZGV2LnBhcmVudCk7Cj4gKwlzdHJ1Y3QgdGVncmFfbXBoeV9s YW5lICpsYW5lID0gcGh5X2dldF9kcnZkYXRhKHBoeSk7Cj4gKwl1MzIgdmFsdWU7Cj4gKwlpbnQg ZXJyOwo+ICsKPiArCWlmIChtcGh5LT5wb3dlcl9jb3VudCsrID09IDApIHsKICAgICAgICAgICAg Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4KCltTZXZlcml0eTogSGlnaF0KU2luY2UgbDAgYW5kIGwx IGFyZSBkaXN0aW5jdCBQSFkgaW5zdGFuY2VzIGV4cG9zZWQgdG8gdGhlIGNvbnN1bWVyLCBjYW4K Y29uY3VycmVudCBwaHlfcG93ZXJfb24oKSBvciBwaHlfcG93ZXJfb2ZmKCkgY2FsbHMgcmFjZSBv biB0aGlzIHNoYXJlZAptcGh5LT5wb3dlcl9jb3VudD8KClRoZSBQSFkgZnJhbWV3b3JrJ3MgaW50 ZXJuYWwgbXV0ZXggb25seSBzZXJpYWxpemVzIG9wZXJhdGlvbnMgb24gYSBwZXItUEhZCmJhc2lz LiBBbiB1bnByb3RlY3RlZCByZWFkLW1vZGlmeS13cml0ZSBoZXJlIGNvdWxkIGxlYWQgdG8gY29y cnVwdGVkCnJlZmVyZW5jZSBjb3VudHMsIHVuYmFsYW5jZWQgY2xvY2sgc3RhdGVzLCBhbmQgaGFy ZHdhcmUgZmF1bHRzLgoKPiArCQllcnIgPSBjbGtfYnVsa19wcmVwYXJlX2VuYWJsZShtcGh5LT5u dW1fY2xrcywgbXBoeS0+Y2xrcyk7Cj4gKwkJaWYgKGVycikgewo+ICsJCQltcGh5LT5wb3dlcl9j b3VudC0tOwo+ICsJCQlkZXZfZXJyKCZwaHktPmRldiwgImZhaWxlZCB0byBlbmFibGUgY2xvY2tz OiAlZFxuIiwgZXJyKTsKPiArCQkJcmV0dXJuIGVycjsKPiArCQl9Cj4gKwkJcmVzZXRfY29udHJv bF9kZWFzc2VydChtcGh5LT5yc3RfY2xrX2N0bCk7Cj4gKwl9Cj4gKwo+ICsJcmVzZXRfY29udHJv bF9kZWFzc2VydChsYW5lLT5yc3RfcngpOwo+ICsJcmVzZXRfY29udHJvbF9kZWFzc2VydChsYW5l LT5yc3RfdHgpOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5e Xl5eXl4KCltTZXZlcml0eTogSGlnaF0KSXMgaXQgaW50ZW50aW9uYWwgdGhhdCB0aGUgUlggcG93 ZXItb24gcGF0aCBoYW5kbGVzIHRoZSByZXNldCBsb2dpYyBmb3IgdGhlCmluZGVwZW5kZW50bHkg ZXhwb3NlZCBUWCBQSFk/CgpUaGUgVFggUEhZIGN1cnJlbnRseSBsYWNrcyAucG93ZXJfb24gYW5k IC5wb3dlcl9vZmYgY2FsbGJhY2tzIGFuZCBzZWVtcyB0bwpyZWx5IGltcGxpY2l0bHkgb24gdGhl IFJYIFBIWSB0byBlbmFibGUgaGFyZHdhcmUgY2xvY2tzLiBJZiB0aGUgVFggUEhZIGlzCmFjY2Vz c2VkIHZpYSBwaHlfY29uZmlndXJlKCkgYmVmb3JlIHRoZSBSWCBQSFkgaXMgZnVsbHkgcG93ZXJl ZCBvbiwgY291bGQKdGhpcyByZXN1bHQgaW4gdW5jbG9ja2VkIG1lbW9yeS1tYXBwZWQgSS9PIGFu ZCB0cmlnZ2VyIGEgc3luY2hyb25vdXMKZXh0ZXJuYWwgYWJvcnQ/Cgo+ICsKPiArCWVyciA9IHRl Z3JhX21waHlfcnhfd3JpdGVfa2lja19nbyhsYW5lLCBNUEhZX1JYX0FQQl9WRU5ET1IzQiwgTVBI WV9FUV9USU1FT1VUKTsKPiArCWlmIChlcnIpIHsKPiArCQlkZXZfZXJyKCZwaHktPmRldiwgImVx X3RpbWVvdXQgcHJvZ3JhbW1pbmcgZmFpbGVkOiAlZFxuIiwgZXJyKTsKPiArCQlnb3RvIGVycl9y ZXNldDsKPiArCX0KPiArCj4gKwllcnIgPSB0ZWdyYV9tcGh5X3J4X3dyaXRlX2tpY2tfZ28obGFu ZSwgTVBIWV9SWF9BUEJfVkVORE9SNDksIE1QSFlfUFdSX0NIQU5HRV9DTEtfQk9PU1QpOwo+ICsJ aWYgKGVycikgewo+ICsJCWRldl9lcnIoJnBoeS0+ZGV2LCAicHdyX2NoYW5nZV9jbGtfYm9vc3Qg cHJvZ3JhbW1pbmcgZmFpbGVkOiAlZFxuIiwgZXJyKTsKPiArCQlnb3RvIGVycl9yZXNldDsKPiAr CX0KPiArCj4gKwl2YWx1ZSA9IHJlYWRsKGxhbmUtPnJlZ3MgKyBNUEhZX1JYX0FQQl9DQVBBQklM SVRZXzg4XzhCKTsKICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl4KCltTZXZlcml0eTog SGlnaF0KU2hvdWxkIHRoaXMgdXNlIGxhbmUtPnJ4X3JlZ3MgaW5zdGVhZCBvZiBsYW5lLT5yZWdz IGZvciBvZmZzZXQgYXBwbGljYXRpb24/CgpVc2luZyBsYW5lLT5yZWdzIG1pc2RpcmVjdHMgdGhl IHJlYWQvd3JpdGUgb3BlcmF0aW9ucyB0byBvZmZzZXRzIDB4ODggYW5kCjB4OTQgaW5zdGVhZCBv ZiAweDIwODggYW5kIDB4MjA5NCAoc2luY2UgTVBIWV9SWF9PRkZTRVQgaXMgMHgyMDAwKSwgd2hp Y2gKbWF5IGxlYWQgdG8gbWVtb3J5IGNvcnJ1cHRpb24gYW5kIGZhaWxlZCBjb25maWd1cmF0aW9u cy4KCj4gKwl2YWx1ZSAmPSB+UlhfSFNfRzFfU1lOQ19MRU5HVEhfQ0FQQUJJTElUWSh+MCk7Cj4g Kwl2YWx1ZSB8PSBSWF9IU19HMV9TWU5DX0xFTkdUSF9DQVBBQklMSVRZKDB4Zik7Cj4gKwl3cml0 ZWwodmFsdWUsIGxhbmUtPnJlZ3MgKyBNUEhZX1JYX0FQQl9DQVBBQklMSVRZXzg4XzhCKTsKPiAr Cj4gKwl2YWx1ZSA9IHJlYWRsKGxhbmUtPnJlZ3MgKyBNUEhZX1JYX0FQQl9DQVBBQklMSVRZXzk0 Xzk3KTsKICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl4KCltTZXZlcml0eTogSGlnaF0K RG9lcyB0aGlzIGFsc28gbmVlZCB0byB1c2UgbGFuZS0+cnhfcmVncyBpbnN0ZWFkIG9mIGxhbmUt PnJlZ3M/Cgo+ICsJdmFsdWUgJj0gflJYX0hTX0czX1NZTkNfTEVOR1RIX0NBUEFCSUxJVFkofjAp Owo+ICsJdmFsdWUgfD0gUlhfSFNfRzNfU1lOQ19MRU5HVEhfQ0FQQUJJTElUWSgweGYpOwo+ICsJ dmFsdWUgJj0gflJYX0hTX0cyX1NZTkNfTEVOR1RIX0NBUEFCSUxJVFkofjApOwo+ICsJdmFsdWUg fD0gUlhfSFNfRzJfU1lOQ19MRU5HVEhfQ0FQQUJJTElUWSgweGYpOwo+ICsJd3JpdGVsKHZhbHVl LCBsYW5lLT5yZWdzICsgTVBIWV9SWF9BUEJfQ0FQQUJJTElUWV85NF85Nyk7CgpbIC4uLiBdCgo+ ICtzdGF0aWMgaW50IHRlZ3JhX21waHlfcnhfcG93ZXJfb2ZmKHN0cnVjdCBwaHkgKnBoeSkKPiAr ewo+ICsJc3RydWN0IHRlZ3JhX21waHkgKm1waHkgPSBkZXZfZ2V0X2RydmRhdGEocGh5LT5kZXYu cGFyZW50KTsKPiArCXN0cnVjdCB0ZWdyYV9tcGh5X2xhbmUgKmxhbmUgPSBwaHlfZ2V0X2RydmRh dGEocGh5KTsKPiArCj4gKwlpZiAoV0FSTl9PTihtcGh5LT5wb3dlcl9jb3VudCA9PSAwKSkKPiAr CQlyZXR1cm4gLUVJTlZBTDsKPiArCj4gKwlyZXNldF9jb250cm9sX2Fzc2VydChsYW5lLT5yc3Rf cngpOwo+ICsJcmVzZXRfY29udHJvbF9hc3NlcnQobGFuZS0+cnN0X3R4KTsKPiArCj4gKwlpZiAo LS1tcGh5LT5wb3dlcl9jb3VudCA9PSAwKQo+ICsJCWNsa19idWxrX2Rpc2FibGVfdW5wcmVwYXJl KG1waHktPm51bV9jbGtzLCBtcGh5LT5jbGtzKTsKICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXgoKW1NldmVyaXR5OiBN ZWRpdW1dClNob3VsZCBtcGh5LT5yc3RfY2xrX2N0bCBiZSBhc3NlcnRlZCBoZXJlIGJlZm9yZSBv ciBhZnRlciBkaXNhYmxpbmcgdGhlCmNsb2Nrcz8KClRoZSBkcml2ZXIgaW50ZW50aW9uYWxseSBk ZWFzc2VydHMgbXBoeS0+cnN0X2Nsa19jdGwgaW4KdGVncmFfbXBoeV9yeF9wb3dlcl9vbigpIHdo ZW4gcG93ZXJfY291bnQgZ29lcyBmcm9tIDAgdG8gMSwgYnV0IG9taXRzIHRoZQpjb3JyZXNwb25k aW5nIHJlc2V0X2NvbnRyb2xfYXNzZXJ0KCkgaW4gdGhpcyBzdWNjZXNzZnVsIHBvd2VyLW9mZiBw YXRoLAp3aGljaCBsZWFrcyB0aGUgcmVzZXQgc3RhdGUgYWNyb3NzIHBvd2VyIGN5Y2xlcy4KCj4g Kwo+ICsJcmV0dXJuIDA7Cj4gK30KClsgLi4uIF0KCj4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgcGh5 X29wcyB0ZWdyYV9tcGh5X3R4X29wcyA9IHsKPiArCS5jb25maWd1cmUgPSB0ZWdyYV9tcGh5X3R4 X2NvbmZpZ3VyZSwKPiArCS5jYWxpYnJhdGUgPSB0ZWdyYV9tcGh5X3R4X2NhbGlicmF0ZSwKPiAr fTsKICAgICAgICBeXgoKW1NldmVyaXR5OiBIaWdoXQpBcmUgLnBvd2VyX29uIGFuZCAucG93ZXJf b2ZmIGNhbGxiYWNrcyBpbnRlbnRpb25hbGx5IG9taXR0ZWQgZm9yIHRoZSBUWCBQSFkKb3BzPwoK TGVhdmluZyB0aGUgVFggUEhZIGV4cG9zZWQgdG8gY29uZmlndXJhdGlvbiB3aGlsZSBpbiBhbiB1 bmNsb2NrZWQgc3RhdGUKY3JlYXRlcyBhIGZyYWdpbGUgQVBJIGNvbnRyYWN0IHRoYXQgcmlza3Mg c3lzdGVtIGNyYXNoZXMuCgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtv LmRldi8jL3BhdGNoc2V0LzIwMjYwOTA5LXRlZ3JhMjY0LW1waHktdjEtMC1jZTYxYTgwZGMwNjVA bnZpZGlhLmNvbT9wYXJ0PTIKCi0tIApsaW51eC1waHkgbWFpbGluZyBsaXN0CmxpbnV4LXBoeUBs aXN0cy5pbmZyYWRlYWQub3JnCmh0dHBzOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpbnV4LXBoeQo= 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 7C6F6387347 for ; Wed, 9 Sep 2026 09:54:20 +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=1788947661; cv=none; b=ajenP9T1vmb6dj+CrYD/xN+UhSL7ZDh4Z9pVz4slUyPwdWosLW9mK1U7N0pWCr0E1sBCcWxEtRZZ187L5JP3v6IvrObZKVFxjiuasyO2U7q2jH+WIjBE4U7PM/jrfqZMg/kyKySqHF+8SZnucry0coKv9anitJyQS0Ps1H03noY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788947661; c=relaxed/simple; bh=7Y6iDoWSVZLfFBshi0b4hs2DykWxH9/UUHj9OOzof+0=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=gdT80EuuOhylR75FDRpyt0gAu6Ci9vZZYjBu71C7sR41gRqNENV78ThcIESGFYaPSJWiutAsE+Wz5C+303R24QQ5Rkty4+3ic0PAib3dpD+34XcmsoX7hiyRlbavG4Ni0iYEgbn7tYyQKZc4tMMZo9BgObW9ZAbv0EckM2dXACY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nHwxHSBF; 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="nHwxHSBF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C30C81F00A3D; Wed, 9 Sep 2026 09:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788947660; bh=WIuUZcVe2UXewNV0LRzVMQyS4T34o/IpvI/Gf9Rv474=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=nHwxHSBFm5HdcGDYoGKXmTHExwPbkP+vHb5D8t7mZJf1y9GV6LrLZF7adL4djEXa7 Kq57E3S6jjUiPxuKuuEVOT9f316gMHfI+COa5UrO2qjDRsjr9XPJlE6MZyIZ+pyOgI YMoId8PezDCzpMwQHUx3GgBnjohxgHAUMWd3/MsI4Uj2ZGo2rBoEBe1jZivDwzR2PV 7X9/VORUaXzizQ6YdtnGoK32dEgg22eiZ8aR0OjetHUWd+oEROt17+XltB0mydKKJa ijak89K1/e9TpNlKJVb7LElxlCogMUlbSDqZkCYa6BtaZBYO84WLUCCRc7EAnsXaA3 2iPL/8m3CA8bg== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/2] phy: tegra: Add Tegra264 MPHY driver Reply-To: sashiko-reviews@lists.linux.dev To: "Kartik Rajput" Cc: robh@kernel.org, olteanv@gmail.com, neil.armstrong@linaro.org, linux-phy@lists.infradead.org, conor+dt@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org In-Reply-To: <20260909-tegra264-mphy-v1-2-ce61a80dc065@nvidia.com> References: <20260909-tegra264-mphy-v1-0-ce61a80dc065@nvidia.com> <20260909-tegra264-mphy-v1-2-ce61a80dc065@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 09 Sep 2026 09:54:19 +0000 Message-Id: <20260909095419.C30C81F00A3D@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 4 potential issue(= s) to consider: - [High] Data race on shared `mphy->power_count` and clock state across mul= tiple PHY instances. - [High] TX PHY lacks power management operations, creating a fragile API c= ontract that risks system crashes. - [High] Wrong base address pointer used for `MPHY_RX_APB_CAPABILITY` regis= ters. - [Medium] Missing reset assertion for `mphy->rst_clk_ctl` in the normal `t= egra_mphy_rx_power_off` path. -- commit bceb08380e03847a80ce77db39c3ff271cbccb0c Author: Kartik Rajput phy: tegra: Add Tegra264 MPHY driver Add a driver for the MIPI M-PHY found on NVIDIA Tegra264 SoCs. The M-PHY has two lanes, each with a transmit and a receive direction, exposed as four PHYs to the UFS host controller. > diff --git a/drivers/phy/tegra/phy-tegra-mphy.c b/drivers/phy/tegra/phy-t= egra-mphy.c > index 0000000000000..01cafe1c7477f > --- /dev/null > +++ b/drivers/phy/tegra/phy-tegra-mphy.c [ ... ] > +static int tegra_mphy_rx_power_on(struct phy *phy) > +{ > + struct tegra_mphy *mphy =3D dev_get_drvdata(phy->dev.parent); > + struct tegra_mphy_lane *lane =3D phy_get_drvdata(phy); > + u32 value; > + int err; > + > + if (mphy->power_count++ =3D=3D 0) { ^^^^^^^^^^^^^^^^^^^^^^^ [Severity: High] Since l0 and l1 are distinct PHY instances exposed to the consumer, can concurrent phy_power_on() or phy_power_off() calls race on this shared mphy->power_count? The PHY framework's internal mutex only serializes operations on a per-PHY basis. An unprotected read-modify-write here could lead to corrupted reference counts, unbalanced clock states, and hardware faults. > + err =3D clk_bulk_prepare_enable(mphy->num_clks, mphy->clks); > + if (err) { > + mphy->power_count--; > + dev_err(&phy->dev, "failed to enable clocks: %d\n", err); > + return err; > + } > + reset_control_deassert(mphy->rst_clk_ctl); > + } > + > + reset_control_deassert(lane->rst_rx); > + reset_control_deassert(lane->rst_tx); ^^^^^^^^^^^^^^^^^^^^ [Severity: High] Is it intentional that the RX power-on path handles the reset logic for the independently exposed TX PHY? The TX PHY currently lacks .power_on and .power_off callbacks and seems to rely implicitly on the RX PHY to enable hardware clocks. If the TX PHY is accessed via phy_configure() before the RX PHY is fully powered on, could this result in unclocked memory-mapped I/O and trigger a synchronous external abort? > + > + err =3D tegra_mphy_rx_write_kick_go(lane, MPHY_RX_APB_VENDOR3B, MPHY_EQ= _TIMEOUT); > + if (err) { > + dev_err(&phy->dev, "eq_timeout programming failed: %d\n", err); > + goto err_reset; > + } > + > + err =3D tegra_mphy_rx_write_kick_go(lane, MPHY_RX_APB_VENDOR49, MPHY_PW= R_CHANGE_CLK_BOOST); > + if (err) { > + dev_err(&phy->dev, "pwr_change_clk_boost programming failed: %d\n", er= r); > + goto err_reset; > + } > + > + value =3D readl(lane->regs + MPHY_RX_APB_CAPABILITY_88_8B); ^^^^^^^^^^ [Severity: High] Should this use lane->rx_regs instead of lane->regs for offset application? Using lane->regs misdirects the read/write operations to offsets 0x88 and 0x94 instead of 0x2088 and 0x2094 (since MPHY_RX_OFFSET is 0x2000), which may lead to memory corruption and failed configurations. > + value &=3D ~RX_HS_G1_SYNC_LENGTH_CAPABILITY(~0); > + value |=3D RX_HS_G1_SYNC_LENGTH_CAPABILITY(0xf); > + writel(value, lane->regs + MPHY_RX_APB_CAPABILITY_88_8B); > + > + value =3D readl(lane->regs + MPHY_RX_APB_CAPABILITY_94_97); ^^^^^^^^^^ [Severity: High] Does this also need to use lane->rx_regs instead of lane->regs? > + value &=3D ~RX_HS_G3_SYNC_LENGTH_CAPABILITY(~0); > + value |=3D RX_HS_G3_SYNC_LENGTH_CAPABILITY(0xf); > + value &=3D ~RX_HS_G2_SYNC_LENGTH_CAPABILITY(~0); > + value |=3D RX_HS_G2_SYNC_LENGTH_CAPABILITY(0xf); > + writel(value, lane->regs + MPHY_RX_APB_CAPABILITY_94_97); [ ... ] > +static int tegra_mphy_rx_power_off(struct phy *phy) > +{ > + struct tegra_mphy *mphy =3D dev_get_drvdata(phy->dev.parent); > + struct tegra_mphy_lane *lane =3D phy_get_drvdata(phy); > + > + if (WARN_ON(mphy->power_count =3D=3D 0)) > + return -EINVAL; > + > + reset_control_assert(lane->rst_rx); > + reset_control_assert(lane->rst_tx); > + > + if (--mphy->power_count =3D=3D 0) > + clk_bulk_disable_unprepare(mphy->num_clks, mphy->clks); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [Severity: Medium] Should mphy->rst_clk_ctl be asserted here before or after disabling the clocks? The driver intentionally deasserts mphy->rst_clk_ctl in tegra_mphy_rx_power_on() when power_count goes from 0 to 1, but omits the corresponding reset_control_assert() in this successful power-off path, which leaks the reset state across power cycles. > + > + return 0; > +} [ ... ] > +static const struct phy_ops tegra_mphy_tx_ops =3D { > + .configure =3D tegra_mphy_tx_configure, > + .calibrate =3D tegra_mphy_tx_calibrate, > +}; ^^ [Severity: High] Are .power_on and .power_off callbacks intentionally omitted for the TX PHY ops? Leaving the TX PHY exposed to configuration while in an unclocked state creates a fragile API contract that risks system crashes. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260909-tegra264-m= phy-v1-0-ce61a80dc065@nvidia.com?part=3D2