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 CA4CAC61DD3 for ; Tue, 1 Sep 2026 11:52:48 +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=qKi7OCIKW1FMxAScvY+ybuzomu85znIF0Lw4JmCbDdI=; b=iL7BjiM6UGgLx2 VNoNRFP0TZSByTTppo1KUogNUeqqHsRbu3DaOyndA6DMsXw7SLm9wTcN+ND5KSI+yztv5gAZNfiy8 8D/scNsKe5hOhvK6pc7FRBka/nKEnyxsfX2F2o59lX6cexDmNfJ6Rv6CaYJG8As8FQD60sFQfsuKI NH7w4YfdA/kMemz7azbbHu5/yX1TMRFF7nEHJp+mFd3NLPBhu17Ot6IK3mLTen+kiw3Fe0BIjQTeX 4eUcsuxJ91Gx6MLdQyW3OYw5jwKumbhtt1giGccDgkOVmgWa14MmO/54UBxPoujUvUNh1KuEnxxzP SFW2uPdA8nf/yP8WifFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x1N2m-0000000Bjzj-2CFX; Tue, 01 Sep 2026 11:52:48 +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 1x1N2l-0000000BjzU-0OeU for linux-i3c@lists.infradead.org; Tue, 01 Sep 2026 11:52:47 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 31D904043C; Tue, 1 Sep 2026 11:52:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56E541F000E9; Tue, 1 Sep 2026 11:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788263563; bh=REoHQB91oLFxxMMmQctDUsa+I1bBQ31czHVyRU20WvQ=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=avoeYrWe8PQrB5YvMrRnqonB7Z0ZPBFsDapC0hfjKV2iW0dJ9I3MpND19EoZkNxLv OVqDfWrMxchgpZpGuu/h6FMgrQOwIAIywDCjm2X2ATYZ/jpsH/g+k/xlDvIzYcOsMh t56HaeVni2Hw2HKaB4gwnlF+mdx+vY/9Q7HI/bB2kTkmF8pu1Q/zgxnKYwFU3rCWGn 7CbZy5qmy/WS6ca94mLQI/opLcqCr7V/a6y5oOSCIuGi7VFqlia2Mx3qAGZ3t3aanE +/z+wJ56IeDJmd3ezaTYkIMOcnA4OK7p941kXpjEYiKqbz9sm8I27b+k2G32QBcjmB dppdnSbxyIIPg== From: sashiko-bot@kernel.org Subject: Re: [PATCH 5/8] i3c: mipi-i3c-hci: Add support for the AST2700 I3C controller To: "Billy Tsai" Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org, linux-i3c@lists.infradead.org, "Alexandre Belloni" , Frank.Li@kernel.org In-Reply-To: <20260901-b4-i3c-hci-ast2700-v1-5-19909e7cbd7e@aspeedtech.com> References: <20260901-b4-i3c-hci-ast2700-v1-0-19909e7cbd7e@aspeedtech.com> <20260901-b4-i3c-hci-ast2700-v1-5-19909e7cbd7e@aspeedtech.com> Date: Tue, 01 Sep 2026 11:52:42 +0000 Message-Id: <20260901115243.56E541F000E9@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 MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIEtlcm5lbCBjcmFzaCBk dWUgdG8gdW5jaGVja2VkIHZlbmRvciByZWdpc3RlciBhY2Nlc3MgaWYgdGhlIGhhcmR3YXJlIGxh Y2tzIHRoZSBBU1BFRUQgZXh0ZW5kZWQgY2FwYWJpbGl0eS4KLSBbSGlnaF0gSW5jb21wbGV0ZSBj bGVhcmluZyBvZiBwcmV2aW91cyBEQUEgaW5kZXggYWNyb3NzIHJlZ2lzdGVycyBsZWF2ZXMgc3Rh bGUgYml0cyBzZXQuCi0gW0xvd10gQ29udHJhZGljdG9yeSB1c2Ugb2Ygb3B0aW9uYWwgY2xvY2sg QVBJIGxlYWRzIHRvIG1pc2xlYWRpbmcgcHJvYmUgZmFpbHVyZXMuCi0tCgpjb21taXQgM2Q0ZTU0 YjJlZTZmMDViYmYxOGNlNGZjNzViODgxYzFkMzMzMDQ4NwpBdXRob3I6IEJpbGx5IFRzYWkgPGJp bGx5X3RzYWlAYXNwZWVkdGVjaC5jb20+CgppM2M6IG1pcGktaTNjLWhjaTogQWRkIHN1cHBvcnQg Zm9yIHRoZSBBU1QyNzAwIEkzQyBjb250cm9sbGVyCgpUaGlzIGNvbW1pdCBhZGRzIHN1cHBvcnQg Zm9yIHRoZSBBU1QyNzAwIEkzQyBjb250cm9sbGVyIGJ5IGNhY2hpbmcgdmVuZG9yCmRhdGEgdGhy b3VnaCBhIE1JUEkgZXh0ZW5kZWQgY2FwYWJpbGl0eSBwYXJzZXIuIEl0IGltcGxlbWVudHMgQVNQ RUVELXNwZWNpZmljCmluaXRpYWxpemF0aW9uIGhvb2tzLCBoYXJkd2FyZSBjb25maWd1cmF0aW9u cyBsaWtlIERBQSBpbmRleGluZywgYW5kIGN1c3RvbQpJUlEgZGlzcGF0Y2hpbmcuCgo+IGRpZmYg LS1naXQgYS9kcml2ZXJzL2kzYy9tYXN0ZXIvbWlwaS1pM2MtaGNpL2NtZF92MS5jIGIvZHJpdmVy cy9pM2MvbWFzdGVyL21pcGktaTNjLWhjaS9jbWRfdjEuYwo+IC0tLSBhL2RyaXZlcnMvaTNjL21h c3Rlci9taXBpLWkzYy1oY2kvY21kX3YxLmMKPiArKysgYi9kcml2ZXJzL2kzYy9tYXN0ZXIvbWlw aS1pM2MtaGNpL2NtZF92MS5jClsgLi4uIF0KPiBAQCAtMjkzLDYgKzI5NCwyNCBAQCBzdGF0aWMg dm9pZCBoY2lfY21kX3YxX3ByZXBfaTJjX3hmZXIoc3RydWN0IGkzY19oY2kgKmhjaSwKPiAgCX0K PiAgfQo+ICAKPiArLyoKPiArICogVGhlIERBQSBpbmRleCByZWdpc3RlcnMgbmFtZSB0aGUgREFU IHNsb3QgYmVpbmcgYXNzaWduZWQgZHVyaW5nIEVOVERBQTsKPiArICogdGhleSBsaXZlIGluIHRo ZSB2ZW5kb3IgY2FwYWJpbGl0eSBibG9jayBkaXNjb3ZlcmVkIGF0IHByb2JlIHRpbWUuCj4gKyAq Lwo+ICtzdGF0aWMgdm9pZCBhc3BlZWRfaTNjX3NldF9kYWFfaW5kZXgoc3RydWN0IGkzY19oY2kg KmhjaSwgdW5zaWduZWQgaW50IGRhdF9pZHgpCj4gK3sKPiArCXZvaWQgX19pb21lbSAqaW5ob3Vz ZV9yZWdzID0gdG9fYXNwZWVkX3ZlbmRvcl9kYXRhKGhjaSktPmluaG91c2VfcmVnczsKPiArCj4g KwlpZiAoZGF0X2lkeCA8IDMyKQo+ICsJCXdyaXRlbChCSVQoZGF0X2lkeCksIGluaG91c2VfcmVn cyArIEFTUEVFRF9JM0NfREFBX0lOREVYMCk7Cj4gKwllbHNlIGlmIChkYXRfaWR4IDwgNjQpCj4g KwkJd3JpdGVsKEJJVChkYXRfaWR4IC0gMzIpLCBpbmhvdXNlX3JlZ3MgKyBBU1BFRURfSTNDX0RB QV9JTkRFWDEpOwo+ICsJZWxzZSBpZiAoZGF0X2lkeCA8IDk2KQo+ICsJCXdyaXRlbChCSVQoZGF0 X2lkeCAtIDY0KSwgaW5ob3VzZV9yZWdzICsgQVNQRUVEX0kzQ19EQUFfSU5ERVgyKTsKPiArCWVs c2UKPiArCQl3cml0ZWwoQklUKGRhdF9pZHggLSA5NiksIGluaG91c2VfcmVncyArIEFTUEVFRF9J M0NfREFBX0lOREVYMyk7CgpbU2V2ZXJpdHk6IEhpZ2hdCkRvZXMgdGhpcyBsZWF2ZSBzdGFsZSBi aXRzIHNldCBpbiB0aGUgb3RoZXIgcmVnaXN0ZXIgYmFua3M/CgpXcml0aW5nIHRvIG9uZSByZWdp c3RlciBiYW5rIGxlYXZlcyB0aGUgb3RoZXIgdGhyZWUgcmVnaXN0ZXIgYmFua3MgdW50b3VjaGVk LgpBcyBkZXZpY2VzIGFyZSBzZXF1ZW50aWFsbHkgYXNzaWduZWQgdG8gREFUIHNsb3RzIGR1cmlu ZyBFTlREQUEsIGlmIHRoZSBpbmRleCAKY3Jvc3NlcyBhIDMyLWJpdCBib3VuZGFyeSAoZS5nLiwg ZnJvbSBpbmRleCAzMSB0byAzMiksIHRoZSBvbGQgYml0IHJlbWFpbnMgc2V0Cmdsb2JhbGx5LgoK VGhlIGhhcmR3YXJlIG1pZ2h0IGludGVycHJldCBtdWx0aXBsZSBzZXQgYml0cyBhcyBpbnN0cnVj dGlvbnMgdG8gYXNzaWduCm11bHRpcGxlIERBVCBzbG90cyBzaW11bHRhbmVvdXNseSwgY29ycnVw dGluZyB0aGUgSENJJ3MgaW50ZXJuYWwgcm91dGluZy4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv aTNjL21hc3Rlci9taXBpLWkzYy1oY2kvY29yZS5jIGIvZHJpdmVycy9pM2MvbWFzdGVyL21pcGkt aTNjLWhjaS9jb3JlLmMKPiAtLS0gYS9kcml2ZXJzL2kzYy9tYXN0ZXIvbWlwaS1pM2MtaGNpL2Nv cmUuYwo+ICsrKyBiL2RyaXZlcnMvaTNjL21hc3Rlci9taXBpLWkzYy1oY2kvY29yZS5jClsgLi4u IF0KPiBAQCAtODY2LDYgKzk0NCwxMSBAQCBzdGF0aWMgaW50IGkzY19oY2lfcmVzZXRfYW5kX2lu aXQoc3RydWN0IGkzY19oY2kgKmhjaSkKPiAgCSAqIEJpdCAwOjUgYXJlIGRlZmluZWQgaW4gSVAg dmVyc2lvbiA8IDAuOCBidXQgbm90IGhhbmRsZWQgYnkgUElPIGNvZGUKPiAgCSAqLwo+ICAJcmVn X3dyaXRlKElOVFJfU1RBVFVTX0VOQUJMRSwgR0VOTUFTSygzMSwgMTApKTsKPiArCWlmIChpc19h c3BlZWQoaGNpKSkgewo+ICsJCWFzcGVlZF9pM2Nfd3JpdGUoaGNpLCBBU1BFRURfSTNDX0lOVFJf U0lHTkFMX0VOQUJMRSwgMCk7CgpbU2V2ZXJpdHk6IEhpZ2hdCkNhbiB0aGlzIGNhdXNlIGEga2Vy bmVsIHBhbmljIGR1ZSB0byBhIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSBvciB0eXBlCmNvbmZ1 c2lvbj8KClRoZSB1bmNvbmRpdGlvbmFsIHdyaXRlIHJlbGllcyBzb2xlbHkgb24gdGhlIERUIGNv bXBhdGlibGUgc3RyaW5nIHRocm91Z2gKaXNfYXNwZWVkKCkgd2l0aG91dCB2ZXJpZnlpbmcgaWYg dGhlIGhhcmR3YXJlIGNhcGFiaWxpdHkgd2FzIGFjdHVhbGx5IGZvdW5kIGFuZApwYXJzZWQuIElm IHRoZSBEVCBpbmRpY2F0ZXMgYW4gQVNQRUVEIGNvbXBhdGlibGUgZGV2aWNlIGJ1dCB0aGUgaGFy ZHdhcmUgZG9lcwpub3QgZXhwb3NlIHRoZSBBU1BFRUQgTUlQSSB2ZW5kb3IgZXh0ZW5kZWQgY2Fw YWJpbGl0eSAoZS5nLiBkdWUgdG8gYSBtaXNtYXRjaGVkCkRUIGJpbmRpbmcpLCBpM2NfaGNpX3By b2JlKCkgYWxsb2NhdGVzIHZkIHdpdGggYSBOVUxMIGluaG91c2VfcmVncyBwb2ludGVyLgoKQWRk aXRpb25hbGx5LCBpZiB0aGUgaGFyZHdhcmUgaXMgTlhQLCB0aGUgTlhQIHBhcnNlciBpbmNvcnJl Y3RseSBvdmVyd3JpdGVzCmhjaS0+dmVuZG9yX2RhdGEuIExhdGVyLCBpM2NfaGNpX3Jlc2V0X2Fu ZF9pbml0KCkgdW5jb25kaXRpb25hbGx5IGV4ZWN1dGVzCkFTUEVFRC1zcGVjaWZpYyB3cml0ZXMg dXNpbmcgdG9fYXNwZWVkX3ZlbmRvcl9kYXRhKGhjaSktPmluaG91c2VfcmVncywKY2F1c2luZyBh IGNyYXNoLgoKWyAuLi4gXQo+IEBAIC0xMTg5LDYgKzEyODksNDAgQEAgc3RhdGljIGludCBpM2Nf aGNpX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpCj4gIAkJCQkJICAgICAiY2Fu bm90IHNldCBETUEgbWFza1xuIik7Cj4gIAl9Cj4gIAo+ICsJaWYgKGlzX2FzcGVlZChoY2kpKSB7 Cj4gKwkJc3RydWN0IGFzcGVlZF9pM2NfdmVuZG9yX2RhdGEgKnZkOwo+ICsKPiArCQl2ZCA9IGRl dm1fa3phbGxvYygmcGRldi0+ZGV2LCBzaXplb2YoKnZkKSwgR0ZQX0tFUk5FTCk7ClsgLi4uIF0K PiArCQl2ZC0+ZG1hX3JzdCA9IGRldm1fcmVzZXRfY29udHJvbF9nZXRfb3B0aW9uYWxfc2hhcmVk KCZwZGV2LT5kZXYsICJkbWEiKTsKPiArCQlpZiAoSVNfRVJSKHZkLT5kbWFfcnN0KSkKPiArCQkJ cmV0dXJuIFBUUl9FUlIodmQtPmRtYV9yc3QpOwo+ICsJCWlmICh2ZC0+ZG1hX3JzdCkgewo+ICsJ CQlyZXQgPSByZXNldF9jb250cm9sX2RlYXNzZXJ0KHZkLT5kbWFfcnN0KTsKPiArCQkJaWYgKHJl dCkKPiArCQkJCXJldHVybiByZXQ7Cj4gKwkJCXJldCA9IGRldm1fYWRkX2FjdGlvbl9vcl9yZXNl dCgmcGRldi0+ZGV2LAo+ICsJCQkJCQkgICAgICAgaTNjX2hjaV9kbWFfcnN0X2Fzc2VydCwKPiAr CQkJCQkJICAgICAgIHZkLT5kbWFfcnN0KTsKPiArCQkJaWYgKHJldCkKPiArCQkJCXJldHVybiBy ZXQ7Cj4gKwkJfQo+ICsKPiArCQl2ZC0+Y2xrID0gZGV2bV9jbGtfZ2V0X29wdGlvbmFsKCZwZGV2 LT5kZXYsIE5VTEwpOwoKW1NldmVyaXR5OiBMb3ddCklzIHRoZSBjb3JlIGNsb2NrIGFjdHVhbGx5 IG9wdGlvbmFsPwoKVGhlIGNsb2NrIGlzIHJldHJpZXZlZCBhcyBvcHRpb25hbCBoZXJlLCB3aGlj aCB3aWxsIHJldHVybiBOVUxMIGlmIGl0IGlzIG5vdApzcGVjaWZpZWQgaW4gdGhlIGRldmljZSB0 cmVlIChtYXNraW5nIHRoZSAtRU5PRU5UIGZhaWx1cmUpLiBIb3dldmVyLCBpbgphc3BlZWRfaTNj X3BoeV9pbml0KCksIGl0IGFwcGVhcnMgdG8gYmUgdHJlYXRlZCBhcyBhIG1hbmRhdG9yeSByZXNv dXJjZS4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL21hc3Rlci9taXBpLWkzYy1oY2kvdmVu ZG9yX2FzcGVlZC5jIGIvZHJpdmVycy9pM2MvbWFzdGVyL21pcGktaTNjLWhjaS92ZW5kb3JfYXNw ZWVkLmMKPiAtLS0gYS9kcml2ZXJzL2kzYy9tYXN0ZXIvbWlwaS1pM2MtaGNpL3ZlbmRvcl9hc3Bl ZWQuYwo+ICsrKyBiL2RyaXZlcnMvaTNjL21hc3Rlci9taXBpLWkzYy1oY2kvdmVuZG9yX2FzcGVl ZC5jClsgLi4uIF0KPiArdm9pZCBhc3BlZWRfaTNjX3dyaXRlKHN0cnVjdCBpM2NfaGNpICpoY2ks IHUzMiByZWcsIHUzMiB2YWwpCj4gK3sKPiArCXdyaXRlbCh2YWwsIHRvX2FzcGVlZF92ZW5kb3Jf ZGF0YShoY2kpLT5pbmhvdXNlX3JlZ3MgKyByZWcpOwo+ICt9CgpbU2V2ZXJpdHk6IEhpZ2hdCkRv ZXMgdGhpcyByZXN1bHQgaW4gYW4gaW52YWxpZCBtZW1vcnkgYWNjZXNzIG9yIE5VTEwgcG9pbnRl ciBkZXJlZmVyZW5jZT8KCklmIHRoZSBBU1BFRUQgZXh0ZW5kZWQgY2FwYWJpbGl0eSB3YXNuJ3Qg cHJlc2VudCBpbiBoYXJkd2FyZSAob3IgaWYgYW4gTlhQCmRldmljZSBpbmNvcnJlY3RseSBvdmVy d3JvdGUgaGNpLT52ZW5kb3JfZGF0YSksIHRvX2FzcGVlZF92ZW5kb3JfZGF0YShoY2kpCm1pZ2h0 IGJlIE5VTEwgb3IgcG9pbnQgdG8gaW52YWxpZCBtZW1vcnkgaGVyZSwgdHJpZ2dlcmluZyBhIGNy YXNoIHdoZW4gY2FsbGVkCnVuY29uZGl0aW9uYWxseSBmcm9tIGkzY19oY2lfcmVzZXRfYW5kX2lu aXQoKS4KClsgLi4uIF0KPiAraW50IGFzcGVlZF9pM2NfcGh5X2luaXQoc3RydWN0IGkzY19oY2kg KmhjaSkKPiArewo+ICsJdTE2IGhjbnQsIGxjbnQsIHRvdGFsX2NudCwgbWluX3RiaXRfY250LCBj YXNfbGNudCwgY2FzX2NudCwgY2JwX2NudDsKPiArCXUzMiBzZGFfdHhfaG9sZCA9IDAsIGNhc19u cyA9IDAsIGNicF9ucyA9IDAsIHNyX3BfbG93ID0gMDsKPiArCXN0cnVjdCBpM2NfYnVzICpidXMg PSBpM2NfbWFzdGVyX2dldF9idXMoJmhjaS0+bWFzdGVyKTsKPiArCXUzMiBwcF9oaWdoID0gMCwg cHBfbG93ID0gMCwgb2RfaGlnaCA9IDAsIG9kX2xvdyA9IDA7Cj4gKwlzdHJ1Y3QgZGV2aWNlX25v ZGUgKm5wID0gaGNpLT5tYXN0ZXIuZGV2Lm9mX25vZGU7Cj4gKwl1MzIgc2RyX2N0cmwwX3JlZywg Y3RybDAsIGN0cmwxLCBjdHJsMjsKPiArCXVuc2lnbmVkIGxvbmcgY29yZV9yYXRlLCBwZXJpb2Rf bnM7Cj4gKwo+ICsJY29yZV9yYXRlID0gY2xrX2dldF9yYXRlKHRvX2FzcGVlZF92ZW5kb3JfZGF0 YShoY2kpLT5jbGspOwo+ICsJaWYgKCFjb3JlX3JhdGUpIHsKPiArCQlkZXZfZXJyKCZoY2ktPm1h c3Rlci5kZXYsICJpbnZhbGlkIGNvcmUgY2xvY2sgcmF0ZVxuIik7Cj4gKwkJcmV0dXJuIC1FSU5W QUw7Cj4gKwl9CgpbU2V2ZXJpdHk6IExvd10KRG9lcyB0aGlzIGNvbnRyYWRpY3QgdGhlIG9wdGlv bmFsIGNsb2NrIHJldHJpZXZhbCBpbiBpM2NfaGNpX3Byb2JlKCk/CgpJZiBkZXZtX2Nsa19nZXRf b3B0aW9uYWwoKSByZXR1cm5zIE5VTEwgZHVyaW5nIHByb2JlLCBjbGtfZ2V0X3JhdGUoKSB3aWxs CnJldHVybiAwIGhlcmUuCgpUaGUgY29kZSBoYXJkLWZhaWxzIGlmIHRoZSByYXRlIGlzIDAsIGNv bXBsZXRlbHkgbmVnYXRpbmcgdGhlIG9wdGlvbmFsCnJldHJpZXZhbCBwYXR0ZXJuLiBUaGlzIGhp ZGVzIHRoZSBhY3R1YWwgbWlzc2luZyByZXNvdXJjZSBlcnJvciwgcmV0dXJuaW5nCmEgY29uZnVz aW5nIGZhaWx1cmUgbWVzc2FnZSBpbnN0ZWFkIG9mIHByb3Blcmx5IHByb3BhZ2F0aW5nIGEgbWlz c2luZyBEVApyZXF1aXJlbWVudC4KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nh c2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA5MDEtYjQtaTNjLWhjaS1hc3QyNzAwLXYxLTAtMTk5 MDllN2NiZDdlQGFzcGVlZHRlY2guY29tP3BhcnQ9NQoKLS0gCmxpbnV4LWkzYyBtYWlsaW5nIGxp c3QKbGludXgtaTNjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5v cmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1pM2MK 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 2F9D23BED6A for ; Tue, 1 Sep 2026 11:52:43 +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=1788263565; cv=none; b=If0P+hVOBIx9DGbIP48g9kXUita3Ikp/UczbaU/zeUKSkkFnvF1QIE8cKQXYdUDTtETtjAKBOwRTKPQFH/x2omtwNnFQt9KvZVhFkUqsF9la/VDaDbhLQUoqGhBlPyQkIqLIUD4SbNZXDH2e7xfs750YjJ+npAti2kNNLXK7VaM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788263565; c=relaxed/simple; bh=Tkz8rpJVgJxr/fAngV8KM3kIeheaTVpSnw5OVC3fP/c=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=c+2azsg4gSWJzjr1KXfFdPisbXHd6bGzRnyoSah+Vj9UYQobOkjK90NGnCLEPpi9fkWKsLBmzzAsgzFsVqCKJ04xyukl/o6aZI2q/9F1meuqIQGpoiFewhFiroNq7cYL6avY7FkBbz/Bgs8OdGykPugMnVmzlcv6vjYmj9eyOos= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=avoeYrWe; 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="avoeYrWe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56E541F000E9; Tue, 1 Sep 2026 11:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788263563; bh=REoHQB91oLFxxMMmQctDUsa+I1bBQ31czHVyRU20WvQ=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=avoeYrWe8PQrB5YvMrRnqonB7Z0ZPBFsDapC0hfjKV2iW0dJ9I3MpND19EoZkNxLv OVqDfWrMxchgpZpGuu/h6FMgrQOwIAIywDCjm2X2ATYZ/jpsH/g+k/xlDvIzYcOsMh t56HaeVni2Hw2HKaB4gwnlF+mdx+vY/9Q7HI/bB2kTkmF8pu1Q/zgxnKYwFU3rCWGn 7CbZy5qmy/WS6ca94mLQI/opLcqCr7V/a6y5oOSCIuGi7VFqlia2Mx3qAGZ3t3aanE +/z+wJ56IeDJmd3ezaTYkIMOcnA4OK7p941kXpjEYiKqbz9sm8I27b+k2G32QBcjmB dppdnSbxyIIPg== From: sashiko-bot@kernel.org Subject: Re: [PATCH 5/8] i3c: mipi-i3c-hci: Add support for the AST2700 I3C controller Reply-To: sashiko-reviews@lists.linux.dev To: "Billy Tsai" Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org, linux-i3c@lists.infradead.org, "Alexandre Belloni" , Frank.Li@kernel.org In-Reply-To: <20260901-b4-i3c-hci-ast2700-v1-5-19909e7cbd7e@aspeedtech.com> References: <20260901-b4-i3c-hci-ast2700-v1-0-19909e7cbd7e@aspeedtech.com> <20260901-b4-i3c-hci-ast2700-v1-5-19909e7cbd7e@aspeedtech.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 01 Sep 2026 11:52:42 +0000 Message-Id: <20260901115243.56E541F000E9@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 3 potential issue(= s) to consider: - [High] Kernel crash due to unchecked vendor register access if the hardwa= re lacks the ASPEED extended capability. - [High] Incomplete clearing of previous DAA index across registers leaves = stale bits set. - [Low] Contradictory use of optional clock API leads to misleading probe f= ailures. -- commit 3d4e54b2ee6f05bbf18ce4fc75b881c1d3330487 Author: Billy Tsai i3c: mipi-i3c-hci: Add support for the AST2700 I3C controller This commit adds support for the AST2700 I3C controller by caching vendor data through a MIPI extended capability parser. It implements ASPEED-specif= ic initialization hooks, hardware configurations like DAA indexing, and custom IRQ dispatching. > diff --git a/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c b/drivers/i3c/maste= r/mipi-i3c-hci/cmd_v1.c > --- a/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c > +++ b/drivers/i3c/master/mipi-i3c-hci/cmd_v1.c [ ... ] > @@ -293,6 +294,24 @@ static void hci_cmd_v1_prep_i2c_xfer(struct i3c_hci = *hci, > } > } > =20 > +/* > + * The DAA index registers name the DAT slot being assigned during ENTDA= A; > + * they live in the vendor capability block discovered at probe time. > + */ > +static void aspeed_i3c_set_daa_index(struct i3c_hci *hci, unsigned int d= at_idx) > +{ > + void __iomem *inhouse_regs =3D to_aspeed_vendor_data(hci)->inhouse_regs; > + > + if (dat_idx < 32) > + writel(BIT(dat_idx), inhouse_regs + ASPEED_I3C_DAA_INDEX0); > + else if (dat_idx < 64) > + writel(BIT(dat_idx - 32), inhouse_regs + ASPEED_I3C_DAA_INDEX1); > + else if (dat_idx < 96) > + writel(BIT(dat_idx - 64), inhouse_regs + ASPEED_I3C_DAA_INDEX2); > + else > + writel(BIT(dat_idx - 96), inhouse_regs + ASPEED_I3C_DAA_INDEX3); [Severity: High] Does this leave stale bits set in the other register banks? Writing to one register bank leaves the other three register banks untouche= d. As devices are sequentially assigned to DAT slots during ENTDAA, if the ind= ex=20 crosses a 32-bit boundary (e.g., from index 31 to 32), the old bit remains = set globally. The hardware might interpret multiple set bits as instructions to assign multiple DAT slots simultaneously, corrupting the HCI's internal routing. > diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/= mipi-i3c-hci/core.c > --- a/drivers/i3c/master/mipi-i3c-hci/core.c > +++ b/drivers/i3c/master/mipi-i3c-hci/core.c [ ... ] > @@ -866,6 +944,11 @@ static int i3c_hci_reset_and_init(struct i3c_hci *hc= i) > * Bit 0:5 are defined in IP version < 0.8 but not handled by PIO code > */ > reg_write(INTR_STATUS_ENABLE, GENMASK(31, 10)); > + if (is_aspeed(hci)) { > + aspeed_i3c_write(hci, ASPEED_I3C_INTR_SIGNAL_ENABLE, 0); [Severity: High] Can this cause a kernel panic due to a NULL pointer dereference or type confusion? The unconditional write relies solely on the DT compatible string through is_aspeed() without verifying if the hardware capability was actually found= and parsed. If the DT indicates an ASPEED compatible device but the hardware do= es not expose the ASPEED MIPI vendor extended capability (e.g. due to a mismat= ched DT binding), i3c_hci_probe() allocates vd with a NULL inhouse_regs pointer. Additionally, if the hardware is NXP, the NXP parser incorrectly overwrites hci->vendor_data. Later, i3c_hci_reset_and_init() unconditionally executes ASPEED-specific writes using to_aspeed_vendor_data(hci)->inhouse_regs, causing a crash. [ ... ] > @@ -1189,6 +1289,40 @@ static int i3c_hci_probe(struct platform_device *p= dev) > "cannot set DMA mask\n"); > } > =20 > + if (is_aspeed(hci)) { > + struct aspeed_i3c_vendor_data *vd; > + > + vd =3D devm_kzalloc(&pdev->dev, sizeof(*vd), GFP_KERNEL); [ ... ] > + vd->dma_rst =3D devm_reset_control_get_optional_shared(&pdev->dev, "dm= a"); > + if (IS_ERR(vd->dma_rst)) > + return PTR_ERR(vd->dma_rst); > + if (vd->dma_rst) { > + ret =3D reset_control_deassert(vd->dma_rst); > + if (ret) > + return ret; > + ret =3D devm_add_action_or_reset(&pdev->dev, > + i3c_hci_dma_rst_assert, > + vd->dma_rst); > + if (ret) > + return ret; > + } > + > + vd->clk =3D devm_clk_get_optional(&pdev->dev, NULL); [Severity: Low] Is the core clock actually optional? The clock is retrieved as optional here, which will return NULL if it is not specified in the device tree (masking the -ENOENT failure). However, in aspeed_i3c_phy_init(), it appears to be treated as a mandatory resource. > diff --git a/drivers/i3c/master/mipi-i3c-hci/vendor_aspeed.c b/drivers/i3= c/master/mipi-i3c-hci/vendor_aspeed.c > --- a/drivers/i3c/master/mipi-i3c-hci/vendor_aspeed.c > +++ b/drivers/i3c/master/mipi-i3c-hci/vendor_aspeed.c [ ... ] > +void aspeed_i3c_write(struct i3c_hci *hci, u32 reg, u32 val) > +{ > + writel(val, to_aspeed_vendor_data(hci)->inhouse_regs + reg); > +} [Severity: High] Does this result in an invalid memory access or NULL pointer dereference? If the ASPEED extended capability wasn't present in hardware (or if an NXP device incorrectly overwrote hci->vendor_data), to_aspeed_vendor_data(hci) might be NULL or point to invalid memory here, triggering a crash when call= ed unconditionally from i3c_hci_reset_and_init(). [ ... ] > +int aspeed_i3c_phy_init(struct i3c_hci *hci) > +{ > + u16 hcnt, lcnt, total_cnt, min_tbit_cnt, cas_lcnt, cas_cnt, cbp_cnt; > + u32 sda_tx_hold =3D 0, cas_ns =3D 0, cbp_ns =3D 0, sr_p_low =3D 0; > + struct i3c_bus *bus =3D i3c_master_get_bus(&hci->master); > + u32 pp_high =3D 0, pp_low =3D 0, od_high =3D 0, od_low =3D 0; > + struct device_node *np =3D hci->master.dev.of_node; > + u32 sdr_ctrl0_reg, ctrl0, ctrl1, ctrl2; > + unsigned long core_rate, period_ns; > + > + core_rate =3D clk_get_rate(to_aspeed_vendor_data(hci)->clk); > + if (!core_rate) { > + dev_err(&hci->master.dev, "invalid core clock rate\n"); > + return -EINVAL; > + } [Severity: Low] Does this contradict the optional clock retrieval in i3c_hci_probe()? If devm_clk_get_optional() returns NULL during probe, clk_get_rate() will return 0 here. The code hard-fails if the rate is 0, completely negating the optional retrieval pattern. This hides the actual missing resource error, returning a confusing failure message instead of properly propagating a missing DT requirement. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260901-b4-i3c-hci= -ast2700-v1-0-19909e7cbd7e@aspeedtech.com?part=3D5