linux-kernel - Re: [PATCH v5 3/3] gpio: grgpio: Add irq support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACRpkdbXFBBetC9uh=AWVNV86oA1S2Ls1dNCMOj8iAur7V2E3w@mail.gmail.com>
Date:	Tue, 23 Apr 2013 13:14:51 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Andreas Larson <andreas@...sler.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>, software@...sler.com
Subject: Re: [PATCH v5 3/3] gpio: grgpio: Add irq support

On Mon, Apr 15, 2013 at 2:38 PM, Andreas Larson <andreas@...sler.com> wrote:

> On 2013-04-10 21:25, Linus Walleij wrote:
>>> +int grgpio_irq_map(struct irq_domain *d, unsigned int virq,
(...)
>>> +       /* Request underlying irq if not already requested */
>>> +       lirq->virq = virq;
>>> +       uirq = &priv->uirqs[lirq->index];
>>> +       if (uirq->refcnt == 0) {
>>> +               ret = request_irq(uirq->uirq, grgpio_irq_handler, 0,
>>> +                                 dev_name(priv->dev), priv);
>>
>>
>> No, please request all present uirqs in probe() before creating the
>> irqdomain.
>
>
> The reason for doing it at irq_map and not in probe is that one
> typical hardware setup for this core is that it has irqs that are shared
> with pretty much all other cores in the system. Therefore, if this
> drivers requests all its irqs in the probe function, pretty much all the
> drivers for the other cores in the system that were not lucky enough to
> request their irq before this driver will fail their probes in such a
> hardware setup. This driver can not share irq:s so even if the other
> drivers can handle shared irqs they are out of luck if this driver is
> probed first.
>
> That is why only the irqs that are actually used should be requested and
> thus why the driver does it on demand instead of in the probe.

OK I buy that explanation...

Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/