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 451F0CCD183 for ; Thu, 16 Oct 2025 16: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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NVeoDyvq0iMe0XNnIKIi5bvxIdPT5FBJo4o6U7TDZsI=; b=c4rpoPozEYPjI/ A7u7cHMw3P/ifOtI3C5TwAC7Rw0rQmvvqQXsSEumTr4h35XFYoabyBB6o1yohcR5Iwb0TbKZWsQT1 csT+3auqbeMOb/ldoIv6a/Qia+BY6c421i+LZp4aeCbJN9MQC6mP0gI+d0tRMwUyQbTWXrnb+A6vB z4TCW392fINHBSSpaqRCEWmdZm+WYLcx6IaaLeRL9VfK1SVSJpG5qTVI5g/2VNg4uX+zee5wJ79wQ 79TYuxc7DFTUPlvNhP4u7TyddphN2+v1DVXNnF1gZCUf0s4Pf8gh3CSG1S9CY+qevBHT/I8VaHJB7 hC0+qZ3lmgE1KojbieVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1v9Qac-00000005NP0-3n7Q; Thu, 16 Oct 2025 16:12:30 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1v9Qab-00000005NO6-0R4Z for linux-riscv@lists.infradead.org; Thu, 16 Oct 2025 16:12:30 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1760631147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EimfC5YBQZ0kq/Gz52aWdB6vLjbMGcafw2nhUU8MVtE=; b=ZRO9mP/8ehCkUpZqmBe1rgk54JZHc29ccwtTz5j954OrVqClG6R+uVRDYkbJp7hC1gdJJZ y5PEOhujG1srTiKm+IOooIdhhs0kUZTBg4no06GdwWfYS9c5mWtbD/4Vm5ajrzxPau/bM9 9V1jlggPXINSOLbxqr8l4O4HJFubXNqMmKD9mxQ4/xIWvOz1XaQ+GtxT9E4rcZGj2ur6Ob wSufpZsQHWCSIZlhRNhxoBXc712/TuEeRpyRjjoavVOhCa2rUqh8BW7FCpL+7ZOryAWmxx AoFp07wqU0/WHcI9Qum/mmpesYmxTEZ1yG++4KX20YvDIBCM3mP0+nBORDZNSA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1760631147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EimfC5YBQZ0kq/Gz52aWdB6vLjbMGcafw2nhUU8MVtE=; b=f4I884pQCh72NrW5bcmy4HgTPvI5ho0GNW8nxlBno/OTw1sTWSsWqoRojjYlPDOcm2wPbr 9w2ELHaEq06LBtBw== To: Charles Mirabile Cc: Lucas Zampieri , linux-kernel@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Samuel Holland , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Vivian Wang , devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, Zhang Xincheng Subject: Re: [PATCH v5 3/3] irqchip/plic: add support for UltraRISC DP1000 PLIC In-Reply-To: References: <20251016084301.27670-1-lzampier@redhat.com> <20251016084301.27670-4-lzampier@redhat.com> <87plan0yvd.ffs@tglx> Date: Thu, 16 Oct 2025 18:12:25 +0200 Message-ID: <87ms5q25cm.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251016_091229_285434_EAD9308C X-CRM114-Status: GOOD ( 34.40 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gVGh1LCBPY3QgMTYgMjAyNSBhdCAxMTo1NCwgQ2hhcmxlcyBNaXJhYmlsZSB3cm90ZToKPiBP biBUaHUsIE9jdCAxNiwgMjAyNSBhdCA5OjE34oCvQU0gVGhvbWFzIEdsZWl4bmVyIDx0Z2x4QGxp bnV0cm9uaXguZGU+IHdyb3RlOgo+PiA+ICtzdGF0aWMgaXJxX2h3X251bWJlcl90IGNwMTAwX2dl dF9od2lycShzdHJ1Y3QgcGxpY19oYW5kbGVyICpoYW5kbGVyLAo+PiA+ICsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCBfX2lvbWVtICpjbGFpbSkKPj4gPiArewo+PiA+ ICsgICAgIGludCBucl9pcnFfZ3JvdXBzID0gRElWX1JPVU5EX1VQKGhhbmRsZXItPnByaXYtPm5y X2lycXMsIDMyKTsKPj4gPiArICAgICB2b2lkIF9faW9tZW0gKnBlbmRpbmcgPSBoYW5kbGVyLT5w cml2LT5yZWdzICsgUEVORElOR19CQVNFOwo+PiA+ICsgICAgIHZvaWQgX19pb21lbSAqZW5hYmxl ID0gaGFuZGxlci0+ZW5hYmxlX2Jhc2U7Cj4+ID4gKyAgICAgaXJxX2h3X251bWJlcl90IGh3aXJx ID0gMDsKPj4gPiArICAgICBpbnQgaTsKPj4gPiArCj4+ID4gKyAgICAgZ3VhcmQocmF3X3NwaW5s b2NrKSgmaGFuZGxlci0+ZW5hYmxlX2xvY2spOwo+PiA+ICsKPj4gPiArICAgICAvKiBTYXZlIGN1 cnJlbnQgaW50ZXJydXB0IGVuYWJsZSBzdGF0ZSAqLwo+PiA+ICsgICAgIGZvciAoaSA9IDA7IGkg PCBucl9pcnFfZ3JvdXBzOyBpKyspCj4+ID4gKyAgICAgICAgICAgICBoYW5kbGVyLT5lbmFibGVf c2F2ZVtpXSA9IHJlYWRsX3JlbGF4ZWQoZW5hYmxlICsgaSAqIHNpemVvZih1MzIpKTsKPj4KPj4g VGhpcyBpcyB0cnVseSB0aGUgbW9zdCBpbmVmZmljaWVudCB3YXkgdG8gc29sdmUgdGhhdCBwcm9i bGVtLiBUaGUgZW5hYmxlCj4+IHJlZ2lzdGVycyBhcmUgbW9kaWZpZWQgd2l0aCBlbmFibGVkX2xv Y2sgaGVsZCwgc28geW91IGNhbiBqdXN0IGNhY2hlIHRoZQo+PiB2YWx1ZSBpbiBwbGljX2hhbmRs ZXI6OmVuYWJsZWRfc2F2ZSBhbmQgYXZvaWQgdGhpcyByZWFkIGxvb3AgY29tcGxldGVseS4KPj4g QWZ0ZXIgY2xhaW1pbmcgdGhlIGludGVycnVwdCB5b3UgcmVzdG9yZSBmcm9tIHRoYXQgY2FjaGUs IG5vPwo+Cj4gWW91IG1lYW4gdG91Y2ggdGhlIG90aGVyIGZ1bmN0aW9ucyB3aGVyZSB0aGUgZW5h YmxlIGJpdHMgYXJlIG1vZGlmaWVkCj4gdG8ga2VlcCB0aGUgY2FjaGUgaW4gc3luYyBzbyB0aGF0 IHdlIGRvbid0IG5lZWQgdG8gZG8gdGhpcyByZWFkIGxvb3AKPiBhbmQgY2FuIGhhdmUgYSBwcm9w ZXIgc2V0IG9mIHZhbHVlcyBjYWNoZWQ/Cj4KPiBNeSBjb25jZXJuIGlzIHRoYXQgdGhpcyBvYnZp b3VzbHkgaGFzIGFuIGltcGFjdCBvbiBvdGhlciBwbGF0Zm9ybXMKPiB3aGljaCBkbyBub3QgaGF2 ZSB0aGlzIHF1aXJrIHNpbmNlIGtlZXBpbmcgdGhlIGNhY2hlIGluIHN5bmMgd291bGQgZ2V0Cj4g cHVzaGVkIGFsbCB0aHJvdWdob3V0IHRoZSBkcml2ZXIuCgpUaGUgaXJxX2VuYWJsZSgpL2Rpc2Fi bGUoKSBjYWxsYmFja3MgYXJlIG5vdCByZWFsbHkgaG90cGF0aCBhbmQgY2FjaGluZwp0aGUgYml0 IGluIHBsaWNfdG9nZ2xlKCkgb3Igc3VjaCBpcyBqdXN0IG5vdCBtZWFzdXJhYmxlIG92ZXJoZWFk CmNvbXBhcmVkIHRvIHRoZSByZWdpc3RlciBhY2Nlc3MuCgo+PiBOb3cgZm9yIHRoZSBzZWFyY2gg YW5kIGRpc2FibGUgbWVjaGFuaXNtLiBPZiBjb3Vyc2UgeW91IG5lZWQgdG8gc2VhcmNoCj4+IGZv ciB0aCBwZW5kaW5nIGludGVycnVwdCBmaXJzdCwgYnV0IHRoZW4geW91IGNhbiBtYWtlIHRoYXQg bWFza2luZyBsb29wCj4+IHZlcnkgc2ltcGxlIGJ5IGhhdmluZyBhIHBsaWNfaGFuZGxlcjo6ZW5h YmxlZF9jbGVhcltdIGFycmF5IHdoaWNoIGlzCj4+IHplcm9lZCBvbiBpbml0aWFsaXphdGlvbjoK Pj4KPj4gICAgICAgICB1bnNpZ25lZCBsb25nIHBlbmRpbmcgPSAwOwo+Pgo+PiAgICAgICAgIGZv ciAoZ3JvdXAgPSAwOyAhcGVuZGluZyAmJiBncm91cCA8IG5yX2lycV9ncm91cHM7IGdyb3VwKysp IHsKPj4gICAgICAgICAgICAgICAgIHBlbmRpbmcgPSBoYW5kbGVyLT5lbmFibGVkX3NhdmVbaV07 Cj4+ICAgICAgICAgICAgICAgICBwZW5kaW5nID0mIHJlYWRsX3JlbGF4ZWQocGVuZGluZyArIGdy b3VwICogc2l6ZW9mKHUzMikpOwo+PiAgICAgICAgIH0KPj4gICAgICAgICBpZiAoIXBlbmRpbmcp Cj4+ICAgICAgICAgICAgICAgICByZXR1cm4gZmFsc2U7Cj4+Cj4+ICAgICAgICAgYml0ID0gZmZz KHBlbmRpbmcpIC0gMTsKPj4gICAgICAgICBoYW5kbGVyLT5lbmFibGVkX2NsZWFyW2dyb3VwXSB8 PSBCSVQoYml0KTsKPj4gICAgICAgICBmb3IgKGludCBpID0gMDsgaSA8IG5yX2lycV9ncm91cHM7 IGkrKykKPj4gICAgICAgICAgICAgICAgIHdyaXRlbF9yZWxheGVkKGhhbmRsZXItPmVuYWJsZWRf Y2xlYXJbaV0sIGVuYWJsZSArIGkgKiBzaXplb2YodTMyKSk7Cj4+ICAgICAgICAgaGFuZGxlci0+ ZW5hYmxlZF9jbGVhcltncm91cF0gPSAwOwo+Pgo+PiBObz8KPgo+IFN1cmUgdGhhdCB3b3VsZCBh bHNvIHdvcmssIGJ1dCB3aHkgYXJlIHdlIHVzaW5nIGZmcyAoc2xvdykgb25seSB0bwo+IHNoaWZ0 IHRoZSByZXN1bHQgYmFjayB0byBtYWtlIGEgbmV3IG1hc2sgd2hlbiAoeCAmIC14KSBpcyBmYXN0 ZXIgYW5kCj4gc2tpcHMgdGhlIGludGVybWVkaWF0ZSBzdGVwIGRlbGl2ZXJpbmcgaW1tZWRpYXRl bHkgdGhlIG1hc2sgb2YgdGhlCj4gbG93ZXN0IGJpdC4KCkJlY2F1c2UgSSBkaWQgbm90IHNwZW5k IHRpbWUgdGhpbmtpbmcgYWJvdXQgaXQuIAoKPiBBcyBmb3IgbWFraW5nIGFub3RoZXIgY2FjaGlu ZyBhcnJheSwgSSBndWVzcywgYnV0IGFnYWluIHRoYXQgaXMganVzdCBhCj4gdGltZSB2cyBzcGFj ZSB0cmFkZSBvZmYgd2l0aCBpdHMgb3duIGludmFyaWFudHMgdG8gbWFpbnRhaW4gdGhhdCB3b3Vs ZAo+IGFsc28gaW1wYWN0IG90aGVyIHBsYXRmb3Jtcy4KCkl0J3MgYSBwb2ludGVyIGluIHN0cnVj dCBwbGljX2hhbmRsZXIgKG9yIHdoYXRldmVyIGl0J3MgbmFtZWQpIGFuZCB5b3UKY2FuIGFsbG9j YXRlIGl0IHdoZW4gdGhlIHF1aXJrIGlzIHJlcXVpcmVkLiBUaGUgcG9pbnRlciBpcyBkZWZpbml0 ZWx5Cm5vdCBhIGJ1cmRlbiBmb3IgYW55b25lIGVsc2UuCgo+PiBJcyB0aGUgZGV2aWNlIEIgaW50 ZXJydXB0IHByZXNlcnZlZCBpbiB0aGUgaW50ZXJydXB0IGNoaXAgYW5kIGFjdHVhbGx5Cj4+IHJh aXNlZCB3aGVuIHRoZSBpbnRlcnJ1cHQgZW5hYmxlIGJpdCBpcyByZXN0b3JlZCBvciBpcyBpdCBs b3N0Pwo+Cj4gSSBhbSBub3Qgc3VyZSBob3cgdG8gdmVyaWZ5IHRoaXMgb3RoZXIgdGhhbiB0byB0 ZWxsIHlvdSB0aGF0IHdpdGhvdXQKPiB0aGlzIHF1aXJrIChpLmUuIHRyeWluZyB0byB1c2Ugbm9y bWFsIHBsaWMgYmVoYXZpb3IpIHRoZSBkZXZpY2UgZG9lcwo+IG5vdCB3b3JrLCBidXQgd2l0aCB0 aGlzIHF1aXJrIEkgY2FuIGJvb3QgdG8gYSBkZXNrdG9wIHdpdGggYSBwY2llCj4gZ3JhcGhpY3Mg Y2FyZCBhbmQgc3RvcmFnZSwgdXNlIG5ldHdvcmtpbmcgZXRjIHRoYXQgYWxsIG9idmlvdXNseQo+ IGRlcGVuZCBvbiB0aGUgY29ycmVjdCBmdW5jdGlvbmluZyBvZiB0aGUgaW50ZXJydXB0IGNvbnRy b2xsZXIuCj4KPiBNeSByZWFkaW5nIG9mIHRoZSBzcGVjIGZvciBQTElDIGFsc28gc3VnZ2VzdHMg KGJ1dCBkb2VzIG5vdCBleHBsaWNpdGx5Cj4gY29uZmlybSkgdGhhdCB0aGUgcGVuZGluZyBiaXRz IGZ1bmN0aW9uIGlycmVzcGVjdGl2ZSBvZiB0aGUgc3RhdGUgb2YKPiB0aGUgY29ycmVzcG9uZGlu ZyBlbmFibGUgYml0OiAiQSBwZW5kaW5nIGJpdCBpbiB0aGUgUExJQyBjb3JlIGNhbiBiZQo+IGNs ZWFyZWQgYnkgc2V0dGluZyB0aGUgYXNzb2NpYXRlZCBlbmFibGUgYml0IHRoZW4gcGVyZm9ybWlu ZyBhIGNsYWltLiIKPiAocGFnZSAxNCBwbGljIHNwZWMgMS4wLjAgWzFdKS4KPgo+IFRoaXMgc2Vu dGVuY2UgaW1wbGllcyB0byBtZSB0aGF0IGl0IGlzIHBvc3NpYmxlIGZvciBhIHBlbmRpbmcgYml0 IHRvCj4gYmUgc2V0IGV2ZW4gdGhvdWdoIHRoZSBjb3JyZXNwb25kaW5nIGVuYWJsZSBiaXQgaXMg bm90LCB3aGljaCBsZW5kcwo+IGNyZWRlbmNlIHRvIHRoZSBpZGVhIHRoYXQgdGhlIHBlbmRpbmcg Yml0cyBvcGVyYXRlIGluZGVwZW5kZW50bHkuCgpMb29rcyBsaWtlIHRoYXQuIFBsZWFzZSBhZGQg YSBjb21tZW50IHRvIHRoYXQgZWZmZWN0IHRoZW4uCgpUaGFua3MsCgogICAgICAgIHRnbHgKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2 IG1haWxpbmcgbGlzdApsaW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 D0DDA32D0C2; Thu, 16 Oct 2025 16:12:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760631150; cv=none; b=XnuQNuQBUx63BOZ90G+iG0+51bl/rlBbfEAZewDqHtOxzR5ENn4Xbltc7455CUnZ0g7ZI1oeZ6G7BsZYklBKGtUtxVyj6yRGSzLx9g47JWSAoibezE9rG+naADeHwhuMclzRJ6vCvf75C1DcVDZwuVe3kp7wA3j8H1VcHxB4AfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760631150; c=relaxed/simple; bh=XW6k3Gcar3ovV4dpcje4zQ2uk6r9dgawRYEicfegPf8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=FKdPHytYTLsW3hIrgNp4F8pKxIrZd0WAXphkqPHQo8AzMsMAZFvnw94EORAIDHSIbtiLqOhJBoGXyLNt2pUh+C02NRy5twjSjiUt2mM54oxwh7jmXcdDVG+OI9OXCsnOUNDl34zpRSV1VeMuccIUDs0Ca0aO5Htnoa84yy0mk/8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=ZRO9mP/8; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=f4I884pQ; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ZRO9mP/8"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="f4I884pQ" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1760631147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EimfC5YBQZ0kq/Gz52aWdB6vLjbMGcafw2nhUU8MVtE=; b=ZRO9mP/8ehCkUpZqmBe1rgk54JZHc29ccwtTz5j954OrVqClG6R+uVRDYkbJp7hC1gdJJZ y5PEOhujG1srTiKm+IOooIdhhs0kUZTBg4no06GdwWfYS9c5mWtbD/4Vm5ajrzxPau/bM9 9V1jlggPXINSOLbxqr8l4O4HJFubXNqMmKD9mxQ4/xIWvOz1XaQ+GtxT9E4rcZGj2ur6Ob wSufpZsQHWCSIZlhRNhxoBXc712/TuEeRpyRjjoavVOhCa2rUqh8BW7FCpL+7ZOryAWmxx AoFp07wqU0/WHcI9Qum/mmpesYmxTEZ1yG++4KX20YvDIBCM3mP0+nBORDZNSA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1760631147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EimfC5YBQZ0kq/Gz52aWdB6vLjbMGcafw2nhUU8MVtE=; b=f4I884pQCh72NrW5bcmy4HgTPvI5ho0GNW8nxlBno/OTw1sTWSsWqoRojjYlPDOcm2wPbr 9w2ELHaEq06LBtBw== To: Charles Mirabile Cc: Lucas Zampieri , linux-kernel@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Paul Walmsley , Samuel Holland , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Vivian Wang , devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, Zhang Xincheng Subject: Re: [PATCH v5 3/3] irqchip/plic: add support for UltraRISC DP1000 PLIC In-Reply-To: References: <20251016084301.27670-1-lzampier@redhat.com> <20251016084301.27670-4-lzampier@redhat.com> <87plan0yvd.ffs@tglx> Date: Thu, 16 Oct 2025 18:12:25 +0200 Message-ID: <87ms5q25cm.ffs@tglx> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 16 2025 at 11:54, Charles Mirabile wrote: > On Thu, Oct 16, 2025 at 9:17=E2=80=AFAM Thomas Gleixner wrote: >> > +static irq_hw_number_t cp100_get_hwirq(struct plic_handler *handler, >> > + void __iomem *claim) >> > +{ >> > + int nr_irq_groups =3D DIV_ROUND_UP(handler->priv->nr_irqs, 32); >> > + void __iomem *pending =3D handler->priv->regs + PENDING_BASE; >> > + void __iomem *enable =3D handler->enable_base; >> > + irq_hw_number_t hwirq =3D 0; >> > + int i; >> > + >> > + guard(raw_spinlock)(&handler->enable_lock); >> > + >> > + /* Save current interrupt enable state */ >> > + for (i =3D 0; i < nr_irq_groups; i++) >> > + handler->enable_save[i] =3D readl_relaxed(enable + i * s= izeof(u32)); >> >> This is truly the most inefficient way to solve that problem. The enable >> registers are modified with enabled_lock held, so you can just cache the >> value in plic_handler::enabled_save and avoid this read loop completely. >> After claiming the interrupt you restore from that cache, no? > > You mean touch the other functions where the enable bits are modified > to keep the cache in sync so that we don't need to do this read loop > and can have a proper set of values cached? > > My concern is that this obviously has an impact on other platforms > which do not have this quirk since keeping the cache in sync would get > pushed all throughout the driver. The irq_enable()/disable() callbacks are not really hotpath and caching the bit in plic_toggle() or such is just not measurable overhead compared to the register access. >> Now for the search and disable mechanism. Of course you need to search >> for th pending interrupt first, but then you can make that masking loop >> very simple by having a plic_handler::enabled_clear[] array which is >> zeroed on initialization: >> >> unsigned long pending =3D 0; >> >> for (group =3D 0; !pending && group < nr_irq_groups; group++) { >> pending =3D handler->enabled_save[i]; >> pending =3D& readl_relaxed(pending + group * sizeof(u32)= ); >> } >> if (!pending) >> return false; >> >> bit =3D ffs(pending) - 1; >> handler->enabled_clear[group] |=3D BIT(bit); >> for (int i =3D 0; i < nr_irq_groups; i++) >> writel_relaxed(handler->enabled_clear[i], enable + i * s= izeof(u32)); >> handler->enabled_clear[group] =3D 0; >> >> No? > > Sure that would also work, but why are we using ffs (slow) only to > shift the result back to make a new mask when (x & -x) is faster and > skips the intermediate step delivering immediately the mask of the > lowest bit. Because I did not spend time thinking about it.=20 > As for making another caching array, I guess, but again that is just a > time vs space trade off with its own invariants to maintain that would > also impact other platforms. It's a pointer in struct plic_handler (or whatever it's named) and you can allocate it when the quirk is required. The pointer is definitely not a burden for anyone else. >> Is the device B interrupt preserved in the interrupt chip and actually >> raised when the interrupt enable bit is restored or is it lost? > > I am not sure how to verify this other than to tell you that without > this quirk (i.e. trying to use normal plic behavior) the device does > not work, but with this quirk I can boot to a desktop with a pcie > graphics card and storage, use networking etc that all obviously > depend on the correct functioning of the interrupt controller. > > My reading of the spec for PLIC also suggests (but does not explicitly > confirm) that the pending bits function irrespective of the state of > the corresponding enable bit: "A pending bit in the PLIC core can be > cleared by setting the associated enable bit then performing a claim." > (page 14 plic spec 1.0.0 [1]). > > This sentence implies to me that it is possible for a pending bit to > be set even though the corresponding enable bit is not, which lends > credence to the idea that the pending bits operate independently. Looks like that. Please add a comment to that effect then. Thanks, tglx