From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) (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 5CC55432E8D for ; Thu, 13 Aug 2026 07:28:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.254.200.128 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786606087; cv=none; b=Pl07eyGoxu6ugEWROYp74qEEcXPMNtjNacmgTRiT2Lj/bHzeJd2GlJ8s0IGV6QZROuHhcZbDRkVbRFUMXdGgkmbt+W1V1t7FGLDEf7LAWzDS7F/RdOaM5HLP2BoAhQ0hOYpI70wmi5ZQkpq+V/jpJhq4CC+IBQNndz3BhFWQgYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786606087; c=relaxed/simple; bh=V2DzkMjzGic606zBSHJ0FMRtI6tXr0c7HdmIxslpI/E=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=cySI7pird4uoye0xG5q6nUacrA2DMyk+EBPbn1hId9BdEhDNCeEywLoCn1f4bXTGr+1gVkCSLdLMp4c3dzs72cYlc0T6HP1AqwG2II4DMXuCifZGQTEpuauE3eOOlPd4FT1rQiV32pLlQhzkoqRcm7iuckxepX106bqHqCOG2pM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=uniontech.com; spf=pass smtp.mailfrom=uniontech.com; dkim=pass (1024-bit key) header.d=uniontech.com header.i=@uniontech.com header.b=KnVSGrN1; arc=none smtp.client-ip=54.254.200.128 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=uniontech.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=uniontech.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=uniontech.com header.i=@uniontech.com header.b="KnVSGrN1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniontech.com; s=onoh2408; t=1786606065; bh=LExGksoYaR+hEaG6exOE3GIwFiO9/3wgLjqOrxxwjow=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=KnVSGrN1xRc5OTnM2YI//Nje8sgT9cgr+o7dfabgeJ0+hXPbotokJDTMDm1sn1X2f Z4flBA9Jg/v8CjduHlykeN15HjtiBdTPBBpYnVRzogHHKmmxSCFv8diufIoY1LE8/6 d4nd1DdJ2UpU6Kn+9n979eVpxuhNHcwftJiBc78o= X-QQ-mid: zesmtpgz9t1786606057t1a0ed936 X-QQ-Originating-IP: MKLq3C/B2ZmKK+U9tWarqGKBJ8Sa18Gqo8mHxYXZFn4= Received: from localhost.localdomain ( [1.85.7.34]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 13 Aug 2026 15:27:35 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 1 X-BIZMAIL-ID: 2303979067318764152 EX-QQ-RecipientCnt: 6 From: caina To: tglx@kernel.org Cc: maz@kernel.org, zouyipeng@huawei.com, guohanjun@huawei.com, linux-kernel@vger.kernel.org, kernel@uniontech.com Subject: mbigen: node 10+ interrupts lost after "Fix mbigen node address layout" Date: Thu, 13 Aug 2026 15:27:35 +0800 Message-Id: <20260813072735.18576-1-caina@uniontech.com> X-Mailer: git-send-email 2.20.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: zesmtpgz:uniontech.com:qybglogicsvrgz:qybglogicsvrgz6b-0 X-QQ-XMAILINFO: MdrRzaNqeqCMIZIJLU45UCgM2rEBAKP58hXSZwX0cyqNA91r0CkKQSTW VaAldg61h9QWwJaT94+EuMMJOpG/U7QJf6UsNgDygbNoAPoEbxjyEeLA0H65eoRH7MNYvzr kqfhSikppxWA/xpsCdURoU1mk0JnBrCb8MhWmX9UsmPCmjbc0cWxBP7Fsi1KAJcr+Ldveud cuG7z7m0v34IowjL7ocPL/NjlpiRE03YNMV1trQ0/sA+JwTF7IEyd52QEUxzaG0rz3hPRT1 Jy+0BfE3W0IzEcleQpxq5DQ3TfdO2jY9IfAw5pVQvkMlGnwPYSQS9vIaWsteyzt/crF7giX Oz5A6d6fzEsvU6Y3JPtn/xjegivCdNIknNXtL7muJrG5diNQzNwtIk0ie0HPetBTIyb3zKV omUn3MGUeUKbgsGj3YU0cDk/DuHfWGKtW0hD/EfQcs6cIDqqY0Dqr6GDPvOlBtiOIm8b4uz KAztMnsDjLcdP3jsHhoa6ZMrIGqVlzRnqvAna7K/BCLMIUo8Ohk7GkWTin5Jf+UPJWD1gfa BsZ9LKiuXRn/EjHgNAWskFdMGdbrB4lsU7C8RRSXFdoWox4dYhrj8XuwRB750GdUGJghSJg xyF3w8JlxkT1g+HCyMXAXZxuLurOCoydZVSmsnvhCfGo1y9L1ujQcv7k/26c2h8FdkuICeS 2B0Vl3gakiISLPdIBzYQRctU+b5lXMxJ/W/uIfWBRw+g2rosfFls8rhKh7uyzVyOyIHwm7u RxhUcMH7VhMJD+kJheLf7pKR4DhwLw+a8bDI77LDCA4YoVITqcojWbsTUgTRXDxP3vZ96j3 uO3fWn6W4QlatQeR/jYHGkybi7Hnq2ReweYxZuv1IqS0/cUahyOtjv8UwJnkLLpRDjpY821 bHPKYCS5fjtN/9BBAmhwbsXGDUlSYJde+wwoeatdt4QEYJb+uq7iD9zHNGjts3yTypShopo bg7cQrCk0TrIcoSrlor1OmKwBNNt0txJ1iKfTlv1p091lBYY99P1PKkFbAqcDJxeoNFtyxm +69EFTQmTEpXVOiLdTVqJIPGIkgd4qtdrPB/Wouq6X4c3Ir1IZjuS08rjtKaWReTg6pB0bG KozxWF6IivJIOZlYMIZhk4cBWBXDsvhZQ== X-QQ-XMRINFO: OD9hHCdaPRBwH5bRRRw8tsiH4UAatJqXfg== X-QQ-RECHKSPAM: 0 Hi Thomas, Yipeng, Commit 6be6cba9c437 ("irqchip/mbigen: Fix mbigen node address layout") appears to cause a regression on Hi1616. Symptom ------- On-board hns NIC has two ports, enahisic2i0 and enahisic2i1, both behind mbigen-v2. Port 0 works; port 1 cannot pass any traffic. Their interrupt pins fall on different mbigen nodes: enahisic2i0: pins 1152-1198 → all in node 9 enahisic2i1: pins 1200-1246 → node 9 (1200-1215) + node 10 (1216-1246) (nid = (hwirq - 64) / 128 + 1; pin 1215 = node 9, pin 1216 = node 10) /proc/interrupts shows the break happens exactly at the node boundary: enahisic2i1-rx0 pin 1200 count 102 ← node 9 enahisic2i1-rx5 pin 1215 count 1 ← node 9, last pin enahisic2i1-tx5 pin 1216 count 0 ← node 10, first pin enahisic2i1-rx6 pin 1218 count 0 ← node 10 ...all node 10 pins stay at zero. Port 0 (entirely node 9) is unaffected. Reverting the commit restores normal operation. Why the commit's premise seems wrong ------------------------------------ The commit assumes CLEAR occupies a full 4 KB page at [0xa000, 0xb000) and collides with node 10, so node 10+ gets shifted by 0x1000. But get_mbigen_clear_reg() uses flat, chip-wide addressing — it never multiplies by the node ID: *addr = (hwirq / 32) * 4 + REG_MBIGEN_CLEAR_OFFSET; /* 0xa000 */ Over the valid hwirq range [64, 1407], CLEAR only spans 0xa008-0xa0af (168 bytes). Node 10's registers are: TYPE: 0xa000-0xa00f (16 B) overlaps CLEAR by 8 B (0xa008-0xa00f) VEC: 0xa200-0xa3ff (512 B) no overlap with CLEAR Shifting the whole page moves VEC from 0xa200 to 0xb200. The hardware reads the event ID from the fixed silicon address 0xa200 on interrupt firing, but software wrote it to 0xb200 — so the hardware gets an uninitialised value and the interrupt is lost. The only real overlap is 8 bytes of TYPE. It can only trigger when a single mbigen instance has devices on both node 1 (CLEAR 0xa008) and node 10 (TYPE 0xa008). On Hi1616 those nodes are on separate mbigen instances, so it never triggers. I don't have mbigen hardware documentation, so before sending a fix I'd like to understand whether the original commit was targeting a specific newer mbigen revision where CLEAR occupies a full 4 KB page. If so, the skip would need to be conditional on hardware revision rather than unconditional. If not, my inclination is to send a revert, or a narrower fix that skips CLEAR only in the TYPE path and leaves VEC untouched — the latter avoids the interrupt loss while still addressing the 8-byte TYPE/CLEAR overlap. Any insight into the target hardware would help me avoid breaking a platform I can't test. Thanks, caina