[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1704181451500.1659@nanos>
Date: Tue, 18 Apr 2017 14:54:32 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: David Howells <dhowells@...hat.com>
cc: LKML <linux-kernel@...r.kernel.org>, gnomes@...rguk.ukuu.org.uk,
gregkh@...uxfoundation.org,
Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
Jens Rottmann <JRottmann@...PERTEmbedded.de>,
Andres Salomon <dilinger@...ued.net>
Subject: Re: [PATCH 06/38] Annotate hardware config module parameters in
drivers/clocksource/
On Tue, 18 Apr 2017, David Howells wrote:
> Thomas Gleixner <tglx@...utronix.de> wrote:
>
> > > > > Btw, is it possible to use IRQ grants to prevent a device that has limited
> > > > > IRQ options from being drivable?
> > > >
> > > > What do you mean with 'IRQ grants' ?
> > >
> > > request_irq().
> >
> > I still can't parse the sentence above. If request_irq() fails the device
> > initialization fails. If you request the wrong irq then request_irq() might
> > succeed but the device won't work.
>
> I was talking about having using a driver to make request_irq() grant an irq
> to that driver so that another driver can't bind to its device because all its
> irq options are taken and the irqs can't be shared.
Yes. That's possible.
init_driver1()
request_irq(X, flags,.....);
init_driver2()
request_irq(X, flags,.....);
The second driver can fail, when flags are not matching. That might be
disagreement about SHARED or the trigger type, i.e. egde vs. level.
Thanks,
tglx
Powered by blists - more mailing lists