On 12/08/2024 21:29, Bart Van Assche wrote:
On 8/12/24 3:46 AM, John Garry wrote:
On 09/08/2024 19:11, Bart Van Assche wrote:
On 12/2/20 2:36 AM, John Garry wrote:
+ for (i = 0; i < nvec; i++) {
+ int irq = platform_get_irq(dev, i);
+ if (irq < 0) {
+ ret = irq;
+ goto err_free_devres;
+ }
+ ptr->irq[i] = irq;
+ }
(replying to an email from four years ago)
Why does this function call platform_get_irq(dev, i) instead of
platform_get_irq(dev, affd->pre_vectors + i)? Is there perhaps something
about the hisi_sas driver that I'm missing? I'm asking this because this
function would be useful for UFS controller drivers if the
affd->pre_vectors offset would be added when calling platform_get_irq().
int devm_platform_get_irqs_affinity(struct platform_device *dev,
struct irq_affinity *affd,
unsigned int minvec,
unsigned int maxvec,
int **irqs)
Function devm_platform_get_irqs_affinity() gets the irq number for a
total between @minvec and @maxvec interrupts, and fills them into
@irqs arg. It does not just get the interrupts for index @minvec to
@maxvec only.
For context, as I remember, hisi_sas v2 hw has 128 interrupts lines.
Interrupts index [96, 112) are completion queue interrupts, which we
want to spread over all CPUs. See interrupt_init_v2_hw() in that
driver for how the control interrupts, like phy up/down, are used.
Hi John,
In interrupt_init_v2_hw() and also elsewhere in the hisi_sas_v2_hw.c
source file I see that the CQ interrupts start at offset 96. However,
devm_platform_get_irqs_affinity() passes the arguments 0..(num_cqs-1) to
Total interrupt lines are 128.
dec.{pre, post}_vectors = {96, 16}
which gives
resv=96+16=112
minvec=resv+1 = 113
maxvec=128
platform_get_irq(). Shouldn't that function pass arguments in the range
96..(96+num_cqs-1) to platform_get_irq() since that is the CQ interrupt
range for this storage controller?
The API is trying to be like pci_alloc_irq_vectors_affinity(), where it
accepts a min and max vectors to allocate.
platform_get_irq() actually does more than just do some lookup for an
irq number - it also sets up a mapping if it does not already exist.
Furthermore, as I recall, maybe platform msi code or mbigen code or hisi
chipset had a restriction that platform_get_irq() had to be called in
order for each and every interrupt line. So having a single point to do
this made sense. Check interrupt_init_v2_hw() code and comment prior to
devm_platform_get_irqs_affinity() existing, like a v5.10 kernel - it
called platform_get_irq() for all 128 interrupt lines.
My understanding is that the
devm_platform_get_irqs_affinity() call from hisi_sas_v2_hw.c will affect
the affinity of the interrupts 0..(num_cqs-1) instead of the interrupts
in the range 96..(96+num_cqs-1). Isn't that wrong?
devm_platform_get_irqs_affinity() will only touch the affinity mapping
of the completion queue interrupts, but still call platform_get_irq()
for all interrupts
