On 07/08/2019 15:43, Linus Walleij wrote:
> Hi Masahiro,
>
> On Thu, Jul 18, 2019 at 1:12 PM Masahiro Yamada
> <yamada.masahiro@xxxxxxxxxxxxx> wrote:
>> On Mon, Jun 24, 2019 at 10:25 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
>>> +static int gpiochip_hierarchy_irq_domain_alloc(struct irq_domain *d,
>>> + unsigned int irq,
>>> + unsigned int nr_irqs,
>>> + void *data)
>>> +{
>>> + struct gpio_chip *gc = d->host_data;
>>> + irq_hw_number_t hwirq;
>>> + unsigned int type = IRQ_TYPE_NONE;
>>> + struct irq_fwspec *fwspec = data;
>>> + int ret;
>>> + int i;
>>
>> We always expect nr_irqs is 1.
>>
>> As gpio-uniphier.c, you can error out with WARN_ON
>> if nr_irqs != 1
>
> Hm, yes I am pretty sure it is always 1.
>
> But I'd like to defer changing this until/if Marc changes
> the signature of the function to not pass nr_irqs anymore.
> I try to design for the current prototype because I don't
> know how e.g. ACPI works with respect to this.
nr_irqs is only here for one single case: PCI Multi-MSI, where we have
to allocate a bunch of contiguous hwirqs. In all other cases, nr_irqs is
always 1.
So yes, you can safely assume nr_irqs == 1, and WARN_ON otherwise.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
