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
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? 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?
Thanks,
Bart.
