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 C0702CA6007 for ; Thu, 8 Oct 2026 06:26:30 +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:Date:References: In-Reply-To:Cc:To:Subject:From:Message-ID:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p0fw8T2ezy9pX3pkVAOACVkaVEo5FbH7IKA+nSRnsto=; b=iyx69j/3BAwt83 I9PG8v4SRFeSNF1i3JhIWoElcoU2wY6s0oMD3Us4Kvj/sXPeEu1280UQGj+pdrMuxDVNDr4xQX+Xk aEfFswTQ34hvCrKLxNg4Rvf/8XmUQCcHy1IER4TJf5NYGxcL5ADU2GFD5Dh+sXDlS9Ye7g5anpuLH zABe3RrYTQO7Oa/h3VPbO5ZqorPbCeFVaDj9RBQhsPv8QFVH/cO/YohY76dSWBnDfadaaWuIpiQ8I s7VSJ3hpB+s7+D95/6prlQzAw4xuPkzWaA+xxkhevoqeSHKFSjHsVkYMp+wLs1CEjB6MGwX4ItKQV r+iWAFxqjyu8sIDld3HQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEhaI-00000003dIC-1Ol1; Thu, 08 Oct 2026 06:26:30 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEhaG-00000003dHr-1zBY for linux-phy@lists.infradead.org; Thu, 08 Oct 2026 06:26:28 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 72410601DB; Thu, 8 Oct 2026 06:26:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA7C51F000FF; Thu, 8 Oct 2026 06:26:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791440787; bh=i3qB9gopBGLMCT1FLzuKhYQYgBZIVEV8TkWEDxSOQSo=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=g09x8D+MghJESuDVvqH2XQfUhhKRrY/1By/x27fOF/Oj0M/nNPtGKK3ntuGRdQR+l 5YYUE4aeoYELjL5RxE0ttII+M5h1MGUVsL6eDOYLjivRxnxFrMNGn+PmqT+wHXNWAI c0u983R1X6pjgzPlotx/5scAtzSEZAthTDGRh6gaIT+5myYmAhtMYLGl6tbubpMy0W tgReuizSRcRAXczOV7l/ocuLnQerV0W1wAnXFm4kj6GMDixXxTj5VdXBQ4BLTQ7gQh JV1+SYsLdYf036NUvRMKulQ8V/veQZyS0j6bg+o1uTXYjXKsmaRpFOww3npPZsTJ6f CfS3VXyd9CkRw== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 4/4] phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support To: "Joey Lu" Cc: devicetree@vger.kernel.org, neil.armstrong@linaro.org, linux-phy@lists.infradead.org, olteanv@gmail.com, vkoul@kernel.org, robh@kernel.org, conor+dt@kernel.org In-Reply-To: <20261008060629.2736806-5-a0987203069@gmail.com> References: <20261008060629.2736806-1-a0987203069@gmail.com> <20261008060629.2736806-5-a0987203069@gmail.com> Date: Thu, 08 Oct 2026 06:26:26 +0000 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 NSBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIHBoeTogS2NvbmZpZyBt aXNzaW5nIFVTQl9ST0xFX1NXSVRDSCBkZXBlbmRlbmN5IGNhdXNlcyBidWlsdC1pbiBsaW5rIGZh aWx1cmUKLSBbSGlnaF0gcGh5OiBEVCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHJlZ3Jlc3Npb24g Zm9yIG92ZXItY3VycmVudCBwb2xhcml0eQotIFtNZWRpdW1dIHBoeTogaWdub3JlZCByZWdtYXBf cmVhZCByZXR1cm4gdmFsdWVzIGNhdXNlIHVuaW5pdGlhbGl6ZWQgdmFyaWFibGUgdXNhZ2UgYW5k IGluZm8gbGVhawotIFtNZWRpdW1dIHBoeTogcmVncmVzc2lvbiBpbiBQSFkgcmVzZXQgZmFsbGJh Y2sgd2hlbiBjbG9jayBwb2xsaW5nIGZhaWxzCi0gW01lZGl1bV0gUE0vY2xvY2s6IFBIWSBwZXJt YW5lbnRseSBob2xkcyBIVVNCSDBfR0FURSBwcmV2ZW50aW5nIFVTQiBzdXNwZW5kCi0tCgpjb21t aXQgZGNlNTNkZjVjZmU0ZGNmYWM4YWYxNmY4YjI5NzQzYTNmNGUxNDdlMApBdXRob3I6IEpvZXkg THUgPGEwOTg3MjAzMDY5QGdtYWlsLmNvbT4KCiAgICBwaHk6IG51dm90b246IHBoeS1tYTM1ZDEt dXNiMjogZXh0ZW5kIHRvIGR1YWwtcG9ydCB3aXRoIE9URyBzdXBwb3J0CiAgICAKICAgIFBIWTAg YW5kIFBIWTEgdXNlIHRoZSBzYW1lIHBvd2VyLW9uL3Jlc2V0IHNlcXVlbmNlIGluIFVTQlBNSVND Uiwgd2l0aAogICAgUEhZMSBjb250cm9sIGJpdHMgc2hpZnRlZCAxNiBwb3NpdGlvbnMgcmVsYXRp dmUgdG8gUEhZMC4gIEEgc2VwYXJhdGUKICAgIGRyaXZlciBmb3IgUEhZMSB3b3VsZCBkdXBsaWNh dGUgdGhpcyBsb2dpYywgc28gdGhlIGV4aXN0aW5nIGRyaXZlciBpcwogICAgZXh0ZW5kZWQgdG8g bWFuYWdlIGJvdGggcG9ydHMuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3BoeS9udXZvdG9uL3Bo eS1tYTM1ZDEtdXNiMi5jIGIvZHJpdmVycy9waHkvbnV2b3Rvbi9waHktbWEzNWQxLXVzYjIuYwo+ IGluZGV4IDBiOTk3NmZiMTVjMTcuLjI1YmQwYTdhMTMxNGIgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVy cy9waHkvbnV2b3Rvbi9waHktbWEzNWQxLXVzYjIuYwo+ICsrKyBiL2RyaXZlcnMvcGh5L251dm90 b24vcGh5LW1hMzVkMS11c2IyLmMKWyAuLi4gXQo+IC1zdGF0aWMgaW50IG1hMzVfdXNiX3BoeV9w b3dlcl9vbihzdHJ1Y3QgcGh5ICpwaHkpCj4gK3N0YXRpYyBpbnQgbWEzNV91c2JfcGh5X2luaXQo c3RydWN0IHBoeSAqcGh5KQo+ICB7Cj4gLQlzdHJ1Y3QgbWEzNV91c2JfcGh5ICpwX3BoeSA9IHBo eV9nZXRfZHJ2ZGF0YShwaHkpOwo+ICsJc3RydWN0IG1hMzVfcGh5X3BvcnQgKnBvcnQgPSBwaHlf Z2V0X2RydmRhdGEocGh5KTsKPiArCXN0cnVjdCBtYTM1X3VzYl9waHkgKnAgPSBjb250YWluZXJf b2YocG9ydCAtIHBvcnQtPmlkeCwKPiArCQkJCQkgICAgICBzdHJ1Y3QgbWEzNV91c2JfcGh5LCBw b3J0WzBdKTsKPiArCXVuc2lnbmVkIGludCBuID0gcG9ydC0+aWR4Owo+ICAJdW5zaWduZWQgaW50 IHZhbDsKPiAgCWludCByZXQ7Cj4gIAo+IC0JcmV0ID0gY2xrX3ByZXBhcmVfZW5hYmxlKHBfcGh5 LT5jbGspOwo+IC0JaWYgKHJldCA8IDApIHsKPiAtCQlkZXZfZXJyKHBfcGh5LT5kZXYsICJGYWls ZWQgdG8gZW5hYmxlIFBIWSBjbG9jazogJWRcbiIsIHJldCk7Cj4gLQkJcmV0dXJuIHJldDsKPiAr CXJlZ21hcF9yZWFkKHAtPnN5c3JlZywgTUEzNV9TWVNfVVNCUE1JU0NSLCAmdmFsKTsKPiArCj4g KwlpZiAoISh2YWwgJiBVU0JQTUlTQ1JfUEhZX1NVU1BFTkQobikpKSB7CgpbU2V2ZXJpdHk6IE1l ZGl1bV0KSXMgdGhpcyBjb2RlIGJyYW5jaGluZyBvbiB1bmluaXRpYWxpemVkIHN0YWNrIG1lbW9y eT8KCklmIHJlZ21hcF9yZWFkKCkgZmFpbHMsIHRoZSByZXR1cm4gdmFsdWUgaXMgaWdub3JlZCBh bmQgdmFsIGlzIGxlZnQKdW5pbml0aWFsaXplZCwgbGVhZGluZyB0byBub24tZGV0ZXJtaW5pc3Rp YyBQSFkgc3RhdGUgaGFuZGxpbmcuCgpbU2V2ZXJpdHk6IE1lZGl1bV0KQ291bGQgdGhpcyBzdHJp Y3QgY29uZGl0aW9uIHJlbW92ZSB0aGUgZmFsbGJhY2sgcmVzZXQgc2VxdWVuY2U/CgpUaGUgb3Jp Z2luYWwgZHJpdmVyIHdvdWxkIHJlc2V0IHRoZSBQSFkgaWYgdGhlIGNsb2NrIGZhaWxlZCB0byBz dGFiaWxpemUgZHVyaW5nCnBvbGxpbmcuIEJ5IGVuY2Fwc3VsYXRpbmcgdGhlIHJlc2V0IHN0cmlj dGx5IGluc2lkZSB0aGlzIGJsb2NrLCBpdCBza2lwcyB0aGUKcmVzZXQgZW50aXJlbHkgaWYgdGhl IFBIWSBpcyBhbHJlYWR5IHJ1bm5pbmcuCgpJZiB0aGUgc3Vic2VxdWVudCBjbG9jayBwb2xsaW5n IHRpbWVzIG91dCwgdGhlIGRyaXZlciBpbW1lZGlhdGVseSByZXR1cm5zIGFuCmVycm9yLiBDYW4g dGhpcyBjYXVzZSBhIHJlZ3Jlc3Npb24gd2hlcmUgdGhlIFBIWSBmYWlscyBpbml0aWFsaXphdGlv biBwZXJtYW5lbnRseQppZiBpdCB3YXMgbGVmdCBydW5uaW5nIGJ1dCB1bnN0YWJsZSBieSB0aGUg Ym9vdGxvYWRlciBvciBhIHByaW9yIGtleGVjPwoKPiArCQlyZWdtYXBfdXBkYXRlX2JpdHMocC0+ c3lzcmVnLCBNQTM1X1NZU19VU0JQTUlTQ1IsCj4gKwkJCQkgICBVU0JQTUlTQ1JfUEhZX0NUTF9N QVNLKG4pLAo+ICsJCQkJICAgVVNCUE1JU0NSX1BIWV9QT1IobikgfCBVU0JQTUlTQ1JfUEhZX1NV U1BFTkQobikpOwo+ICsJCXVkZWxheSgyMCk7Cj4gKwo+ICsJCXJlZ21hcF91cGRhdGVfYml0cyhw LT5zeXNyZWcsIE1BMzVfU1lTX1VTQlBNSVNDUiwKPiArCQkJCSAgIFVTQlBNSVNDUl9QSFlfQ1RM X01BU0sobiksCj4gKwkJCQkgICBVU0JQTUlTQ1JfUEhZX1NVU1BFTkQobikpOwo+ICAJfQpbIC4u LiBdCj4gLXN0YXRpYyBpbnQgbWEzNV91c2JfcGh5X3Bvd2VyX29mZihzdHJ1Y3QgcGh5ICpwaHkp Cj4gLXsKPiAtCXN0cnVjdCBtYTM1X3VzYl9waHkgKnBfcGh5ID0gcGh5X2dldF9kcnZkYXRhKHBo eSk7Cj4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgcGh5X29wcyBtYTM1X3VzYl9waHlfb3BzID0gewo+ ICsJLmluaXQJCT0gbWEzNV91c2JfcGh5X2luaXQsCj4gKwkub3duZXIJCT0gVEhJU19NT0RVTEUs Cj4gK307CgpbU2V2ZXJpdHk6IE1lZGl1bV0KV2lsbCB0aGUgcmVtb3ZhbCBvZiBkeW5hbWljIGNs b2NrIHRvZ2dsaW5nIGluIC5wb3dlcl9vbiBhbmQgLnBvd2VyX29mZiBjYXVzZQphIHBvd2VyIHJl Z3Jlc3Npb24/CgpTaW5jZSB0aGUgY2xvY2sgaXMgbm93IGFjcXVpcmVkIHBlcm1hbmVudGx5IHZp YSBkZXZtX2Nsa19nZXRfZW5hYmxlZCgpIGR1cmluZwpwcm9iZSwgdGhlIFVTQiBob3N0IGNsb2Nr IGdhdGUgKEhVU0JIMF9HQVRFKSByZW1haW5zIG9wZW4gcGVybWFuZW50bHksCnByZXZlbnRpbmcg aXQgZnJvbSBjbG9zaW5nIGFuZCBjb25zdW1pbmcgdW5uZWNlc3NhcnkgcG93ZXIgd2hlbiB0aGUg VVNCIGhvc3QKY29udHJvbGxlciAoRUhDSTAvT0hDSTApIHN1c3BlbmRzLgoKPiArCj4gK3N0YXRp YyBpbnQgbWEzNV9yb2xlX3N3X3NldChzdHJ1Y3QgdXNiX3JvbGVfc3dpdGNoICpzdywgZW51bSB1 c2Jfcm9sZSByb2xlKQo+ICt7Cj4gKwlyZXR1cm4gLUVPUE5PVFNVUFA7Cj4gK30KPiArCj4gK3N0 YXRpYyBlbnVtIHVzYl9yb2xlIG1hMzVfcm9sZV9zd19nZXQoc3RydWN0IHVzYl9yb2xlX3N3aXRj aCAqc3cpCj4gK3sKPiArCXN0cnVjdCBtYTM1X3VzYl9waHkgKnAgPSB1c2Jfcm9sZV9zd2l0Y2hf Z2V0X2RydmRhdGEoc3cpOwo+ICsJdTMyIHZhbDsKPiArCj4gKwlyZWdtYXBfcmVhZChwLT5zeXNy ZWcsIE1BMzVfU1lTX1BXUk9OT1RQLCAmdmFsKTsKPiArCj4gKwlyZXR1cm4gKHZhbCAmIFBXUk9O T1RQX1VTQlAwSUQpID8gVVNCX1JPTEVfSE9TVCA6IFVTQl9ST0xFX0RFVklDRTsKPiArfQoKW1Nl dmVyaXR5OiBNZWRpdW1dCkNhbiB0aGlzIGxlYWsgdW5pbml0aWFsaXplZCBzdGFjayBtZW1vcnkg dG8gdXNlcnNwYWNlPwoKSWYgcmVnbWFwX3JlYWQoKSBmYWlscywgdGhlIHJldHVybiB2YWx1ZSBp cyBpZ25vcmVkIGFuZCB2YWwgcmVtYWlucwp1bmluaXRpYWxpemVkLiBUaGlzIHVuaW5pdGlhbGl6 ZWQgZGF0YSBkZXRlcm1pbmVzIHRoZSByZXR1cm5lZCBVU0Igcm9sZSwKaW5hZHZlcnRlbnRseSBs ZWFraW5nIDEgYml0IG9mIGtlcm5lbCBzdGFjayBzdGF0ZSB0byB1c2Vyc3BhY2UgdmlhIHRoZSBz eXNmcwpyb2xlIGF0dHJpYnV0ZS4KCj4gKwo+ICtzdGF0aWMgaW50IG1hMzVfcm9sZV9zd2l0Y2hf aW5pdChzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2LAo+ICsJCQkJIHN0cnVjdCBtYTM1X3Vz Yl9waHkgKnApCj4gK3sKPiArCXN0cnVjdCB1c2Jfcm9sZV9zd2l0Y2hfZGVzYyBzd19kZXNjID0g ezB9Owo+ICsKPiArCXN3X2Rlc2Muc2V0ID0gbWEzNV9yb2xlX3N3X3NldDsKPiArCXN3X2Rlc2Mu Z2V0ID0gbWEzNV9yb2xlX3N3X2dldDsKPiArCXN3X2Rlc2MuYWxsb3dfdXNlcnNwYWNlX2NvbnRy b2wgPSB0cnVlOwo+ICsJc3dfZGVzYy5kcml2ZXJfZGF0YSA9IHA7Cj4gKwlzd19kZXNjLmZ3bm9k ZSA9IGRldl9md25vZGUoJnBkZXYtPmRldik7Cj4gKwo+ICsJcC0+cm9sZV9zdyA9IHVzYl9yb2xl X3N3aXRjaF9yZWdpc3RlcigmcGRldi0+ZGV2LCAmc3dfZGVzYyk7CgpbU2V2ZXJpdHk6IEhpZ2hd CldvdWxkIHRoaXMgaW50cm9kdWNlIGEgYnVpbHQtaW4gbGluayBmYWlsdXJlIGlmIHRoZSBkcml2 ZXIgaXMgYnVpbHQtaW4KKENPTkZJR19QSFlfTUEzNV9VU0I9eSkgYW5kIHRoZSByb2xlIHN3aXRj aCBmcmFtZXdvcmsgaXMgbW9kdWxhcgooQ09ORklHX1VTQl9ST0xFX1NXSVRDSD1tKT8KCkluIHRo aXMgY29uZmlndXJhdGlvbiwgSVNfRU5BQkxFRChDT05GSUdfVVNCX1JPTEVfU1dJVENIKSBldmFs dWF0ZXMgdG8gdHJ1ZSwKc28gaW5jbHVkZS9saW51eC91c2Ivcm9sZS5oIGRlY2xhcmVzIHRoZSBl eHRlcm5hbCBmdW5jdGlvbnMgaW5zdGVhZCBvZiBwcm92aWRpbmcKaW5saW5lIHN0dWJzLCBjYXVz aW5nIGFuIHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gdXNiX3JvbGVfc3dpdGNoX3JlZ2lzdGVyLgoK U2hvdWxkIGRyaXZlcnMvcGh5L251dm90b24vS2NvbmZpZyBiZSB1cGRhdGVkIHRvIGluY2x1ZGUK ZGVwZW5kcyBvbiBVU0JfUk9MRV9TV0lUQ0ggfHwgIVVTQl9ST0xFX1NXSVRDSCBmb3IgUEhZX01B MzVfVVNCIHRvIHByZXZlbnQKdGhpcyBpbnZhbGlkIEtjb25maWcgY29tYmluYXRpb24/Cgo+ICsJ aWYgKElTX0VSUihwLT5yb2xlX3N3KSkgewpbIC4uLiBdCj4gIHN0YXRpYyBpbnQgbWEzNV91c2Jf cGh5X3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpCj4gIHsKPiAgCXN0cnVjdCBw aHlfcHJvdmlkZXIgKnByb3ZpZGVyOwo+IC0Jc3RydWN0IG1hMzVfdXNiX3BoeSAqcF9waHk7Cj4g LQlzdHJ1Y3QgcGh5ICpwaHk7Cj4gKwlzdHJ1Y3QgbWEzNV91c2JfcGh5ICpwOwo+ICsJc3RydWN0 IGNsayAqY2xrOwo+ICsJaW50IG4sIHJldDsKPiArCXUzMiBjb2RlOwpbIC4uLiBdCj4gKwlyZWdt YXBfdXBkYXRlX2JpdHMocC0+c3lzcmVnLCBNQTM1X1NZU19NSVNDRkNSMCwgTUlTQ0ZDUjBfVUhP VlJDVVJILAo+ICsJCQkgICBvZl9wcm9wZXJ0eV9yZWFkX2Jvb2wocGRldi0+ZGV2Lm9mX25vZGUs Cj4gKwkJCQkJCSAibnV2b3RvbixvYy1hY3RpdmUtaGlnaCIpID8KPiArCQkJICAgTUlTQ0ZDUjBf VUhPVlJDVVJIIDogMCk7CgpbU2V2ZXJpdHk6IEhpZ2hdCkRvZXMgdGhpcyB1bmNvbmRpdGlvbmFs IHdyaXRlIGJyZWFrIGRldmljZSB0cmVlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk/CgpJZiB0aGUg b3B0aW9uYWwgcHJvcGVydHkgbnV2b3RvbixvYy1hY3RpdmUtaGlnaCBpcyBhYnNlbnQsIHRoaXMg ZXhwbGljaXRseQp3cml0ZXMgMCB0byB0aGUgYml0LCBmb3JjaW5nIHRoZSBvdmVyLWN1cnJlbnQg cG9sYXJpdHkgdG8gYWN0aXZlLWxvdy4gVGhlCm9yaWdpbmFsIGRyaXZlciByZWxpZWQgb24gdGhl IGJvb3Rsb2FkZXIncyBjb25maWd1cmF0aW9uLgoKV2lsbCB0aGlzIGNhdXNlIGEgcmVncmVzc2lv biBpbiBvdmVyLWN1cnJlbnQgZGV0ZWN0aW9uIG9uIGV4aXN0aW5nIGJvYXJkcyB0aGF0CnVzZSBh Y3RpdmUtaGlnaCBoYXJkd2FyZSBjb25maWd1cmVkIGJ5IHRoZSBib290bG9hZGVyIGJ1dCBsYWNr IHRoaXMgbmV3CnByb3BlcnR5IGluIHRoZWlyIG9sZGVyIGRldmljZSB0cmVlPwoKPiArCj4gKwlm b3IgKG4gPSAwOyBuIDwgTUEzNV9QSFlfTlVNOyBuKyspIHsKCi0tIApTYXNoaWtvIEFJIHJldmll dyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjEwMDgwNjA2MjkuMjczNjgw Ni0xLWEwOTg3MjAzMDY5QGdtYWlsLmNvbT9wYXJ0PTQKCi0tIApsaW51eC1waHkgbWFpbGluZyBs 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 8DB6B37F8B3 for ; Thu, 8 Oct 2026 06:26:27 +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=1791440788; cv=none; b=eTdF7F2tERve3Zz8JsYOQyR4ncWBcExXuK6N9nUhsL1XnJ2PxRzPLuwWlp06YQd0XXUIKhxmeBDifUwEj0b+YsceJ9L1/Iu3ARGZI82XS00EplIIypIK7rbHaym89euDzEsudhdrG1PlNaaKx20NjZvir2lbKYLFoEfHhn1h7Cc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791440788; c=relaxed/simple; bh=1tzUXemJd2eq5aiF5NYpYzqrp/ZoYNTwc+vmceMlM2c=; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type: Date; b=TTiNFSA9BF45Nn61LjmshTf1+o/ON+pthnS+jOh9NGF8CuNW+5NIwPaTICDQ8c2s2JE7TJmOk93kY1FuUJiNBLW59QHWrM6n8VLN/UQpRHjMh5SN1OUSF/ticXQUu6I4Cd7DcvZhQo8KCUGbhHplXp+MZxUZ50N0JKaO1PhU2oc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g09x8D+M; 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="g09x8D+M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA7C51F000FF; Thu, 8 Oct 2026 06:26:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791440787; bh=i3qB9gopBGLMCT1FLzuKhYQYgBZIVEV8TkWEDxSOQSo=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=g09x8D+MghJESuDVvqH2XQfUhhKRrY/1By/x27fOF/Oj0M/nNPtGKK3ntuGRdQR+l 5YYUE4aeoYELjL5RxE0ttII+M5h1MGUVsL6eDOYLjivRxnxFrMNGn+PmqT+wHXNWAI c0u983R1X6pjgzPlotx/5scAtzSEZAthTDGRh6gaIT+5myYmAhtMYLGl6tbubpMy0W tgReuizSRcRAXczOV7l/ocuLnQerV0W1wAnXFm4kj6GMDixXxTj5VdXBQ4BLTQ7gQh JV1+SYsLdYf036NUvRMKulQ8V/veQZyS0j6bg+o1uTXYjXKsmaRpFOww3npPZsTJ6f CfS3VXyd9CkRw== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 4/4] phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support Reply-To: sashiko-reviews@lists.linux.dev To: "Joey Lu" Cc: devicetree@vger.kernel.org, neil.armstrong@linaro.org, linux-phy@lists.infradead.org, olteanv@gmail.com, vkoul@kernel.org, robh@kernel.org, conor+dt@kernel.org In-Reply-To: <20261008060629.2736806-5-a0987203069@gmail.com> References: <20261008060629.2736806-1-a0987203069@gmail.com> <20261008060629.2736806-5-a0987203069@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 08 Oct 2026 06:26:26 +0000 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 5 potential issue(= s) to consider: - [High] phy: Kconfig missing USB_ROLE_SWITCH dependency causes built-in li= nk failure - [High] phy: DT backward compatibility regression for over-current polarity - [Medium] phy: ignored regmap_read return values cause uninitialized varia= ble usage and info leak - [Medium] phy: regression in PHY reset fallback when clock polling fails - [Medium] PM/clock: PHY permanently holds HUSBH0_GATE preventing USB suspe= nd -- commit dce53df5cfe4dcfac8af16f8b29743a3f4e147e0 Author: Joey Lu phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support =20 PHY0 and PHY1 use the same power-on/reset sequence in USBPMISCR, with PHY1 control bits shifted 16 positions relative to PHY0. A separate driver for PHY1 would duplicate this logic, so the existing driver is extended to manage both ports. > diff --git a/drivers/phy/nuvoton/phy-ma35d1-usb2.c b/drivers/phy/nuvoton/= phy-ma35d1-usb2.c > index 0b9976fb15c17..25bd0a7a1314b 100644 > --- a/drivers/phy/nuvoton/phy-ma35d1-usb2.c > +++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c [ ... ] > -static int ma35_usb_phy_power_on(struct phy *phy) > +static int ma35_usb_phy_init(struct phy *phy) > { > - struct ma35_usb_phy *p_phy =3D phy_get_drvdata(phy); > + struct ma35_phy_port *port =3D phy_get_drvdata(phy); > + struct ma35_usb_phy *p =3D container_of(port - port->idx, > + struct ma35_usb_phy, port[0]); > + unsigned int n =3D port->idx; > unsigned int val; > int ret; > =20 > - ret =3D clk_prepare_enable(p_phy->clk); > - if (ret < 0) { > - dev_err(p_phy->dev, "Failed to enable PHY clock: %d\n", ret); > - return ret; > + regmap_read(p->sysreg, MA35_SYS_USBPMISCR, &val); > + > + if (!(val & USBPMISCR_PHY_SUSPEND(n))) { [Severity: Medium] Is this code branching on uninitialized stack memory? If regmap_read() fails, the return value is ignored and val is left uninitialized, leading to non-deterministic PHY state handling. [Severity: Medium] Could this strict condition remove the fallback reset sequence? The original driver would reset the PHY if the clock failed to stabilize du= ring polling. By encapsulating the reset strictly inside this block, it skips the reset entirely if the PHY is already running. If the subsequent clock polling times out, the driver immediately returns an error. Can this cause a regression where the PHY fails initialization perma= nently if it was left running but unstable by the bootloader or a prior kexec? > + regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR, > + USBPMISCR_PHY_CTL_MASK(n), > + USBPMISCR_PHY_POR(n) | USBPMISCR_PHY_SUSPEND(n)); > + udelay(20); > + > + regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR, > + USBPMISCR_PHY_CTL_MASK(n), > + USBPMISCR_PHY_SUSPEND(n)); > } [ ... ] > -static int ma35_usb_phy_power_off(struct phy *phy) > -{ > - struct ma35_usb_phy *p_phy =3D phy_get_drvdata(phy); > +static const struct phy_ops ma35_usb_phy_ops =3D { > + .init =3D ma35_usb_phy_init, > + .owner =3D THIS_MODULE, > +}; [Severity: Medium] Will the removal of dynamic clock toggling in .power_on and .power_off cause a power regression? Since the clock is now acquired permanently via devm_clk_get_enabled() duri= ng probe, the USB host clock gate (HUSBH0_GATE) remains open permanently, preventing it from closing and consuming unnecessary power when the USB host controller (EHCI0/OHCI0) suspends. > + > +static int ma35_role_sw_set(struct usb_role_switch *sw, enum usb_role ro= le) > +{ > + return -EOPNOTSUPP; > +} > + > +static enum usb_role ma35_role_sw_get(struct usb_role_switch *sw) > +{ > + struct ma35_usb_phy *p =3D usb_role_switch_get_drvdata(sw); > + u32 val; > + > + regmap_read(p->sysreg, MA35_SYS_PWRONOTP, &val); > + > + return (val & PWRONOTP_USBP0ID) ? USB_ROLE_HOST : USB_ROLE_DEVICE; > +} [Severity: Medium] Can this leak uninitialized stack memory to userspace? If regmap_read() fails, the return value is ignored and val remains uninitialized. This uninitialized data determines the returned USB role, inadvertently leaking 1 bit of kernel stack state to userspace via the sysfs role attribute. > + > +static int ma35_role_switch_init(struct platform_device *pdev, > + struct ma35_usb_phy *p) > +{ > + struct usb_role_switch_desc sw_desc =3D {0}; > + > + sw_desc.set =3D ma35_role_sw_set; > + sw_desc.get =3D ma35_role_sw_get; > + sw_desc.allow_userspace_control =3D true; > + sw_desc.driver_data =3D p; > + sw_desc.fwnode =3D dev_fwnode(&pdev->dev); > + > + p->role_sw =3D usb_role_switch_register(&pdev->dev, &sw_desc); [Severity: High] Would this introduce a built-in link failure if the driver is built-in (CONFIG_PHY_MA35_USB=3Dy) and the role switch framework is modular (CONFIG_USB_ROLE_SWITCH=3Dm)? In this configuration, IS_ENABLED(CONFIG_USB_ROLE_SWITCH) evaluates to true, so include/linux/usb/role.h declares the external functions instead of prov= iding inline stubs, causing an undefined reference to usb_role_switch_register. Should drivers/phy/nuvoton/Kconfig be updated to include depends on USB_ROLE_SWITCH || !USB_ROLE_SWITCH for PHY_MA35_USB to prevent this invalid Kconfig combination? > + if (IS_ERR(p->role_sw)) { [ ... ] > static int ma35_usb_phy_probe(struct platform_device *pdev) > { > struct phy_provider *provider; > - struct ma35_usb_phy *p_phy; > - struct phy *phy; > + struct ma35_usb_phy *p; > + struct clk *clk; > + int n, ret; > + u32 code; [ ... ] > + regmap_update_bits(p->sysreg, MA35_SYS_MISCFCR0, MISCFCR0_UHOVRCURH, > + of_property_read_bool(pdev->dev.of_node, > + "nuvoton,oc-active-high") ? > + MISCFCR0_UHOVRCURH : 0); [Severity: High] Does this unconditional write break device tree backward compatibility? If the optional property nuvoton,oc-active-high is absent, this explicitly writes 0 to the bit, forcing the over-current polarity to active-low. The original driver relied on the bootloader's configuration. Will this cause a regression in over-current detection on existing boards t= hat use active-high hardware configured by the bootloader but lack this new property in their older device tree? > + > + for (n =3D 0; n < MA35_PHY_NUM; n++) { --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261008060629.2736= 806-1-a0987203069@gmail.com?part=3D4