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 99F32C4451C for ; Tue, 21 Jul 2026 04:31:00 +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=1gaoXPMATFqm0/LdHsinjPtuJmqwy9UqecsEPZLMU34=; b=1lNjfSKf9c1eeB NOSOy86iiPrbsyW594wvTv/NqTxlZfjFAyyCw3/SkMC0vzxwUaoPLbQMfLSqCN3njLzqHHNZeK/DV Ac5C7ZF6A00hKwFDK0+s3avbhpcqij+5RsUfjuvR38b8mA+fgLZ0N1hr7luoNqM0nz9p9cagGOUry iT1m7je1Lkb/fnnb4nRMOZF1D3hBjp2ETb2U8Hac0/0lmV2UR4rPaZE8hKNDOtjZjVMNoP3eckMQ7 Z/up10buRConPq8IFtLEakOgfgd2vkwU8GH+YUYXs3o5RHfAw+Zb9rLONvmdi6noZXAcF6R4tdiH8 sZQAjHsqCphbPAo33RPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wm28C-00000008NyB-1HQG; Tue, 21 Jul 2026 04:31:00 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wm28B-00000008Ny0-2uFH for linux-i3c@lists.infradead.org; Tue, 21 Jul 2026 04:30:59 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4D8714133D; Tue, 21 Jul 2026 04:30:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C02B31F000E9; Tue, 21 Jul 2026 04:30:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784608259; bh=kKu168ryXHB8z85GQdd/fahJPbMe/kfeBgo7Pl6WDNc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=QfNJfbkC/azEzN8JUVO4bVy2qPL1et/LQJiCbpvyWT101z+TxxYqLkJ4uMzip/Pvx 2PTMvJ5fTz7UYCHYLDg/t8g9wLAzHd1OVOUMMuCKnIJJIk+xQQgk2qRu6+FlU2nYVq o69it+D95NtX7O4W95dSI9XLxc0WwYSqOfcvpL7GjOfyGGEz042+vOICoTM5QD1Vji S8cMLShJjSw/pO+JlKCPwnZ9mkbBRkW51HHD8+oIIQLCTTJFX53gndWTe7+jnxw7W2 ODfdvpwXYwGwn+TGtxxyZJx3dHVLju947RAEA8vkhqVdbQgCBwAI/TQoePJcIIY1P1 YPylh5vDE2CAg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v6 04/12] i3c: master: Add support for devices using SETAASA To: "Akhil R" Cc: linux-hwmon@vger.kernel.org, Frank.Li@kernel.org, "Alexandre Belloni" , conor+dt@kernel.org, linux-i3c@lists.infradead.org, devicetree@vger.kernel.org, robh@kernel.org In-Reply-To: <20260721040805.1696503-5-akhilrajeev@nvidia.com> References: <20260721040805.1696503-1-akhilrajeev@nvidia.com> <20260721040805.1696503-5-akhilrajeev@nvidia.com> Date: Tue, 21 Jul 2026 04:30:58 +0000 Message-Id: <20260721043058.C02B31F000E9@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBT dGF0ZSBpbmNvbnNpc3RlbmN5IG9uIGVycm9yIHBhdGg6IGEgU0VUQUFTQSBkZXZpY2UgZmFpbGlu ZyBzb2Z0d2FyZSBhdHRhY2htZW50IHdpbGwgc3RpbGwgY2xhaW0gaXRzIHN0YXRpYyBhZGRyZXNz IHdoZW4gdGhlIFNFVEFBU0EgYnJvYWRjYXN0IGlzIHNlbnQsIGxlYWRpbmcgdG8gYW4gYWRkcmVz cyBjb2xsaXNpb24uCi0gW0hpZ2hdIE11bHRpcGxlIFNFVEFBU0EgZGV2aWNlcyB3aXRob3V0IHNw ZWNpZmllZCBQSURzIHdpbGwgY2F1c2UgYSBrb2JqZWN0IG5hbWUgY29sbGlzaW9uIGR1cmluZyBg ZGV2aWNlX3JlZ2lzdGVyKClgLCBwcmV2ZW50aW5nIHJlZ2lzdHJhdGlvbiBvZiBzdWJzZXF1ZW50 IGRldmljZXMuCi0gW0hpZ2hdIFRoZSBuZXdseSBpbnRyb2R1Y2VkIFNFVEFBU0EgYW5kIFNFVEhJ RCAodmVuZG9yKSBDQ0MgY29tbWFuZHMgYXJlIG5vdCB3aGl0ZWxpc3RlZCBpbiB0aGUgbWFqb3Jp dHkgb2YgSTNDIG1hc3RlciBjb250cm9sbGVyIGRyaXZlcnMsIGNhdXNpbmcgdGhlIGVudGlyZSBi dXMgaW5pdGlhbGl6YXRpb24gdG8gZmFpbC4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0gW0hpZ2hd IFByZWV4aXN0aW5nIFNFVERBU0EgSGFyZHdhcmUvU29mdHdhcmUgc3RhdGUgbWlzbWF0Y2ggb24g ZmFpbHVyZSBkdWUgdG8gcHJlbWF0dXJlIHNsb3QgZnJlZWluZyBiZWZvcmUgaGFyZHdhcmUgcmVz ZXQuCi0tCgotLS0gUGF0Y2ggWzRdOiBbUEFUQ0ggdjYgMDQvMTJdIGkzYzogbWFzdGVyOiBBZGQg c3VwcG9ydCBmb3IgZGV2aWNlcyB1c2luZyBTRVRBQVNBIC0tLQpjb21taXQgZTE1OGI1NzZhOWY3 MzM2OTVkODY4ZWUxNmYzNGJhY2RiNDMyODViMwpBdXRob3I6IEFraGlsIFIgPGFraGlscmFqZWV2 QG52aWRpYS5jb20+CgppM2M6IG1hc3RlcjogQWRkIHN1cHBvcnQgZm9yIGRldmljZXMgdXNpbmcg U0VUQUFTQQoKVGhpcyBjb21taXQgYWRkcyBzdXBwb3J0IGZvciBkaXNjb3ZlcmluZyBJM0MgZGV2 aWNlcyB1c2luZyB0aGUgU0VUQUFTQQpwcm9jZWR1cmUsIHN1Y2ggYXMgU1BENTExOCBhbmQgU1BE NTEwOCBhdHRhY2hlZCB0byBERFI1IG1lbW9yeSBtb2R1bGVzLiBJdAphZGRzIHRoZSBTRVRBQVNB IGFuZCBTRVRISUQgQ0NDIGNvbW1hbmRzIGFuZCB1cGRhdGVzIHRoZSBkaXNjb3ZlcnkgbG9naWMu CgpMaW5rOiBodHRwczovL3d3dy5taXBpLm9yZy9taXBpLWRpc2NvLWZvci1pM2MtZG93bmxvYWQK Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL21hc3Rlci5jIGIvZHJpdmVycy9pM2MvbWFzdGVy LmMKPiBpbmRleCA2MjNjNmIyMjQ3ZDlmLi5iMThkZGE4OWM0NzM3IDEwMDY0NAo+IC0tLSBhL2Ry aXZlcnMvaTNjL21hc3Rlci5jCj4gKysrIGIvZHJpdmVycy9pM2MvbWFzdGVyLmMKClsgLi4uIF0K Cj4gQEAgLTExMDIsNiArMTEwMyw1MSBAQCBzdGF0aWMgaW50IGkzY19tYXN0ZXJfcnN0ZGFhX2xv Y2tlZChzdHJ1Y3QgaTNjX21hc3Rlcl9jb250cm9sbGVyICptYXN0ZXIsCj4gIAlyZXR1cm4gcmV0 Owo+ICB9Cj4gIAo+ICsvKioKPiArICogaTNjX21hc3Rlcl9zZXRhYXNhX2xvY2tlZCgpIC0gc3Rh cnQgYSBTRVRBQVNBIHByb2NlZHVyZSAoU2V0IEFsbCBBZGRyZXNzZXMgdG8gU3RhdGljIEFkZHJl c3MpCgpbIC4uLiBdCgo+ICtzdGF0aWMgaW50IGkzY19tYXN0ZXJfc2V0YWFzYV9sb2NrZWQoc3Ry dWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciAqbWFzdGVyKQo+ICt7Cj4gKwlzdHJ1Y3QgaTNjX2Nj Y19jbWRfZGVzdCBkZXN0Owo+ICsJc3RydWN0IGkzY19jY2NfY21kIGNtZDsKPiArCWludCByZXQ7 Cj4gKwo+ICsJLyoKPiArCSAqIFNlbmQgU0VUSElEIENDQyBjb21tYW5kLiBUaG91Z2ggaXQgaXMg YSBzdGFuZGFyZCBDQ0MgY29tbWFuZCBzcGVjaWZpZWQKPiArCSAqIGluIEpFU0QzMDAtNSwgd2Ug YXJlIG5vdCBkZWZpbmluZyBhIHNlcGFyYXRlIG1hY3JvIHRvIGJlIGV4cGxpY2l0IHRoYXQKPiAr CSAqIHRoZSB2YWx1ZSBmYWxscyB1bmRlciB0aGUgdmVuZG9yIHNwZWNpZmljIHJhbmdlLgo+ICsJ ICovCj4gKwlpM2NfY2NjX2NtZF9kZXN0X2luaXQoJmRlc3QsIEkzQ19CUk9BRENBU1RfQUREUiwg MCk7Cj4gKwlpM2NfY2NjX2NtZF9pbml0KCZjbWQsIGZhbHNlLCBJM0NfQ0NDX1ZFTkRPUigwLCB0 cnVlKSwgJmRlc3QsIDEpOwo+ICsJcmV0ID0gaTNjX21hc3Rlcl9zZW5kX2NjY19jbWRfbG9ja2Vk KG1hc3RlciwgJmNtZCk7CgpbU2V2ZXJpdHk6IEhpZ2hdCldpbGwgdGhpcyBmYWlsIG9uIG1vc3Qg ZXhpc3RpbmcgSTNDIG1hc3RlciBjb250cm9sbGVycz8KCkxvb2tpbmcgYXQgaTNjX21hc3Rlcl9z ZW5kX2NjY19jbWRfbG9ja2VkKCksIGl0IGNhbGxzCm1hc3Rlci0+b3BzLT5zdXBwb3J0c19jY2Nf Y21kKCkgYmVmb3JlIHNlbmRpbmcuIE1hbnkgY29yZSBjb250cm9sbGVyIGRyaXZlcnMKKGxpa2Ug ZHctaTNjLW1hc3Rlci5jKSBoYXZlIHN0cmljdCBzd2l0Y2gtc3RhdGVtZW50IHdoaXRlbGlzdHMg Zm9yIHN1cHBvcnRlZApDQ0MgSURzIHRoYXQgZG8gbm90IGluY2x1ZGUgdGhlc2UgbmV3IFNFVEFB U0EgKDB4MjkpIGFuZCBTRVRISUQgKDB4NjEpCmNvbW1hbmRzLgoKV291bGQgdGhpcyByZXN1bHQg aW4gcmV0dXJuaW5nIC1FT1BOT1RTVVBQIGFuZCBhYm9ydGluZyB0aGUgZW50aXJlIGJ1cwppbml0 aWFsaXphdGlvbiBvbiBzeXN0ZW1zIHdpdGggdGhlc2UgY29udHJvbGxlcnM/Cgo+ICsJaTNjX2Nj Y19jbWRfZGVzdF9jbGVhbnVwKCZkZXN0KTsKPiArCWlmIChyZXQgJiYgY21kLmVyciA9PSBJM0Nf RVJST1JfTTIpCj4gKwkJcmV0ID0gMDsKPiArCWlmIChyZXQpCj4gKwkJcmV0dXJuIHJldDsKClsg Li4uIF0KCj4gQEAgLTE4NzgsNiArMTkyNCwyMiBAQCBzdGF0aWMgaW50IGkzY19tYXN0ZXJfZWFy bHlfaTNjX2Rldl9hZGQoc3RydWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciAqbWFzdGVyLAo+ICAJ aWYgKHJldCkKPiAgCQlnb3RvIGVycl9mcmVlX2RldjsKPiAgCj4gKwkvKgo+ICsJICogRm9yIGRl dmljZXMgdXNpbmcgU0VUQUFTQSBpbnN0ZWFkIG9mIEVOVERBQSwgdGhlIGFkZHJlc3MgaXMgc3Rh dGljYWxseQo+ICsJICogYXNzaWduZWQuIFVwZGF0ZSB0aGUgZHluYW1pYyBhZGRyZXNzIHRvIHRo ZSBwcm92aWRlZCBzdGF0aWMgYWRkcmVzcy4KPiArCSAqIFJlYXR0YWNoIHRoZSBJM0MgZGV2aWNl IGFmdGVyIHVwZGF0aW5nIHRoZSBkeW5hbWljIGFkZHJlc3Mgd2l0aCB0aGUgc2FtZQo+ICsJICog c3RhdGljIGFkZHJlc3MuIEl0IGlzIG5vdCBtYW5kYXRvcnkgZm9yIHN1Y2ggZGV2aWNlcyB0byBp bXBsZW1lbnQgQ0NDCj4gKwkgKiBjb21tYW5kcyBsaWtlIEdFVFBJRCwgR0VURENSIGV0Yy4gSGVu Y2UsIHdlIGNhbiByZXR1cm4gYWZ0ZXIgcmVhdHRhY2hpbmcuCj4gKwkgKi8KPiArCWlmIChpM2Nk ZXYtPmJvYXJkaW5mby0+c3RhdGljX2FkZHJfbWV0aG9kICYgSTNDX0FERFJfTUVUSE9EX1NFVEFB U0EpIHsKPiArCQlpM2NkZXYtPmluZm8uZHluX2FkZHIgPSBpM2NkZXYtPmJvYXJkaW5mby0+c3Rh dGljX2FkZHI7Cj4gKwkJcmV0ID0gaTNjX21hc3Rlcl9yZWF0dGFjaF9pM2NfZGV2X2xvY2tlZChp M2NkZXYsIDApOwo+ICsJCWlmIChyZXQpCj4gKwkJCWdvdG8gZXJyX3JzdGRhYTsKCltTZXZlcml0 eTogSGlnaF0KSWYgaTNjX21hc3Rlcl9yZWF0dGFjaF9pM2NfZGV2X2xvY2tlZCgpIGZhaWxzIGhl cmUsIHdlIGp1bXAgdG8gZXJyX3JzdGRhYQphbmQgZXZlbnR1YWxseSBmcmVlIHRoZSBkZXZpY2Ug c3RydWN0dXJlLiBIb3dldmVyLCBpM2NfbWFzdGVyX2J1c19pbml0KCkKbGF0ZXIgdW5jb25kaXRp b25hbGx5IGJyb2FkY2FzdHMgU0VUQUFTQSB0byB0aGUgYnVzLgoKV29uJ3QgdGhlIHBoeXNpY2Fs IGRldmljZSBjbGFpbSB0aGlzIHN0YXRpYyBhZGRyZXNzIGR1cmluZyB0aGUgYnJvYWRjYXN0LApl dmVuIHRob3VnaCB0aGUgY29udHJvbGxlciBzb2Z0d2FyZSBubyBsb25nZXIgdHJhY2tzIGl0PyBU aGlzIGNvdWxkIGxlYWQgdG8KYSBidXMgY29sbGlzaW9uIHdoZW4gdGhlIHNvZnR3YXJlIGxhdGVy IHRyaWVzIHRvIGR5bmFtaWNhbGx5IGFzc2lnbiB0aGlzCiJmcmVlIiBhZGRyZXNzIHNsb3QgdG8g YSBkaWZmZXJlbnQgZGV2aWNlLgoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0 aW5nIGlzc3VlLCBidXQgZG9lcyBqdW1waW5nIHRvIGVycl9yc3RkYWEgY29ycmVjdGx5IHJlc2V0 CnRoZSBoYXJkd2FyZSBpZiByZWF0dGFjaG1lbnQgZmFpbHMgZHVyaW5nIFNFVERBU0Egb3IgU0VU QUFTQT8KCklmIGkzY19tYXN0ZXJfcmVhdHRhY2hfaTNjX2Rldl9sb2NrZWQoKSBmYWlscywgaXRz IGludGVybmFsIGVycm9yIHBhdGggY2FsbHMKaTNjX21hc3Rlcl9wdXRfaTNjX2FkZHJzKCksIHdo aWNoIG1hcmtzIHRoZSBzbG90IGFzIEkzQ19BRERSX1NMT1RfRlJFRS4KCldoZW4gd2UgcmVhY2gg dGhlIGVycl9yc3RkYWEgcGF0aDoKCmVycl9yc3RkYWE6CiAgICBpM2NfbWFzdGVyX3JzdGRhYV9s b2NrZWQobWFzdGVyLCBpM2NkZXYtPmJvYXJkaW5mby0+aW5pdF9keW5fYWRkcik7CgppM2NfbWFz dGVyX3JzdGRhYV9sb2NrZWQoKSBjaGVja3MgaTNjX2J1c19nZXRfYWRkcl9zbG90X3N0YXR1cygp LiBCZWNhdXNlIHRoZQpzbG90IGlzIGFscmVhZHkgbWFya2VkIEZSRUUsIGl0IHJldHVybnMgLUVJ TlZBTCBhbmQgc2lsZW50bHkgYWJvcnRzIHdpdGhvdXQKc2VuZGluZyB0aGUgUlNUREFBIGNvbW1h bmQgdG8gdGhlIGhhcmR3YXJlLgoKRG9lcyB0aGlzIGxlYXZlIHRoZSBwaHlzaWNhbCBkZXZpY2Ug aG9sZGluZyB0aGUgYWRkcmVzcyB3aGlsZSB0aGUgc29mdHdhcmUKY29uc2lkZXJzIGl0IGZyZWU/ Cgo+ICsKPiArCQlyZXR1cm4gMDsKPiArCX0KPiArCj4gIAlyZXQgPSBpM2NfbWFzdGVyX3NldGRh c2FfbG9ja2VkKG1hc3RlciwgaTNjZGV2LT5pbmZvLnN0YXRpY19hZGRyLAo+ICAJCQkJCWkzY2Rl di0+Ym9hcmRpbmZvLT5pbml0X2R5bl9hZGRyKTsKClsgLi4uIF0KCj4gQEAgLTI3NDEsNyArMjgx NiwxOSBAQCBpM2NfbWFzdGVyX2FkZF9pM2NfYm9hcmRpbmZvKHN0cnVjdCBpM2NfbWFzdGVyX2Nv bnRyb2xsZXIgKm1hc3RlciwKPiAgCj4gIAlib2FyZGluZm8tPnN0YXRpY19hZGRyID0gcmVnWzBd Owo+ICAKPiArCWlmICghZndub2RlX3Byb3BlcnR5X3JlYWRfdTMyKGZ3bm9kZSwgIm1pcGktaTNj LXN0YXRpYy1tZXRob2QiLCAmc3RhdGljX2FkZHJfbWV0aG9kKSkKPiArCQlib2FyZGluZm8tPnN0 YXRpY19hZGRyX21ldGhvZCA9IHN0YXRpY19hZGRyX21ldGhvZCAmCj4gKwkJCQkJKEkzQ19BRERS X01FVEhPRF9TRVREQVNBIHwgSTNDX0FERFJfTUVUSE9EX1NFVEFBU0EpOwo+ICsKClsgLi4uIF0K Cj4gKwlpZiAoYm9hcmRpbmZvLT5zdGF0aWNfYWRkcl9tZXRob2QgJiBJM0NfQUREUl9NRVRIT0Rf U0VUQUFTQSkgewo+ICsJCS8qIEZvciBTRVRBQVNBLCBzdGF0aWMgYWRkcmVzcyBpcyB0YWtlbiBh cyB0aGUgZHluYW1pYyBhZGRyZXNzLiAqLwo+ICsJCWluaXRfZHluX2FkZHIgPSBib2FyZGluZm8t PnN0YXRpY19hZGRyOwo+ICsJfQo+ICsKPiArCS8qIFVwZGF0ZSB0aGUgYWRkcmVzcyBtZXRob2Rz IHJlcXVpcmVkIGZvciBkZXZpY2UgZGlzY292ZXJ5ICovCj4gKwltYXN0ZXItPmFkZHJfbWV0aG9k IHw9IGJvYXJkaW5mby0+c3RhdGljX2FkZHJfbWV0aG9kOwo+ICsKPiAgCWJvYXJkaW5mby0+cGlk ID0gKCh1NjQpcmVnWzFdIDw8IDMyKSB8IHJlZ1syXTsKPiAgCj4gIAlpZiAoKGJvYXJkaW5mby0+ cGlkICYgR0VOTUFTS19VTEwoNjMsIDQ4KSkgfHwKCltTZXZlcml0eTogSGlnaF0KQnkgcmVsYXhp bmcgdGhlIFBJRCB2YWxpZGF0aW9uIGZvciBTRVRBQVNBIGRldmljZXMgaW4gdGhpcyBmdW5jdGlv biwgcGlkIGNhbgpkZWZhdWx0IHRvIDAuIElmIGEgc3lzdGVtIGNvbmZpZ3VyZXMgbXVsdGlwbGUg U0VUQUFTQSBkZXZpY2VzIChsaWtlIEREUjUKU1BEcykgd2l0aG91dCBQSURzLCB3aWxsIHRoaXMg Y2F1c2UgYSBrb2JqZWN0IG5hbWUgY29sbGlzaW9uPwoKRHVyaW5nIHJlZ2lzdHJhdGlvbiwgaTNj X21hc3Rlcl9yZWdpc3Rlcl9uZXdfaTNjX2RldnMoKSBuYW1lcyB0aGUgZGV2aWNlCnVzaW5nIGl0 cyBidXMgSUQgYW5kIFBJRDoKCmRldl9zZXRfbmFtZSgmZGVzYy0+ZGV2LT5kZXYsICIlZC0lbGx4 IiwgbWFzdGVyLT5idXMuaWQsIGRlc2MtPmluZm8ucGlkKTsKCklmIG11bHRpcGxlIGRldmljZXMg aGF2ZSBwaWQ9MCwgdGhleSB3b3VsZCBhbGwgYmUgbmFtZWQgIjAtMCIsIGNhdXNpbmcKZGV2aWNl X3JlZ2lzdGVyKCkgdG8gZmFpbCB3aXRoIC1FRVhJU1QgZm9yIHN1YnNlcXVlbnQgZGV2aWNlcyBh bmQgcHJldmVudGluZwp0aGVtIGZyb20gZnVuY3Rpb25pbmcuCgotLSAKU2FzaGlrbyBBSSByZXZp ZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzIxMDQwODA1LjE2OTY1 MDMtMS1ha2hpbHJhamVldkBudmlkaWEuY29tP3BhcnQ9NAoKLS0gCmxpbnV4LWkzYyBtYWlsaW5n IGxpc3QKbGludXgtaTNjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVh ZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1pM2MK 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 8DD73DF6C; Tue, 21 Jul 2026 04:30:59 +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=1784608260; cv=none; b=lQW8jdm9PxXW2K+uSE58WK6rD5tsFWANudr9MmOxRYmZMg75ufr5hfX3DhLe1kuqfdrshm1dUg463hiH8kOufPW0wHZ8kGy8IkHRxPItX26EABzM/RwUihxgNva30Q9WF/iZLpMxNbmzkeDwd6f+rSAP7zcRqFaEOzPwryonFdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784608260; c=relaxed/simple; bh=hIi3miAZPOeJPN3RBTLw2GYm2gcHxs8PeQI0kLvI+zI=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=YW2FXqY9DIhBZUG2vma5e69tcfTqlSMBG5AgxY7eiW+ZoclbSwLyJ6HzFMnHmPGDerpEs7zR6+6sLks2TnahKoVi6wwuCuLkx9O24wKYBECkYuyGWhx3vFxr29l3v8ZE8qwe50X505cMNX5GyXuOMVlmcfDlIKMuS3yuvUyE+hs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QfNJfbkC; 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="QfNJfbkC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C02B31F000E9; Tue, 21 Jul 2026 04:30:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784608259; bh=kKu168ryXHB8z85GQdd/fahJPbMe/kfeBgo7Pl6WDNc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=QfNJfbkC/azEzN8JUVO4bVy2qPL1et/LQJiCbpvyWT101z+TxxYqLkJ4uMzip/Pvx 2PTMvJ5fTz7UYCHYLDg/t8g9wLAzHd1OVOUMMuCKnIJJIk+xQQgk2qRu6+FlU2nYVq o69it+D95NtX7O4W95dSI9XLxc0WwYSqOfcvpL7GjOfyGGEz042+vOICoTM5QD1Vji S8cMLShJjSw/pO+JlKCPwnZ9mkbBRkW51HHD8+oIIQLCTTJFX53gndWTe7+jnxw7W2 ODfdvpwXYwGwn+TGtxxyZJx3dHVLju947RAEA8vkhqVdbQgCBwAI/TQoePJcIIY1P1 YPylh5vDE2CAg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v6 04/12] i3c: master: Add support for devices using SETAASA Reply-To: sashiko-reviews@lists.linux.dev To: "Akhil R" Cc: linux-hwmon@vger.kernel.org, Frank.Li@kernel.org, "Alexandre Belloni" , conor+dt@kernel.org, linux-i3c@lists.infradead.org, devicetree@vger.kernel.org, robh@kernel.org In-Reply-To: <20260721040805.1696503-5-akhilrajeev@nvidia.com> References: <20260721040805.1696503-1-akhilrajeev@nvidia.com> <20260721040805.1696503-5-akhilrajeev@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2026 04:30:58 +0000 Message-Id: <20260721043058.C02B31F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-hwmon@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: New issues: - [High] State inconsistency on error path: a SETAASA device failing softwa= re attachment will still claim its static address when the SETAASA broadcas= t is sent, leading to an address collision. - [High] Multiple SETAASA devices without specified PIDs will cause a kobje= ct name collision during `device_register()`, preventing registration of su= bsequent devices. - [High] The newly introduced SETAASA and SETHID (vendor) CCC commands are = not whitelisted in the majority of I3C master controller drivers, causing t= he entire bus initialization to fail. Pre-existing issues: - [High] Preexisting SETDASA Hardware/Software state mismatch on failure du= e to premature slot freeing before hardware reset. -- --- Patch [4]: [PATCH v6 04/12] i3c: master: Add support for devices using = SETAASA --- commit e158b576a9f733695d868ee16f34bacdb43285b3 Author: Akhil R i3c: master: Add support for devices using SETAASA This commit adds support for discovering I3C devices using the SETAASA procedure, such as SPD5118 and SPD5108 attached to DDR5 memory modules. It adds the SETAASA and SETHID CCC commands and updates the discovery logic. Link: https://www.mipi.org/mipi-disco-for-i3c-download > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > index 623c6b2247d9f..b18dda89c4737 100644 > --- a/drivers/i3c/master.c > +++ b/drivers/i3c/master.c [ ... ] > @@ -1102,6 +1103,51 @@ static int i3c_master_rstdaa_locked(struct i3c_mas= ter_controller *master, > return ret; > } > =20 > +/** > + * i3c_master_setaasa_locked() - start a SETAASA procedure (Set All Addr= esses to Static Address) [ ... ] > +static int i3c_master_setaasa_locked(struct i3c_master_controller *maste= r) > +{ > + struct i3c_ccc_cmd_dest dest; > + struct i3c_ccc_cmd cmd; > + int ret; > + > + /* > + * Send SETHID CCC command. Though it is a standard CCC command specifi= ed > + * in JESD300-5, we are not defining a separate macro to be explicit th= at > + * the value falls under the vendor specific range. > + */ > + i3c_ccc_cmd_dest_init(&dest, I3C_BROADCAST_ADDR, 0); > + i3c_ccc_cmd_init(&cmd, false, I3C_CCC_VENDOR(0, true), &dest, 1); > + ret =3D i3c_master_send_ccc_cmd_locked(master, &cmd); [Severity: High] Will this fail on most existing I3C master controllers? Looking at i3c_master_send_ccc_cmd_locked(), it calls master->ops->supports_ccc_cmd() before sending. Many core controller drivers (like dw-i3c-master.c) have strict switch-statement whitelists for supported CCC IDs that do not include these new SETAASA (0x29) and SETHID (0x61) commands. Would this result in returning -EOPNOTSUPP and aborting the entire bus initialization on systems with these controllers? > + i3c_ccc_cmd_dest_cleanup(&dest); > + if (ret && cmd.err =3D=3D I3C_ERROR_M2) > + ret =3D 0; > + if (ret) > + return ret; [ ... ] > @@ -1878,6 +1924,22 @@ static int i3c_master_early_i3c_dev_add(struct i3c= _master_controller *master, > if (ret) > goto err_free_dev; > =20 > + /* > + * For devices using SETAASA instead of ENTDAA, the address is statical= ly > + * assigned. Update the dynamic address to the provided static address. > + * Reattach the I3C device after updating the dynamic address with the = same > + * static address. It is not mandatory for such devices to implement CCC > + * commands like GETPID, GETDCR etc. Hence, we can return after reattac= hing. > + */ > + if (i3cdev->boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) { > + i3cdev->info.dyn_addr =3D i3cdev->boardinfo->static_addr; > + ret =3D i3c_master_reattach_i3c_dev_locked(i3cdev, 0); > + if (ret) > + goto err_rstdaa; [Severity: High] If i3c_master_reattach_i3c_dev_locked() fails here, we jump to err_rstdaa and eventually free the device structure. However, i3c_master_bus_init() later unconditionally broadcasts SETAASA to the bus. Won't the physical device claim this static address during the broadcast, even though the controller software no longer tracks it? This could lead to a bus collision when the software later tries to dynamically assign this "free" address slot to a different device. [Severity: High] This is a pre-existing issue, but does jumping to err_rstdaa correctly reset the hardware if reattachment fails during SETDASA or SETAASA? If i3c_master_reattach_i3c_dev_locked() fails, its internal error path calls i3c_master_put_i3c_addrs(), which marks the slot as I3C_ADDR_SLOT_FREE. When we reach the err_rstdaa path: err_rstdaa: i3c_master_rstdaa_locked(master, i3cdev->boardinfo->init_dyn_addr); i3c_master_rstdaa_locked() checks i3c_bus_get_addr_slot_status(). Because t= he slot is already marked FREE, it returns -EINVAL and silently aborts without sending the RSTDAA command to the hardware. Does this leave the physical device holding the address while the software considers it free? > + > + return 0; > + } > + > ret =3D i3c_master_setdasa_locked(master, i3cdev->info.static_addr, > i3cdev->boardinfo->init_dyn_addr); [ ... ] > @@ -2741,7 +2816,19 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_con= troller *master, > =20 > boardinfo->static_addr =3D reg[0]; > =20 > + if (!fwnode_property_read_u32(fwnode, "mipi-i3c-static-method", &static= _addr_method)) > + boardinfo->static_addr_method =3D static_addr_method & > + (I3C_ADDR_METHOD_SETDASA | I3C_ADDR_METHOD_SETAASA); > + [ ... ] > + if (boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) { > + /* For SETAASA, static address is taken as the dynamic address. */ > + init_dyn_addr =3D boardinfo->static_addr; > + } > + > + /* Update the address methods required for device discovery */ > + master->addr_method |=3D boardinfo->static_addr_method; > + > boardinfo->pid =3D ((u64)reg[1] << 32) | reg[2]; > =20 > if ((boardinfo->pid & GENMASK_ULL(63, 48)) || [Severity: High] By relaxing the PID validation for SETAASA devices in this function, pid can default to 0. If a system configures multiple SETAASA devices (like DDR5 SPDs) without PIDs, will this cause a kobject name collision? During registration, i3c_master_register_new_i3c_devs() names the device using its bus ID and PID: dev_set_name(&desc->dev->dev, "%d-%llx", master->bus.id, desc->info.pid); If multiple devices have pid=3D0, they would all be named "0-0", causing device_register() to fail with -EEXIST for subsequent devices and preventing them from functioning. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260721040805.1696= 503-1-akhilrajeev@nvidia.com?part=3D4