[PATCH] alpha build fixes

[PATCH] alpha build fixes

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

Needed this to build Fedora rawhide kernel (2.6.12-rc1 + some patches) 
on alpha.  This is the upstream portion of the build fixes.

Signed-off-by: Jeff Garzik <jgarzik@pobox.com>


[-- Attachment #2: kernel-build1.patch --]
[-- Type: text/x-patch, Size: 2566 bytes --]

diff -urN ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/agp/generic.c linux-2.6.11/drivers/char/agp/generic.c
--- ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/agp/generic.c	2005-03-18 16:45:23.000000000 -0500
+++ linux-2.6.11/drivers/char/agp/generic.c	2005-03-18 18:34:00.000000000 -0500
@@ -35,6 +35,7 @@
 #include <linux/pm.h>
 #include <linux/agp_backend.h>
 #include <linux/vmalloc.h>
+#include <linux/dma-mapping.h>
 #include <linux/mm.h>
 #include <asm/io.h>
 #include <asm/cacheflush.h>
diff -urN ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/pci.h linux-2.6.11/include/asm-alpha/pci.h
--- ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/pci.h	2005-03-02 02:38:34.000000000 -0500
+++ linux-2.6.11/include/asm-alpha/pci.h	2005-03-18 18:39:31.000000000 -0500
@@ -223,6 +223,12 @@
 	/* Nothing to do. */
 }
 
+/* TODO: integrate with include/asm-generic/pci.h ? */
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+	return channel ? 15 : 14;
+}
+
 extern void pcibios_resource_to_bus(struct pci_dev *, struct pci_bus_region *,
 				    struct resource *);
 
diff -urN ../kernel-2.6.11.orig/linux-2.6.11/include/linux/debugfs.h linux-2.6.11/include/linux/debugfs.h
--- ../kernel-2.6.11.orig/linux-2.6.11/include/linux/debugfs.h	2005-03-02 02:38:33.000000000 -0500
+++ linux-2.6.11/include/linux/debugfs.h	2005-03-18 18:14:12.000000000 -0500
@@ -15,6 +15,8 @@
 #ifndef _DEBUGFS_H_
 #define _DEBUGFS_H_
 
+#include <linux/fs.h>
+
 #if defined(CONFIG_DEBUG_FS)
 struct dentry *debugfs_create_file(const char *name, mode_t mode,
 				   struct dentry *parent, void *data,
diff -ur ../kernel-2.6.11.orig/linux-2.6.11/drivers/atm/lanai.c linux-2.6.11/drivers/atm/lanai.c
--- ../kernel-2.6.11.orig/linux-2.6.11/drivers/atm/lanai.c	2005-03-18 20:06:31.000000000 -0500
+++ linux-2.6.11/drivers/atm/lanai.c	2005-03-18 20:36:19.000000000 -0500
@@ -61,6 +61,7 @@
 #include <asm/byteorder.h>
 #include <linux/spinlock.h>
 #include <linux/pci.h>
+#include <linux/dma-mapping.h>
 #include <linux/init.h>
 #include <linux/delay.h>
 #include <linux/interrupt.h>
diff -ur ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/tpm/tpm.h linux-2.6.11/drivers/char/tpm/tpm.h
--- ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/tpm/tpm.h	2005-03-18 20:06:31.000000000 -0500
+++ linux-2.6.11/drivers/char/tpm/tpm.h	2005-03-18 20:50:31.000000000 -0500
@@ -22,6 +22,7 @@
 #include <linux/version.h>
 #include <linux/pci.h>
 #include <linux/delay.h>
+#include <linux/fs.h>
 #include <linux/miscdevice.h>
 
 #define TPM_TIMEOUT msecs_to_jiffies(5)

Re: [PATCH] alpha build fixes

[Richard Henderson]

On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> +/* TODO: integrate with include/asm-generic/pci.h ? */
> +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> +{
> +	return channel ? 15 : 14;
> +}

Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
Why in the world would we have this much infrastructure for one driver?  And
why not just not compile that one for Alpha, since it'll never be used.


r~

Re: [PATCH] alpha build fixes

[Jeff Garzik]

On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > +	return channel ? 15 : 14;
> > +}
> 
> Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> Why in the world would we have this much infrastructure for one driver?  And
> why not just not compile that one for Alpha, since it'll never be used.

My presumption is that it will be used in other IDE drivers in the
future.  Bart?

If it will only be used in that one driver, then I agree.

	Jeff

Re: [PATCH] alpha build fixes

[Bartlomiej Zolnierkiewicz]

On Sat, 19 Mar 2005 18:16:41 -0500, Jeff Garzik <jgarzik@pobox.com> wrote:
> On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > > +{
> > > +   return channel ? 15 : 14;
> > > +}
> >
> > Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> > Why in the world would we have this much infrastructure for one driver?  And
> > why not just not compile that one for Alpha, since it'll never be used.
> 
> My presumption is that it will be used in other IDE drivers in the
> future.  Bart?

This code is meant to be used by other IDE/libata drivers.

[ Original thread can be found in linux-ide ML archive. ]

Re: [PATCH] alpha build fixes

[Ivan Kokshaysky]

On Mon, Mar 21, 2005 at 09:05:39AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sat, 19 Mar 2005 18:16:41 -0500, Jeff Garzik <jgarzik@pobox.com> wrote:
> > On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> > > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > > > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > > > +{
> > > > +   return channel ? 15 : 14;
> > > > +}
> > >
> > > Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> > > Why in the world would we have this much infrastructure for one driver?  And
> > > why not just not compile that one for Alpha, since it'll never be used.
> > 
> > My presumption is that it will be used in other IDE drivers in the
> > future.  Bart?
> 
> This code is meant to be used by other IDE/libata drivers.

Then isn't linux/ide.h the proper place for default pci_get_legacy_ide_irq()
implementation instead of asm-generic/pci.h? The latter is only used by
7 out of 23 architectures, so not only alpha gets broken.

Ivan.

Re: [PATCH] alpha build fixes

[Bartlomiej Zolnierkiewicz]

On Mon, 21 Mar 2005 12:16:16 +0300, Ivan Kokshaysky
<ink@jurassic.park.msu.ru> wrote:
> On Mon, Mar 21, 2005 at 09:05:39AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Sat, 19 Mar 2005 18:16:41 -0500, Jeff Garzik <jgarzik@pobox.com> wrote:
> > > On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> > > > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > > > > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > > > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > > > > +{
> > > > > +   return channel ? 15 : 14;
> > > > > +}
> > > >
> > > > Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> > > > Why in the world would we have this much infrastructure for one driver?  And
> > > > why not just not compile that one for Alpha, since it'll never be used.
> > >
> > > My presumption is that it will be used in other IDE drivers in the
> > > future.  Bart?
> >
> > This code is meant to be used by other IDE/libata drivers.
> 
> Then isn't linux/ide.h the proper place for default pci_get_legacy_ide_irq()

ide.h is not shared between IDE and libata drivers (but ata.h is)

> implementation instead of asm-generic/pci.h? The latter is only used by
> 7 out of 23 architectures, so not only alpha gets broken.

I'm cc:ing Ben as it was his idea

Re: [PATCH] alpha build fixes

[Benjamin Herrenschmidt]

> > Then isn't linux/ide.h the proper place for default pci_get_legacy_ide_irq()
> 
> ide.h is not shared between IDE and libata drivers (but ata.h is)
> 
> > implementation instead of asm-generic/pci.h? The latter is only used by
> > 7 out of 23 architectures, so not only alpha gets broken.


I'm not sure what the original problem is with alpha, but I added this
call to remove the hard coding of irq numbers in various drivers that
"find" the chip in legacy mode. Instead, I give the arch the opportunity
to provide the actual irq numbers in that case.

IRQs on IDE in legacy mode is sort of an out-of-spec piece of junk that
was invented to make PCI based peecees "look like" good old rotten
hardware, unfortunately, some modern and non-x86 HW vendors still don't
haev a clue and configure (wire in some case) their on board IDE in
legacy mode, but with IRQs that, on those archs, aren't 14 and 15. That
hook fixes the problem on some ppc64 machines but should be extended to
cover various other cases where similar shit happens.

It's in PCI because I figured it was as bad there than anywhere else. In
this case, it's the IDE layer asking the PCI layer "hey, that guy
doesn't respect the normal PCI IRQ mapping, can you tell me how it's
routed ?" :) Back then, I didn't know of a header shared between ide and
libata so I put it there.

Ben.

Re: [PATCH] alpha build fixes

[Ivan Kokshaysky]

On Mon, Mar 21, 2005 at 11:27:39PM +1100, Benjamin Herrenschmidt wrote:
> IRQs on IDE in legacy mode is sort of an out-of-spec piece of junk that
> was invented to make PCI based peecees "look like" good old rotten
> hardware, unfortunately, some modern and non-x86 HW vendors still don't
> haev a clue and configure (wire in some case) their on board IDE in
> legacy mode, but with IRQs that, on those archs, aren't 14 and 15. That
> hook fixes the problem on some ppc64 machines but should be extended to
> cover various other cases where similar shit happens.

Indeed, such setup is quite typical for southbridge chips with
integrated IDE controller - they still simulate sort of ISA IRQ
routing...

> It's in PCI because I figured it was as bad there than anywhere else. In
> this case, it's the IDE layer asking the PCI layer "hey, that guy
> doesn't respect the normal PCI IRQ mapping, can you tell me how it's
> routed ?" :) Back then, I didn't know of a header shared between ide and
> libata so I put it there.

Ok, but asm-generic/pci.h is not a good place for default IRQ 14/15 case -
this header cannot be included on non-x86 without additional #ifdef's.
Perhaps we can move it to linux/pci.h or linux/ata.h (as Bart noted)?

Ivan.

Re: [PATCH] alpha build fixes

[Benjamin Herrenschmidt]

> 
> Ok, but asm-generic/pci.h is not a good place for default IRQ 14/15 case -
> this header cannot be included on non-x86 without additional #ifdef's.
> Perhaps we can move it to linux/pci.h or linux/ata.h (as Bart noted)?

Well, I would have expected other archs to just make their own, but I
have no special preference here ... linux/pci.h is as good as anything.

Ben.

Re: [PATCH] alpha build fixes

[Alan Cox]

On Sad, 2005-03-19 at 23:11, Richard Henderson wrote:
> On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > +	return channel ? 15 : 14;
> > +}
> 
> Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> Why in the world would we have this much infrastructure for one driver?  And
> why not just not compile that one for Alpha, since it'll never be used.

The issue is bigger - it's needed for the CMD controllers on PA-RISC for
example it appears - and anything else where IDE legacy IRQ is wired
oddly.

Re: [PATCH] alpha build fixes

[Richard Henderson]

On Mon, Mar 21, 2005 at 02:52:10PM +0000, Alan Cox wrote:
> The issue is bigger - it's needed for the CMD controllers on PA-RISC for
> example it appears - and anything else where IDE legacy IRQ is wired
> oddly.

Sure, but who queries this information?  That's my question.


r~

Re: [PATCH] alpha build fixes

[Jeff Garzik]

On Mon, Mar 21, 2005 at 10:16:18AM -0800, Richard Henderson wrote:
> On Mon, Mar 21, 2005 at 02:52:10PM +0000, Alan Cox wrote:
> > The issue is bigger - it's needed for the CMD controllers on PA-RISC for
> > example it appears - and anything else where IDE legacy IRQ is wired
> > oddly.
> 
> Sure, but who queries this information?  That's my question.

IDE drivers.

Since its a detail that varies widely depending on platform, the arch
should either provide it or at least have a way to override it.

linux/pci.h would be fine place for the "generic version arch overrides
with HAVE_ARCH_PCI_IDE_IRQ", or we could fix the asm-generic header to
not need #ifdefs in -your- source just to be usable.

	Jeff

Re: [PATCH] alpha build fixes

[Matthew Wilcox]

[I'm not subscribed, please excuse the thread-breaking]

Alan Cox wrote:
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > + return channel ? 15 : 14;
> > +}
> 
> The issue is bigger - it's needed for the CMD controllers on PA-RISC for
> example it appears - and anything else where IDE legacy IRQ is wired
> oddly.

The built-in IDE controller on the Astro/Elroy based PA-RISC workstations
(B1000, C3000, J5000 and similar) is part of a NS87560 chip.  By default
(and we don't currently touch this), we route the internal interrupts
to Linux interrupts 14 and 15.  We could change that, but I don't currently
see a need to, since we're "the same as x86".  It uses the ns87415 driver.

I don't know what the situation is with the zx1-based boxes, currently only
the C8000.  If it's the same as the ia64 zx1 boxes, it'll have a CMD 649.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

[patch] alpha: build fixes

[Ivan Kokshaysky]

This fixes some of the alpha-specific build problems, except a) modpost
warning about COMMON symbol "saved_config" and b) nasty final link
failure with gcc-4.x, -Os and scsi-disk driver configured built-in
(due to jump table in .rodata referencing discarded .exit.text).

- build failure with gcc-4.2.x: fix up casts in cia_io* routines to avoid
  warnings ('discards qualifiers from pointer target type'), which are
  failures, thanks to -Werror;
- modpost warnings: add missing __init qualifier for titan and marvel;
  for non-generic build, move machine vectors from .data to .data.init.refok
  section;
- unbreak CPU-specific optimization: rearrange cpuflags-y assignments
  so that extended -mcpu value (ev56, pca56, ev67) overrides basic
  one (ev5, ev6) and not vice versa.

Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>

Ivan.

--- 2.6.24-rc5/arch/alpha/Makefile	2007-12-04 13:08:46.000000000 +0300
+++ linux/arch/alpha/Makefile	2007-12-04 13:24:22.000000000 +0300
@@ -14,13 +14,13 @@ LDFLAGS_vmlinux	:= -static -N #-relax
 CHECKFLAGS	+= -D__alpha__ -m64
 cflags-y	:= -pipe -mno-fp-regs -ffixed-8 -msmall-data
 
-cpuflags-$(CONFIG_ALPHA_EV67)		:= -mcpu=ev67
-cpuflags-$(CONFIG_ALPHA_EV6)		:= -mcpu=ev6
+cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4
+cpuflags-$(CONFIG_ALPHA_EV5)		:= -mcpu=ev5
+cpuflags-$(CONFIG_ALPHA_EV56)		:= -mcpu=ev56
 cpuflags-$(CONFIG_ALPHA_POLARIS)	:= -mcpu=pca56
 cpuflags-$(CONFIG_ALPHA_SX164)		:= -mcpu=pca56
-cpuflags-$(CONFIG_ALPHA_EV56)		:= -mcpu=ev56
-cpuflags-$(CONFIG_ALPHA_EV5)		:= -mcpu=ev5
-cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4
+cpuflags-$(CONFIG_ALPHA_EV6)		:= -mcpu=ev6
+cpuflags-$(CONFIG_ALPHA_EV67)		:= -mcpu=ev67
 # If GENERIC, make sure to turn off any instruction set extensions that
 # the host compiler might have on by default.  Given that EV4 and EV5
 # have the same instruction set, prefer EV5 because an EV5 schedule is
--- 2.6.24-rc5/include/asm-alpha/io_trivial.h	2007-10-10 00:31:38.000000000 +0400
+++ linux/include/asm-alpha/io_trivial.h	2007-12-04 14:30:13.000000000 +0300
@@ -72,25 +72,29 @@ IO_CONCAT(__IO_PREFIX,writew)(u16 b, vol
 __EXTERN_INLINE u8
 IO_CONCAT(__IO_PREFIX,readb)(const volatile void __iomem *a)
 {
-	return IO_CONCAT(__IO_PREFIX,ioread8)((void __iomem *)a);
+	void __iomem *addr = (void __iomem *)a;
+	return IO_CONCAT(__IO_PREFIX,ioread8)(addr);
 }
 
 __EXTERN_INLINE u16
 IO_CONCAT(__IO_PREFIX,readw)(const volatile void __iomem *a)
 {
-	return IO_CONCAT(__IO_PREFIX,ioread16)((void __iomem *)a);
+	void __iomem *addr = (void __iomem *)a;
+	return IO_CONCAT(__IO_PREFIX,ioread16)(addr);
 }
 
 __EXTERN_INLINE void
 IO_CONCAT(__IO_PREFIX,writeb)(u8 b, volatile void __iomem *a)
 {
-	IO_CONCAT(__IO_PREFIX,iowrite8)(b, (void __iomem *)a);
+	void __iomem *addr = (void __iomem *)a;
+	IO_CONCAT(__IO_PREFIX,iowrite8)(b, addr);
 }
 
 __EXTERN_INLINE void
 IO_CONCAT(__IO_PREFIX,writew)(u16 b, volatile void __iomem *a)
 {
-	IO_CONCAT(__IO_PREFIX,iowrite16)(b, (void __iomem *)a);
+	void __iomem *addr = (void __iomem *)a;
+	IO_CONCAT(__IO_PREFIX,iowrite16)(b, addr);
 }
 #endif
 
--- 2.6.24-rc5/arch/alpha/kernel/err_marvel.c	Thu Dec  6 14:33:58 2007
+++ linux/arch/alpha/kernel/err_marvel.c	Thu Dec  6 20:14:17 2007
@@ -1152,7 +1152,7 @@ marvel_machine_check(u64 vector, u64 la_
 	mb();
 }
 
-void
+void __init
 marvel_register_error_handlers(void)
 {
 	ev7_register_error_handlers();
--- 2.6.24-rc5/arch/alpha/kernel/machvec_impl.h	Wed Oct 10 00:31:38 2007
+++ linux/arch/alpha/kernel/machvec_impl.h	Thu Dec  6 12:14:57 2007
@@ -134,7 +134,7 @@
 #define __initmv __initdata
 #define ALIAS_MV(x)
 #else
-#define __initmv
+#define __initmv __initdata_refok
 
 /* GCC actually has a syntax for defining aliases, but is under some
    delusion that you shouldn't be able to declare it extern somewhere
--- 2.6.24-rc5/arch/alpha/kernel/err_titan.c	Thu Dec  6 02:11:54 2007
+++ linux/arch/alpha/kernel/err_titan.c	Thu Dec  6 20:03:15 2007
@@ -564,7 +564,7 @@ static struct el_subpacket_handler titan
 	SUBPACKET_HANDLER_INIT(EL_CLASS__REGATTA_FAMILY, 
 			       el_process_regatta_subpacket);
 
-void
+void __init
 titan_register_error_handlers(void)
 {
 	size_t i;
--- 2.6.24-rc5/arch/alpha/kernel/err_ev7.c	Wed Oct 10 00:31:38 2007
+++ linux/arch/alpha/kernel/err_ev7.c	Thu Dec  6 20:02:28 2007
@@ -273,7 +273,7 @@ ev7_process_pal_subpacket(struct el_subp
 struct el_subpacket_handler ev7_pal_subpacket_handler =
 	SUBPACKET_HANDLER_INIT(EL_CLASS__PAL, ev7_process_pal_subpacket);
 
-void
+void __init
 ev7_register_error_handlers(void)
 {
 	int i;