lkml.org 
[lkml]   [2020]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 2/4] gpio: visconti: Add Toshiba Visconti GPIO support
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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

\
 
 \ /
  Last update: 2020-12-17 06:17    [W:0.046 / U:1.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site