[PATCH v4 2/4] gpio: visconti: Add Toshiba Visconti GPIO support

[Nobuhiro Iwamatsu]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>