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 BC9D6CDB47C for ; Wed, 24 Jun 2026 10:46:01 +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=VhPbPx02kVucyEA1gMItjJa8bFw+lTol5RzQejOkwyI=; b=x6AD4YVi4shCjE St8IDSubXjM0PU+srbS0xX6pH02MJNn0vUT6WLN7j3tujsUUthhvIJcQR+UD/844BFiJZnojhx1ZM 58faEPfgUhvX27M9Pr2xdlrlC69GNvGxQXEyAbFzw+aS74g3Vr7A3vdTtpoo22uvmBYbM7j47dC/5 aDuwZafU4AHPHeXk7dRP2LK3dnyZnCKNVPL2H4TZ3xp/4UNRfAyvzYVIyG8PbsphLk1A8jbVIq2z2 sBhuL5pwxF1nOuHGRXEBr908/x+oQR1l30VZHwbWNYJpKMfG73H+xwCNmjCOl1jb9vEkddKOlhj2v D8147hXhEVR7iwj5vTHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wcL7H-00000007cuP-0sau; Wed, 24 Jun 2026 10:46:01 +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 1wcL7D-00000007ctl-16oi for linux-i3c@lists.infradead.org; Wed, 24 Jun 2026 10:45:55 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 0B3AA4004F; Wed, 24 Jun 2026 10:45:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98EF71F000E9; Wed, 24 Jun 2026 10:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782297954; bh=jKgs/HAdxm66fJBTL5AbFOaCH3Dsrsjs1Xn5W2bk2uc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=T9LRnklbFBzDyZ4eOOjBx+K4b8XigR6393mpFcGCRyqGNm7JOyLOHNXb/E8jAulRl b7zJd4XLYHlAbaS96to9YylCDUztHUZwOyUOT47y6iyaI6ZUBjReM5UjEPW43qGMdI osVrlzzrX+By8WTcI6gTornVcSAPDoceAIJt1zzuhvsy5+y63rrFh66xqaA6nnTNZw KCQ6oQjRiK5ZCAq0H8Q+Li3fJv8vg37alYfn3rJU+yrK/w2TyKY43+t13UmQuiSQ2M j5IRmjzzdL+ZWRekB+ZeAfGxgF5HrVKKOIbe+sabJvgYXuRkekau0ttFNx2ePB3gKp n4silM0x/kElw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v5 05/12] i3c: master: Add support for devices without PID To: "Akhil R" Cc: Frank.Li@kernel.org, robh@kernel.org, conor+dt@kernel.org, linux-i3c@lists.infradead.org, devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org In-Reply-To: <20260624102153.1770072-6-akhilrajeev@nvidia.com> References: <20260624102153.1770072-1-akhilrajeev@nvidia.com> <20260624102153.1770072-6-akhilrajeev@nvidia.com> Date: Wed, 24 Jun 2026 10:45:54 +0000 Message-Id: <20260624104554.98EF71F000E9@smtp.kernel.org> X-BeenThere: linux-i3c@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: 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-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg NiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBE ZXZpY2VzIHJldHVybmluZyBhIFBJRCBvZiAwIGR1cmluZyBEeW5hbWljIEFkZHJlc3MgQXNzaWdu bWVudCAoREFBKSBieXBhc3MgZHVwbGljYXRlIGRldGVjdGlvbiwgbGVhZGluZyB0byBzeXNmcyBu YW1pbmcgY29sbGlzaW9ucyB0aGF0IHJlbGlhYmx5IHRyaWdnZXIgYSBwcmVleGlzdGluZyBVc2Ut QWZ0ZXItRnJlZS4KLSBbTWVkaXVtXSBUaGUgZHJpdmVyIGluY29ycmVjdGx5IGFsbG93cyBub24t U0VUQUFTQSBJM0MgZGV2aWNlcyB0byBiZSBkZWZpbmVkIGluIHRoZSBkZXZpY2UgdHJlZSB3aXRo IGEgUElEIG9mIDAsIHBlcm1hbmVudGx5IGJyZWFraW5nIGRldmljZSBtYXRjaGluZyB1cG9uIEhv dC1Kb2luIHJlLWF0dGFjaG1lbnQuCi0gW0xvd10gVGhlIG5ld2x5IGFkZGVkIHN0YXRpYyBhZGRy ZXNzIG1hdGNoaW5nIGxvZ2ljIGluIGBpM2NfbWFzdGVyX2F0dGFjaF9ib2FyZGluZm8oKWAgd2ls bCBuZXZlciBzdWNjZXNzZnVsbHkgbWF0Y2ggYW55IGRldmljZSwgcmVuZGVyaW5nIHRoZSBgZWxz ZWAgYnJhbmNoIGRlYWQgY29kZS4KLSBbTG93XSBSZWR1bmRhbnQgYm9vbGVhbiBjaGVjayBmb3Ig YGkzY2Rldi0+aW5mby5waWRgIGluc2lkZSB0aGUgZHVwbGljYXRlIHNlYXJjaCBsb29wLgoKUHJl LWV4aXN0aW5nIGlzc3VlczoKLSBbSGlnaF0gRGFuZ2xpbmcgcG9pbnRlciBpbiBgZGVzYy0+ZGV2 YCBsZWFkcyB0byBhIFVzZS1BZnRlci1GcmVlIGFuZCBEb3VibGUgRnJlZSBpZiBgZGV2aWNlX3Jl Z2lzdGVyKClgIGZhaWxzLgotIFtIaWdoXSBDYWxsaW5nIGBkZXZpY2VfcmVnaXN0ZXIoKWAgd2hp bGUgaG9sZGluZyBhIHJlYWQgbG9jayBvbiB0aGUgYnVzIHJ3c2VtIGNhbiBsZWFkIHRvIGEgZGVh ZGxvY2sgaWYgdGhlIGRyaXZlcidzIHByb2JlIGZ1bmN0aW9uIGF0dGVtcHRzIGFuIEkzQyB0cmFu c2Zlci4KLS0KCmNvbW1pdCA3NmU3Yzg1MDY5ZjY1Zjc1ZTU0NzZhMTNlNmY0YWIyYWU3MDU1ODlm CkF1dGhvcjogQWtoaWwgUiA8YWtoaWxyYWplZXZAbnZpZGlhLmNvbT4KCmkzYzogbWFzdGVyOiBB ZGQgc3VwcG9ydCBmb3IgZGV2aWNlcyB3aXRob3V0IFBJRAoKRGV2aWNlcyB1c2luZyBTRVRBQVNB IGZvciBhZGRyZXNzIGFzc2lnbm1lbnQgYXJlIG5vdCByZXF1aXJlZCB0byBoYXZlCmEgNDgtYml0 IFBJRCBhY2NvcmRpbmcgdG8gdGhlIEkzQyBzcGVjaWZpY2F0aW9uLiBBbGxvdyBzdWNoIGRldmlj ZXMgdG8KcmVnaXN0ZXIgYW5kIHVzZSB0aGUgc3RhdGljIGFkZHJlc3Mgd2hlcmUgUElEIHdhcyBy ZXF1aXJlZC4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL21hc3Rlci5jIGIvZHJpdmVycy9p M2MvbWFzdGVyLmMKPiBpbmRleCAzZGVhZThjZGFlNTI1Li5iZDBkYzc2YzdiYTFlIDEwMDY0NAo+ IC0tLSBhL2RyaXZlcnMvaTNjL21hc3Rlci5jCj4gKysrIGIvZHJpdmVycy9pM2MvbWFzdGVyLmMK PiBAQCAtMTk4OSw4ICsxOTg5LDE3IEBAIGkzY19tYXN0ZXJfcmVnaXN0ZXJfbmV3X2kzY19kZXZz KHN0cnVjdCBpM2NfbWFzdGVyX2NvbnRyb2xsZXIgKm1hc3RlcikKPiAgCQlkZXNjLT5kZXYtPmRl di50eXBlID0gJmkzY19kZXZpY2VfdHlwZTsKPiAgCQlkZXNjLT5kZXYtPmRldi5idXMgPSAmaTNj X2J1c190eXBlOwo+ICAJCWRlc2MtPmRldi0+ZGV2LnJlbGVhc2UgPSBpM2NfZGV2aWNlX3JlbGVh c2U7Cj4gLQkJZGV2X3NldF9uYW1lKCZkZXNjLT5kZXYtPmRldiwgIiVkLSVsbHgiLCBtYXN0ZXIt PmJ1cy5pZCwKPiAtCQkJICAgICBkZXNjLT5pbmZvLnBpZCk7Cj4gKwo+ICsJCS8qCj4gKwkJICog Rm9yIGRldmljZXMgd2l0aG91dCBQSUQgKGUuZy4sIFNFVEFBU0EgZGV2aWNlcyksIHVzZQo+ICsJ CSAqIHN0YXRpYyBhZGRyZXNzIGZvciBuYW1pbmcgaW5zdGVhZC4KPiArCQkgKi8KPiArCQlpZiAo ZGVzYy0+aW5mby5waWQpCj4gKwkJCWRldl9zZXRfbmFtZSgmZGVzYy0+ZGV2LT5kZXYsICIlZC0l bGx4IiwgbWFzdGVyLT5idXMuaWQsCj4gKwkJCQkgICAgIGRlc2MtPmluZm8ucGlkKTsKPiArCQll bHNlCj4gKwkJCWRldl9zZXRfbmFtZSgmZGVzYy0+ZGV2LT5kZXYsICIlZC0lMDJ4IiwgbWFzdGVy LT5idXMuaWQsCj4gKwkJCQkgICAgIGRlc2MtPmluZm8uc3RhdGljX2FkZHIpOwo+ICAKPiAgCQlp ZiAoZGVzYy0+Ym9hcmRpbmZvKQo+ICAJCQlkZXZpY2Vfc2V0X25vZGUoJmRlc2MtPmRldi0+ZGV2 LAoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgZG9l cyBmYWlsaW5nIHRvIGNsZWFyIGRlc2MtPmRldiB3aGVuCmRldmljZV9yZWdpc3RlcigpIGZhaWxz IGxlYWQgdG8gYSBkb3VibGUgZnJlZSBhbmQgdXNlLWFmdGVyLWZyZWUgbGF0ZXI/CgpMb29raW5n IGF0IGkzY19tYXN0ZXJfcmVnaXN0ZXJfbmV3X2kzY19kZXZzKCk6CgogICAgcmV0ID0gZGV2aWNl X3JlZ2lzdGVyKCZkZXNjLT5kZXYtPmRldik7CiAgICBpZiAocmV0KSB7CiAgICAgICAgZGV2X2Vy cigmbWFzdGVyLT5kZXYsICJGYWlsZWQgdG8gYWRkIEkzQyBkZXZpY2UgKGVyciA9ICVkKVxuIiwg cmV0KTsKICAgICAgICBwdXRfZGV2aWNlKCZkZXNjLT5kZXYtPmRldik7CiAgICB9CgpJZiBkZXZp Y2VfcmVnaXN0ZXIoKSBmYWlscywgcHV0X2RldmljZSgpIGlzIGNhbGxlZCB3aGljaCBmcmVlcyB0 aGUgaTNjX2RldmljZQpzdHJ1Y3R1cmUsIGJ1dCBkZXNjLT5kZXYgaXMgbGVmdCBkYW5nbGluZy4g TGF0ZXIsIHdoZW4gdGhlIG1hc3RlciBpcwp1bnJlZ2lzdGVyZWQgaW4gaTNjX21hc3Rlcl91bnJl Z2lzdGVyX2kzY19kZXZzKCksIHRoZSBsb29wIGNoZWNrczoKCiAgICBpZiAoIWkzY2Rldi0+ZGV2 KQogICAgICAgIGNvbnRpbnVlOwogICAgaTNjZGV2LT5kZXYtPmRlc2MgPSBOVUxMOwogICAgaWYg KGRldmljZV9pc19yZWdpc3RlcmVkKCZpM2NkZXYtPmRldi0+ZGV2KSkKICAgICAgICBkZXZpY2Vf dW5yZWdpc3RlcigmaTNjZGV2LT5kZXYtPmRldik7CiAgICBlbHNlCiAgICAgICAgcHV0X2Rldmlj ZSgmaTNjZGV2LT5kZXYtPmRldik7CgpTaW5jZSBkZXNjLT5kZXYgaXMgbm90IE5VTEwsIHRoaXMg d3JpdGVzIHRvIHRoZSBmcmVlZCBtZW1vcnkgYW5kIHRoZW4gY2FsbHMKcHV0X2RldmljZSgpIGFn YWluLCByZXN1bHRpbmcgaW4gYSB1c2UtYWZ0ZXItZnJlZSBhbmQgZG91YmxlIGZyZWUuCgpbU2V2 ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYWxzbyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGNhbiBj YWxsaW5nIGRldmljZV9yZWdpc3RlcigpIHdoaWxlCmhvbGRpbmcgYSByZWFkIGxvY2sgb24gdGhl IGJ1cyByd3NlbSBsZWFkIHRvIGEgZGVhZGxvY2s/CgpJbiBpM2NfbWFzdGVyX3JlZ193b3JrX2Zu KCk6CgogICAgaTNjX2J1c19ub3JtYWx1c2VfbG9jaygmbWFzdGVyLT5idXMpOwogICAgaWYgKCFt YXN0ZXItPnNodXR0aW5nX2Rvd24pCiAgICAgICAgaTNjX21hc3Rlcl9yZWdpc3Rlcl9uZXdfaTNj X2RldnMobWFzdGVyKTsKClRoZSBkZXZpY2VfcmVnaXN0ZXIoKSBjYWxsIGluc2lkZSBpM2NfbWFz dGVyX3JlZ2lzdGVyX25ld19pM2NfZGV2cygpCnN5bmNocm9ub3VzbHkgdHJpZ2dlcnMgdGhlIGRy aXZlcidzIHByb2JlIGZ1bmN0aW9uLiBJZiB0aGUgcHJvYmUgYXR0ZW1wdHMgYW4KSTNDIHRyYW5z ZmVyLCBpdCBjYWxscyBpM2NfZGV2aWNlX2RvX3ByaXZfeGZlcnMoKSwgd2hpY2ggcmVjdXJzaXZl bHkgcmVxdWVzdHMKdGhlIHJlYWQgbG9jayBvbiB0aGUgYnVzLgoKSWYgYSBjb25jdXJyZW50IHRo cmVhZCwgc3VjaCBhcyBhIEhvdCBKb2luLCByZXF1ZXN0cyBhIHdyaXRlIGxvY2sgYmV0d2Vlbgp0 aGVzZSB0d28gcmVhZCBsb2NrIGF0dGVtcHRzLCB0aGUgcndzZW0gYmxvY2tzIHRoZSBzZWNvbmQg cmVhZCBsb2NrIHRvIHByZXZlbnQKd3JpdGVyIHN0YXJ2YXRpb24uIFRoZSB3cml0ZXIgYmxvY2tz IHdhaXRpbmcgZm9yIHRoZSBmaXJzdCByZWFkIGxvY2sgdG8gYmUKcmVsZWFzZWQsIHdoaWNoIHdv bid0IGhhcHBlbiB1bnRpbCBkZXZpY2VfcmVnaXN0ZXIoKSByZXR1cm5zLCByZXN1bHRpbmcgaW4g YW4KQUJCQSBkZWFkbG9jay4KClsgLi4uIF0KCj4gQEAgLTIzODMsOCArMjM5MiwxOCBAQCBzdGF0 aWMgdm9pZCBpM2NfbWFzdGVyX2F0dGFjaF9ib2FyZGluZm8oc3RydWN0IGkzY19kZXZfZGVzYyAq aTNjZGV2KQo+ICAJc3RydWN0IGkzY19kZXZfYm9hcmRpbmZvICppM2Nib2FyZGluZm87Cj4gIAo+ ICAJbGlzdF9mb3JfZWFjaF9lbnRyeShpM2Nib2FyZGluZm8sICZtYXN0ZXItPmJvYXJkaW5mby5p M2MsIG5vZGUpIHsKPiAtCQlpZiAoaTNjZGV2LT5pbmZvLnBpZCAhPSBpM2Nib2FyZGluZm8tPnBp ZCkKPiAtCQkJY29udGludWU7Cj4gKwkJLyoKPiArCQkgKiBGb3IgZGV2aWNlcyB3aXRob3V0IFBJ RCAoZS5nLiwgU0VUQUFTQSBkZXZpY2VzKSwgbWF0Y2ggYnkKPiArCQkgKiBzdGF0aWMgYWRkcmVz cy4gRm9yIGRldmljZXMgd2l0aCBQSUQsIG1hdGNoIGJ5IFBJRC4KPiArCQkgKi8KPiArCQlpZiAo aTNjYm9hcmRpbmZvLT5waWQpIHsKPiArCQkJaWYgKGkzY2Rldi0+aW5mby5waWQgIT0gaTNjYm9h cmRpbmZvLT5waWQpCj4gKwkJCQljb250aW51ZTsKPiArCQl9IGVsc2Ugewo+ICsJCQlpZiAoIWkz Y2JvYXJkaW5mby0+c3RhdGljX2FkZHIgfHwKPiArCQkJICAgIGkzY2Rldi0+aW5mby5zdGF0aWNf YWRkciAhPSBpM2Nib2FyZGluZm8tPnN0YXRpY19hZGRyKQo+ICsJCQkJY29udGludWU7Cj4gKwkJ fQoKW1NldmVyaXR5OiBMb3ddCldpbGwgdGhpcyBuZXdseSBhZGRlZCBlbHNlIGJsb2NrIGV2ZXIg c3VjY2Vzc2Z1bGx5IG1hdGNoIGEgZGV2aWNlPwoKaTNjX21hc3Rlcl9hdHRhY2hfYm9hcmRpbmZv KCkgaXMgY2FsbGVkIGZyb20KX19pM2NfbWFzdGVyX2FkZF9pM2NfZGV2X2xvY2tlZCgpIHRvIGhh bmRsZSBkZXZpY2VzIGRpc2NvdmVyZWQgZHluYW1pY2FsbHkgdmlhCkRBQSBvciBIb3QtSm9pbi4g Rm9yIHRoZXNlIGRldmljZXMsIHRoZSBoYXJkd2FyZSBkb2VzIG5vdCBwcm92aWRlIGEgc3RhdGlj CmFkZHJlc3MgZHVyaW5nIERBQSwgc28gaTNjZGV2LT5pbmZvLnN0YXRpY19hZGRyIGlzIHN0cmlj dGx5IDAuCgpCZWNhdXNlIG9mIHRoaXMsIHRoZSBjb25kaXRpb24KaTNjZGV2LT5pbmZvLnN0YXRp Y19hZGRyICE9IGkzY2JvYXJkaW5mby0+c3RhdGljX2FkZHIKd2lsbCBldmFsdWF0ZSB0byAwICE9 IG5vbl96ZXJvLCB3aGljaCBpcyBhbHdheXMgdHJ1ZS4gVGhpcyBjYXVzZXMgdGhlIGxvb3AKdG8g dW5jb25kaXRpb25hbGx5IGNvbnRpbnVlLCBtYWtpbmcgdGhpcyBmYWxsYmFjayBkZWFkIGNvZGUu Cgo+ICAKPiAgCQlpM2NkZXYtPmJvYXJkaW5mbyA9IGkzY2JvYXJkaW5mbzsKPiAgCQlpM2NkZXYt PmluZm8uc3RhdGljX2FkZHIgPSBpM2Nib2FyZGluZm8tPnN0YXRpY19hZGRyOwo+IEBAIC0yMzk4 LDggKzI0MTcsMTIgQEAgaTNjX21hc3Rlcl9zZWFyY2hfaTNjX2Rldl9kdXBsaWNhdGUoc3RydWN0 IGkzY19kZXZfZGVzYyAqcmVmZGV2KQo+ICAJc3RydWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciAq bWFzdGVyID0gaTNjX2Rldl9nZXRfbWFzdGVyKHJlZmRldik7Cj4gIAlzdHJ1Y3QgaTNjX2Rldl9k ZXNjICppM2NkZXY7Cj4gIAo+ICsJaWYgKCFyZWZkZXYtPmluZm8ucGlkKQo+ICsJCXJldHVybiBO VUxMOwo+ICsKCltTZXZlcml0eTogSGlnaF0KRG9lcyByZXR1cm5pbmcgTlVMTCB3aGVuIFBJRCBp cyAwIGFsbG93IGRldmljZXMgdG8gYnlwYXNzIGR1cGxpY2F0ZSBkZXRlY3Rpb24KYW5kIHRyaWdn ZXIgdGhlIHByZS1leGlzdGluZyB1c2UtYWZ0ZXItZnJlZSBidWc/CgpJZiBhIGR5bmFtaWNhbGx5 IGRpc2NvdmVyZWQgZGV2aWNlIHJlcG9ydHMgYSBQSUQgb2YgMCwgdGhpcyBjaGVjawp1bmNvbmRp dGlvbmFsbHkgYnlwYXNzZXMgZHVwbGljYXRlIHJlamVjdGlvbiwgc28gdGhlIGRldmljZSBpcyBy ZXBlYXRlZGx5CmFkZGVkLgoKQmVjYXVzZSBzdGF0aWNfYWRkciBpcyBhbHNvIDAgZm9yIERBQS1k aXNjb3ZlcmVkIGRldmljZXMsIHRoZSBuZXcgbmFtaW5nCmZhbGxiYWNrIGluIGkzY19tYXN0ZXJf cmVnaXN0ZXJfbmV3X2kzY19kZXZzKCk6CgogICAgZGV2X3NldF9uYW1lKCZkZXNjLT5kZXYtPmRl diwgIiVkLSUwMngiLCBtYXN0ZXItPmJ1cy5pZCwKICAgICAgICAgICAgICAgICBkZXNjLT5pbmZv LnN0YXRpY19hZGRyKTsKCndpbGwgbmFtZSBtdWx0aXBsZSBkZXZpY2VzIHRoZSBzYW1lIChlLmcu LCAlZC0wMCkuIFRoZSBmaXJzdCBpbnN0YW5jZSB3aWxsCnJlZ2lzdGVyIHN1Y2Nlc3NmdWxseSwg YnV0IHN1YnNlcXVlbnQgb25lcyB3aWxsIGZhaWwgZGV2aWNlX3JlZ2lzdGVyKCkgZHVlIHRvCnN5 c2ZzIG5hbWUgY29sbGlzaW9ucy4gVGhpcyBwZXJmZWN0bHkgdHJpZ2dlcnMgdGhlIGRlc2MtPmRl diB1c2UtYWZ0ZXItZnJlZQpvbiB0aGUgZXJyb3IgcGF0aC4KCj4gIAlpM2NfYnVzX2Zvcl9lYWNo X2kzY2RldigmbWFzdGVyLT5idXMsIGkzY2Rldikgewo+IC0JCWlmIChpM2NkZXYgIT0gcmVmZGV2 ICYmIGkzY2Rldi0+aW5mby5waWQgPT0gcmVmZGV2LT5pbmZvLnBpZCkKPiArCQlpZiAoaTNjZGV2 ICE9IHJlZmRldiAmJiBpM2NkZXYtPmluZm8ucGlkICYmCj4gKwkJICAgIGkzY2Rldi0+aW5mby5w aWQgPT0gcmVmZGV2LT5pbmZvLnBpZCkKCltTZXZlcml0eTogTG93XQpJcyB0aGUgY2hlY2sgZm9y IGkzY2Rldi0+aW5mby5waWQgcmVkdW5kYW50IGhlcmU/CgpTaW5jZSByZWZkZXYtPmluZm8ucGlk IHdhcyBleHBsaWNpdGx5IGNoZWNrZWQgZm9yIGJlaW5nIG5vbi16ZXJvIHJpZ2h0IGJlZm9yZQp0 aGlzIGxvb3AsIHRoZSBlcXVhbGl0eSBjaGVjayBpM2NkZXYtPmluZm8ucGlkID09IHJlZmRldi0+ aW5mby5waWQgYWxyZWFkeQpndWFyYW50ZWVzIHRoYXQgaTNjZGV2LT5pbmZvLnBpZCBpcyBub24t emVyby4gVGhlIGJvb2xlYW4gY2hlY2sgaXNuJ3Qgc3RyaWN0bHkKbmVjZXNzYXJ5LgoKPiAgCQkJ cmV0dXJuIGkzY2RldjsKPiAgCX0KClsgLi4uIF0KCj4gQEAgLTI4MzIsOSArMjg1NSwxNSBAQCBp M2NfbWFzdGVyX2FkZF9pM2NfYm9hcmRpbmZvKHN0cnVjdCBpM2NfbWFzdGVyX2NvbnRyb2xsZXIg Km1hc3RlciwKPiAgCj4gIAlib2FyZGluZm8tPnBpZCA9ICgodTY0KXJlZ1sxXSA8PCAzMikgfCBy ZWdbMl07Cj4gIAo+IC0JaWYgKChib2FyZGluZm8tPnBpZCAmIEdFTk1BU0tfVUxMKDYzLCA0OCkp IHx8Cj4gLQkgICAgSTNDX1BJRF9STkRfTE9XRVJfMzJCSVRTKGJvYXJkaW5mby0+cGlkKSkKPiAt CQlyZXR1cm4gLUVJTlZBTDsKPiArCS8qIEZvciBTRVRBQVNBIGRldmljZXMsIHZhbGlkYXRlIHRo ZSBzdGF0aWMgYWRkcmVzcyBpbnN0ZWFkIG9mIFBJRCAqLwo+ICsJaWYgKGJvYXJkaW5mby0+c3Rh dGljX2FkZHJfbWV0aG9kICYgSTNDX0FERFJfTUVUSE9EX1NFVEFBU0EpIHsKPiArCQlpZiAoIWJv YXJkaW5mby0+c3RhdGljX2FkZHIpCj4gKwkJCXJldHVybiAtRUlOVkFMOwo+ICsJfSBlbHNlIHsK PiArCQlpZiAoKGJvYXJkaW5mby0+cGlkICYgR0VOTUFTS19VTEwoNjMsIDQ4KSkgfHwKPiArCQkg ICAgSTNDX1BJRF9STkRfTE9XRVJfMzJCSVRTKGJvYXJkaW5mby0+cGlkKSkKPiArCQkJcmV0dXJu IC1FSU5WQUw7Cj4gKwl9CgpbU2V2ZXJpdHk6IE1lZGl1bV0KQ291bGQgdGhpcyBsb2dpYyBpbmNv cnJlY3RseSBhbGxvdyBub24tU0VUQUFTQSBJM0MgZGV2aWNlcyBpbiB0aGUgZGV2aWNlIHRyZWUK dG8gaGF2ZSBhIFBJRCBvZiAwLCBwZXJtYW5lbnRseSBicmVha2luZyBkZXZpY2UgbWF0Y2hpbmcg dXBvbiBIb3QtSm9pbj8KCklmIGEgZGV2aWNlIGlzIGNvbmZpZ3VyZWQgd2l0aCBtaXBpLWkzYy1z dGF0aWMtbWV0aG9kID0gU0VUREFTQSwgaXQgd2lsbCByZWFjaAp0aGlzIGVsc2UgYmxvY2suIElm IGl0cyBQSUQgaXMgMCwgYm90aCBib2FyZGluZm8tPnBpZCAmIEdFTk1BU0tfVUxMKDYzLCA0OCkK YW5kIEkzQ19QSURfUk5EX0xPV0VSXzMyQklUUyhib2FyZGluZm8tPnBpZCkgZXZhbHVhdGUgdG8g MCwgd2hpY2ggYnlwYXNzZXMKdmFsaWRhdGlvbiwgYW5kIHRoZSBkZXZpY2UgcmVnaXN0ZXJzIHdp dGggUElEIDAuCgpJZiB0aGUgZGV2aWNlIGxhdGVyIEhvdC1Kb2lucywgREFBIHdpbGwgcmV0cmll dmUgaXRzIHJlYWwsIG5vbi16ZXJvIFBJRC4gV2hlbgppM2NfbWFzdGVyX2F0dGFjaF9ib2FyZGlu Zm8oKSBydW5zLCBpdCBzZWVzIGkzY2JvYXJkaW5mby0+cGlkID09IDAgYW5kIGZhbGxzCmJhY2sg dG8gbWF0Y2hpbmcgYnkgc3RhdGljX2FkZHIuIEJlY2F1c2Ugc3RhdGljX2FkZHIgaXMgMCBkdXJp bmcgREFBLCBpdApmYWlscyB0byBtYXRjaCBhbmQgdGhlIGRldmljZSBwZXJtYW5lbnRseSBsb3Nl cyBpdHMgRFQgcHJvcGVydGllcy4KCj4gIAo+ICAJYm9hcmRpbmZvLT5pbml0X2R5bl9hZGRyID0g aW5pdF9keW5fYWRkcjsKPiAgCWJvYXJkaW5mby0+Zndub2RlID0gZndub2RlX2hhbmRsZV9nZXQo Zndub2RlKTsKCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMv cGF0Y2hzZXQvMjAyNjA2MjQxMDIxNTMuMTc3MDA3Mi0xLWFraGlscmFqZWV2QG52aWRpYS5jb20/ cGFydD01CgotLSAKbGludXgtaTNjIG1haWxpbmcgbGlzdApsaW51eC1pM2NAbGlzdHMuaW5mcmFk ZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4 LWkzYwo= 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 4B4D524676D; Wed, 24 Jun 2026 10:45:55 +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=1782297956; cv=none; b=SO5L74aJc2j18EFXHbRlS/c7TuuYdxIOdPXVoNSwUkr5gGKn43fZ/4hzGKG4/+0Lfdt5FFNb7T2ELVAxAiEFvPkwGU7MV8tvzu9W3TI0V2r0F2EFs6AWf4Nt15yQaTbdMHvm2siVT+l0OanZGhvOjC6t0DIJdiEqPKYpwzYV1eo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782297956; c=relaxed/simple; bh=vZVfmvw9xB2HuoyqqYJItu4LS2lP2wWNbBJJpDqkOKw=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=PaP/FOkpHlZIW7vXt2/WzyVdKCXyewX0oj0u8vz/HAGRTLOhHnb4LEXK6DXox58Xa66HDXmgj+94OPF3Xm5yr/Us5yGNTQC40F7c+xOcztiGYu7YnT85z28U/+5STuOlF6sFZtfYJzi7PE37m2XIvPMaapWHcWLbMNfV1+FENCE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T9LRnklb; 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="T9LRnklb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98EF71F000E9; Wed, 24 Jun 2026 10:45:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782297954; bh=jKgs/HAdxm66fJBTL5AbFOaCH3Dsrsjs1Xn5W2bk2uc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=T9LRnklbFBzDyZ4eOOjBx+K4b8XigR6393mpFcGCRyqGNm7JOyLOHNXb/E8jAulRl b7zJd4XLYHlAbaS96to9YylCDUztHUZwOyUOT47y6iyaI6ZUBjReM5UjEPW43qGMdI osVrlzzrX+By8WTcI6gTornVcSAPDoceAIJt1zzuhvsy5+y63rrFh66xqaA6nnTNZw KCQ6oQjRiK5ZCAq0H8Q+Li3fJv8vg37alYfn3rJU+yrK/w2TyKY43+t13UmQuiSQ2M j5IRmjzzdL+ZWRekB+ZeAfGxgF5HrVKKOIbe+sabJvgYXuRkekau0ttFNx2ePB3gKp n4silM0x/kElw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v5 05/12] i3c: master: Add support for devices without PID Reply-To: sashiko-reviews@lists.linux.dev To: "Akhil R" Cc: Frank.Li@kernel.org, robh@kernel.org, conor+dt@kernel.org, linux-i3c@lists.infradead.org, devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org In-Reply-To: <20260624102153.1770072-6-akhilrajeev@nvidia.com> References: <20260624102153.1770072-1-akhilrajeev@nvidia.com> <20260624102153.1770072-6-akhilrajeev@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2026 10:45:54 +0000 Message-Id: <20260624104554.98EF71F000E9@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 6 potential issue(= s) to consider: New issues: - [High] Devices returning a PID of 0 during Dynamic Address Assignment (DA= A) bypass duplicate detection, leading to sysfs naming collisions that reli= ably trigger a preexisting Use-After-Free. - [Medium] The driver incorrectly allows non-SETAASA I3C devices to be defi= ned in the device tree with a PID of 0, permanently breaking device matchin= g upon Hot-Join re-attachment. - [Low] The newly added static address matching logic in `i3c_master_attach= _boardinfo()` will never successfully match any device, rendering the `else= ` branch dead code. - [Low] Redundant boolean check for `i3cdev->info.pid` inside the duplicate= search loop. Pre-existing issues: - [High] Dangling pointer in `desc->dev` leads to a Use-After-Free and Doub= le Free if `device_register()` fails. - [High] Calling `device_register()` while holding a read lock on the bus r= wsem can lead to a deadlock if the driver's probe function attempts an I3C = transfer. -- commit 76e7c85069f65f75e5476a13e6f4ab2ae705589f Author: Akhil R i3c: master: Add support for devices without PID Devices using SETAASA for address assignment are not required to have a 48-bit PID according to the I3C specification. Allow such devices to register and use the static address where PID was required. > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > index 3deae8cdae525..bd0dc76c7ba1e 100644 > --- a/drivers/i3c/master.c > +++ b/drivers/i3c/master.c > @@ -1989,8 +1989,17 @@ i3c_master_register_new_i3c_devs(struct i3c_master= _controller *master) > desc->dev->dev.type =3D &i3c_device_type; > desc->dev->dev.bus =3D &i3c_bus_type; > desc->dev->dev.release =3D i3c_device_release; > - dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id, > - desc->info.pid); > + > + /* > + * For devices without PID (e.g., SETAASA devices), use > + * static address for naming instead. > + */ > + if (desc->info.pid) > + dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id, > + desc->info.pid); > + else > + dev_set_name(&desc->dev->dev, "%d-%02x", master->bus.id, > + desc->info.static_addr); > =20 > if (desc->boardinfo) > device_set_node(&desc->dev->dev, [Severity: High] This is a pre-existing issue, but does failing to clear desc->dev when device_register() fails lead to a double free and use-after-free later? Looking at i3c_master_register_new_i3c_devs(): ret =3D device_register(&desc->dev->dev); if (ret) { dev_err(&master->dev, "Failed to add I3C device (err =3D %d)\n", re= t); put_device(&desc->dev->dev); } If device_register() fails, put_device() is called which frees the i3c_devi= ce structure, but desc->dev is left dangling. Later, when the master is unregistered in i3c_master_unregister_i3c_devs(), the loop checks: if (!i3cdev->dev) continue; i3cdev->dev->desc =3D NULL; if (device_is_registered(&i3cdev->dev->dev)) device_unregister(&i3cdev->dev->dev); else put_device(&i3cdev->dev->dev); Since desc->dev is not NULL, this writes to the freed memory and then calls put_device() again, resulting in a use-after-free and double free. [Severity: High] This is also a pre-existing issue, but can calling device_register() while holding a read lock on the bus rwsem lead to a deadlock? In i3c_master_reg_work_fn(): i3c_bus_normaluse_lock(&master->bus); if (!master->shutting_down) i3c_master_register_new_i3c_devs(master); The device_register() call inside i3c_master_register_new_i3c_devs() synchronously triggers the driver's probe function. If the probe attempts an I3C transfer, it calls i3c_device_do_priv_xfers(), which recursively reques= ts the read lock on the bus. If a concurrent thread, such as a Hot Join, requests a write lock between these two read lock attempts, the rwsem blocks the second read lock to prev= ent writer starvation. The writer blocks waiting for the first read lock to be released, which won't happen until device_register() returns, resulting in = an ABBA deadlock. [ ... ] > @@ -2383,8 +2392,18 @@ static void i3c_master_attach_boardinfo(struct i3c= _dev_desc *i3cdev) > struct i3c_dev_boardinfo *i3cboardinfo; > =20 > list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) { > - if (i3cdev->info.pid !=3D i3cboardinfo->pid) > - continue; > + /* > + * For devices without PID (e.g., SETAASA devices), match by > + * static address. For devices with PID, match by PID. > + */ > + if (i3cboardinfo->pid) { > + if (i3cdev->info.pid !=3D i3cboardinfo->pid) > + continue; > + } else { > + if (!i3cboardinfo->static_addr || > + i3cdev->info.static_addr !=3D i3cboardinfo->static_addr) > + continue; > + } [Severity: Low] Will this newly added else block ever successfully match a device? i3c_master_attach_boardinfo() is called from __i3c_master_add_i3c_dev_locked() to handle devices discovered dynamically = via DAA or Hot-Join. For these devices, the hardware does not provide a static address during DAA, so i3cdev->info.static_addr is strictly 0. Because of this, the condition i3cdev->info.static_addr !=3D i3cboardinfo->static_addr will evaluate to 0 !=3D non_zero, which is always true. This causes the loop to unconditionally continue, making this fallback dead code. > =20 > i3cdev->boardinfo =3D i3cboardinfo; > i3cdev->info.static_addr =3D i3cboardinfo->static_addr; > @@ -2398,8 +2417,12 @@ i3c_master_search_i3c_dev_duplicate(struct i3c_dev= _desc *refdev) > struct i3c_master_controller *master =3D i3c_dev_get_master(refdev); > struct i3c_dev_desc *i3cdev; > =20 > + if (!refdev->info.pid) > + return NULL; > + [Severity: High] Does returning NULL when PID is 0 allow devices to bypass duplicate detecti= on and trigger the pre-existing use-after-free bug? If a dynamically discovered device reports a PID of 0, this check unconditionally bypasses duplicate rejection, so the device is repeatedly added. Because static_addr is also 0 for DAA-discovered devices, the new naming fallback in i3c_master_register_new_i3c_devs(): dev_set_name(&desc->dev->dev, "%d-%02x", master->bus.id, desc->info.static_addr); will name multiple devices the same (e.g., %d-00). The first instance will register successfully, but subsequent ones will fail device_register() due = to sysfs name collisions. This perfectly triggers the desc->dev use-after-free on the error path. > i3c_bus_for_each_i3cdev(&master->bus, i3cdev) { > - if (i3cdev !=3D refdev && i3cdev->info.pid =3D=3D refdev->info.pid) > + if (i3cdev !=3D refdev && i3cdev->info.pid && > + i3cdev->info.pid =3D=3D refdev->info.pid) [Severity: Low] Is the check for i3cdev->info.pid redundant here? Since refdev->info.pid was explicitly checked for being non-zero right befo= re this loop, the equality check i3cdev->info.pid =3D=3D refdev->info.pid alre= ady guarantees that i3cdev->info.pid is non-zero. The boolean check isn't stric= tly necessary. > return i3cdev; > } [ ... ] > @@ -2832,9 +2855,15 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_con= troller *master, > =20 > boardinfo->pid =3D ((u64)reg[1] << 32) | reg[2]; > =20 > - if ((boardinfo->pid & GENMASK_ULL(63, 48)) || > - I3C_PID_RND_LOWER_32BITS(boardinfo->pid)) > - return -EINVAL; > + /* For SETAASA devices, validate the static address instead of PID */ > + if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) { > + if (!boardinfo->static_addr) > + return -EINVAL; > + } else { > + if ((boardinfo->pid & GENMASK_ULL(63, 48)) || > + I3C_PID_RND_LOWER_32BITS(boardinfo->pid)) > + return -EINVAL; > + } [Severity: Medium] Could this logic incorrectly allow non-SETAASA I3C devices in the device tr= ee to have a PID of 0, permanently breaking device matching upon Hot-Join? If a device is configured with mipi-i3c-static-method =3D SETDASA, it will = reach this else block. If its PID is 0, both boardinfo->pid & GENMASK_ULL(63, 48) and I3C_PID_RND_LOWER_32BITS(boardinfo->pid) evaluate to 0, which bypasses validation, and the device registers with PID 0. If the device later Hot-Joins, DAA will retrieve its real, non-zero PID. Wh= en i3c_master_attach_boardinfo() runs, it sees i3cboardinfo->pid =3D=3D 0 and = falls back to matching by static_addr. Because static_addr is 0 during DAA, it fails to match and the device permanently loses its DT properties. > =20 > boardinfo->init_dyn_addr =3D init_dyn_addr; > boardinfo->fwnode =3D fwnode_handle_get(fwnode); --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260624102153.1770= 072-1-akhilrajeev@nvidia.com?part=3D5