Re: [PATCH v5 4/5] Driver core: platform: Add devm_platform_get_irqs_affinity()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux