linuxsh-dev

Re: [linuxsh-dev] Merging PCI support code.

[David W. <dw...@in...>]

du...@se... said:
> I've tried out the patch on a couple SH7751 based plaforms.  The
> pci-sh7751.c changes work fine as well. 


gn...@m1... said:
>  I've tried and it's fine for DC too.

OK, committed. Thanks for testing.

--
dwmw2

Re: [linuxsh-dev] Clean up memory start/size definitions.

[David W. <dw...@in...>]

gb...@po... said:
> 
>   Fine by me, as long as the "mem=" commandline option still works. I
> use a modification to sh-ipl which probes the size of RAM and builds
> "mem=" for the kernel, because the IDA units come in different RAM
> sizes.

Yep, the only place CONFIG_MEMORY_SIZE is used is in setup.c where we 
previously used a hard-coded 4MiB. If you could override that, you can 
still override CONFIG_MEMORY_SIZE.

--
dwmw2

Re: [linuxsh-dev] Clean up memory start/size definitions.

[Greg B. <gb...@po...>]

David Woodhouse wrote:
> 
> This patch adds a new config variable CONFIG_MEMORY_SIZE, and uses that in
> the initial memory setup instead of a hardcoded 4MiB.
> 
> It also cleans up the nested if statements in the platform-specific
> definitions of CONFIG_MEMORY_START and CONFIG_MEMORY_SIZE.
> 
> I'll commit it soon unless someone complains.

  Fine by me, as long as the "mem=" commandline option still works.
I use a modification to sh-ipl which probes the size of RAM and
builds "mem=" for the kernel, because the IDA units come in
different RAM sizes.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Merging PCI support code.

[NIIBE Y. <gn...@m1...>]

David Woodhouse wrote:
 > Cool, thanks. Unless I hear objections in the meantime I'll merge it when I
 > go into work in the morning.

I've tried and it's fine for DC too.
-- 

[linuxsh-dev] stable SH4 environment

[NIIBE Y. <gn...@m1...>]

Bryan Rittmeyer wrote:
 > 1) What is currently the most stable SH4 kernel version for production
 > use?

I think that it's the one around 2.4.5 but it's slow.  For me, our
2.4.8 is stable but it's not tested much.

 > 2) What is currently the most stable toolchain for building the kernel?
 > Still the 2.97 version described by Masahiro Abe's instructions?
 > 
 > (I'm a little reluctant to use an experimental compiler for production
 > stuff, especially on the kernel)

Yes, it's still 2.97.

I'm trying 3.0 now, with help of Kaz and Takeshi.

However, glibc does not support 3.0 yet, it's difficult to just move
to 3.0.

 > 3) What is the status of gcc 3.0, as we will shortly need it for
 > building user code? (I've heard the kernel and glibc are still
 > most stable/fast when built with older gcc).
 > 
 > I know kaz Kojima has patches here:
 > http://dodo.nurs.or.jp/~kkojima/index.html, but
 > is anyone using them in a real production environment?

I'm currently trying to build (part of ) Debian SH-4 with 3.0.  I
think I will have time for this work at San Francisco this weekend.

 > 4) what is an approximate timeframe for getting binutils and gcc patches
 > for LinuxSH merged with the mainline GNU trees? My work with Linux
 > on the PPC405 has led me to think that this should be a _really_ high
 > priority for all embedded forks of Linux/GNU tools. If my employer
 > allows, I could be able to spend some time assisting in what ever way
 > possible.
 > 
 > Thanks! I'm looking forward to working with all of you again.

Yes, I think so too.  I'm not sure for the timeframe, I expects Kaz
comments for that.  I explain the current status here.

This two weeks, I've tried to provide GNU/SH tool-chain for Debian.
I've done some work based on binutils-2.11.2 and GCC 3.0.1.

I think that binutils is ready for use.  I sent diffs to Takeshi for
comments.  I expect new binutils-sh-linux Debian package comes soon by
Takeshi.  And I sent the needed diff to Kaz for comments, then, he
tried it to current CVS version.  Next comes, send them to mainline
binutils development.

For GCC, I think that it's not ready.  Major concern is the definition
of multilibbed environment.  I built my own Debian gcc-sh-linux 3.0.1
package.  I'm now using this for my experiment, and try to build some
sort of Debian SH-4 distribution with this 3.0.1.  While I'm doing
this week, I encountered issues of name of libgcc shared library, 
still not solved.
-- 

RE: [linuxsh-dev] Merging PCI support code.

[Dustin M. <du...@se...>]

I've tried out the patch on a couple SH7751 based plaforms.  The
pci-sh7751.c changes work fine as well.

Dustin.

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of David
> Woodhouse
> Sent: Thursday, August 23, 2001 10:36 AM
> To: Stuart Menefy
> Cc: lin...@li...
> Subject: Re: [linuxsh-dev] Merging PCI support code.
>
>
>
> Stu...@st... said:
> >  Looks like a good idea to me.
>
> > I've just tested it using the pci_st40.c and it works fine.
>
> Cool, thanks. Unless I hear objections in the meantime I'll merge
> it when I
> go into work in the morning.
>
> --
> dwmw2
>
>
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>

Re: [linuxsh-dev] Merging PCI support code.

[David W. <dw...@in...>]

Stu...@st... said:
>  Looks like a good idea to me.

> I've just tested it using the pci_st40.c and it works fine. 

Cool, thanks. Unless I hear objections in the meantime I'll merge it when I
go into work in the morning.

--
dwmw2

Re: [linuxsh-dev] Merging PCI support code.

[Stuart M. <Stu...@st...>]

David

On Aug 22, 10:20pm, dw...@in... wrote:
> Subject: [linuxsh-dev] Merging PCI support code.
> It looks as if some of the PCI support functions which are currently
> implemented in each set of platform support code could usefully be shared. 
> 
> Should I go ahead and commit something like the following? This is untested 
> on any platform but the one I'm playing with, for which support isn't yet 
> merged. 

Looks like a good idea to me.

> If it's deemed to be a good idea, it would be useful to get it tested on the
> affected platforms before it's committed. Any volunteers?

I've just tested it using the pci_st40.c and it works fine.

> At the moment, you have to take all five of the common functions, or take 
> none of them and provide your own. Maybe some day we might find a need to 
> make that choice more fine-grained, but we can cross that bridge if and 
> when we come to it.

All five worked for us.

Stuart

[linuxsh-dev] Clean up memory start/size definitions.

[David W. <dw...@in...>]

This patch adds a new config variable CONFIG_MEMORY_SIZE, and uses that in 
the initial memory setup instead of a hardcoded 4MiB.

It also cleans up the nested if statements in the platform-specific 
definitions of CONFIG_MEMORY_START and CONFIG_MEMORY_SIZE. 

I'll commit it soon unless someone complains.

I haven't yet had any feedback on the PCI patch I posted yesterday. Does 
that mean that nobody objects?

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.332
diff -u -r1.332 ChangeLog
--- ChangeLog	2001/08/22 21:09:35	1.332
+++ ChangeLog	2001/08/23 12:44:07
@@ -1,3 +1,10 @@
+2001-08-23 David Woodhouse  <dw...@in...>
+
+	* arch/sh/config.in: Add CONFIG_MEMORY_SIZE, clean up 
+	platform-specific memory start/size definitions.
+	* include/asm-sh/page.h: Define __MEMORY_SIZE.
+	* arch/sh/kernel/setup.c: Use __MEMORY_SIZE instead of hardcoded 4MiB.
+
 2001-08-22 David Woodhouse  <dw...@in...>
 
 	* drivers/net/via-rhine.c: Update to version LK1.1.11 from
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.56
diff -u -r1.56 config.in
--- arch/sh/config.in	2001/08/11 10:18:29	1.56
+++ arch/sh/config.in	2001/08/23 12:44:07
@@ -89,25 +89,31 @@
    define_bool CONFIG_CPU_SH4 y
 fi
 bool 'Little Endian' CONFIG_CPU_LITTLE_ENDIAN
+# Platform-specific memory start and size definitions
 if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" -o "$CONFIG_SH_HP600" = "y" -o \
      "$CONFIG_SH_BIGSUR" = "y" -o "$CONFIG_SH_7751_SOLUTION_ENGINE" = "y" -o \
      "$CONFIG_SH_DREAMCAST" = "y" -o "$CONFIG_SH_SH2000" = "y" ]; then
    define_hex CONFIG_MEMORY_START 0c000000
-else
-   if [ "$CONFIG_CPU_SUBTYPE_ST40STB1" = "y" ]; then
-      bool 'Memory on LMI' CONFIG_ST40_LMI_MEMORY
-      if [ "$CONFIG_ST40_LMI_MEMORY" = "y" ] ; then
-         define_hex CONFIG_MEMORY_START 08000000
-      else
-         hex 'EMI physical memory start address' CONFIG_MEMORY_START 08000000
-      fi
-   else
-      if [ "$CONFIG_SH_ADX" = "y" ]; then
-         define_hex CONFIG_MEMORY_START 08000000
-      else
-         hex 'Physical memory start address' CONFIG_MEMORY_START 08000000
-      fi
+   define_hex CONFIG_MEMORY_SIZE 00400000
+   define_bool CONFIG_MEMORY_SET y
+fi
+if [ "$CONFIG_CPU_SUBTYPE_ST40STB1" = "y" ]; then
+   bool 'Memory on LMI' CONFIG_ST40_LMI_MEMORY
+   if [ "$CONFIG_ST40_LMI_MEMORY" = "y" ] ; then
+      define_hex CONFIG_MEMORY_START 08000000
+      define_hex CONFIG_MEMORY_SIZE 00400000
+      define_bool CONFIG_MEMORY_SET y
    fi
+fi
+if [ "$CONFIG_SH_ADX" = "y" ]; then
+   define_hex CONFIG_MEMORY_START 08000000
+   define_hex CONFIG_MEMORY_SIZE 00400000
+   define_bool CONFIG_MEMORY_SET y
+fi
+# If none of the above have set memory start/size, ask the user.
+if [ "$CONFIG_MEMORY_SET" != "y" ]; then
+   hex 'Physical memory start address' CONFIG_MEMORY_START 08000000
+   hex 'Physical memory size' CONFIG_MEMORY_SIZE 00400000
 fi
 endmenu
 
Index: include/asm-sh/page.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/page.h,v
retrieving revision 1.13
diff -u -r1.13 page.h
--- include/asm-sh/page.h	2001/08/18 06:10:41	1.13
+++ include/asm-sh/page.h	2001/08/23 12:44:07
@@ -69,6 +69,7 @@
  */
 
 #define __MEMORY_START		CONFIG_MEMORY_START
+#define __MEMORY_SIZE		CONFIG_MEMORY_SIZE
 #ifdef CONFIG_DISCONTIGMEM
 /* Just for HP690, for now.. */
 #define __MEMORY_START_2ND	(__MEMORY_START+0x02000000)
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.30
diff -u -r1.30 setup.c
--- arch/sh/kernel/setup.c	2001/08/07 03:43:15	1.30
+++ arch/sh/kernel/setup.c	2001/08/23 12:44:07
@@ -213,8 +213,7 @@
 	saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
 
 	memory_start = (unsigned long)PAGE_OFFSET+__MEMORY_START;
-	/* Default is 4Mbyte. */
-	memory_end = (unsigned long)PAGE_OFFSET+0x00400000+__MEMORY_START;
+	memory_end = (unsigned long)PAGE_OFFSET+__MEMORY_SIZE+__MEMORY_START;
 
 	for (;;) {
 		/*



--
dwmw2

[linuxsh-dev] stable SH4 environment

[Bryan R. <br...@ix...>]

Hello,

Don't know if anyone on the list remembers me, but I'm back to SH4
after a six month affair with the PPC405. :-)

We are going to be shipping a product including LinuxSH very shortly,
and since a lot has probably changed since I was last involved with the
project, I would really appreciate answers to the following
ever-present questions:

1) What is currently the most stable SH4 kernel version for production
use?

We have had great luck with the 2.4.2 snapshot I got months ago,
but I'd like to get something newer than that without going all the way
to bleeding edge.

2) What is currently the most stable toolchain for building the kernel?
Still the 2.97 version described by Masahiro Abe's instructions?

(I'm a little reluctant to use an experimental compiler for production
stuff, especially on the kernel)

3) What is the status of gcc 3.0, as we will shortly need it for
building user code? (I've heard the kernel and glibc are still
most stable/fast when built with older gcc).

I know kaz Kojima has patches here:
http://dodo.nurs.or.jp/~kkojima/index.html, but
is anyone using them in a real production environment?

4) what is an approximate timeframe for getting binutils and gcc patches
for LinuxSH merged with the mainline GNU trees? My work with Linux
on the PPC405 has led me to think that this should be a _really_ high
priority for all embedded forks of Linux/GNU tools. If my employer
allows, I could be able to spend some time assisting in what ever way
possible.

Thanks! I'm looking forward to working with all of you again.

Regards,

Bryan

-- 
Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] New strace patches

[Greg B. <gb...@po...>]

Stuart Menefy wrote:
> 
> Folks
> 
> Several months ago Greg did a great job adding SuperH support to strace
> version 4.2. However that version didn't support some of the new 64 bit
> file operations, and as a result trying to strace a program using those
> system calls gives some rather odd output.

  Yes, I screwed up there (I learnt my lesson by the time I ported LTT).
 
  Also, there is a known problem with the msgrcv(2) or shmat(2) calls giving
the error

ptrace: umoven: Input/output error

> So what I have done is adapted Greg's patches for strace 4.4 (which
> supports the new system calls). Attached is a copy of the new patches
> against strace 4.4 from the SourceForge repository downloaded yesterday
> (21st Aug 2001). This appears to fix the problems I've seen, but
> if any of the new system calls require architecture dependant fixes
> then they will almost certainly be missing. If you find anything like
> this, please let me know.

  
> 
> Greg, I know you were going to submit your changes to the strace
> maintainer, did you ever hear anything? 

  I submitted patches circa Aug 2000, and didn't hear anything back.
The day after I submitted patches I discovered I was going to be in
the US for a month, and I sort of lost track.  Ok, it's a real bad
excuse, sorry.

> Would you like me to try - keeping
> your copyrights intact of course.

  Yes, but the situation is slightly more complex, see my private message.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

[linuxsh-dev] Merging PCI support code.

[David W. <dw...@in...>]

It looks as if some of the PCI support functions which are currently
implemented in each set of platform support code could usefully be shared. 

Should I go ahead and commit something like the following? This is untested 
on any platform but the one I'm playing with, for which support isn't yet 
merged. 

If it's deemed to be a good idea, it would be useful to get it tested on the
affected platforms before it's committed. Any volunteers?

At the moment, you have to take all five of the common functions, or take 
none of them and provide your own. Maybe some day we might find a need to 
make that choice more fine-grained, but we can cross that bridge if and 
when we come to it.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.332
diff -u -r1.332 ChangeLog
--- ChangeLog	2001/08/22 21:09:35	1.332
+++ ChangeLog	2001/08/22 21:10:10
@@ -1,3 +1,12 @@
+2001-08-xx David Woodhouse  <dw...@in...>
+
+	* arch/sh/kernel/pcibios.c: Generic versions of five pcibios_xxx()
+	functions which can be shared between platforms.
+	* arch/sh/kernel/pci_st40.c: Use $1.
+	* arch/sh/kernel/pci-dc.c: Use $1.
+	* arch/sh/kernel/pci-sh7751.c: Use $1.
+	* arch/sh/kernel/Makefile: Use $1.
+
 2001-08-22 David Woodhouse  <dw...@in...>
 
 	* drivers/net/via-rhine.c: Update to version LK1.1.11 from
--- /dev/null	Sat Mar 24 04:37:44 2001
+++ arch/sh/kernel/pcibios.c	Wed Aug 22 20:08:01 2001
@@ -0,0 +1,126 @@
+/*
+ * $Id$
+ *
+ * arch/sh/kernel/pcibios.c
+ *
+ * This is GPL'd.
+ *
+ * Provided here are generic versions of:
+ *	pcibios_update_resource()
+ *	pcibios_align_resource()
+ *	pcibios_enable_device()
+ *	pcibios_set_master()
+ *	pcibios_update_irq()
+ *
+ * These functions are collected here to reduce duplication of common
+ * code amongst the many platform-specific PCI support code files.
+ *
+ * Platform-specific files are expected to provide:
+ *	pcibios_fixup_bus()
+ *	pcibios_init()
+ *	pcibios_setup()
+ *	pcibios_fixup_pbus_ranges()
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/init.h>
+
+void
+pcibios_update_resource(struct pci_dev *dev, struct resource *root,
+			struct resource *res, int resource)
+{
+	u32 new, check;
+	int reg;
+
+	new = res->start | (res->flags & PCI_REGION_FLAG_MASK);
+	if (resource < 6) {
+		reg = PCI_BASE_ADDRESS_0 + 4*resource;
+	} else if (resource == PCI_ROM_RESOURCE) {
+		res->flags |= PCI_ROM_ADDRESS_ENABLE;
+		new |= PCI_ROM_ADDRESS_ENABLE;
+		reg = dev->rom_base_reg;
+	} else {
+		/* Somebody might have asked allocation of a non-standard resource */
+		return;
+	}
+	
+	pci_write_config_dword(dev, reg, new);
+	pci_read_config_dword(dev, reg, &check);
+	if ((new ^ check) & ((new & PCI_BASE_ADDRESS_SPACE_IO) ? PCI_BASE_ADDRESS_IO_MASK : PCI_BASE_ADDRESS_MEM_MASK)) {
+		printk(KERN_ERR "PCI: Error while updating region "
+		       "%s/%d (%08x != %08x)\n", dev->slot_name, resource,
+		       new, check);
+	}
+}
+
+/*
+ * We need to avoid collisions with `mirrored' VGA ports
+ * and other strange ISA hardware, so we always want the
+ * addresses to be allocated in the 0x000-0x0ff region
+ * modulo 0x400.
+ */
+void pcibios_align_resource(void *data, struct resource *res, unsigned long size)
+{
+	if (res->flags & IORESOURCE_IO) {
+		unsigned long start = res->start;
+
+		if (start & 0x300) {
+			start = (start + 0x3ff) & ~0x3ff;
+			res->start = start;
+		}
+	}
+}
+
+int pcibios_enable_device(struct pci_dev *dev)
+{
+	u16 cmd, old_cmd;
+	int idx;
+	struct resource *r;
+
+	pci_read_config_word(dev, PCI_COMMAND, &cmd);
+	old_cmd = cmd;
+	for(idx=0; idx<6; idx++) {
+		r = &dev->resource[idx];
+		if (!r->start && r->end) {
+			printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name);
+			return -EINVAL;
+		}
+		if (r->flags & IORESOURCE_IO)
+			cmd |= PCI_COMMAND_IO;
+		if (r->flags & IORESOURCE_MEM)
+			cmd |= PCI_COMMAND_MEMORY;
+	}
+	if (dev->resource[PCI_ROM_RESOURCE].start)
+		cmd |= PCI_COMMAND_MEMORY;
+	if (cmd != old_cmd) {
+		printk(KERN_INFO "PCI: Enabling device %s (%04x -> %04x)\n", dev->name, old_cmd, cmd);
+		pci_write_config_word(dev, PCI_COMMAND, cmd);
+	}
+	return 0;
+}
+
+/*
+ *  If we set up a device for bus mastering, we need to check and set
+ *  the latency timer as it may not be properly set.
+ */
+unsigned int pcibios_max_latency = 255;
+
+void pcibios_set_master(struct pci_dev *dev)
+{
+	u8 lat;
+	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &lat);
+	if (lat < 16)
+		lat = (64 <= pcibios_max_latency) ? 64 : pcibios_max_latency;
+	else if (lat > pcibios_max_latency)
+		lat = pcibios_max_latency;
+	else
+		return;
+	printk(KERN_INFO "PCI: Setting latency timer of device %s to %d\n", dev->name, lat);
+	pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
+}
+
+void __init pcibios_update_irq(struct pci_dev *dev, int irq)
+{
+	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
+}
Index: arch/sh/kernel/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/Makefile,v
retrieving revision 1.29
diff -u -r1.29 Makefile
--- arch/sh/kernel/Makefile	2001/08/11 01:23:28	1.29
+++ arch/sh/kernel/Makefile	2001/08/22 20:59:10
@@ -26,9 +26,9 @@
 
 ifeq ($(CONFIG_PCI),y)
 ifeq ($(CONFIG_SH_DREAMCAST),y)
-obj-y 				+= pci-dc.o
+obj-y 				+= pci-dc.o pcibios.o
 else
-obj-y                           += pci-dma.o 
+obj-y                           += pci-dma.o pcibios.o
 obj-$(CONFIG_CPU_SUBTYPE_ST40STB1)+= pci_st40.o
 obj-$(CONFIG_CPU_SUBTYPE_SH7751)+= pci-sh7751.o 
 obj-$(CONFIG_SH_BIGSUR)+= pci-bigsur.o
Index: arch/sh/kernel/pci-dc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/pci-dc.c,v
retrieving revision 1.4
diff -u -r1.4 pci-dc.c
--- arch/sh/kernel/pci-dc.c	2001/08/08 14:48:23	1.4
+++ arch/sh/kernel/pci-dc.c	2001/08/22 20:59:10
@@ -104,62 +104,6 @@
 };
 
 
-void pcibios_align_resource(void *data, struct resource *res,
-			    unsigned long size)
-{
-}
-
-
-void __init pcibios_update_irq(struct pci_dev *dev, int irq)
-{
-}
-
-
-void __init pcibios_update_resource(struct pci_dev *dev, struct resource *root,
-			     struct resource *res, int resource)
-{
-}
-
-
-void pcibios_set_master(struct pci_dev *dev)
-{
-	/* No special bus mastering setup handling */
-}
-
-
-int pcibios_enable_device(struct pci_dev *dev)
-{
-
-	u16 cmd, old_cmd;
-	int idx;
-	struct resource *r;
-
-	pci_read_config_word(dev, PCI_COMMAND, &cmd);
-	old_cmd = cmd;
-	for (idx = 0; idx < 6; idx++) {
-		r = dev->resource + idx;
-		if (!r->start && r->end) {
-			printk(KERN_ERR
-			       "PCI: Device %s not available because"
-			       " of resource collisions\n",
-			       dev->slot_name);
-			return -EINVAL;
-		}
-		if (r->flags & IORESOURCE_IO)
-			cmd |= PCI_COMMAND_IO;
-		if (r->flags & IORESOURCE_MEM)
-			cmd |= PCI_COMMAND_MEMORY;
-	}
-	if (cmd != old_cmd) {
-		printk("PCI: enabling device %s (%04x -> %04x)\n",
-		       dev->slot_name, old_cmd, cmd);
-		pci_write_config_word(dev, PCI_COMMAND, cmd);
-	}
-	return 0;
-
-}
-
-
 void *pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
 			   dma_addr_t * dma_handle)
 {
Index: arch/sh/kernel/pci-sh7751.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/pci-sh7751.c,v
retrieving revision 1.5
diff -u -r1.5 pci-sh7751.c
--- arch/sh/kernel/pci-sh7751.c	2001/08/11 01:23:28	1.5
+++ arch/sh/kernel/pci-sh7751.c	2001/08/22 20:59:10
@@ -416,54 +416,6 @@
 	return str;
 }
 
-void
-pcibios_update_resource(struct pci_dev *dev, struct resource *root,
-			struct resource *res, int resource)
-{
-	u32 new, check;
-	int reg;
-
-	new = res->start | (res->flags & PCI_REGION_FLAG_MASK);
-	if (resource < 6) {
-		reg = PCI_BASE_ADDRESS_0 + 4*resource;
-	} else if (resource == PCI_ROM_RESOURCE) {
-		res->flags |= PCI_ROM_ADDRESS_ENABLE;
-		new |= PCI_ROM_ADDRESS_ENABLE;
-		reg = dev->rom_base_reg;
-	} else {
-		/* Somebody might have asked allocation of a non-standard resource */
-		return;
-	}
-	
-	pci_write_config_dword(dev, reg, new);
-	pci_read_config_dword(dev, reg, &check);
-	if ((new ^ check) & ((new & PCI_BASE_ADDRESS_SPACE_IO) ? PCI_BASE_ADDRESS_IO_MASK : PCI_BASE_ADDRESS_MEM_MASK)) {
-		printk(KERN_ERR "PCI: Error while updating region "
-		       "%s/%d (%08x != %08x)\n", dev->slot_name, resource,
-		       new, check);
-	}
-}
-
-/*
- * We need to avoid collisions with `mirrored' VGA ports
- * and other strange ISA hardware, so we always want the
- * addresses to be allocated in the 0x000-0x0ff region
- * modulo 0x400.
- */
-void
-pcibios_align_resource(void *data, struct resource *res, unsigned long size)
-{
-	if (res->flags & IORESOURCE_IO) {
-		unsigned long start = res->start;
-
-		if (start & 0x300) {
-			start = (start + 0x3ff) & ~0x3ff;
-			res->start = start;
-		}
-	}
-}
-
-
 /*
  *    Allocate the bridge and device resources
  */
@@ -592,54 +544,7 @@
 	pcibios_assign_resources();
 }
 
-int pcibios_enable_device(struct pci_dev *dev)
-{
-	u16 cmd, old_cmd;
-	int idx;
-	struct resource *r;
-
-	pci_read_config_word(dev, PCI_COMMAND, &cmd);
-	old_cmd = cmd;
-	for(idx=0; idx<6; idx++) {
-		r = &dev->resource[idx];
-		if (!r->start && r->end) {
-			printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", dev->slot_name);
-			return -EINVAL;
-		}
-		if (r->flags & IORESOURCE_IO)
-			cmd |= PCI_COMMAND_IO;
-		if (r->flags & IORESOURCE_MEM)
-			cmd |= PCI_COMMAND_MEMORY;
-	}
-	if (dev->resource[PCI_ROM_RESOURCE].start)
-		cmd |= PCI_COMMAND_MEMORY;
-	if (cmd != old_cmd) {
-		printk(KERN_INFO "PCI: Enabling device %s (%04x -> %04x)\n", dev->name, old_cmd, cmd);
-		pci_write_config_word(dev, PCI_COMMAND, cmd);
-	}
-	return 0;
-}
 
-/*
- *  If we set up a device for bus mastering, we need to check and set
- *  the latency timer as it may not be properly set.
- */
-unsigned int pcibios_max_latency = 255;
-
-void pcibios_set_master(struct pci_dev *dev)
-{
-	u8 lat;
-	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &lat);
-	if (lat < 16)
-		lat = (64 <= pcibios_max_latency) ? 64 : pcibios_max_latency;
-	else if (lat > pcibios_max_latency)
-		lat = pcibios_max_latency;
-	else
-		return;
-	printk(KERN_INFO "PCI: Setting latency timer of device %s to %d\n", dev->name, lat);
-	pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
-}
-
 /***************************************************************************************/
 /* 
  * 	IRQ functions 
@@ -664,10 +569,4 @@
 	PCIDBG(2,"Setting IRQ for slot %s to %d\n", dev->slot_name, irq);
 
 	return irq;
-}
-
-void __init pcibios_update_irq(struct pci_dev *dev, int irq)
-{
-	PCIDBG(3,"PCI: Update IRQ for %s on irq %d\n", dev->name, irq);
-	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
 }
Index: arch/sh/kernel/pci_st40.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/pci_st40.c,v
retrieving revision 1.3
diff -u -r1.3 pci_st40.c
--- arch/sh/kernel/pci_st40.c	2001/05/23 18:19:07	1.3
+++ arch/sh/kernel/pci_st40.c	2001/08/22 20:59:10
@@ -458,91 +458,6 @@
 
 }
 
-int pcibios_enable_device(struct pci_dev *dev)
-{
-
-	u16 cmd, old_cmd;
-	int idx;
-	struct resource *r;
-
-	pci_read_config_word(dev, PCI_COMMAND, &cmd);
-	old_cmd = cmd;
-	for (idx = 0; idx < 6; idx++) {
-		r = dev->resource + idx;
-		if (!r->start && r->end) {
-			printk(KERN_ERR
-			       "PCI: Device %s not available because"
-			       " of resource collisions\n",
-			       dev->slot_name);
-			return -EINVAL;
-		}
-		if (r->flags & IORESOURCE_IO)
-			cmd |= PCI_COMMAND_IO;
-		if (r->flags & IORESOURCE_MEM)
-			cmd |= PCI_COMMAND_MEMORY;
-	}
-	if (cmd != old_cmd) {
-		printk("PCI: enabling device %s (%04x -> %04x)\n",
-		       dev->slot_name, old_cmd, cmd);
-		pci_write_config_word(dev, PCI_COMMAND, cmd);
-	}
-	return 0;
-
-}
-
 void __init pcibios_fixup_bus(struct pci_bus *bus)
 {
-}
-
-void pcibios_align_resource(void *data, struct resource *res,
-			    unsigned long size)
-{
-}
-
-void __init pcibios_update_resource(struct pci_dev *dev,
-				    struct resource *root,
-				    struct resource *res, int resource)
-{
-
-	unsigned long where, size;
-	u32 reg;
-
-	printk("PCI: Assigning %3s %08lx to %s\n",
-	       res->flags & IORESOURCE_IO ? "IO" : "MEM",
-	       res->start, dev->name);
-
-	where = PCI_BASE_ADDRESS_0 + resource * 4;
-	size = res->end - res->start;
-
-	pci_read_config_dword(dev, where, &reg);
-	reg = (reg & size) | (((u32) (res->start - root->start)) & ~size);
-	pci_write_config_dword(dev, where, reg);
-
-}
-
-
-void __init pcibios_update_irq(struct pci_dev *dev, int irq)
-{
-	printk("PCI: Assigning IRQ %02d to %s\n", irq, dev->name);
-	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
-}
-
-/*
- *  If we set up a device for bus mastering, we need to check the latency
- *  timer as certain crappy BIOSes forget to set it properly.
- */
-unsigned int pcibios_max_latency = 255;
-
-void pcibios_set_master(struct pci_dev *dev)
-{
-	u8 lat;
-	pci_read_config_byte(dev, PCI_LATENCY_TIMER, &lat);
-	if (lat < 16)
-		lat = (64 <= pcibios_max_latency) ? 64 : pcibios_max_latency;
-	else if (lat > pcibios_max_latency)
-		lat = pcibios_max_latency;
-	else
-		return;
-	printk("PCI: Setting latency timer of device %s to %d\n", dev->slot_name, lat);
-	pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
 }

--
dwmw2

[linuxsh-dev] Via-rhine fixes.

[David W. <dw...@in...>]

Some fixes to the via-rhine driver which aren't actually bogus this time.
I'll commit them shortly.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.328
diff -u -r1.328 ChangeLog
--- ChangeLog	2001/08/14 14:44:58	1.328
+++ ChangeLog	2001/08/22 14:45:32
@@ -1,3 +1,10 @@
+2001-08-22 David Woodhouse  <dw...@in...>
+
+	* drivers/net/via-rhine.c: Update to version LK1.1.11 from
+	2.4.9-ac9 (set dev->base_addr before first call to wait_for_reset()
+	and free the bounce buffers only if we allocated any in the first
+	place.
+		
 2001-08-14  David Woodhouse  <dw...@in...>
 
 	* arch/sh/kernel/pci-dma.c: Use dma_cache_wback_inv() in 
Index: drivers/net/via-rhine.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/net/via-rhine.c,v
retrieving revision 1.9
diff -u -r1.9 via-rhine.c
--- drivers/net/via-rhine.c	2001/07/18 02:54:27	1.9
+++ drivers/net/via-rhine.c	2001/08/22 14:45:32
@@ -69,6 +69,10 @@
 	- Manfred Spraul: use "singlecopy" for unaligned buffers
 	                  don't allocate bounce buffers for !ReqTxAlign cards
 
+	LK1.1.11:
+	- David Woodhouse: Set dev->base_addr before the first time we call
+					   wait_for_reset(). It's a lot happier that way.
+					   Free np->tx_bufs only if we actually allocated it.
 */
 
 
@@ -151,7 +155,7 @@
 
 /* These identify the driver base version and may not be removed. */
 static char version[] __devinitdata =
-KERN_INFO "via-rhine.c:v1.10-LK1.1.10  07/12/2001  Written by Donald Becker\n"
+KERN_INFO "via-rhine.c:v1.10-LK1.1.11  20/08/2001  Written by Donald Becker\n"
 KERN_INFO "  http://www.scyld.com/network/via-rhine.html\n";
 
 static char shortname[] __devinitdata = "via-rhine";
@@ -584,6 +588,8 @@
 
 	/* Reset the chip to erase previous misconfiguration. */
 	writew(CmdReset, ioaddr + ChipCmd);
+
+	dev->base_addr = ioaddr;
 	wait_for_reset(dev, shortname);
 
 	/* Reload the station address from the EEPROM. */
@@ -609,7 +615,6 @@
 		writeb(readb(ioaddr + ConfigA) & 0xFE, ioaddr + ConfigA);
 	}
 
-	dev->base_addr = ioaddr;
 	dev->irq = pdev->irq;
 
 	np = dev->priv;
@@ -757,9 +762,12 @@
 			    RX_RING_SIZE * sizeof(struct rx_desc) +
 			    TX_RING_SIZE * sizeof(struct tx_desc),
 			    np->rx_ring, np->rx_ring_dma);
+
+	if (np->tx_bufs)
+		pci_free_consistent(np->pdev, PKT_BUF_SZ * TX_RING_SIZE,
+							np->tx_bufs, np->tx_bufs_dma);
 
-	pci_free_consistent(np->pdev, PKT_BUF_SZ * TX_RING_SIZE,
-						np->tx_bufs, np->tx_bufs_dma);
+	np->tx_bufs = NULL;
 
 }
 

--
dwmw2

[linuxsh-dev] New strace patches

[Stuart M. <Stu...@st...>]

Folks

Several months ago Greg did a great job adding SuperH support to strace
version 4.2. However that version didn't support some of the new 64 bit
file operations, and as a result trying to strace a program using those
system calls gives some rather odd output.

So what I have done is adapted Greg's patches for strace 4.4 (which
supports the new system calls). Attached is a copy of the new patches
against strace 4.4 from the SourceForge repository downloaded yesterday
(21st Aug 2001). This appears to fix the problems I've seen, but
if any of the new system calls require architecture dependant fixes
then they will almost certainly be missing. If you find anything like
this, please let me know.

Greg, I know you were going to submit your changes to the strace
maintainer, did you ever hear anything? Would you like me to try - keeping
your copyrights intact of course.

Stuart

[linuxsh-dev] stat64 patch

[Jeremy S. <js...@mv...>]

Hi folks,

Adding SH to distribution, we've found the stat64 definition
in asm-sh/stat.h is inconsistent with glibc for big-endian.
(Not noticed when the library is compiled w/o fstat64 or
whatever, as it's not used then.)  Any objections to my
putting the following patch in the SourceForge tree?

--Jeremy Siegel

Re: [linuxsh-dev] byteorder.h from elf.h

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
>  >   Probably because it's easier to create an empty header than fix
>  > all the cruft throughout the kernel.
> 
> Yes.  Technically speaking, adding the file is the wrong thing,

  Yes, agreed.

>  >   Sure, but does the SuperH team have to be the one to feel this
>  > pressure?  It's not a SuperH-specific issue.
> 
> All other ports has asm/segment.h, so, none will notice about the
> issue.  Only SuperH doesn't have the file from the beginning.

  True, but again why us?  Surely this is a job for the kernel janitors?

>  >   But can we wait with removing segment.h until those changes percolate
>  > back through the mainline kernel?
> 
> Well, it's OK to add the file containing some comments ("this file
> should not exist" or something like that).  Please do that if you
> really need it.  

  Hmm, see below.

> Perhaps, I don't send it to mainline.

  Fair enough.  No need to *propagate* cruft.

> I like following implementation, but I guess none agrees :-)
> --------- asm-sh/segment.h
> #error "It is obsolete to include this file.  Please fix."
> ---------

  There's no practical difference between this and not having
the file: in each case the preprocessor spits an error and
the build fails.

> As time permits, I keep removing the inclusion.

  Well, it's really up to you.

  Having these diffs in the SuperH port as we have now, is going
to create a small amount of extra work for the person does the
merges for the drop-in tree (which I expect will eventually be
yourself).  This will be much less work than using the drop-in
tree will save in the first place.

  If you think removing the spurious includes is worth the
extra effort, then fine, we can do it that way.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] byteorder.h from elf.h

[NIIBE Y. <gn...@m1...>]

The file asm-sh/segment.h was not created, because it has already been
obsoleteat the time when SuperH port started.  Someone added the file
asm-sh/segment.h into the CVS repository, and I've removed.

 >   Probably because it's easier to create an empty header than fix
 > all the cruft throughout the kernel.

Yes.  Technically speaking, adding the file is the wrong thing,
removing the inclusion of the file is the right thing.  However, in
real life, adding the file is good thing, perhaps.

 >   Sure, but does the SuperH team have to be the one to feel this
 > pressure?  It's not a SuperH-specific issue.

All other ports has asm/segment.h, so, none will notice about the
issue.  Only SuperH doesn't have the file from the beginning.

 >   But can we wait with removing segment.h until those changes percolate
 > back through the mainline kernel?

Well, it's OK to add the file containing some comments ("this file
should not exist" or something like that).  Please do that if you
really need it.  Perhaps, I don't send it to mainline.

I like following implementation, but I guess none agrees :-)
--------- asm-sh/segment.h
#error "It is obsolete to include this file.  Please fix."
---------

As time permits, I keep removing the inclusion.
-- 

Re: [linuxsh-dev] byteorder.h from elf.h

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> Removing the inclusion of asm/segment.h is the way to go.  It seems
> that no one (except me) tries to do that. 

  Probably because it's easier to create an empty header than fix
all the cruft throughout the kernel.

> It's easy to just put empty
> segment.h, but then, I will lose the pressure of removing.

  Sure, but does the SuperH team have to be the one to feel this
pressure?  It's not a SuperH-specific issue.

> Except soundcard.c (which I don't know who is in charge of), I've sent
> the fix to relevant maintainers, and positive ACK for cdrom.c,
> i82365.c, tcic.c and base.c.  I don't get reply for joydev.c yet.

  Excellent!  You may also want to check Ben Reed's Aironet 4800 driver.

  But can we wait with removing segment.h until those changes percolate
back through the mainline kernel?

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] byteorder.h from elf.h

[NIIBE Y. <gn...@m1...>]

Greg Banks wrote:
 >   I know that for SH, <asm/segment.h> is empty, but it is included
 > in several places in the core kernel.

It's not only for SuperH, please look for other architectures.

For drivers, file system layer, or network layer, including the file
of <asm/segment.h> is obsolete.  In old days, when we needed segment
specification for user process access, it was needed.  The inclusion
of the file has not been needed for quite some time now, say, three
years or so.  It only makes sense for architecture specific code.

Removing the inclusion of asm/segment.h is the way to go.  It seems
that no one (except me) tries to do that.  It's easy to just put empty
segment.h, but then, I will lose the pressure of removing.

 > drivers/cdrom/cdrom.c
 > drivers/input/joydev.c
 > drivers/pcmcia/i82365.c
 > drivers/pcmcia/tcic.c
 > drivers/sound/soundcard.c
 > fs/devfs/base.c

Those are files I've chekced.

Except soundcard.c (which I don't know who is in charge of), I've sent
the fix to relevant maintainers, and positive ACK for cdrom.c,
i82365.c, tcic.c and base.c.  I don't get reply for joydev.c yet.
-- 

Re: [linuxsh-dev] byteorder.h from elf.h

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
> We don't need to include byteorder.h in elf.h.
> 

  On an unrelated note, I have a problem with this change:

+2001-07-24  NIIBE Yutaka  <gn...@m1...>
+
+	* include/asm-sh/segment.h: Removed.
+	* arch/sh/kernel/pci-sh7751.c: Remove inclusion of <asm/segment.h>.
+

  I know that for SH, <asm/segment.h> is empty, but it is included
in several places in the core kernel.  Removing the file entirely
rather than just leaving it empty means we have to modify mainline
files to not include it anymore.  This means the following files 
have pointless one-line differences between the SuperH and mainline
kernels:

drivers/cdrom/cdrom.c
drivers/input/joydev.c
drivers/pcmcia/i82365.c
drivers/pcmcia/tcic.c
drivers/sound/soundcard.c
fs/devfs/base.c

  Trivial diffs in mainline files which provide no actual functionality,
create unnecessary problems with maintaining the drop-in tree.

  So can we please have include/asm-sh/segment.h back?

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

[linuxsh-dev] byteorder.h from elf.h

[NIIBE Y. <gn...@m1...>]

We don't need to include byteorder.h in elf.h.

	* include/asm-sh/elf.h: Removed inclusion of <asm/byteorder.h>.

--- include/asm-sh/elf.h	2000/07/17 07:18:39	1.4
+++ include/asm-sh/elf.h	2001/08/20 05:51:13
@@ -7,7 +7,6 @@
 
 #include <asm/ptrace.h>
 #include <asm/user.h>
-#include <asm/byteorder.h>
 
 typedef unsigned long elf_greg_t;
 

[linuxsh-dev] Re: Floating point problem

[kaz K. <kk...@rr...>]

Jeremy Siegel <js...@mv...> wrote:
> I suspect the odd fpscr displayed is due to a broken GDB,
> or at least one with register number identifiers that are
> inconsistent with the kernel/ptrace... mine behaves the
> same way (at the moment).  [BTW, we see the same
> thing, and we're using glibc 2.2.3.]

Agreed. I've found bad fpscr values on the native gdb.

BTW, I've just build libc-2.2.3 by gcc-2.97(20001120) again,
but I can't reproduce the problem with it.

	kaz

Re: [linuxsh-dev] Re: Floating point problem

[Jeremy S. <js...@mv...>]

I suspect the odd fpscr displayed is due to a broken GDB,
or at least one with register number identifiers that are
inconsistent with the kernel/ptrace... mine behaves the
same way (at the moment).  [BTW, we see the same
thing, and we're using glibc 2.2.3.]

--Jeremy Siegel

kaz Kojima wrote:

> "Bao C. Ha" <ba...@se...> wrote:
> > It still crashed when $fpscr was set to 0x80004
> >
> > (gdb) p/x $fpscr=0x80004
> > $2 = 0x80004
> > (gdb) p/x $fpscr
> > $3 = 0x80004
> > (gdb) c
> > Continuing.
> >
> >  status=%x
> [snip]
>
> Hmm... I have no idea for the real problem at this point. Anyway,
> 0x3f737871 is very broken if gdb works correctly and it seems
> that some bad things occur in shared library. Perhaps, rebuilding
> libc with gcc -O may be not so bad idea.
>
>         kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev

Re: [linuxsh-dev] 2.4.9

[David W. <dw...@in...>]

gn...@m1... said:
> 	* drivers/net/8139too.c: Include <linux/completion.h>. 
 
Argh. I thought I'd fixed that. Must have sent the wrong version to Linus 
when I resent the complete_and_exit() stuff.


--
dwmw2

[linuxsh-dev] 2.4.9

[NIIBE Y. <gn...@m1...>]

 > Here it is:

No, that's bad.  Here's update.  This includes patches for drivers.

	* drivers/net/8139too.c: Include <linux/completion.h>.
	* drivers/maple/maple.c: Likewise.
	(kmapled_exited, maple_exit, kmapled_thread): Use new "completion"
	interface.

	* include/asm-sh/keyboard.h (kbd_rate): New function.
	* include/asm-sh/io.h (page_to_bus): New macro.
	* include/asm-sh/mmzone.h (page_to_phys): Defined.

Index: drivers/maple/maple.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/maple/maple.c,v
retrieving revision 1.6
diff -u -r1.6 maple.c
--- drivers/maple/maple.c	2001/08/03 11:22:06	1.6
+++ drivers/maple/maple.c	2001/08/17 07:47:48
@@ -13,6 +13,7 @@
 #include <linux/init.h>
 #include <linux/string.h>
 #include <linux/smp_lock.h>
+#include <linux/completion.h>
 
 #include <asm/page.h>
 #include <asm/io.h>
@@ -35,7 +36,7 @@
 static LIST_HEAD(maple_waitq);
 static LIST_HEAD(maple_sentq);
 static DECLARE_WAIT_QUEUE_HEAD(kmapled_wait);
-static DECLARE_MUTEX_LOCKED(kmapled_exited);
+static DECLARE_COMPLETION(kmapled_exited);
 static int kmapled_pid = 0;
 
 struct timer_list maple_timer;
@@ -462,7 +463,7 @@
 	
 	unlock_kernel();
 
-	up_and_exit(&kmapled_exited, 0);
+	complete_and_exit(&kmapled_exited, 0);
 }
 
 
@@ -526,7 +527,7 @@
 	/* XXX: Must do proper clean-up */
 
 	kill_proc(kmapled_pid, SIGTERM, 1);
-	down(&kmapled_exited);
+	wait_for_completion(&kmapled_exited);
 
 	if (maple_sendbuf)
 		free_pages((unsigned long)maple_sendbuf, MAPLE_DMA_PAGES);
Index: drivers/net/8139too.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/net/8139too.c,v
retrieving revision 1.23
diff -u -r1.23 8139too.c
--- drivers/net/8139too.c	2001/08/17 00:41:15	1.23
+++ drivers/net/8139too.c	2001/08/17 07:47:48
@@ -152,6 +152,8 @@
 #include <linux/delay.h>
 #include <linux/ethtool.h>
 #include <linux/mii.h>
+#include <linux/completion.h>
+
 #include <asm/io.h>
 #include <asm/uaccess.h>
 
Index: include/asm-sh/io.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io.h,v
retrieving revision 1.30
diff -u -r1.30 io.h
--- include/asm-sh/io.h	2001/08/11 01:23:28	1.30
+++ include/asm-sh/io.h	2001/08/17 07:48:01
@@ -405,6 +405,7 @@
 
 #define virt_to_bus virt_to_phys
 #define bus_to_virt phys_to_virt
+#define page_to_bus page_to_phys
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some
Index: include/asm-sh/keyboard.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/keyboard.h,v
retrieving revision 1.10
diff -u -r1.10 keyboard.h
--- include/asm-sh/keyboard.h	2001/08/08 14:54:58	1.10
+++ include/asm-sh/keyboard.h	2001/08/17 07:48:01
@@ -4,6 +4,7 @@
  *	$Id: keyboard.h,v 1.10 2001/08/08 14:54:58 yaegashi Exp $
  */
 
+#include <linux/kd.h>
 #include <linux/config.h>
 #include <asm/machvec.h>
 
@@ -40,6 +41,13 @@
 
 static __inline__ void kbd_leds(unsigned char leds)
 {
+}
+
+static __inline__ int kbd_rate(struct kbd_repeat *rep)
+{
+	if (rep == NULL)
+		return -EINVAL;
+	return -EIO;
 }
 
 extern void hp600_kbd_init_hw(void);
Index: include/asm-sh/mmzone.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/mmzone.h,v
retrieving revision 1.3
diff -u -r1.3 mmzone.h
--- include/asm-sh/mmzone.h	2001/08/09 23:52:16	1.3
+++ include/asm-sh/mmzone.h	2001/08/17 07:48:01
@@ -55,5 +55,7 @@
 }
 
 #define VALID_PAGE(page)	is_valid_page(page)
+#define page_to_phys(page)	PHYSADDR(page_address(page))
+
 #endif /* CONFIG_DISCONTIGMEM */
 #endif
Index: include/asm-sh/page.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/page.h,v
retrieving revision 1.12
diff -u -r1.12 page.h
--- include/asm-sh/page.h	2001/07/27 06:09:47	1.12
+++ include/asm-sh/page.h	2001/08/17 07:48:01
@@ -82,6 +82,7 @@
 #ifndef CONFIG_DISCONTIGMEM
 #define phys_to_page(phys)	(mem_map + (((phys)-__MEMORY_START) >> PAGE_SHIFT))
 #define VALID_PAGE(page)	((page - mem_map) < max_mapnr)
+#define page_to_phys(page)	(((page - mem_map) << PAGE_SHIFT) + __MEMORY_START)
 #endif
 
 #define virt_to_page(kaddr)	phys_to_page(__pa(kaddr))