From: Arnd Bergmann <arnd@arndb.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Mike Frysinger <vapier@gentoo.org>,
linux-kernel@vger.kernel.org,
Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH] asm-generic: hard_irqs: handle NR_IRQS > 256 automatically
Date: Sat, 13 Jun 2009 23:18:18 +0200 [thread overview]
Message-ID: <200906132318.19208.arnd@arndb.de> (raw)
In-Reply-To: <4A33E892.6010704@zytor.com>
On Saturday 13 June 2009, H. Peter Anvin wrote:
> Mike Frysinger wrote:
> > If we're going to automatically set HARDIRQ_BITS for the arch, might as
> > well be a little bit smart about it and set it to 9 automatically if
> > NR_IRQS is larger than 8 bits.
> >
>
> Why would the only possible values be 8 or 9?
All architectures that define this either set it to 8 or 9, I chose
8 because it is the more common constant, but I now realized that
we also have (in include/linux/hardirq.h, last touched by Steven):
#define MAX_HARDIRQ_BITS 10
#ifndef HARDIRQ_BITS
# define HARDIRQ_BITS MAX_HARDIRQ_BITS
#endif
#if HARDIRQ_BITS > MAX_HARDIRQ_BITS
#error HARDIRQ_BITS too high!
#endif
Not sure why we even need to make this overridable from the architecture,
10 still seems like a reasonable default that should always work.
I'd suggest we either drop the definition for HARDIRQ_BITS from
asm-generic/hardirq.h, or we use
#ifndef HARDIRQ_BITS
-#define HARDIRQ_BITS 8
+# if NR_IRQS > 255
+# define HARDIRQ_BITS 9
+# elif NR_IRQS > 511
+# define HARDIRQ_BITS 10
+# elif NR_IRQS > 1023
+# warning too many interrupts for HARDIRQ_BITS
+# endif
#endif
Arnd <><
next prev parent reply other threads:[~2009-06-13 21:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-13 14:30 [PATCH] asm-generic: uaccess: fix up local access_ok() usage Mike Frysinger
2009-06-13 14:30 ` [PATCH] asm-generic: hard_irqs: handle NR_IRQS > 256 automatically Mike Frysinger
2009-06-13 17:57 ` H. Peter Anvin
2009-06-13 21:18 ` Arnd Bergmann [this message]
2009-06-14 0:25 ` Mike Frysinger
2009-06-14 20:43 ` [PATCH] asm-generic: drop HARDIRQ_BITS definition from hardirq.h Arnd Bergmann
2009-06-15 15:59 ` Steven Rostedt
2009-06-15 16:17 ` Mike Frysinger
2009-06-15 16:44 ` Steven Rostedt
2009-06-16 14:37 ` [PATCH v3] " Arnd Bergmann
2009-06-13 15:59 ` [PATCH] asm-generic: uaccess: fix up local access_ok() usage Mike Frysinger
2009-06-13 20:53 ` Arnd Bergmann
2009-06-14 0:47 ` Mike Frysinger
2009-06-14 10:10 ` Arnd Bergmann
2009-06-14 10:17 ` Mike Frysinger
2009-06-14 10:24 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906132318.19208.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=srostedt@redhat.com \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.