linux-kernel - Re: [PATCH v4 2/4] gpio: visconti: Add Toshiba Visconti GPIO support

Open Source and information security mailing list archives

Message-ID: <20201217051021.x57bigbbdmc7uj7w@toshiba.co.jp>
Date:   Thu, 17 Dec 2020 14:10:21 +0900
From:   Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>
To:     Marc Zyngier <maz@...nel.org>
Cc:     "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Punit Agrawal <punit1.agrawal@...hiba.co.jp>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>, yuji2.ishikawa@...hiba.co.jp,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives