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 F2CC5CD6E4A for ; Thu, 4 Jun 2026 10:23:39 +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=i8PkCGpy+lqvjjp+Z/wh712RivPXVcmo0aGhZ8kLquI=; b=UzokLdQycR010e +V4fWcPrheqN7ByH3YWxQ5ve5qZjH2ZdbT2CrNLG7wl6eFQVTKNeZwLPvNjyAthGHvNRmBfzWDCMH uamQULZquRMstXtPYYZ91JkHznGZc52KzVo2Xr9MEfwp+p9PR/S1PczGvAOLp/iv22OxUAYD3Tlqx 0dqRT//fZ1wHvA/bcpSM1/aSvvm2VX+1jOpmgkd3qloyrr2dIEZ3y8CQI7YnpcgNDlVPmZeE9ub1z YmnRK0n5xy6ZJXZRdaTTYdMp71PZMUXtIK6zuxGJj3+o4bN3zWtyad2Ykg61/fzeaxJX6S4NfKQLq z8Em2/2nsD1jKjXESM9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wV5Eh-0000000GZP2-2VVt; Thu, 04 Jun 2026 10:23:39 +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 1wV5Eg-0000000GZOk-1Hhc for linux-phy@lists.infradead.org; Thu, 04 Jun 2026 10:23:38 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 7A15560219; Thu, 4 Jun 2026 10:23:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F2431F00893; Thu, 4 Jun 2026 10:23:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780568617; bh=Q1LsA3nSmSROFbmp+n5+LgDT4N55hEX8eHiUDKDjrRI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=TIWhDF4zRlBRWBhpahWdyWncCH0zZ9jAZLk4PpFNc+IQoZVNqc7AfldIyGFcKoiG0 3KLYA1MtHBJe+KCIl9JL99NaTX14zjfFWn9nXlhfzGMwGvDqMm57ohCaY6lJbLP4bv 5cJsn3PVVZBKGft8XdfMZrluqOIh+p8uubnJmftL+1Yp98JQ2Xy11Y9at3cQ55H6nT Gw/DRuPDMr61aIXl15oUo7zmxHGsUQe0oFC3uxGq0nmpa+R88FvfCi27lmBs7equyW wKfDm/QBB/5VvGhM1UatvJKBYp1WPJrnvMWEtIf5T8BvmAoZ7pSC242rXQWWu/Ms9N g7zCSqyJy4faA== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/2] phy: nuvoton: Add MA35D1 USB2 OTG PHY driver To: "Joey Lu" Cc: olteanv@gmail.com, robh@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org, linux-phy@lists.infradead.org, vkoul@kernel.org In-Reply-To: <20260604101220.1092822-3-a0987203069@gmail.com> References: <20260604101220.1092822-3-a0987203069@gmail.com> Date: Thu, 04 Jun 2026 10:23:35 +0000 Message-Id: <20260604102336.3F2431F00893@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIFRoZSBkcml2ZXIgaW1w bGVtZW50cyBhIGR1bW15IFVTQiByb2xlIHN3aXRjaCB0aGF0IGZhbHNlbHkgcmVwb3J0cyBzdWNj ZXNzIHdpdGhvdXQgbW9kaWZ5aW5nIGhhcmR3YXJlIHN0YXRlLgotIFtIaWdoXSBSYWNlIGNvbmRp dGlvbiBleHBvc2luZyB0aGUgUEhZIHByb3ZpZGVyIGJlZm9yZSBpbml0aWFsaXphdGlvbiBjb21w bGV0ZXMgbGVhZHMgdG8gYSBVc2UtQWZ0ZXItRnJlZS4KLSBbSGlnaF0gUEhZIGluaXRpYWxpemF0 aW9uIGZhaWxzIGR1ZSB0byBwb2xsaW5nIGNsb2NrIHN0YWJpbGl0eSBiaXRzIHdoaWxlIHRoZSBQ SFkgY2xvY2sgaXMgZGlzYWJsZWQuCi0gW01lZGl1bV0gSWdub3JpbmcgdGhlIHJldHVybiB2YWx1 ZSBvZiBgcmVnbWFwX3JlYWQoKWAgcmVzdWx0cyBpbiB0aGUgdXNlIG9mIHVuaW5pdGlhbGl6ZWQg c3RhY2sgbWVtb3J5LgotLQoKY29tbWl0IDllNTdjYzI1NzJiMzZhOGY3NWY3Y2E5YmMyNWExNGMz NjdjMThiMWEKQXV0aG9yOiBKb2V5IEx1IDxhMDk4NzIwMzA2OUBnbWFpbC5jb20+ClN1YmplY3Q6 IHBoeTogbnV2b3RvbjogQWRkIE1BMzVEMSBVU0IyIE9URyBQSFkgZHJpdmVyCgpBZGQgYSBQSFkg ZHJpdmVyIGZvciB0aGUgVVNCIDIuMCBQSFlzIGluIHRoZSBOdXZvdG9uIE1BMzVEMSBTb0MuIEl0 IAppbXBsZW1lbnRzIFBvd2VyLU9uIFJlc2V0IHNlcXVlbmNlLCBvcHRpb25hbCByZXNpc3RvciBj YWxpYnJhdGlvbiB0cmltLCAKYW5kIGEgVVNCIHJvbGUgc3dpdGNoLgoKPiBkaWZmIC0tZ2l0IGEv ZHJpdmVycy9waHkvbnV2b3Rvbi9waHktbWEzNWQxLW90Zy5jIGIvZHJpdmVycy9waHkvbnV2b3Rv bi9waHktbWEzNWQxLW90Zy5jCj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAw MDAwMDAwLi41M2JjNmRkZjc1NWU2Cj4gLS0tIC9kZXYvbnVsbAo+ICsrKyBiL2RyaXZlcnMvcGh5 L251dm90b24vcGh5LW1hMzVkMS1vdGcuYwpbIC4uLiBdCj4gK3N0YXRpYyBpbnQgbWEzNV9vdGdf cGh5X2luaXQoc3RydWN0IHBoeSAqcGh5KQo+ICt7Cj4gKwlzdHJ1Y3QgbWEzNV9vdGdfcGh5ICpw ID0gcGh5X2dldF9kcnZkYXRhKHBoeSk7Cj4gKwl1bnNpZ25lZCBpbnQgbiA9IHAtPnBoeV9pZHg7 Cj4gKwl1MzIgcmVhZHlfbWFzayA9IFVTQlBNSVNDUl9QSFlfSE9TVF9SRUFEWShuKTsKPiArCXVu c2lnbmVkIGludCB2YWw7Cj4gKwlpbnQgcmV0Owo+ICsKPiArCXJlZ21hcF9yZWFkKHAtPnN5c3Jl ZywgTUEzNV9TWVNfVVNCUE1JU0NSLCAmdmFsKTsKPiArCWlmICgodmFsICYgcmVhZHlfbWFzaykg PT0gcmVhZHlfbWFzaykKPiArCQlyZXR1cm4gMDsKCltTZXZlcml0eTogTWVkaXVtXQpEb2VzIGln bm9yaW5nIHRoZSByZXR1cm4gdmFsdWUgb2YgcmVnbWFwX3JlYWQoKSByaXNrIGV2YWx1YXRpbmcg dW5pbml0aWFsaXplZApzdGFjayBtZW1vcnkgaGVyZT8KCklmIHRoZSByZWFkIGZhaWxzLCB2YWwg cmVtYWlucyB1bmluaXRpYWxpemVkLCBhbmQgdXNpbmcgaXQgaW4gdGhlIGJpdHdpc2UKb3BlcmF0 aW9uIGNvdWxkIGNhdXNlIG5vbi1kZXRlcm1pbmlzdGljIGJlaGF2aW9yLCBzdWNoIGFzIGluY29y cmVjdGx5IHNraXBwaW5nCnRoZSBQSFkgcG93ZXItb24gcmVzZXQgc2VxdWVuY2UuCgo+ICsKPiAr CXJlZ21hcF91cGRhdGVfYml0cyhwLT5zeXNyZWcsIE1BMzVfU1lTX1VTQlBNSVNDUiwKPiArCQkJ ICAgVVNCUE1JU0NSX1BIWV9DVExfTUFTSyhuKSwKPiArCQkJICAgVVNCUE1JU0NSX1BIWV9QT1Io bikgfCBVU0JQTUlTQ1JfUEhZX1NVU1BFTkQobikpOwo+ICsJbXNsZWVwKDIwKTsKPiArCj4gKwly ZWdtYXBfdXBkYXRlX2JpdHMocC0+c3lzcmVnLCBNQTM1X1NZU19VU0JQTUlTQ1IsCj4gKwkJCSAg IFVTQlBNSVNDUl9QSFlfQ1RMX01BU0sobiksCj4gKwkJCSAgIFVTQlBNSVNDUl9QSFlfU1VTUEVO RChuKSk7Cj4gKwo+ICsJcmV0ID0gcmVnbWFwX3JlYWRfcG9sbF90aW1lb3V0KHAtPnN5c3JlZywg TUEzNV9TWVNfVVNCUE1JU0NSLCB2YWwsCj4gKwkJCQkgICAgICAgKHZhbCAmIHJlYWR5X21hc2sp ID09IHJlYWR5X21hc2ssCj4gKwkJCQkgICAgICAgMTAsIDEwMDApOwoKW1NldmVyaXR5OiBIaWdo XQpJcyBpdCBwb3NzaWJsZSBmb3IgdGhpcyBwb2xsaW5nIHRvIHRpbWUgb3V0IGJlY2F1c2UgdGhl IFBIWSBjbG9jayBpc24ndAplbmFibGVkIHlldD8KClRoZSBwb2xsaW5nIGV4cGVjdHMgdGhlIFBI WSBjbG9jayB0byBiZSBzdGFibGUsIGJ1dCB0aGUgUEhZIGNsb2NrIChwLT5jbGspIGlzCm9ubHkg ZW5hYmxlZCBsYXRlciBpbiBtYTM1X290Z19waHlfcG93ZXJfb24oKS4gQmVjYXVzZSB0aGUgTGlu dXggUEhZIGZyYW1ld29yawpndWFyYW50ZWVzIHRoYXQgcGh5X2luaXQoKSBpcyBjYWxsZWQgYmVm b3JlIHBoeV9wb3dlcl9vbigpLCB0aGUgUEhZIHJlZmVyZW5jZQpjbG9jayByZW1haW5zIGRpc2Fi bGVkIGR1cmluZyB0aGlzIHN0YWJpbGl0eSBwb2xsaW5nLgoKPiArCWlmIChyZXQpIHsKPiArCQlk ZXZfZXJyKHAtPmRldiwgIlVTQiBQSFkldSBjbG9jayBub3Qgc3RhYmxlIChVU0JQTUlTQ1I9MHgl MDh4KVxuIiwKPiArCQkJbiwgdmFsKTsKPiArCQlyZXR1cm4gcmV0Owo+ICsJfQo+ICsKPiArCXJl dHVybiAwOwo+ICt9ClsgLi4uIF0KPiArc3RhdGljIGVudW0gdXNiX3JvbGUgbWEzNV9vdGdfcmVh ZF9pZChzdHJ1Y3QgbWEzNV9vdGdfcGh5ICpwKQo+ICt7Cj4gKwl1bnNpZ25lZCBpbnQgdmFsOwo+ ICsKPiArCXJlZ21hcF9yZWFkKHAtPnN5c3JlZywgTUEzNV9TWVNfUFdST05PVFAsICZ2YWwpOwo+ ICsJcmV0dXJuICh2YWwgJiBQV1JPTk9UUF9VU0JQMElEKSA/IFVTQl9ST0xFX0hPU1QgOiBVU0Jf Uk9MRV9ERVZJQ0U7Cj4gK30KCltTZXZlcml0eTogTWVkaXVtXQpDYW4gdGhpcyByZXR1cm4gYW4g YXJiaXRyYXJ5IFVTQiByb2xlIGlmIHJlZ21hcF9yZWFkKCkgZmFpbHM/CgpJZiB0aGUgcmVhZCBm YWlscywgdGhlIHVuaW5pdGlhbGl6ZWQgc3RhY2sgdmFyaWFibGUgdmFsIGlzIGV2YWx1YXRlZCwg bGVhZGluZwp0byBhIHBvdGVudGlhbGx5IGluY29ycmVjdCByb2xlIGJlaW5nIHJlcG9ydGVkLgoK PiArCj4gK3N0YXRpYyBpbnQgbWEzNV9vdGdfcm9sZV9zd19zZXQoc3RydWN0IHVzYl9yb2xlX3N3 aXRjaCAqc3csCj4gKwkJCQllbnVtIHVzYl9yb2xlIHJvbGUpCj4gK3sKPiArCXN0cnVjdCBtYTM1 X290Z19waHkgKnAgPSB1c2Jfcm9sZV9zd2l0Y2hfZ2V0X2RydmRhdGEoc3cpOwo+ICsKPiArCXAt PmN1cl9yb2xlID0gcm9sZTsKPiArCj4gKwlyZXR1cm4gMDsKPiArfQoKW1NldmVyaXR5OiBIaWdo XQpTaW5jZSB0aGUgaGFyZHdhcmUgbXV4IGlzIGVudGlyZWx5IGF1dG9tYXRpYyBiYXNlZCBvbiB0 aGUgcGh5c2ljYWwgVVNCIElEIHBpbiwKc2hvdWxkIHRoaXMgLnNldCBjYWxsYmFjayByZXR1cm4g YW4gZXJyb3IgaW5zdGVhZCBvZiBmYWxzZWx5IHJlcG9ydGluZyBzdWNjZXNzPwoKV3JpdGluZyB0 byBwLT5jdXJfcm9sZSBkb2Vzbid0IGNvbmZpZ3VyZSBhbnkgaGFyZHdhcmUgcmVnaXN0ZXIsIGFu ZCB0aGUgLmdldApjYWxsYmFjayBjb3JyZWN0bHkgcXVlcmllcyB0aGUgaGFyZHdhcmUgZGlyZWN0 bHkuIFJldHVybmluZyAwIGhlcmUgZGVmZWF0cyB0aGUKc3Vic3lzdGVtJ3MgLUVPUE5PVFNVUFAg cmVqZWN0aW9uIGZvciByZWFkLW9ubHkgc3dpdGNoZXMsIGFzIHdyaXRlcyBmcm9tCnVzZXJzcGFj ZSB3aWxsIGFwcGVhciB0byBzdWNjZWVkIGJ1dCB3aWxsIG5vdCBjaGFuZ2UgdGhlIGFjdHVhbCBo YXJkd2FyZSBzdGF0ZS4KCj4gKwo+ICtzdGF0aWMgZW51bSB1c2Jfcm9sZSBtYTM1X290Z19yb2xl X3N3X2dldChzdHJ1Y3QgdXNiX3JvbGVfc3dpdGNoICpzdykKPiArewo+ICsJc3RydWN0IG1hMzVf b3RnX3BoeSAqcCA9IHVzYl9yb2xlX3N3aXRjaF9nZXRfZHJ2ZGF0YShzdyk7Cj4gKwo+ICsJcmV0 dXJuIG1hMzVfb3RnX3JlYWRfaWQocCk7Cj4gK30KPiArCj4gK3N0YXRpYyBpbnQgbWEzNV9vdGdf cm9sZV9zd2l0Y2hfaW5pdChzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2LAo+ICsJCQkJICAg ICBzdHJ1Y3QgbWEzNV9vdGdfcGh5ICpwKQo+ICt7Cj4gKwlzdHJ1Y3QgdXNiX3JvbGVfc3dpdGNo X2Rlc2Mgc3dfZGVzYyA9IHsgfTsKPiArCj4gKwlwLT5jdXJfcm9sZSA9IG1hMzVfb3RnX3JlYWRf aWQocCk7Cj4gKwo+ICsJc3dfZGVzYy5zZXQgPSBtYTM1X290Z19yb2xlX3N3X3NldDsKPiArCXN3 X2Rlc2MuZ2V0ID0gbWEzNV9vdGdfcm9sZV9zd19nZXQ7Cj4gKwlzd19kZXNjLmFsbG93X3VzZXJz cGFjZV9jb250cm9sID0gdHJ1ZTsKCltTZXZlcml0eTogSGlnaF0KSXMgaXQgYXBwcm9wcmlhdGUg dG8gc2V0IGFsbG93X3VzZXJzcGFjZV9jb250cm9sIHRvIHRydWUgZ2l2ZW4gdGhhdCB0aGUgc3dp dGNoCnN0cmljdGx5IHJlZmxlY3RzIGFuIGF1dG9tYXRpYyBoYXJkd2FyZSBzdGF0ZT8KCj4gKwlz d19kZXNjLmRyaXZlcl9kYXRhID0gcDsKPiArCXN3X2Rlc2MuZndub2RlID0gZGV2X2Z3bm9kZSgm cGRldi0+ZGV2KTsKWyAuLi4gXQo+ICtzdGF0aWMgaW50IG1hMzVfb3RnX3BoeV9wcm9iZShzdHJ1 Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQo+ICt7ClsgLi4uIF0KPiArCXByb3ZpZGVyID0gZGV2 bV9vZl9waHlfcHJvdmlkZXJfcmVnaXN0ZXIoJnBkZXYtPmRldiwKPiArCQkJCQkJIG9mX3BoeV9z aW1wbGVfeGxhdGUpOwo+ICsJaWYgKElTX0VSUihwcm92aWRlcikpCj4gKwkJcmV0dXJuIGRldl9l cnJfcHJvYmUoJnBkZXYtPmRldiwgUFRSX0VSUihwcm92aWRlciksCj4gKwkJCQkgICAgICJGYWls ZWQgdG8gcmVnaXN0ZXIgUEhZIHByb3ZpZGVyXG4iKTsKPiArCj4gKwlpZiAocC0+cGh5X2lkeCA9 PSAwKSB7Cj4gKwkJcmV0ID0gbWEzNV9vdGdfcm9sZV9zd2l0Y2hfaW5pdChwZGV2LCBwKTsKPiAr CQlpZiAocmV0KQo+ICsJCQlyZXR1cm4gcmV0Owo+ICsJfQo+ICsKPiArCXJldHVybiAwOwo+ICt9 CgpbU2V2ZXJpdHk6IEhpZ2hdCkNvdWxkIHJlZ2lzdGVyaW5nIHRoZSBQSFkgcHJvdmlkZXIgYmVm b3JlIHJvbGUgc3dpdGNoIGluaXRpYWxpemF0aW9uIHJpc2sgYQp1c2UtYWZ0ZXItZnJlZT8KCklm IGRldm1fb2ZfcGh5X3Byb3ZpZGVyX3JlZ2lzdGVyKCkgZXhwb3NlcyB0aGUgUEhZIGdsb2JhbGx5 LCBhIGNvbnN1bWVyIG9uCmFub3RoZXIgQ1BVIGNvdWxkIGxvb2sgdXAgdGhlIFBIWSBhbmQgY2Fs bCBwaHlfaW5pdCgpLCBhY3F1aXJpbmcgYSByZWZlcmVuY2UuCgpJZiBtYTM1X290Z19yb2xlX3N3 aXRjaF9pbml0KCkgc3Vic2VxdWVudGx5IGZhaWxzLCBwcm9iZSByZXR1cm5zIGFuIGVycm9yLAp0 cmlnZ2VyaW5nIHRoZSBkZXZtIGNsZWFudXAgd2hpY2ggZnJlZXMgdGhlIHN0cnVjdCBtYTM1X290 Z19waHkgKnAgbWVtb3J5LgpCZWNhdXNlIHRoZSBjb25zdW1lciBhbHJlYWR5IGhvbGRzIGEgdmFs aWQgcmVmZXJlbmNlLCBzdWJzZXF1ZW50IGNhbGxzIHRvClBIWSBBUElzIHdpbGwgZGVyZWZlcmVu Y2UgdGhlIGZyZWVkIHBvaW50ZXIuCgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9z YXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNjA0MTAxMjIwLjEwOTI4MjItMS1hMDk4NzIwMzA2 OUBnbWFpbC5jb20/cGFydD0yCgotLSAKbGludXgtcGh5IG1haWxpbmcgbGlzdApsaW51eC1waHlA bGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwczovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW51eC1waHkK 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 94FA42F7F14 for ; Thu, 4 Jun 2026 10:23:37 +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=1780568618; cv=none; b=Sp/R2XY2tQUCVnphUBYKf8HCEezBHzGR1FAMt9Qhu2/gmjmQlrbdZ1cWZWyLKQwB9uOjFsux41e14/5tMwB/kwdVJSf7he6fkXAQjUivC9bRWxiwy1csK/EAWEQqbbsyzCljp20P9sjFQp/JSrmWGgeLfsBFCsZD3nXO1BnFCR8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780568618; c=relaxed/simple; bh=pMrU86ypFhkDCBxR/4xBHCI/uT80UMz9Cxl43WYUtCA=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=DMh/61WKlxfLk71W8Lu1zs46PY0O9KMMpQ+CvNLbH63tusbryRMIxLaFvZ5z5SrO5UWMmN8DLUg6j9uyXXKHHhyJKTo2nsQ2Djh2KIkuWtZ1xHI0AUdkhZIzJc2d+U6zFEc/4Y43TcEhCuoVJiw3C3SzOJewuwjChvwmaOR5HPg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TIWhDF4z; 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="TIWhDF4z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F2431F00893; Thu, 4 Jun 2026 10:23:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780568617; bh=Q1LsA3nSmSROFbmp+n5+LgDT4N55hEX8eHiUDKDjrRI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=TIWhDF4zRlBRWBhpahWdyWncCH0zZ9jAZLk4PpFNc+IQoZVNqc7AfldIyGFcKoiG0 3KLYA1MtHBJe+KCIl9JL99NaTX14zjfFWn9nXlhfzGMwGvDqMm57ohCaY6lJbLP4bv 5cJsn3PVVZBKGft8XdfMZrluqOIh+p8uubnJmftL+1Yp98JQ2Xy11Y9at3cQ55H6nT Gw/DRuPDMr61aIXl15oUo7zmxHGsUQe0oFC3uxGq0nmpa+R88FvfCi27lmBs7equyW wKfDm/QBB/5VvGhM1UatvJKBYp1WPJrnvMWEtIf5T8BvmAoZ7pSC242rXQWWu/Ms9N g7zCSqyJy4faA== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/2] phy: nuvoton: Add MA35D1 USB2 OTG PHY driver Reply-To: sashiko-reviews@lists.linux.dev To: "Joey Lu" Cc: olteanv@gmail.com, robh@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org, conor+dt@kernel.org, linux-phy@lists.infradead.org, vkoul@kernel.org In-Reply-To: <20260604101220.1092822-3-a0987203069@gmail.com> References: <20260604101220.1092822-3-a0987203069@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 04 Jun 2026 10:23:35 +0000 Message-Id: <20260604102336.3F2431F00893@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] The driver implements a dummy USB role switch that falsely reports= success without modifying hardware state. - [High] Race condition exposing the PHY provider before initialization com= pletes leads to a Use-After-Free. - [High] PHY initialization fails due to polling clock stability bits while= the PHY clock is disabled. - [Medium] Ignoring the return value of `regmap_read()` results in the use = of uninitialized stack memory. -- commit 9e57cc2572b36a8f75f7ca9bc25a14c367c18b1a Author: Joey Lu Subject: phy: nuvoton: Add MA35D1 USB2 OTG PHY driver Add a PHY driver for the USB 2.0 PHYs in the Nuvoton MA35D1 SoC. It=20 implements Power-On Reset sequence, optional resistor calibration trim,=20 and a USB role switch. > diff --git a/drivers/phy/nuvoton/phy-ma35d1-otg.c b/drivers/phy/nuvoton/p= hy-ma35d1-otg.c > new file mode 100644 > index 0000000000000..53bc6ddf755e6 > --- /dev/null > +++ b/drivers/phy/nuvoton/phy-ma35d1-otg.c [ ... ] > +static int ma35_otg_phy_init(struct phy *phy) > +{ > + struct ma35_otg_phy *p =3D phy_get_drvdata(phy); > + unsigned int n =3D p->phy_idx; > + u32 ready_mask =3D USBPMISCR_PHY_HOST_READY(n); > + unsigned int val; > + int ret; > + > + regmap_read(p->sysreg, MA35_SYS_USBPMISCR, &val); > + if ((val & ready_mask) =3D=3D ready_mask) > + return 0; [Severity: Medium] Does ignoring the return value of regmap_read() risk evaluating uninitializ= ed stack memory here? If the read fails, val remains uninitialized, and using it in the bitwise operation could cause non-deterministic behavior, such as incorrectly skipp= ing the PHY power-on reset sequence. > + > + regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR, > + USBPMISCR_PHY_CTL_MASK(n), > + USBPMISCR_PHY_POR(n) | USBPMISCR_PHY_SUSPEND(n)); > + msleep(20); > + > + regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR, > + USBPMISCR_PHY_CTL_MASK(n), > + USBPMISCR_PHY_SUSPEND(n)); > + > + ret =3D regmap_read_poll_timeout(p->sysreg, MA35_SYS_USBPMISCR, val, > + (val & ready_mask) =3D=3D ready_mask, > + 10, 1000); [Severity: High] Is it possible for this polling to time out because the PHY clock isn't enabled yet? The polling expects the PHY clock to be stable, but the PHY clock (p->clk) = is only enabled later in ma35_otg_phy_power_on(). Because the Linux PHY framew= ork guarantees that phy_init() is called before phy_power_on(), the PHY referen= ce clock remains disabled during this stability polling. > + if (ret) { > + dev_err(p->dev, "USB PHY%u clock not stable (USBPMISCR=3D0x%08x)\n", > + n, val); > + return ret; > + } > + > + return 0; > +} [ ... ] > +static enum usb_role ma35_otg_read_id(struct ma35_otg_phy *p) > +{ > + unsigned int val; > + > + regmap_read(p->sysreg, MA35_SYS_PWRONOTP, &val); > + return (val & PWRONOTP_USBP0ID) ? USB_ROLE_HOST : USB_ROLE_DEVICE; > +} [Severity: Medium] Can this return an arbitrary USB role if regmap_read() fails? If the read fails, the uninitialized stack variable val is evaluated, leadi= ng to a potentially incorrect role being reported. > + > +static int ma35_otg_role_sw_set(struct usb_role_switch *sw, > + enum usb_role role) > +{ > + struct ma35_otg_phy *p =3D usb_role_switch_get_drvdata(sw); > + > + p->cur_role =3D role; > + > + return 0; > +} [Severity: High] Since the hardware mux is entirely automatic based on the physical USB ID p= in, should this .set callback return an error instead of falsely reporting succ= ess? Writing to p->cur_role doesn't configure any hardware register, and the .get callback correctly queries the hardware directly. Returning 0 here defeats = the subsystem's -EOPNOTSUPP rejection for read-only switches, as writes from userspace will appear to succeed but will not change the actual hardware st= ate. > + > +static enum usb_role ma35_otg_role_sw_get(struct usb_role_switch *sw) > +{ > + struct ma35_otg_phy *p =3D usb_role_switch_get_drvdata(sw); > + > + return ma35_otg_read_id(p); > +} > + > +static int ma35_otg_role_switch_init(struct platform_device *pdev, > + struct ma35_otg_phy *p) > +{ > + struct usb_role_switch_desc sw_desc =3D { }; > + > + p->cur_role =3D ma35_otg_read_id(p); > + > + sw_desc.set =3D ma35_otg_role_sw_set; > + sw_desc.get =3D ma35_otg_role_sw_get; > + sw_desc.allow_userspace_control =3D true; [Severity: High] Is it appropriate to set allow_userspace_control to true given that the swi= tch strictly reflects an automatic hardware state? > + sw_desc.driver_data =3D p; > + sw_desc.fwnode =3D dev_fwnode(&pdev->dev); [ ... ] > +static int ma35_otg_phy_probe(struct platform_device *pdev) > +{ [ ... ] > + provider =3D devm_of_phy_provider_register(&pdev->dev, > + of_phy_simple_xlate); > + if (IS_ERR(provider)) > + return dev_err_probe(&pdev->dev, PTR_ERR(provider), > + "Failed to register PHY provider\n"); > + > + if (p->phy_idx =3D=3D 0) { > + ret =3D ma35_otg_role_switch_init(pdev, p); > + if (ret) > + return ret; > + } > + > + return 0; > +} [Severity: High] Could registering the PHY provider before role switch initialization risk a use-after-free? If devm_of_phy_provider_register() exposes the PHY globally, a consumer on another CPU could look up the PHY and call phy_init(), acquiring a referenc= e. If ma35_otg_role_switch_init() subsequently fails, probe returns an error, triggering the devm cleanup which frees the struct ma35_otg_phy *p memory. Because the consumer already holds a valid reference, subsequent calls to PHY APIs will dereference the freed pointer. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260604101220.1092= 822-1-a0987203069@gmail.com?part=3D2