[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201304191614.19821.arnd@arndb.de>
Date: Fri, 19 Apr 2013 16:14:19 +0200
From: Arnd Bergmann <arnd@...db.de>
To: "Uwe Kleine-König"
<u.kleine-koenig@...gutronix.de>
Cc: Thomas Gleixner <tglx@...utronix.de>, kernel@...gutronix.de,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Jonathan Austin <jonathan.austin@....com>,
Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH v3] irqchip: Add support for ARMv7-M's NVIC
On Friday 19 April 2013, Uwe Kleine-König wrote:
> On Thu, Apr 18, 2013 at 11:38:13AM +0200, Arnd Bergmann wrote:
> > On Thursday 18 April 2013, Uwe Kleine-König wrote:
> > > That is, there are (INTLINESNUM + 1) * 32 irqs for INTLINESNUM < 15. For
> > > INTLINESNUM == 15 there are only 496 and not 16 * 32 == 512. That's the
> > > same on the gic (just with bigger numbers).
> >
> > Ok, but since you are now using a linear domain, it doesn't actually hurt
> > to register 512 in that special case, right?
> Well, it depends if allocating space for 16 unused unsigned ints hurts
> (maybe not).
As long as SPARSE_IRQ is enabled, the space won't actually be allocated.
> And it makes mapping some irqs successfull while the irq
> doesn't really exist. But probably this doesn't hurt either because the
> problem already exists.
>
> I don't care much. Is there another advantage beside saving a few source
> lines/instructions?
It just feels strange to read the value from hardware and then override
it anyway. But I agree it's not important either way.
Arnd
--
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/
Powered by blists - more mailing lists