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 DBAF8C5CFC1 for ; Wed, 12 Aug 2026 01:12:43 +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=4UIp7BRWqLt+OlhMCZ5XViOEMvDdCtZZFFGMjk8hufg=; b=oi0uPZe+PNXZr2 unX6q/deaEMH54PsIb3ZWKK0scej7MNCIrtNxyRP5hZhLPYHI1Yl1qyWIADqObvffg4QqYtiQRusY KYzkcP/TX6SPzY4lBHFb55ySswBSdF2XUGzqNJV4Qa1Ed7QzJdnvKw7psto1LeD2p3dbLBXQODGNn L3DIJRzRDr8YMcJkttRnlyH6fIX3tRVApuUp7LEd4K8AFS78Uasm7hlsIs8QHI7lZiuxEjJzW249y gxjJWOibebraP7s0QYmJH65YUoa6baTTtNHVCv+EXVfnQrah/hTDnsl05tCvtqF+xA99itsPsK1Xt SukwiB/PX1prg4G6adCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtxWN-0000000FBuO-2PkN; Wed, 12 Aug 2026 01:12:43 +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 1wtxWM-0000000FBuI-0UZe for linux-phy@lists.infradead.org; Wed, 12 Aug 2026 01:12:42 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id AD60843A92; Wed, 12 Aug 2026 01:12:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C7D41F00A3A; Wed, 12 Aug 2026 01:12:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786497161; bh=1nASlmuS+v0jwRQC+UuinvC4MnCWsadWTWifB+SK38k=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=O55lGvysKAoyApyyk9+lgSWZ84r9gRh6DbpgDka+io+0zA23Tm2z58Ka6YbgYXAMu 2x+Ce9eRGpcmPewY/OrnuZHIxfIRItAQ6DW4bWaaGH+474FtlJy6pCcGNYaf8/6nqV y3yYHgTwLFbVTuFpiVltstkPAK7qiN5T70sXLbfipT5gUXxTJCtRHLqiRx4GCd6iA7 +0AT2qZK4FqIhWEdS3dVmGFjpDE7l0tKv9f4wvtv7CyecHJxwTllv4OYXQS/0IKupR 6p3PF2US8lvEr/xShiOprfu7Bwenu2yscRRdFzgDKLVC/wAm2sJElE4se6GTHrVee+ akMA/FjTJx/gw== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/8] phy: stm32: Add support for ST STM32MP25 USB2-FEMTO PHY To: "Marek Vasut" Cc: robh@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com, linux-phy@lists.infradead.org, conor+dt@kernel.org In-Reply-To: <20260812010157.1772849-3-marex@nabladev.com> References: <20260812010157.1772849-1-marex@nabladev.com> <20260812010157.1772849-3-marex@nabladev.com> Date: Wed, 12 Aug 2026 01:12:40 +0000 Message-Id: <20260812011241.2C7D41F00A3A@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 NSBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIEVycm9yIHBhdGhzIGlu IGBzdG0zMl91c2IycGh5X2VuYWJsZWAgYW5kIGBzdG0zMl91c2IycGh5X2Rpc2FibGVgIGZhaWwg dG8gYmFsYW5jZSB0aGUgYGVuX3JlZmNudGAgcmVmZXJlbmNlIGNvdW50ZXIuCi0gW0hpZ2hdIENv bmN1cnJlbnQgaGFyZHdhcmUgaW5pdGlhbGl6YXRpb24gYmV0d2VlbiB0aGUgUEhZIGZyYW1ld29y ayBhbmQgdGhlIENsb2NrIGZyYW1ld29yayBpcyBub3Qgc2VyaWFsaXplZC4KLSBbSGlnaF0gU3lz dGVtIHN1c3BlbmQvcmVzdW1lIGxvZ2ljIGZhaWxzIHRvIGNvcnJlY3RseSBzdXNwZW5kIGFuZCBy ZXN0b3JlIGhhcmR3YXJlIHN0YXRlLgotIFtNZWRpdW1dIENvbmZpZ3VyaW5nIHRoZSBob3N0LW9u bHkgUEhZIGludG8gZGV2aWNlIG1vZGUgcGh5c2ljYWxseSBjb3JydXB0cyB0aGUgcmVmZXJlbmNl IGNsb2NrIHNlbGVjdGlvbiByZWdpc3Rlci4KLSBbTG93XSBNaXNzaW5nIHZhbGlkYXRpb24gb2Yg YGRldmljZV9nZXRfbWF0Y2hfZGF0YSgpYCByZXR1cm4gdmFsdWUgbGVhZHMgdG8gYSBOVUxMIHBv aW50ZXIgZGVyZWZlcmVuY2UuCi0tCgotLS0gUGF0Y2ggWzJdOiBbUEFUQ0ggMi84XSBwaHk6IHN0 bTMyOiBBZGQgc3VwcG9ydCBmb3IgU1QgU1RNMzJNUDI1IFVTQjItRkVNVE8gUEhZIC0tLQpjb21t aXQgZjJhZGQ3ZmY2MjFlOWYxMTA4NzI3MTg2MWExOThhMjdlMWRhODE4YQpBdXRob3I6IFBhbmth aiBEZXYgPHBhbmthai5kZXZAc3QuY29tPgpwaHk6IHN0bTMyOiBBZGQgc3VwcG9ydCBmb3IgU1Qg U1RNMzJNUDI1IFVTQjItRkVNVE8gUEhZCgpUaGlzIGNvbW1pdCBhZGRzIHRoZSBVU0IyIFBIWSBk cml2ZXIgZm9yIFNUTTMyTVAyNSBVU0IyIGNvbnRyb2xsZXJzLiBJdApzdXBwb3J0cyBib3RoIHRo ZSBVU0IyLjAgaG9zdC1vbmx5IGNvbnRyb2xsZXIgYW5kIHRoZSBVU0IgMi4wIHBhcnQgb2YgdGhl CkRXQzMgY29udHJvbGxlciBieSBkaWZmZXJlbnRpYXRpbmcgdGhlbSB2aWEgY29tcGF0aWJsZSBz dHJpbmdzLgoKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9waHkvc3QvcGh5LXN0bTMyLXVzYjJwaHku YyBiL2RyaXZlcnMvcGh5L3N0L3BoeS1zdG0zMi11c2IycGh5LmMKPiBuZXcgZmlsZSBtb2RlIDEw MDY0NAo+IGluZGV4IDAwMDAwMDAwMDAwMDAuLmQ5MDIzNTRmODhiNjkKPiAtLS0gL2Rldi9udWxs Cj4gKysrIGIvZHJpdmVycy9waHkvc3QvcGh5LXN0bTMyLXVzYjJwaHkuYwpbIC4uLiBdCj4gK3N0 YXRpYyBpbnQgc3RtMzJfdXNiMnBoeV9lbmFibGUoc3RydWN0IHN0bTMyX3VzYjJwaHkgKnBoeV9k ZXYpCj4gK3sKPiArCWNvbnN0IHN0cnVjdCBzdG0zMm1wMl91c2IycGh5X2h3X2RhdGEgKnBoeV9k YXRhID0gcGh5X2Rldi0+aHdfZGF0YTsKPiArCXVuc2lnbmVkIGxvbmcgcmF0ZTsKPiArCWludCBy ZWZzZWwsIHJldDsKPiArCj4gKwkvKiBDaGVjayBpZiBhIHBoeSBpcyBhbHJlYWR5IGluaXQgb3Ig Y2xrNDggaW4gdXNlICovCj4gKwlpZiAoYXRvbWljX2luY19yZXR1cm4oJnBoeV9kZXYtPmVuX3Jl ZmNudCkgPiAxKQo+ICsJCXJldHVybiAwOwoKW1NldmVyaXR5OiBIaWdoXQpJcyB0aGVyZSBhIHJh Y2UgY29uZGl0aW9uIGhlcmUgaWYgYm90aCB0aGUgUEhZIGFuZCBDbG9jayBmcmFtZXdvcmtzCmF0 dGVtcHQgdG8gZW5hYmxlIHRoZSBoYXJkd2FyZSBjb25jdXJyZW50bHk/CgpJZiBUaHJlYWQgQSBj YWxscyBzdG0zMl91c2IycGh5X2VuYWJsZSgpIHZpYSBwaHlfaW5pdCBhbmQgVGhyZWFkIEIgY2Fs bHMKaXQgdmlhIGNsa19wcmVwYXJlIGNvbmN1cnJlbnRseToKClRocmVhZCBBIGluY3JlbWVudHMg ZW5fcmVmY250IHRvIDEgYW5kIHByb2NlZWRzIHdpdGggaW5pdGlhbGl6YXRpb24uClRocmVhZCBC IGluY3JlbWVudHMgZW5fcmVmY250IHRvIDIgYW5kIHJldHVybnMgc3VjY2VzcyBpbW1lZGlhdGVs eS4KClNpbmNlIG5vIG11dGV4IGlzIGhlbGQgZHVyaW5nIHRoZSBtdWx0aS1zdGVwIGhhcmR3YXJl IGluaXRpYWxpemF0aW9uLApjb3VsZCBUaHJlYWQgQiBzdGFydCB1c2luZyB0aGUgaGFyZHdhcmUg YmVmb3JlIFRocmVhZCBBIGhhcyBmaW5pc2hlZApjb25maWd1cmluZyBpdD8KCj4gKwo+ICsJcmF0 ZSA9IGNsa19nZXRfcmF0ZShwaHlfZGV2LT5waHlyZWYpOwo+ICsJaWYgKHJhdGUgPT0gMTkyMDAw MDApCj4gKwkJcmVmc2VsID0gMDsKPiArCWVsc2UgaWYgKHJhdGUgPT0gMjAwMDAwMDApCj4gKwkJ cmVmc2VsID0gMTsKPiArCWVsc2UgaWYgKHJhdGUgPT0gMjQwMDAwMDApCj4gKwkJcmVmc2VsID0g MjsKPiArCWVsc2UKPiArCQlyZXR1cm4gLUVJTlZBTDsKPiArCj4gKwlyZXQgPSByZWdtYXBfdXBk YXRlX2JpdHMocGh5X2Rldi0+cmVnbWFwLAo+ICsJCQkJIHBoeV9kZXYtPmNyX29mZnNldCwKPiAr CQkJCSBwaHlfZGF0YS0+cGh5cmVmc2VsX21hc2ssCj4gKwkJCQkgZmllbGRfcHJlcChwaHlfZGF0 YS0+cGh5cmVmc2VsX21hc2ssIHJlZnNlbCkpOwo+ICsJaWYgKHJldCkKPiArCQlyZXR1cm4gcmV0 OwoKW1NldmVyaXR5OiBIaWdoXQpJZiByZWdtYXBfdXBkYXRlX2JpdHMoKSBmYWlscywgZG9lcyB0 aGlzIHJldHVybiBlYXJseSB3aXRob3V0IGRlY3JlbWVudGluZwplbl9yZWZjbnQ/CgpUaGlzIGxv b2tzIGxpa2UgaXQgY291bGQgbGVhdmUgdGhlIHJlZmVyZW5jZSBjb3VudGVyIHBlcm1hbmVudGx5 IGluY3JlbWVudGVkLApwcmV2ZW50aW5nIGZ1dHVyZSBhdHRlbXB0cyB0byBpbml0aWFsaXplIHRo ZSBQSFkgb3IgY2xvY2sgaWYgYSByZXNvdXJjZQphbGxvY2F0aW9uIGZhaWxzIGhlcmUgb3IgaW4g c3Vic2VxdWVudCBzdGVwcyBsaWtlIHJlZ3VsYXRvcl9lbmFibGUoKS4KCj4gKwo+ICsJaWYgKHBo eV9kYXRhLT5pc191c2IyX2hvc3Rfb25seSkgewpbIC4uLiBdCj4gK3N0YXRpYyBpbnQgc3RtMzJf dXNiMnBoeV9kaXNhYmxlKHN0cnVjdCBzdG0zMl91c2IycGh5ICpwaHlfZGV2KQo+ICt7Cj4gKwlp bnQgcmV0Owo+ICsKPiArCS8qIENoZWNrIGlmIGEgcGh5IGlzIHN0aWxsIGluaXQgb3IgY2xrNDgg aW4gdXNlICovCj4gKwlpZiAoYXRvbWljX2RlY19yZXR1cm4oJnBoeV9kZXYtPmVuX3JlZmNudCkg PiAwKQo+ICsJCXJldHVybiAwOwo+ICsKPiArCXJldCA9IHJlc2V0X2NvbnRyb2xfYXNzZXJ0KHBo eV9kZXYtPnJzdGMpOwo+ICsJaWYgKHJldCkKPiArCQlyZXR1cm4gcmV0OwoKW1NldmVyaXR5OiBI aWdoXQpJZiByZXNldF9jb250cm9sX2Fzc2VydCgpIGZhaWxzLCBkb2VzIHRoaXMgc2tpcCB0aGUg cmVtYWluaW5nIGhhcmR3YXJlIGRpc2FibGUKc3RlcHMgd2hpbGUgbGVhdmluZyBlbl9yZWZjbnQg YWxyZWFkeSBkZWNyZW1lbnRlZD8KCj4gKwo+ICsJY2xrX2Rpc2FibGVfdW5wcmVwYXJlKHBoeV9k ZXYtPnBoeXJlZik7Cj4gKwo+ICsJcmV0dXJuIHJlZ3VsYXRvcl9kaXNhYmxlKHBoeV9kZXYtPnZk ZDMzKTsKPiArfQo+ICsKPiArc3RhdGljIGludCBzdG0zMl91c2IycGh5X3NldF9tb2RlKHN0cnVj dCBwaHkgKnBoeSwgZW51bSBwaHlfbW9kZSBtb2RlLCBpbnQgc3VibW9kZSkKPiArewo+ICsJc3Ry dWN0IHN0bTMyX3VzYjJwaHkgKnBoeV9kZXYgPSBwaHlfZ2V0X2RydmRhdGEocGh5KTsKPiArCWNv bnN0IHN0cnVjdCBzdG0zMm1wMl91c2IycGh5X2h3X2RhdGEgKnBoeV9kYXRhID0gcGh5X2Rldi0+ aHdfZGF0YTsKPiArCXUzMiB2YWwsIG1hc2sgPSBTWVNDRkdfVVNCMlBIWTJDUl9VU0IyUEhZMkNN TjsKPiArCWludCByZXQ7Cj4gKwo+ICsJaWYgKG1vZGUgPT0gUEhZX01PREVfVVNCX0hPU1QpIHsK WyAuLi4gXQo+ICsJfSBlbHNlIGlmIChtb2RlID09IFBIWV9NT0RFX1VTQl9ERVZJQ0UpIHsKPiAr CQl2YWwgPSBTWVNDRkdfVVNCMlBIWTJDUl9VU0IyUEhZMkNNTiB8Cj4gKwkJICAgICAgU1lTQ0ZH X1VTQjJQSFkyQ1JfVkJVU1ZMREVYVFNFTDsKPiArCQltYXNrIHw9IFNZU0NGR19VU0IyUEhZMkNS X1ZCVVNWQUxJRCB8Cj4gKwkJCVNZU0NGR19VU0IyUEhZMkNSX1ZCVVNWTERFWFRTRUwgfAo+ICsJ CQlTWVNDRkdfVVNCMlBIWTJDUl9WQlVTVkxERVhUOwo+ICsJCWlmIChzdWJtb2RlICE9IFVTQl9S T0xFX05PTkUpCj4gKwkJCXZhbCB8PSBTWVNDRkdfVVNCMlBIWTJDUl9WQlVTVkxERVhUOwo+ICsJ fSBlbHNlIHsKPiArCQlyZXR1cm4gLUVJTlZBTDsKPiArCX0KPiArCj4gKwlyZXQgPSByZWdtYXBf dXBkYXRlX2JpdHMocGh5X2Rldi0+cmVnbWFwLCBwaHlfZGV2LT5jcl9vZmZzZXQsIG1hc2ssIHZh bCk7CgpbU2V2ZXJpdHk6IE1lZGl1bV0KSWYgZGV2aWNlIG1vZGUgaXMgbWlzdGFrZW5seSByZXF1 ZXN0ZWQgb24gdGhlIGhvc3Qtb25seSBQSFkgdmFyaWFudCwgZG9lcwp0aGlzIHVuY29uZGl0aW9u YWxseSB3cml0ZSB0aGUgZGV2aWNlLW1vZGUgY29uZmlndXJhdGlvbiB0byBiaXRzIDQsIDUsIGFu ZCA2Cm9mIFNZU0NGR19VU0IyUEhZMkNSPwoKTG9va2luZyBhdCB0aGUgaGFyZHdhcmUgZGF0YSBk ZWZpbml0aW9uIGZvciB0aGUgaG9zdC1vbmx5IFBIWToKCnN0YXRpYyBjb25zdCBzdHJ1Y3Qgc3Rt MzJtcDJfdXNiMnBoeV9od19kYXRhIHN0bTMybXAyNV91c2IycGh5MV9od2RhdGEgPSB7CiAgICAu cGh5cmVmc2VsX21hc2sgPSBHRU5NQVNLKDYsIDQpLAogICAgLmlzX3VzYjJfaG9zdF9vbmx5ID0g dHJ1ZSwKfTsKClNpbmNlIHRob3NlIGV4YWN0IGJpdHMgYXJlIHVzZWQgZm9yIHRoZSByZWZlcmVu Y2UgY2xvY2sgc2VsZWN0aW9uLCBjb3VsZAp0aGlzIHNpbGVudGx5IGNvcnJ1cHQgdGhlIFBIWSBj bG9jayBjb25maWd1cmF0aW9uPwoKPiArCWlmIChyZXQpCj4gKwkJcmV0dXJuIHJldDsKWyAuLi4g XQo+ICtzdGF0aWMgaW50IHN0bTMyX3VzYjJwaHlfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2Rldmlj ZSAqcGRldikKPiArewpbIC4uLiBdCj4gKwlwaHlfZGV2LT5yZWdtYXAgPSBzeXNjb25fcmVnbWFw X2xvb2t1cF9ieV9waGFuZGxlX2FyZ3MoZGV2LT5vZl9ub2RlLCAic3Qsc3lzY2ZnIiwgMSwKPiAr CQkJCQkJCSAgICAgICAmcGh5X2Rldi0+Y3Jfb2Zmc2V0KTsKPiArCWlmIChJU19FUlIocGh5X2Rl di0+cmVnbWFwKSkgewo+ICsJCXJldHVybiBkZXZfZXJyX3Byb2JlKGRldiwgUFRSX0VSUihwaHlf ZGV2LT5yZWdtYXApLAo+ICsJCQkJICAgICAiTm8gc3Qsc3lzY2ZnIHBoYW5kbGUgc3BlY2lmaWVk XG4iKTsKPiArCX0KPiArCj4gKwlwaHlfZGV2LT5od19kYXRhID0gZGV2aWNlX2dldF9tYXRjaF9k YXRhKGRldik7CgpbU2V2ZXJpdHk6IExvd10KSWYgdGhlIGRyaXZlciBpcyBtYW51YWxseSBib3Vu ZCB2aWEgc3lzZnMgdG8gYSBkZXZpY2UgdGhhdCBkb2VzIG5vdCBtYXRjaAp0aGUgT0YgY29tcGF0 aWJsZSBzdHJpbmdzLCBkZXZpY2VfZ2V0X21hdGNoX2RhdGEoKSBjb3VsZCByZXR1cm4gTlVMTC4K ClNpbmNlIHRoZSByZXR1cm4gdmFsdWUgaXMgbm90IHZhbGlkYXRlZCBoZXJlLCBjb3VsZCB0aGlz IGxlYWQgdG8gYSBOVUxMCnBvaW50ZXIgZGVyZWZlcmVuY2Ugd2hlbiBwaHlfZGF0YS0+cGh5cmVm c2VsX21hc2sgaXMgYWNjZXNzZWQgbGF0ZXIgaW4Kc3RtMzJfdXNiMnBoeV9lbmFibGUoKT8KCj4g Kwo+ICsJcGh5ID0gZGV2bV9waHlfY3JlYXRlKGRldiwgTlVMTCwgJnN0bTMyX3VzYjJwaHlfZGF0 YSk7Cj4gKwlpZiAoSVNfRVJSKHBoeSkpCj4gKwkJcmV0dXJuIGRldl9lcnJfcHJvYmUoZGV2LCBQ VFJfRVJSKHBoeSksICJGYWlsZWQgdG8gY3JlYXRlIFBIWVxuIik7ClsgLi4uIF0KPiArc3RhdGlj IGludCBzdG0zMl91c2IycGh5X3N1c3BlbmQoc3RydWN0IGRldmljZSAqZGV2KQo+ICt7Cj4gKwlz dHJ1Y3Qgc3RtMzJfdXNiMnBoeSAqcGh5X2RldiA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOwo+ICsK PiArCWlmIChwaHlfZGV2LT5pc19pbml0KQo+ICsJCXJldHVybiBzdG0zMl91c2IycGh5X2Rpc2Fi bGUocGh5X2Rldik7Cj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KPiArCj4gK3N0YXRpYyBpbnQgc3Rt MzJfdXNiMnBoeV9yZXN1bWUoc3RydWN0IGRldmljZSAqZGV2KQo+ICt7Cj4gKwlzdHJ1Y3Qgc3Rt MzJfdXNiMnBoeSAqcGh5X2RldiA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOwo+ICsKPiArCWlmIChw aHlfZGV2LT5pc19pbml0KQo+ICsJCXJldHVybiBzdG0zMl91c2IycGh5X2VuYWJsZShwaHlfZGV2 KTsKPiArCj4gKwlyZXR1cm4gMDsKPiArfQoKW1NldmVyaXR5OiBIaWdoXQpEb2VzIHRoaXMgc3lz dGVtIHN1c3BlbmQvcmVzdW1lIGxvZ2ljIHByb3Blcmx5IHNhdmUgYW5kIHJlc3RvcmUgaGFyZHdh cmUKc3RhdGUgd2hlbiBib3RoIHRoZSBQSFkgYW5kIGNsb2NrIGNvbnN1bWVycyBhcmUgYWN0aXZl PwoKSWYgZW5fcmVmY250IGlzIDIsIGNhbGxpbmcgc3RtMzJfdXNiMnBoeV9kaXNhYmxlKCkgZHVy aW5nIHN1c3BlbmQgd2lsbCBtZXJlbHkKZGVjcmVtZW50IHRoZSBjb3VudGVyIHRvIDEgYW5kIHNr aXAgdGhlIGFjdHVhbCBoYXJkd2FyZSB0ZWFyZG93bi4gQ29udmVyc2VseSwKb24gcmVzdW1lLCBz dG0zMl91c2IycGh5X2VuYWJsZSgpIGluY3JlbWVudHMgdGhlIGNvdW50ZXIgdG8gMiBhbmQgc2tp cHMKaGFyZHdhcmUgaW5pdGlhbGl6YXRpb24uCgpJZiBwb3dlciBpcyBsb3N0IGR1cmluZyBzdXNw ZW5kLCBjb3VsZCB0aGUgaGFyZHdhcmUgcmVtYWluIGNvbXBsZXRlbHkKdW5pbml0aWFsaXplZCB1 cG9uIHJlc3VtZT8KCkFkZGl0aW9uYWxseSwgc3RtMzJfdXNiMnBoeV9yZXN1bWUoKSBkb2VzIG5v dCBhcHBlYXIgdG8gY2FsbApzdG0zMl91c2IycGh5X3NldF9tb2RlKCksIHdoaWNoIG1pZ2h0IG1l YW4gdGhlIFBIWSBtb2RlIGNvbmZpZ3VyYXRpb24gaXMgbG9zdAphZnRlciByZXN1bWluZy4KCi0t IApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAy NjA4MTIwMTAxNTcuMTc3Mjg0OS0xLW1hcmV4QG5hYmxhZGV2LmNvbT9wYXJ0PTIKCi0tIApsaW51 eC1waHkgbWFpbGluZyBsaXN0CmxpbnV4LXBoeUBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHBzOi8v bGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXBoeQo= 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 E64462BE034 for ; Wed, 12 Aug 2026 01:12:41 +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=1786497163; cv=none; b=C9q113Ozweg/+ENMFOgr8/ioXnll46VQOsauyNotQRdaM63ZNlPQDTpecobA2M9ZD+RiF0I/BtEHiZiOFgUlaYKtL2m/Exgo7jgyHx1HLvGcAq2n9xHm5XkTVKQ9LqOxswcyCSyaa/jP/Xl50dVQG/Kyxwuwhky71PL8kMLNeSU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786497163; c=relaxed/simple; bh=rU1kwpjMQSB4ifyUfbQGYvWQQdRQG7a2UaEamrvtuKk=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=ep8h9P7NLlfEDlELgySrXUf9MUPsyviU2IPHw+KhoGUK3TgIDbe3KrHdH9FoJPtM0NAV6gxEWY/IJfrVMDvqGaKUFrupA9j+cE1CCkpIMdcBrHrqbwzUkHbUC2ZZiL9XzEN6uNDCl/L9vSvGjltj3wwDYyUCpiVDPfFi5r5sRUo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O55lGvys; 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="O55lGvys" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C7D41F00A3A; Wed, 12 Aug 2026 01:12:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786497161; bh=1nASlmuS+v0jwRQC+UuinvC4MnCWsadWTWifB+SK38k=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=O55lGvysKAoyApyyk9+lgSWZ84r9gRh6DbpgDka+io+0zA23Tm2z58Ka6YbgYXAMu 2x+Ce9eRGpcmPewY/OrnuZHIxfIRItAQ6DW4bWaaGH+474FtlJy6pCcGNYaf8/6nqV y3yYHgTwLFbVTuFpiVltstkPAK7qiN5T70sXLbfipT5gUXxTJCtRHLqiRx4GCd6iA7 +0AT2qZK4FqIhWEdS3dVmGFjpDE7l0tKv9f4wvtv7CyecHJxwTllv4OYXQS/0IKupR 6p3PF2US8lvEr/xShiOprfu7Bwenu2yscRRdFzgDKLVC/wAm2sJElE4se6GTHrVee+ akMA/FjTJx/gw== From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/8] phy: stm32: Add support for ST STM32MP25 USB2-FEMTO PHY Reply-To: sashiko-reviews@lists.linux.dev To: "Marek Vasut" Cc: robh@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com, linux-phy@lists.infradead.org, conor+dt@kernel.org In-Reply-To: <20260812010157.1772849-3-marex@nabladev.com> References: <20260812010157.1772849-1-marex@nabladev.com> <20260812010157.1772849-3-marex@nabladev.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2026 01:12:40 +0000 Message-Id: <20260812011241.2C7D41F00A3A@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 5 potential issue(= s) to consider: - [High] Error paths in `stm32_usb2phy_enable` and `stm32_usb2phy_disable` = fail to balance the `en_refcnt` reference counter. - [High] Concurrent hardware initialization between the PHY framework and t= he Clock framework is not serialized. - [High] System suspend/resume logic fails to correctly suspend and restore= hardware state. - [Medium] Configuring the host-only PHY into device mode physically corrup= ts the reference clock selection register. - [Low] Missing validation of `device_get_match_data()` return value leads = to a NULL pointer dereference. -- --- Patch [2]: [PATCH 2/8] phy: stm32: Add support for ST STM32MP25 USB2-FE= MTO PHY --- commit f2add7ff621e9f11087271861a198a27e1da818a Author: Pankaj Dev phy: stm32: Add support for ST STM32MP25 USB2-FEMTO PHY This commit adds the USB2 PHY driver for STM32MP25 USB2 controllers. It supports both the USB2.0 host-only controller and the USB 2.0 part of the DWC3 controller by differentiating them via compatible strings. > diff --git a/drivers/phy/st/phy-stm32-usb2phy.c b/drivers/phy/st/phy-stm3= 2-usb2phy.c > new file mode 100644 > index 0000000000000..d902354f88b69 > --- /dev/null > +++ b/drivers/phy/st/phy-stm32-usb2phy.c [ ... ] > +static int stm32_usb2phy_enable(struct stm32_usb2phy *phy_dev) > +{ > + const struct stm32mp2_usb2phy_hw_data *phy_data =3D phy_dev->hw_data; > + unsigned long rate; > + int refsel, ret; > + > + /* Check if a phy is already init or clk48 in use */ > + if (atomic_inc_return(&phy_dev->en_refcnt) > 1) > + return 0; [Severity: High] Is there a race condition here if both the PHY and Clock frameworks attempt to enable the hardware concurrently? If Thread A calls stm32_usb2phy_enable() via phy_init and Thread B calls it via clk_prepare concurrently: Thread A increments en_refcnt to 1 and proceeds with initialization. Thread B increments en_refcnt to 2 and returns success immediately. Since no mutex is held during the multi-step hardware initialization, could Thread B start using the hardware before Thread A has finished configuring it? > + > + rate =3D clk_get_rate(phy_dev->phyref); > + if (rate =3D=3D 19200000) > + refsel =3D 0; > + else if (rate =3D=3D 20000000) > + refsel =3D 1; > + else if (rate =3D=3D 24000000) > + refsel =3D 2; > + else > + return -EINVAL; > + > + ret =3D regmap_update_bits(phy_dev->regmap, > + phy_dev->cr_offset, > + phy_data->phyrefsel_mask, > + field_prep(phy_data->phyrefsel_mask, refsel)); > + if (ret) > + return ret; [Severity: High] If regmap_update_bits() fails, does this return early without decrementing en_refcnt? This looks like it could leave the reference counter permanently incremente= d, preventing future attempts to initialize the PHY or clock if a resource allocation fails here or in subsequent steps like regulator_enable(). > + > + if (phy_data->is_usb2_host_only) { [ ... ] > +static int stm32_usb2phy_disable(struct stm32_usb2phy *phy_dev) > +{ > + int ret; > + > + /* Check if a phy is still init or clk48 in use */ > + if (atomic_dec_return(&phy_dev->en_refcnt) > 0) > + return 0; > + > + ret =3D reset_control_assert(phy_dev->rstc); > + if (ret) > + return ret; [Severity: High] If reset_control_assert() fails, does this skip the remaining hardware disa= ble steps while leaving en_refcnt already decremented? > + > + clk_disable_unprepare(phy_dev->phyref); > + > + return regulator_disable(phy_dev->vdd33); > +} > + > +static int stm32_usb2phy_set_mode(struct phy *phy, enum phy_mode mode, i= nt submode) > +{ > + struct stm32_usb2phy *phy_dev =3D phy_get_drvdata(phy); > + const struct stm32mp2_usb2phy_hw_data *phy_data =3D phy_dev->hw_data; > + u32 val, mask =3D SYSCFG_USB2PHY2CR_USB2PHY2CMN; > + int ret; > + > + if (mode =3D=3D PHY_MODE_USB_HOST) { [ ... ] > + } else if (mode =3D=3D PHY_MODE_USB_DEVICE) { > + val =3D SYSCFG_USB2PHY2CR_USB2PHY2CMN | > + SYSCFG_USB2PHY2CR_VBUSVLDEXTSEL; > + mask |=3D SYSCFG_USB2PHY2CR_VBUSVALID | > + SYSCFG_USB2PHY2CR_VBUSVLDEXTSEL | > + SYSCFG_USB2PHY2CR_VBUSVLDEXT; > + if (submode !=3D USB_ROLE_NONE) > + val |=3D SYSCFG_USB2PHY2CR_VBUSVLDEXT; > + } else { > + return -EINVAL; > + } > + > + ret =3D regmap_update_bits(phy_dev->regmap, phy_dev->cr_offset, mask, v= al); [Severity: Medium] If device mode is mistakenly requested on the host-only PHY variant, does this unconditionally write the device-mode configuration to bits 4, 5, and 6 of SYSCFG_USB2PHY2CR? Looking at the hardware data definition for the host-only PHY: static const struct stm32mp2_usb2phy_hw_data stm32mp25_usb2phy1_hwdata =3D { .phyrefsel_mask =3D GENMASK(6, 4), .is_usb2_host_only =3D true, }; Since those exact bits are used for the reference clock selection, could this silently corrupt the PHY clock configuration? > + if (ret) > + return ret; [ ... ] > +static int stm32_usb2phy_probe(struct platform_device *pdev) > +{ [ ... ] > + phy_dev->regmap =3D syscon_regmap_lookup_by_phandle_args(dev->of_node, = "st,syscfg", 1, > + &phy_dev->cr_offset); > + if (IS_ERR(phy_dev->regmap)) { > + return dev_err_probe(dev, PTR_ERR(phy_dev->regmap), > + "No st,syscfg phandle specified\n"); > + } > + > + phy_dev->hw_data =3D device_get_match_data(dev); [Severity: Low] If the driver is manually bound via sysfs to a device that does not match the OF compatible strings, device_get_match_data() could return NULL. Since the return value is not validated here, could this lead to a NULL pointer dereference when phy_data->phyrefsel_mask is accessed later in stm32_usb2phy_enable()? > + > + phy =3D devm_phy_create(dev, NULL, &stm32_usb2phy_data); > + if (IS_ERR(phy)) > + return dev_err_probe(dev, PTR_ERR(phy), "Failed to create PHY\n"); [ ... ] > +static int stm32_usb2phy_suspend(struct device *dev) > +{ > + struct stm32_usb2phy *phy_dev =3D dev_get_drvdata(dev); > + > + if (phy_dev->is_init) > + return stm32_usb2phy_disable(phy_dev); > + > + return 0; > +} > + > +static int stm32_usb2phy_resume(struct device *dev) > +{ > + struct stm32_usb2phy *phy_dev =3D dev_get_drvdata(dev); > + > + if (phy_dev->is_init) > + return stm32_usb2phy_enable(phy_dev); > + > + return 0; > +} [Severity: High] Does this system suspend/resume logic properly save and restore hardware state when both the PHY and clock consumers are active? If en_refcnt is 2, calling stm32_usb2phy_disable() during suspend will mere= ly decrement the counter to 1 and skip the actual hardware teardown. Conversel= y, on resume, stm32_usb2phy_enable() increments the counter to 2 and skips hardware initialization. If power is lost during suspend, could the hardware remain completely uninitialized upon resume? Additionally, stm32_usb2phy_resume() does not appear to call stm32_usb2phy_set_mode(), which might mean the PHY mode configuration is lo= st after resuming. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260812010157.1772= 849-1-marex@nabladev.com?part=3D2