[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1601281116310.3886@nanos>
Date: Thu, 28 Jan 2016 11:29:21 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Brian Starkey <brian.starkey@....com>
cc: linux-kernel@...r.kernel.org, marc.zyngier@....com
Subject: Re: [PATCH] genirq: fix trigger flags check for shared irqs
Brian,
On Thu, 28 Jan 2016, Brian Starkey wrote:
> On Tue, Jan 26, 2016 at 09:45:32PM +0100, Thomas Gleixner wrote:
> > On Tue, 26 Jan 2016, Brian Starkey wrote:
> >
> > > For shared interrupts, if one requester passes in any IRQF_TRIGGER_*
> > > flags whilst another doesn't, __setup_irq() can erroneously fail.
> > >
> > > The no-flags case should be treated as "already configured", so change
> > > __setup_irq() to only check that the flags match if any have been
> > > provided.
> >
> > What happens if that "already configured", i.e. the default setting, is
> > conflicting with the newly requested interrupt?
> >
> > I rather prefer the failure than the resulting silent wreckage.
> >
>
> Yes, I agree that would be best avoided. It seems to me that this case
> is actually handled a bit lower down:
>
> } else if (new->flags & IRQF_TRIGGER_MASK) {
> unsigned int nmsk = new->flags & IRQF_TRIGGER_MASK;
> unsigned int omsk = irq_settings_get_trigger_mask(desc);
>
> if (nmsk != omsk)
> /* hope the handler works with current trigger mode
> */
> pr_warning("irq %d uses trigger mode %u; requested
> %u\n",
> irq, nmsk, omsk);
> }
>
> Perhaps that should be louder/fatal?
Perhaps. So what's the actual problem case you are trying to solve?
Thanks,
tglx
Powered by blists - more mailing lists