Re: [PATCH v4 2/4] gpio: visconti: Add Toshiba Visconti GPIO support
From: Nobuhiro Iwamatsu
Date: Thu Dec 17 2020 - 00:21:15 EST
Hi,
On Wed, Dec 16, 2020 at 09:36:17AM +0000, Marc Zyngier wrote:
> On 2020-12-16 09:11, Nobuhiro Iwamatsu wrote:
>
> [...]
>
> > > > + for (i = 0; i < num_irq; i++) {
> > > > + desc = irq_to_desc(priv->irq[i]);
> > > > + desc->status_use_accessors |= IRQ_NOAUTOEN;
> > > > + if (devm_request_irq(dev, priv->irq[i],
> > > > + visconti_gpio_irq_handler, 0, name, priv)) {
> > > > + dev_err(dev, "failed to request IRQ[%d]\n", i);
> > > > + return -ENOENT;
> > > > + }
> > > > + }
> > >
> > > This should not be needed either when using hiearchical IRQs,
> > > also the irqchip maintainers will beat us up for poking around in the
> > > descs like this.
> >
> > I understand that the processing equivalent to request_irq() is
> > processed
> > by the irqchip frame work (or GIC driver). Is this correct?
>
> request_irq() is reserved to endpoint drivers (the driver for the device
> driving the IRQ line). If this is indeed a hierarchical irqchip, the
> line allocation will be driven from the GPIO framework, and request_irq()
> will perform the activation. There isn't anything that this driver should
> do directly other than configuring its own state and passing the request
> along to the parent controller.
>
> And yes, mucking with the irq descriptor will get you in massive trouble,
> never do that.
>
I see. Thank you for the explanation.
I got a better understanding.
Best regards,
Nobuhiro
> --
> Jazz is not dead. It just smells funny...
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>