From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Chen Liqin <liqin.chen@sunplusct.com>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Guan Xuetao <gxt@mprc.pku.edu.cn>,
Lennox Wu <lennox.wu@gmail.com>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Russell King <linux@arm.linux.org.uk>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>,
x86@kernel.org, "James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Matt Turner <mattst88@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf <cmetcalf@tilera.com>,
Mikael Starvik <starvik@axis.com>, Ivan Kokshaysky <>
Subject: Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
Date: Tue, 14 Jun 2011 23:33:15 +0200 [thread overview]
Message-ID: <201106142333.16203.arnd@arndb.de> (raw)
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Chen Liqin <liqin.chen@sunplusct.com>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Guan Xuetao <gxt@mprc.pku.edu.cn>,
Lennox Wu <lennox.wu@gmail.com>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Russell King <linux@arm.linux.org.uk>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>,
x86@kernel.org, "James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Matt Turner <mattst88@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf <cmetcalf@tilera.com>,
Mikael Starvik <starvik@axis.com>
Subject: Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
Date: Tue, 14 Jun 2011 23:33:15 +0200 [thread overview]
Message-ID: <201106142333.16203.arnd@arndb.de> (raw)
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Chen Liqin <liqin.chen@sunplusct.com>,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Guan Xuetao <gxt@mprc.pku.edu.cn>,
Lennox Wu <lennox.wu@gmail.com>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Russell King <linux@arm.linux.org.uk>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>,
x86@kernel.org, "James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Matt Turner <mattst88@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf <cmetcalf@tilera.com>,
Mikael Starvik <starvik@axis.com>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Henderson <rth@twiddle.net>,
Chris Zankel <chris@zankel.net>, Michal Simek <monstr@monstr.eu>,
Tony Luck <tony.luck@intel.com>,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Kyle McMartin <kyle@mcmartin.ca>,
Paul Mundt <lethal@linux-sh.org>,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
Date: Tue, 14 Jun 2011 23:33:15 +0200 [thread overview]
Message-ID: <201106142333.16203.arnd@arndb.de> (raw)
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Chen Liqin <liqin.chen@sunplusct.com>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Guan Xuetao <gxt@mprc.pku.edu.cn>,
Lennox Wu <lennox.wu@gmail.com>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Russell King <linux@arm.linux.org.uk>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>,
x86@kernel.org, "James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Matt Turner <mattst88@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf <cmetcalf@tilera.com>,
Mikael Starvik <starvik@axis.com>, Ivan Kokshaysky <
Subject: Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
Date: Tue, 14 Jun 2011 23:33:15 +0200 [thread overview]
Message-ID: <201106142333.16203.arnd@arndb.de> (raw)
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Chen Liqin <liqin.chen@sunplusct.com>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, Guan Xuetao <gxt@mprc.pku.edu.cn>,
Lennox Wu <lennox.wu@gmail.com>,
linux-arch@vger.kernel.org,
Jesper Nilsson <jesper.nilsson@axis.com>,
Russell King <linux@arm.linux.org.uk>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>,
x86@kernel.org, "James E.J. Bottomley" <jejb@parisc-linux.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Matt Turner <mattst88@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf <cmetcalf@tilera.com>,
Mikael Starvik <starvik@axis.com>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Henderson <rth@twiddle.net>,
Chris Zankel <chris@zankel.net>, Michal Simek <monstr@monstr.eu>,
Tony Luck <tony.luck@intel.com>,
linux-cris-kernel@axis.com, linux-parisc@vger.kernel.org,
linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Kyle McMartin <kyle@mcmartin.ca>,
Paul Mundt <lethal@linux-sh.org>,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
Date: Tue, 14 Jun 2011 23:33:15 +0200 [thread overview]
Message-ID: <201106142333.16203.arnd@arndb.de> (raw)
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC,PATCH] Cleanup PC parallel port Kconfig
Date: Tue, 14 Jun 2011 23:33:15 +0200 [thread overview]
Message-ID: <201106142333.16203.arnd@arndb.de> (raw)
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
next prev parent reply other threads:[~2011-06-14 21:33 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 19:08 [RFC,PATCH] Cleanup PC parallel port Kconfig Ralf Baechle
2011-06-14 19:08 ` Ralf Baechle
2011-06-14 19:08 ` Ralf Baechle
2011-06-14 19:08 ` Ralf Baechle
2011-06-14 19:08 ` Ralf Baechle
2011-06-14 20:22 ` Arnd Bergmann
2011-06-14 20:22 ` Arnd Bergmann
2011-06-14 20:22 ` Arnd Bergmann
2011-06-14 20:22 ` Arnd Bergmann
2011-06-14 20:22 ` Arnd Bergmann
2011-06-14 20:22 ` Arnd Bergmann
2011-06-15 8:02 ` Lennox Wu
2011-06-15 8:02 ` Lennox Wu
2011-06-15 8:02 ` Lennox Wu
2011-06-15 8:02 ` Lennox Wu
2011-06-14 20:25 ` H. Peter Anvin
2011-06-14 20:25 ` H. Peter Anvin
2011-06-14 20:25 ` H. Peter Anvin
2011-06-14 20:25 ` H. Peter Anvin
2011-06-14 20:25 ` H. Peter Anvin
2011-06-14 21:33 ` Arnd Bergmann [this message]
2011-06-14 21:33 ` Arnd Bergmann
2011-06-14 21:33 ` Arnd Bergmann
2011-06-14 21:33 ` Arnd Bergmann
2011-06-14 21:33 ` Arnd Bergmann
2011-06-14 21:33 ` Arnd Bergmann
2011-06-15 4:30 ` H. Peter Anvin
2011-06-15 4:30 ` H. Peter Anvin
2011-06-15 4:30 ` H. Peter Anvin
2011-06-15 4:30 ` H. Peter Anvin
2011-06-15 7:47 ` Russell King - ARM Linux
2011-06-15 7:47 ` Russell King - ARM Linux
2011-06-15 7:47 ` Russell King - ARM Linux
2011-06-15 7:47 ` Russell King - ARM Linux
2011-06-15 7:47 ` Russell King - ARM Linux
2011-06-15 15:08 ` H. Peter Anvin
2011-06-15 15:08 ` H. Peter Anvin
2011-06-15 15:08 ` H. Peter Anvin
2011-06-15 15:08 ` H. Peter Anvin
2011-06-15 15:21 ` Russell King - ARM Linux
2011-06-15 15:21 ` Russell King - ARM Linux
2011-06-15 15:21 ` Russell King - ARM Linux
2011-06-15 15:21 ` Russell King - ARM Linux
2011-06-15 15:21 ` Russell King - ARM Linux
2011-06-15 9:46 ` Arnd Bergmann
2011-06-15 9:46 ` Arnd Bergmann
2011-06-15 9:46 ` Arnd Bergmann
2011-06-15 9:46 ` Arnd Bergmann
2011-06-15 11:24 ` Geert Uytterhoeven
2011-06-15 11:24 ` Geert Uytterhoeven
2011-06-15 11:24 ` Geert Uytterhoeven
2011-06-15 11:24 ` Geert Uytterhoeven
2011-06-15 11:24 ` Geert Uytterhoeven
2011-06-14 22:34 ` Ralf Baechle
2011-06-14 22:34 ` Ralf Baechle
2011-06-14 22:34 ` Ralf Baechle
2011-06-14 22:34 ` Ralf Baechle
2011-06-15 4:18 ` H. Peter Anvin
2011-06-15 4:18 ` H. Peter Anvin
2011-06-15 4:18 ` H. Peter Anvin
2011-06-15 4:18 ` H. Peter Anvin
2011-06-15 4:18 ` H. Peter Anvin
2011-06-15 4:40 ` Guenter Roeck
2011-06-15 4:40 ` Guenter Roeck
2011-06-15 4:40 ` Guenter Roeck
2011-06-15 4:40 ` Guenter Roeck
2011-06-15 4:40 ` Guenter Roeck
2011-06-15 5:43 ` H. Peter Anvin
2011-06-15 5:43 ` H. Peter Anvin
2011-06-15 5:43 ` H. Peter Anvin
2011-06-15 5:43 ` H. Peter Anvin
2011-06-15 5:43 ` H. Peter Anvin
2011-06-15 8:34 ` Ralf Baechle
2011-06-15 8:34 ` Ralf Baechle
2011-06-15 8:34 ` Ralf Baechle
2011-06-15 8:34 ` Ralf Baechle
2011-06-15 8:34 ` Ralf Baechle
2011-06-15 14:36 ` Guenter Roeck
2011-06-15 14:36 ` Guenter Roeck
2011-06-15 14:36 ` Guenter Roeck
2011-06-15 14:36 ` Guenter Roeck
2011-06-15 14:36 ` Guenter Roeck
2011-06-14 20:32 ` Geert Uytterhoeven
2011-06-14 20:32 ` Geert Uytterhoeven
2011-06-14 20:32 ` Geert Uytterhoeven
2011-06-14 20:32 ` Geert Uytterhoeven
2011-06-14 20:32 ` Geert Uytterhoeven
2011-06-14 22:08 ` Luck, Tony
2011-06-14 22:08 ` Luck, Tony
2011-06-14 22:08 ` Luck, Tony
2011-06-14 22:08 ` Luck, Tony
2011-06-14 22:08 ` Luck, Tony
2011-06-15 4:31 ` H. Peter Anvin
2011-06-15 4:31 ` H. Peter Anvin
2011-06-15 4:31 ` H. Peter Anvin
2011-06-15 4:31 ` H. Peter Anvin
2011-06-15 4:31 ` H. Peter Anvin
2011-06-15 7:39 ` Russell King - ARM Linux
2011-06-15 7:39 ` Russell King - ARM Linux
2011-06-15 7:39 ` Russell King - ARM Linux
2011-06-15 7:39 ` Russell King - ARM Linux
2011-06-15 7:39 ` Russell King - ARM Linux
2011-06-15 15:16 ` H. Peter Anvin
2011-06-15 15:16 ` H. Peter Anvin
2011-06-15 15:16 ` H. Peter Anvin
2011-06-15 15:16 ` H. Peter Anvin
2011-06-15 15:16 ` H. Peter Anvin
2011-06-15 1:24 ` Guan Xuetao
2011-06-15 1:24 ` Guan Xuetao
2011-06-15 1:24 ` Guan Xuetao
2011-06-15 1:24 ` Guan Xuetao
2011-06-15 1:24 ` Guan Xuetao
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=201106142333.16203.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=cmetcalf@tilera.com \
--cc=deller@gmx.de \
--cc=fenghua.yu@intel.com \
--cc=geert@linux-m68k.org \
--cc=gxt@mprc.pku.edu.cn \
--cc=hpa@zytor.com \
--cc=jejb@parisc-linux.org \
--cc=jesper.nilsson@axis.com \
--cc=lennox.wu@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=liqin.chen@sunplusct.com \
--cc=mattst88@gmail.com \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=sparclinux@vger.kernel.org \
--cc=starvik@axis.com \
--cc=x86@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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.