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 A00133D567F for ; Mon, 20 Jul 2026 09:41:52 +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=1784540516; cv=none; b=iuuexyuLnuJuUOlxaHNW+b9jcFiiq+P4lVcij870DZqJ2w0quz9dvqdhxZcgjodTFt2EUKZIXr8nfmK3Ta2lEVQNTQdnZ+awC2o3Do0wuDRRvHXep5LxmBU6MeYBRZ7cFn4CDxNse1xCA6S6fvxF5CBALdKgXSijEemUvzTy+k8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784540516; c=relaxed/simple; bh=PkmXdtUm8fI/NL28D97Y122SIHeiOZLYyXvvrIEjMmY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OVGCiIorNt/V4HcRmHKdkuDu2pwhMOnhcBgy7R7jlBq4j/r+jc1Abge7sRzxCmaJDYjEcBcNVqPx3XWbA6U9Xi7bvVqMF41ZVdhyYBup0BZ7SzP1hRVwGIRPTW1ijT38J+xsLiw+rVin6ZpnLyAG0D0kEScQW1cD23CHYdJs4lA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ll0KhGv9; 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="Ll0KhGv9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 239421F00ADF; Mon, 20 Jul 2026 09:41:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784540511; bh=s4jbJCk0MIt/tKtdttBQh+IuMs35M4ljrNdM4eJfkeQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Ll0KhGv9FaqutWrqFcBb+qcq5cT9hMGiehhxTXGhKYUSntBuRX02sgbya17+zUyF8 raTn4SNyoI7tycRz2QBmc7YSn+dCI8EuXZ/0S3N8z2Y2moSxGDbRqVPtbljqahAuZY s0IEH44zQH1WP+FdmAQKGjqeJmjLV7AXRKGenHJCJzraWTUTqzsF56TlTbh5I3etSe Hx4ZIDvEu2q3hiZazwZqdy97RYe8Hsj+xcH8CpOBcad2rQurKK1tJ47fBGQLIUFZhQ B+nxW2gAdIMkGcbfmB7lHOy67BW1zbmFPmEt45UuveUG9xn6N6Pso3QG7/RPXznNy3 rnpJPhO6azp/g== From: Thomas Gleixner To: Alexander Wilhelm Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 2/2] irqchip/ls-scfg-msi: enable multi-MSI allocation In-Reply-To: <20260716-irqchip-ls-scfg-msi-add-multi-msi-support-v1-2-9795356d0ebc@westermo.com> References: <20260716-irqchip-ls-scfg-msi-add-multi-msi-support-v1-0-9795356d0ebc@westermo.com> <20260716-irqchip-ls-scfg-msi-add-multi-msi-support-v1-2-9795356d0ebc@westermo.com> Date: Mon, 20 Jul 2026 11:41:48 +0200 Message-ID: <87fr1engkj.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Jul 16 2026 at 12:15, Alexander Wilhelm wrote: > Add MSI_FLAG_MULTI_PCI_MSI to the parent domain's supported flags so PCI > devices can request more than one contiguous MSI vector. The previous > refactor to bitmap_find_free_region() already handles arbitrary > power-of-two orders, so drop the WARN_ON(nr_irqs != 1) guard. Same comment vs. changelog as before. > In practice, multi-MSI requires the 'no-affinity' MSIR routing, because > affinity mode only releases every (1 << ibs_shift)-th hwirq and therefore > cannot satisfy aligned power-of-two blocks larger than one bit. Statically > pin each MSIR's chained parent IRQ to its matching CPU in that mode: the > low ibs_shift bits of the hwirq then select both the MSIR and the target > CPU, giving each MSI vector a deterministic target CPU without runtime > migration. > + } else { > msir->srs = index; > + /* Statically pin each MSIR to its matching CPU */ This wants some explanation of the WHY in the comment. > + if (index < num_possible_cpus()) > + irq_set_affinity(msir->gic_irq, get_cpu_mask(index)); > + } Thanks, tglx