linuxsh-dev

[linuxsh-dev] ppp and SH4

[sibusiso x. <si...@bt...>]

Greetings,

This is my first posting.  My question  may be a bit newbie-ish,
indeed the answer is probably quite old., (but how is one to learn?).

Here goes:-
Can ppp be implemented using the onbard serial port on the  7750 and
if it has been,  could someone  offer a link?

regards
Sibu

[linuxsh-dev] ppp and SH4

[sibusiso x. <si...@b-...>]

Greetings,

This is my first posting.  My question  may be a bit newbie-ish,
indeed the answer is probably quite old., (but how is one to learn?).

Here goes:-
Can ppp be implemented using the onbard serial port on the  7750 and
if it has been,  could someone  offer a link?

regards
Sibu

[linuxsh-dev] Cleanup patch

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

I think this is good to apply to branch and trunk.

2001-12-14  NIIBE Yutaka  <gn...@m1...>

	* include/asm-sh/hitachi_se.h (PA_BCR): Comment fix to sync mainline.

	* drivers/block/rd.c (initrd_read): Don't need to flush the cache.
	(This file can be removed.)
	* include/linux/highmem.h (memclear_highpage_flush): Likewise.

Index: drivers/block/rd.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/drivers/block/rd.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 rd.c
--- drivers/block/rd.c	2001/12/03 22:15:34	1.2
+++ drivers/block/rd.c	2001/12/14 06:53:02
@@ -399,7 +399,6 @@ static ssize_t initrd_read(struct file *
 	if (count > left) count = left;
 	if (count == 0) return 0;
 	copy_to_user(buf, (char *)initrd_start + *ppos, count);
-	flush_cache_all();
 	*ppos += count;
 	return count;
 }
Index: include/asm-sh/hitachi_se.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/hitachi_se.h,v
retrieving revision 1.2
diff -u -3 -p -r1.2 hitachi_se.h
--- include/asm-sh/hitachi_se.h	2001/10/16 21:33:00	1.2
+++ include/asm-sh/hitachi_se.h	2001/12/14 06:53:02
@@ -36,7 +36,7 @@
 #define PA_DIPSW0	0xb0800000	/* Dip switch 5,6 */
 #define PA_DIPSW1	0xb0800002	/* Dip switch 7,8 */
 #define PA_LED		0xb0c00000	/* LED */
-#define PA_BCR		0xb1400000	/* FPGA on the MS7750SE01 */
+#define PA_BCR		0xb1400000	/* FPGA */
 
 #define PA_MRSHPC	0xb83fffe0	/* MR-SHPC-01 PCMCIA controller */
 #define PA_MRSHPC_MW1	0xb8400000	/* MR-SHPC-01 memory window base */
Index: include/linux/highmem.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/linux/highmem.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 highmem.h
--- include/linux/highmem.h	2001/10/15 20:45:12	1.1.1.1
+++ include/linux/highmem.h	2001/12/14 06:53:02
@@ -78,7 +78,6 @@ static inline void memclear_highpage_flu
 		BUG();
 	kaddr = kmap(page);
 	memset(kaddr + offset, 0, size);
-	flush_dcache_page(page);
 	flush_page_to_ram(page);
 	kunmap(page);
 }
-- 

[linuxsh-dev] Status

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

NIIBE Yutaka wrote:
 > My plan for this week is like following:
 > 	(1) Check the patches I hold, and check in to the repository:
 > 		big-endian bug for users.h

It was included already.

 > 		discontigous memory handling

It's up to Takeshi.

 > 		configuration issues (i.e., config.in and config.help)

I'm doing this for cml2.
We need explanations for following entries:
   STB1 Harp
   CAT68701
   BigSur
   SH2000
   ADX
(Besides, current Configure.help for CqREEK is wrong, need fix)
Please send entries to ESR.  Or send me so that I'll merge them, 
and send to ESR.

Question to Stuart: Does ST40STB1 has on-chip watchdog timer?
If so, we need to fix the explanation and title of CONFIG_SH_WDT.

 > 	(2) Check the difference between 2.4 and repository
 > 	    and send it to upstream.

Done.  I think it will be included in 2.4.18-pre1 or something.

 > 	(3) Check the difference between 2.5 and repository
 > 	    and send it to upstream.

Done, all has been included.  It's included in 2.5.0-pre10.

 > 	(4) Gather opinion and features for 2.5

Has anyone tried kbuild?

BTW, I've also sent GNU C library change (profiler) and binutils change.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Tom R. <tr...@ke...>]

On Tue, Dec 11, 2001 at 11:55:49PM -0600, M. R. Brown wrote:
> * YAEGASHI Takeshi <t...@ke...> on Wed, Dec 12, 2001:
> 
> > My patch for 8139too.c is here.  I suspect there're similar bugs in
> > other drivers.
> 
> Looks sane based on what's been stated on lkml this past weekend.  Thanks!

There's actually a lot of similar bugs.  2.4.17-pre7 or so fixed this
(There's now a __devexit_p(X) macro I think it's called that's either
NULL or X, depending on which is correct).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [linuxsh-dev] Drop-In tree updates

[M. R. B. <mr...@0x...>]

* YAEGASHI Takeshi <t...@ke...> on Wed, Dec 12, 2001:

>=20
> > * 8139too driver
> >=20
> >  >  Documentation/Configure.help                   |    6=20
> >  >  drivers/net/8139too.c                          |   25 +
> >=20
> > This is changes for 8139too, I and Takeshi sent them to 8139too
> > maintainer two or three times, but it has not yet included.
> > I don't know the status of this change.  Takeshi?
>=20
> I don't know anything about that patch status...
>=20

I'm cleaning this up to remove the spurious "Dreamcast Support" configure
option.  If we're going to #ifdef, we should use CONFIG_SH_DREAMCAST, since
it will exist when we build 8139too.c anyway.  No need to create a new
CONFIG_ macro when we already have the constraint available.

I'll send this off to Jeff Garzik and lkml when it's ready.

> 	http://bugs.debian.org/122179
>=20
> My patch for 8139too.c is here.  I suspect there're similar bugs in
> other drivers.
>=20

Looks sane based on what's been stated on lkml this past weekend.  Thanks!

M. R.

Re: [linuxsh-dev] Drop-In tree updates

[YAEGASHI T. <t...@ke...>]

Hi,

In the article <200...@mu...>,
NIIBE Yutaka <gn...@m1...> wrote:

> * 8139too driver
> 
>  >  Documentation/Configure.help                   |    6 
>  >  drivers/net/8139too.c                          |   25 +
> 
> This is changes for 8139too, I and Takeshi sent them to 8139too
> maintainer two or three times, but it has not yet included.
> I don't know the status of this change.  Takeshi?

I don't know anything about that patch status...

For 8139too.c, I found current binutils fails when ld linking vmlinux,
reporting undefined reference to symbols in discarded section
(.text.exit).

I think it's kernel's fault and we should correct them.  See follwoing
discussion recorded in the Debian bug database:

	http://bugs.debian.org/122179

My patch for 8139too.c is here.  I suspect there're similar bugs in
other drivers.

Index: drivers/net/8139too.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/drivers/net/8139too.c,v
retrieving revision 1.3
diff -u -r1.3 8139too.c
--- drivers/net/8139too.c	2001/12/03 22:15:34	1.3
+++ drivers/net/8139too.c	2001/12/12 05:25:45
@@ -2515,7 +2515,9 @@
 	name:		DRV_NAME,
 	id_table:	rtl8139_pci_tbl,
 	probe:		rtl8139_init_one,
+#if defined(CONFIG_HOTPLUG) || defined(MODULE) /* if "__devexit" == "" */
 	remove:		rtl8139_remove_one,
+#endif
 #ifdef CONFIG_PM
 	suspend:	rtl8139_suspend,
 	resume:		rtl8139_resume,


>  >  include/asm-sh/mmzone.h
> 
> This version is known not to work.  I think that Takeshi has newer
> version.

Unfortunately it seems that the correct version of mmzone.h had been
lost in a recent HDD arrangemnet...

I remember it's small change, so it wouldn't take much time for me to
rewrite.  I'd submit it with other patches together when testing newer
kernels on hp690 later.  Please wait if you could be patient.

--
YAEGASHI Takeshi <t...@ke...> <ta...@ya...>

Re: [linuxsh-dev] 2.4 patch to mainline

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

SUGIOKA Toshinobu wrote:
 > If 'sec' is chenged from 0 -> 0xffffffff then RTC will reset here.
 > That is bad.
 > 
 > My original patch seems correct at this point.

Thanks.  My bad to apply the patch.  Fixed version will be sent.
-- 

Re: [linuxsh-dev] 2.4 patch to mainline

[SUGIOKA T. <su...@it...>]

At 09:41 01/12/12 +0900, NIIBE Yutaka <gn...@m1...> wrote:
>diff -ruN3p v2.4.17-pre8/arch/sh/kernel/rtc.c linux/arch/sh/kernel/rtc.c
>--- v2.4.17-pre8/arch/sh/kernel/rtc.c	Thu Jun 28 05:55:29 2001
>+++ linux/arch/sh/kernel/rtc.c	Wed Dec 12 09:17:30 2001
>@@ -61,6 +61,11 @@ void sh_rtc_gettimeofday(struct timeval 
> 	BCD_TO_BIN(min);
> 	BCD_TO_BIN(sec);
> 
>+#if RTC_BIT_INVERTED != 0
>+	if ((sec128 & RTC_BIT_INVERTED))
>+		sec--;
>+#endif
>+
> 	if (yr > 99 || mon < 1 || mon > 12 || day > 31 || day < 1 ||
> 	    hr > 23 || min > 59 || sec > 59) {
> 		printk(KERN_ERR

If 'sec' is chenged from 0 -> 0xffffffff then RTC will reset here.
That is bad.

My original patch seems correct at this point.


----
SUGIOKA Toshinobu

[linuxsh-dev] 2.4 patch to mainline

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

I'll send following patch to Marcelo for inclusion of 2.4 mainline.

Note that I've added two changes over yesterday's patch.
One is SUGIOKA-san's patch for RTC fix, and another is
commenting out maple/Config.in in config.in (it results error
as we don't have it in mainline yet).

--------------------------
* Documentation for adding new machine (Stuart Menefy)
  Documentation/sh/new-machine.txt

* Follows PCI interface update (Jeremy Siegel)
 include/asm-sh/pci.h

* Configuration fix (Jeremy Siegel, NIIBE Yutaka)
 arch/sh/config.in

* Solution Engine 7751 update  (Jeremy Siegel)
 arch/sh/kernel/io_7751se.c
 arch/sh/kernel/pci-7751se.c

* Big endian support fixes (Jeremy Siegel, Tomoyoshi ASANO)
 include/asm-sh/stat.h
 include/asm-sh/uaccess.h

* SuperH watch dog timer fix (Paul Mundt)
 drivers/char/shwdt.c

* Follow new interface of sched.c (will implement later)
 arch/sh/kernel/traps.c

* RTC fix (SUGIOKA Toshinobu)
 arch/sh/kernel/rtc.c

diff -ruN3p v2.4.17-pre8/Documentation/sh/new-machine.txt linux/Documentation/sh/new-machine.txt
--- v2.4.17-pre8/Documentation/sh/new-machine.txt	Thu Jan  1 09:00:00 1970
+++ linux/Documentation/sh/new-machine.txt	Tue Dec 11 15:52:33 2001
@@ -0,0 +1,77 @@
+The multiple machine support relies on redirecting all functions which will
+need to be machine specific through a table of function pointers, the
+machvec. These functions fall into a number of categories:
+
+ - I/O functions to IO memory (inb etc) and PCI/main memory (readb etc).
+ - I/O remapping functions (ioremap etc)
+ - some initialisation functions
+ - a 'heartbeat' function
+ - some miscellaneous flags
+
+The tree can be built in two ways:
+ - as a fully generic build. All drivers are linked in, and all functions
+   go through the machvec
+ - as a machine specific build. In this case only the required drivers
+   will be linked in, and some macros may be redefined to not go through
+   the machvec where performance is important (in particular IO functions).
+
+There are three ways in which IO can be performed:
+ - none at all. This is really only useful for the 'unknown' machine type,
+   which us designed to run on a machine about which we know nothing, and
+   so all all IO instructions do nothing.
+ - fully custom. In this case all IO functions go to a machine specific
+   set of functions which can do what they like
+ - a generic set of functions. These will cope with most situations,
+   and rely on a single function, mv_port2addr, which is called through the
+   machine vector, and converts an IO address into a memory address, which
+   can be read from/written to directly.
+
+Thus adding a new machine involves the following steps (I will assume I am
+adding a machine called fred):
+
+ - add a new file include/asm-sh/io_fred.h which contains prototypes for
+   any machine specific IO functions prefixed with the machine name, for
+   example fred_inb. These will be needed when filling out the machine
+   vector. In addition, a section is required which defines what to do when
+   building a machine specific version. For example:
+
+     #ifdef __WANT_IO_DEF
+     #define inb  fred_inb
+     ...
+     #endif
+
+   This is the minimum that is required, however there are ample
+   opportunities to optimise this. In particular, by making the prototypes
+   inline function definitions, it is possible to inline the function when
+   building machine specific versions. Note that the machine vector
+   functions will still be needed, so that a module built for a generic
+   setup can be loaded.
+
+ - add a new file arch/sh/kernel/mach_fred.c. This contains the definition
+   of the machine vector. When building the machine specific version, this
+   will be the real machine vector (via an alias), while in the generic
+   version is used to initialise the machine vector, and then freed, by
+   making it initdata. This should be defined as:
+
+     struct sh_machine_vector mv_fred __initmv = {
+       mv_name: "Fred"
+     }
+     ALIAS_MV(se)
+
+ - finally add a file arch/sh/kernel/io_fred.c, which contains
+   definitions of the machine specific io functions.
+
+A note about initialisation functions. Three initialisation functions are
+provided in the machine vector:
+ - mv_arch_init - called very early on from setup_arch
+ - mv_init_irq - called from init_IRQ, after the generic SH interrupt
+   initialisation
+ - mv_init_pci - currently not used
+
+Any other remaining functions which need to be called at start up can be
+added to the list using the __initcalls macro (or module_init if the code
+can be built as a module). Many generic drivers probe to see if the device
+they are targeting is present, however this may not always be appropriate,
+so a flag can be added to the machine vector which will be set on those
+machines which have the hardware in question, reducing the probe to a
+single conditional.
diff -ruN3p v2.4.17-pre8/arch/sh/config.in linux/arch/sh/config.in
--- v2.4.17-pre8/arch/sh/config.in	Tue Oct 16 05:36:48 2001
+++ linux/arch/sh/config.in	Wed Dec 12 09:22:08 2001
@@ -189,7 +189,7 @@ if [ "$CONFIG_PCI" = "y" ]; then
    if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
       define_bool CONFIG_PCI_DIRECT y
    fi
-   define_bool CONFIG_SH_PCIDMA_NONCOHERENT n
+   bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT n
 fi
 
 source drivers/pci/Config.in
@@ -280,9 +280,9 @@ endmenu
 #
 source drivers/input/Config.in
 
-if [ "$CONFIG_SH_DREAMCAST" = "y" ]; then
-   source drivers/maple/Config.in
-fi
+# if [ "$CONFIG_SH_DREAMCAST" = "y" ]; then
+#    source drivers/maple/Config.in
+# fi
 
 mainmenu_option next_comment
 comment 'Character devices'
diff -ruN3p v2.4.17-pre8/arch/sh/kernel/io_7751se.c linux/arch/sh/kernel/io_7751se.c
--- v2.4.17-pre8/arch/sh/kernel/io_7751se.c	Sun Sep  9 04:29:09 2001
+++ linux/arch/sh/kernel/io_7751se.c	Tue Dec 11 15:52:33 2001
@@ -17,7 +17,7 @@
 #include <asm/hitachi_7751se.h>
 #include <asm/addrspace.h>
 
-#include <asm/pci.h>
+#include <linux/pci.h>
 #include <asm/pci-sh7751.h>
 
 #if 0
@@ -70,7 +70,7 @@ port2adr(unsigned int port)
 	else
 		return (volatile __u16 *) (PA_SUPERIO + (port << 1));
 #endif
-	maybebadio(name,port);
+	maybebadio(name,(unsigned long)port);
 	return (volatile __u16*)port;
 }
 
@@ -276,6 +276,7 @@ void sh7751se_writel(unsigned int b, uns
 /* ISA page descriptor.  */
 static __u32 sh_isa_memmap[256];
 
+#if 0
 static int
 sh_isa_mmap(__u32 start, __u32 length, __u32 offset)
 {
@@ -286,12 +287,11 @@ sh_isa_mmap(__u32 start, __u32 length, _
 
 	idx = start >> 12;
 	sh_isa_memmap[idx] = 0xb8000000 + (offset &~ 0xfff);
-#if 0
 	printk("sh_isa_mmap: start %x len %x offset %x (idx %x paddr %x)\n",
 	       start, length, offset, idx, sh_isa_memmap[idx]);
-#endif
 	return 0;
 }
+#endif
 
 unsigned long
 sh7751se_isa_port2addr(unsigned long offset)
diff -ruN3p v2.4.17-pre8/arch/sh/kernel/pci-7751se.c linux/arch/sh/kernel/pci-7751se.c
--- v2.4.17-pre8/arch/sh/kernel/pci-7751se.c	Sun Sep  9 04:29:09 2001
+++ linux/arch/sh/kernel/pci-7751se.c	Tue Dec 11 15:52:33 2001
@@ -37,7 +37,6 @@
  */
 int __init pcibios_init_platform(void)
 {
-   unsigned long data;
    unsigned long bcr1, wcr1, wcr2, wcr3, mcr;
    unsigned short bcr2;
 
diff -ruN3p v2.4.17-pre8/arch/sh/kernel/rtc.c linux/arch/sh/kernel/rtc.c
--- v2.4.17-pre8/arch/sh/kernel/rtc.c	Thu Jun 28 05:55:29 2001
+++ linux/arch/sh/kernel/rtc.c	Wed Dec 12 09:17:30 2001
@@ -46,7 +46,7 @@ void sh_rtc_gettimeofday(struct timeval 
 	} while ((ctrl_inb(RCR1) & RCR1_CF) != 0);
 
 #if RTC_BIT_INVERTED != 0
-	/* Work around to avoid reading correct value. */
+	/* Work around to avoid reading incorrect value. */
 	if (sec128 == RTC_BIT_INVERTED) {
 		schedule_timeout(1);
 		goto again;
@@ -61,6 +61,11 @@ void sh_rtc_gettimeofday(struct timeval 
 	BCD_TO_BIN(min);
 	BCD_TO_BIN(sec);
 
+#if RTC_BIT_INVERTED != 0
+	if ((sec128 & RTC_BIT_INVERTED))
+		sec--;
+#endif
+
 	if (yr > 99 || mon < 1 || mon > 12 || day > 31 || day < 1 ||
 	    hr > 23 || min > 59 || sec > 59) {
 		printk(KERN_ERR
@@ -82,11 +87,12 @@ void sh_rtc_gettimeofday(struct timeval 
 	}
 
 	tv->tv_sec = mktime(yr100 * 100 + yr, mon, day, hr, min, sec);
-	tv->tv_usec = ((sec128 ^ RTC_BIT_INVERTED) * 1000000) / 128;
+	tv->tv_usec = (sec128 * 1000000) / 128;
 }
 
-static int set_rtc_time(unsigned long nowtime)
+int sh_rtc_settimeofday(const struct timeval *tv)
 {
+	unsigned long nowtime = tv->tv_sec;
 	int retval = 0;
 	int real_seconds, real_minutes, cmos_minutes;
 
@@ -122,13 +128,4 @@ static int set_rtc_time(unsigned long no
 	ctrl_outb(RCR2_RTCEN|RCR2_START, RCR2);  /* Start RTC */
 
 	return retval;
-}
-
-int sh_rtc_settimeofday(const struct timeval *tv)
-{
-#if RTC_BIT_INVERTED != 0
-	/* This is not accurate, but better than nothing. */
-	schedule_timeout(HZ/2);
-#endif
-	return set_rtc_time(tv->tv_sec);
 }
diff -ruN3p v2.4.17-pre8/drivers/char/shwdt.c linux/drivers/char/shwdt.c
--- v2.4.17-pre8/drivers/char/shwdt.c	Tue Oct 16 05:36:48 2001
+++ linux/drivers/char/shwdt.c	Tue Dec 11 15:52:33 2001
@@ -10,7 +10,6 @@
  * Free Software Foundation; either version 2 of the License, or (at your
  * option) any later version.
  */
-
 #include <linux/config.h>
 #include <linux/module.h>
 #include <linux/init.h>
@@ -177,7 +176,7 @@ static int sh_wdt_close(struct inode *in
  * 	sh_wdt_read - Read from Device
  *
  * 	@file: file handle of device
- * 	@char: buffer to write to
+ * 	@buf: buffer to write to
  * 	@count: length of buffer
  * 	@ppos: offset
  *
@@ -193,7 +192,7 @@ static ssize_t sh_wdt_read(struct file *
  * 	sh_wdt_write - Write to Device
  *
  * 	@file: file handle of device
- * 	@char: buffer to write
+ * 	@buf: buffer to write
  * 	@count: length of buffer
  * 	@ppos: offset
  *
@@ -269,7 +268,7 @@ static int sh_wdt_ioctl(struct inode *in
 static int sh_wdt_notify_sys(struct notifier_block *this,
 			     unsigned long code, void *unused)
 {
-	if (code == SYS_DOWN || SYS_HALT) {
+	if (code == SYS_DOWN || code == SYS_HALT) {
 		sh_wdt_stop();
 	}
 
diff -ruN3p v2.4.17-pre8/include/asm-sh/pci.h linux/include/asm-sh/pci.h
--- v2.4.17-pre8/include/asm-sh/pci.h	Sat Oct 13 07:35:54 2001
+++ linux/include/asm-sh/pci.h	Tue Dec 11 15:52:33 2001
@@ -196,6 +196,11 @@ static inline int pci_dma_supported(stru
 	return 1;
 }
 
+/* Not supporting more than 32-bit PCI bus addresses now, but
+ * must satisfy references to this function.  Change if needed.
+ */
+#define pci_dac_dma_supported(pci_dev, mask) (0)
+
 /* Return the index of the PCI controller for device PDEV. */
 #define pci_controller_num(PDEV)	(0)
 
diff -ruN3p v2.4.17-pre8/include/asm-sh/stat.h linux/include/asm-sh/stat.h
--- v2.4.17-pre8/include/asm-sh/stat.h	Tue Aug  1 09:38:07 2000
+++ linux/include/asm-sh/stat.h	Tue Dec 11 15:52:33 2001
@@ -42,8 +42,16 @@ struct stat {
  * insane amounts of padding around dev_t's.
  */
 struct stat64 {
+#if defined(__BIG_ENDIAN__)
+	unsigned char   __pad0b[6];
 	unsigned short	st_dev;
-	unsigned char	__pad0[10];
+#elif defined(__LITTLE_ENDIAN__)
+	unsigned short	st_dev;
+	unsigned char	__pad0b[6];
+#else
+#error Must know endian to build stat64 structure!
+#endif
+	unsigned char	__pad0[4];
 
 	unsigned long	st_ino;
 	unsigned int	st_mode;
@@ -52,14 +60,25 @@ struct stat64 {
 	unsigned long	st_uid;
 	unsigned long	st_gid;
 
+#if defined(__BIG_ENDIAN__)
+	unsigned char	__pad3b[6];
+	unsigned short	st_rdev;
+#else /* Must be little */
 	unsigned short	st_rdev;
-	unsigned char	__pad3[10];
+	unsigned char	__pad3b[6];
+#endif
+	unsigned char	__pad3[4];
 
 	long long	st_size;
 	unsigned long	st_blksize;
 
+#if defined(__BIG_ENDIAN__)
+	unsigned long	__pad4;		/* Future possible st_blocks hi bits */
+	unsigned long	st_blocks;	/* Number 512-byte blocks allocated. */
+#else /* Must be little */
 	unsigned long	st_blocks;	/* Number 512-byte blocks allocated. */
-	unsigned long	__pad4;		/* future possible st_blocks high bits */
+	unsigned long	__pad4;		/* Future possible st_blocks hi bits */
+#endif
 
 	unsigned long	st_atime;
 	unsigned long	__pad5;
diff -ruN3p v2.4.17-pre8/include/asm-sh/uaccess.h linux/include/asm-sh/uaccess.h
--- v2.4.17-pre8/include/asm-sh/uaccess.h	Tue Oct 16 05:36:48 2001
+++ linux/include/asm-sh/uaccess.h	Tue Dec 11 15:52:33 2001
@@ -216,6 +216,7 @@ __asm__ __volatile__( \
 	: "r" (val), "m" (__m(addr)), "i" (-EFAULT) \
         : "memory"); })
 #else
+#define __put_user_u64(val,addr,retval) \
 ({ \
 __asm__ __volatile__( \
 	"1:\n\t" \
-- 

[linuxsh-dev] [PATCH] RTC bug on SH-4

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

SUGIOKA Toshinobu wrote:
 > When I comment out schedule_timeout(HZ/2) calls in
 > arch/sh/kernel/rtc.c:sh_rtc_settimeofday, these messages disappear.
 > 
 > I think that sh_rtc_settimeofday is called from time.c:do_timer_interrupt,
 > so we should not call schedule_timeout here.

Good.  For me, it's good.  Please check it in to both tree (2.4 and 2.5).
-- 

Re: [linuxsh-dev] Drop-In tree updates

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

David Woodhouse wrote:
 > I sent Linus and Marcelo the patch to remove #include <asm/segment.h> from 
 > all offending drivers. I'll resend it soon.

Thanks.  FYI, I've been sending the patch removing to relevant
maintainers when I found the error against <asm/segment.h> for SuperH.
For CD-ROM driver and Joystick drivers, I didn't success.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Paul M. <pm...@mv...>]

On Tue, Dec 11, 2001 at 06:21:58PM +0900, NIIBE Yutaka wrote:
> And for GT-64111, I've read a manual for GT-64111:
> 	http://cobalt22.cobalt.com/docs/gt64111_rev11.pdf
>=20
> It says, the initial value is 0x4146 but ID number is 0x146.  I'm
> confused.  Is that really valid entry?
>=20
Looks like they got confused in their wording .. just for clarification,
device ID 0x146 refers to the GT64010A controller, which was one of their
earlist ones.

As far as what Cobalt shipped their configurations with, very early boards
(pre Cobalt-27 IIRC), shipped with the GT64011 (device ID 0x4146), which
Galileo later replaced with the GT64111. Since the GT64111 was intended as a
complete and total drop-in replacement for the GT64011, it retained the same
device ID. The only noticeable difference is that the GT64111 consumed a lot
less power, and supported voltages of both 3.3 and 5V.

Galileo also has a brief entry in their FAQ that compare the two and list
the changes in the GT64111, which can be obtained from here:

http://marvell.com/Products/Doc_Files/224/faq_gt64_641_960_961xxx.pdf)

The relevant section is found on pages 4 and 5.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxsh-dev] Drop-In tree updates

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

gn...@m1... said:
>  For the addition of include/asm-sh/segment.h, IIRC, our conclusion
> was: have it in our tree for convenience, but not send it to mainline
> because the it has been obsolete for seven years or so.

I sent Linus and Marcelo the patch to remove #include <asm/segment.h> from 
all offending drivers. I'll resend it soon.

--
dwmw2

Re: [linuxsh-dev] Drop-In tree updates

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

rm...@te... said:
>  I've CC'ed David.  David, we are working on syncing the SH tree.
> Note maintainer is not sending your mtd work off -- I just wanted to
> make sure you were aware.

> If you get the chance it would be great to merge your changes upstream
> with Marcelo and Linus :)

Feel free to send that part if you like. I'll then work from there when I
get round to syncing up again, which ought to be soon. Just let Linus and/or
Marcelo know I approved - not that Linus usually takes care to reject 
patches from non-maintainers anyway.

--
dwmw2

Re: [linuxsh-dev] Drop-In tree updates

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

Folks

> STMicro people please confirm the pci.ids change is valid (or not).
> At http://www.yourvote.com/pci/pciread.asp?sort=venid
> The entry is:
> 	ST Microelectronics
> (with space between ST and Microelectronics).

I'll try submitting a change. There shouldn't be a space in the name.

> And for GT-64111, I've read a manual for GT-64111:
> 	http://cobalt22.cobalt.com/docs/gt64111_rev11.pdf
> 
> It says, the initial value is 0x4146 but ID number is 0x146.  I'm
> confused.  Is that really valid entry?

The 1.0 rev of the document has the same typo (which we used when
writing the 7750 Overdrive software). I'll try and remember to
see what the hardware says next time I fire it up.

However the earlier chip, the 64010 appears to have ID 0146. So maybe
it makes sense for the later one to be 4146? We'll see.

> I won't send the patch of pci.ids to maintainer, please do that by yourself.

OK

Thanks

Stuart

Re: [linuxsh-dev] Drop-In tree updates

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Tue, Dec 11, 2001:

>=20
> For DC guys:
>=20
> BTW, I've submit the information for Dreamcast BBA to
> 	http://www.yourvote.com/pci/pciread.asp
> for inclusion.
>=20
> I won't send the patch of pci.ids to maintainer, please do that by yourse=
lf.

Cool.  No problem.

M. R.

[linuxsh-dev] 2.4 branch

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

I'll commit following change to 2.4 branch of our repository, 
if there's no objection.

2001-12-11  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/kernel/pci-sh7751.c: Change Martin Mares' e-mail
	address as mainline.
	* mm/memory.c (do_wp_page): Re-introduce ifdef-out-ing
	flush_cache_page.
	* arch/sh/kernel/sys_sh.c-1.7: Removed.
	
Index: arch/sh/kernel/pci-sh7751.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/pci-sh7751.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 pci-sh7751.c
--- arch/sh/kernel/pci-sh7751.c	2001/10/15 20:44:49	1.1.1.1
+++ arch/sh/kernel/pci-sh7751.c	2001/12/11 09:30:00
@@ -3,7 +3,7 @@
  *
  *  Dustin McIntire (du...@se...)
  *	Derived from arch/i386/kernel/pci-*.c which bore the message:
- *	(c) 1999--2000 Martin Mares <mj...@su...>
+ *	(c) 1999--2000 Martin Mares <mj...@uc...>
  *	
  *  May be copied or modified under the terms of the GNU General Public
  *  License.  See linux/COPYING for more information.
Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/mm/memory.c,v
retrieving revision 1.1.1.1.2.2
diff -u -3 -p -r1.1.1.1.2.2 memory.c
--- mm/memory.c	2001/11/30 23:03:58	1.1.1.1.2.2
+++ mm/memory.c	2001/12/11 09:30:00
@@ -917,7 +917,9 @@ static int do_wp_page(struct mm_struct *
 		int reuse = can_share_swap_page(old_page);
 		unlock_page(old_page);
 		if (reuse) {
+#if 0 /* This is not needed for VIPT cache, performance goes bad if we flush */
 			flush_cache_page(vma, address);
+#endif
 			establish_pte(vma, address, page_table, pte_mkyoung(pte_mkdirty(pte_mkwrite(pte))));
 			spin_unlock(&mm->page_table_lock);
 			return 1;	/* Minor fault */
-- 

Re: [linuxsh-dev] Drop-In tree updates

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

STMicro people please confirm the pci.ids change is valid (or not).
At http://www.yourvote.com/pci/pciread.asp?sort=venid
The entry is:
	ST Microelectronics
(with space between ST and Microelectronics).

And for GT-64111, I've read a manual for GT-64111:
	http://cobalt22.cobalt.com/docs/gt64111_rev11.pdf

It says, the initial value is 0x4146 but ID number is 0x146.  I'm
confused.  Is that really valid entry?

I won't send the patch of pci.ids to maintainer, please do that by yourself.

For DC guys:

BTW, I've submit the information for Dreamcast BBA to
	http://www.yourvote.com/pci/pciread.asp
for inclusion.

I won't send the patch of pci.ids to maintainer, please do that by yourself.
-- 

Re: [linuxsh-dev] [PATCH] RTC bug on SH-4

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 04:02, SUGIOKA Toshinobu wrote:

> When I comment out schedule_timeout(HZ/2) calls in
> arch/sh/kernel/rtc.c:sh_rtc_settimeofday, these messages disappear.
> 
> I think that sh_rtc_settimeofday is called from time.c:do_timer_interrupt,
> so we should not call schedule_timeout here.

Yes, this seems correct.  Why was schedule_timeout being called there
anyway?

	Robert Love

[linuxsh-dev] [PATCH] RTC bug on SH-4

[SUGIOKA T. <su...@it...>]

Hi all.

I'm using kernel 2.4.16 on my SH-4 board.
After I start xntpd, I get following kernel messages.

---------------------------------------------
Scheduling in interrupt
kernel BUG at sched.c:551!
alloc_skb called nonatomically from interrupt 880c2086
Warning: kfree_skb on hard IRQ 88105074
Warning: kfree_skb on hard IRQ 880ae3c6
---------------------------------------------

When I comment out schedule_timeout(HZ/2) calls in
arch/sh/kernel/rtc.c:sh_rtc_settimeofday, these messages disappear.

I think that sh_rtc_settimeofday is called from time.c:do_timer_interrupt,
so we should not call schedule_timeout here.

Here is the patch. Please test it.

	* arch/sh/kernel/rtc.c (sh_rtc_gettimeofday): Another work around implemented.
	(set_rtc_time sh_rtc_settimeofday): merged.

Index: arch/sh/kernel/rtc.c
===================================================================
RCS file: /home/cvs/linux/linux-sh-2.4/arch/sh/kernel/rtc.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 rtc.c
--- arch/sh/kernel/rtc.c        2001/05/28 10:39:21     1.1.1.1
+++ arch/sh/kernel/rtc.c        2001/12/11 07:41:45
@@ -46,7 +46,7 @@
        } while ((ctrl_inb(RCR1) & RCR1_CF) != 0);

 #if RTC_BIT_INVERTED != 0
-       /* Work around to avoid reading correct value. */
+       /* Work around to avoid reading incorrect value. */
        if (sec128 == RTC_BIT_INVERTED) {
                schedule_timeout(1);
                goto again;
@@ -81,12 +81,18 @@
                goto again;
        }

+#if RTC_BIT_INVERTED != 0
+       if ((sec128 & RTC_BIT_INVERTED) != 0)
+               sec--;
+#endif
+
        tv->tv_sec = mktime(yr100 * 100 + yr, mon, day, hr, min, sec);
-       tv->tv_usec = ((sec128 ^ RTC_BIT_INVERTED) * 1000000) / 128;
+       tv->tv_usec = (sec128 * 1000000) / 128;
 }

-static int set_rtc_time(unsigned long nowtime)
+int sh_rtc_settimeofday(const struct timeval *tv)
 {
+       unsigned long nowtime = tv->tv_sec;
        int retval = 0;
        int real_seconds, real_minutes, cmos_minutes;

@@ -122,13 +128,4 @@
        ctrl_outb(RCR2_RTCEN|RCR2_START, RCR2);  /* Start RTC */

        return retval;
-}
-
-int sh_rtc_settimeofday(const struct timeval *tv)
-{
-#if RTC_BIT_INVERTED != 0
-       /* This is not accurate, but better than nothing. */
-       schedule_timeout(HZ/2);
-#endif
-       return set_rtc_time(tv->tv_sec);
 }

----
SUGIOKA Toshinobu

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 03:40, NIIBE Yutaka wrote:
> Ooops, 2.4 tree is now about to be released for 2.4.17, and it's not
> time to send update...

Send it against 2.4.17, for inclusion in 2.4.18-pre1.  Marcelo should
take it.

It might be wise to separate or at least point out where we touch non-SH
things.  Everything that is SH only is considered safe, since you are
maintainer and it won't hurt anything else.

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

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

Ooops, 2.4 tree is now about to be released for 2.4.17, and it's not
time to send update...

Well, I'll send following update for 2.5 soon.

If it's true that people test 2.5 more, it will result good effect,
2.5 at first and 2.4 later, possibly include feedback from testing.

--------------------------
* Documentation for adding new machine (Stuart Menefy)
  Documentation/sh/new-machine.txt

* Follows PCI interface update (Jeremy Siegel)
 include/asm-sh/pci.h

* Configuration fix (Jeremy Siegel)
 arch/sh/config.in

* Solution Engine 7751 update  (Jeremy Siegel)
 arch/sh/kernel/io_7751se.c
 arch/sh/kernel/pci-7751se.c

* Big endian support fixes (Jeremy Siegel, Tomoyoshi ASANO)
 include/asm-sh/stat.h
 include/asm-sh/uaccess.h

* SuperH watch dog timer fix (Paul Mundt)
 drivers/char/shwdt.c

* Follow new interface of sched.c (will implement later)
 arch/sh/kernel/traps.c

diff -ruN3p v2.5.1-pre9/Documentation/sh/new-machine.txt linux/Documentation/sh/new-machine.txt
--- v2.5.1-pre9/Documentation/sh/new-machine.txt	Thu Jan  1 09:00:00 1970
+++ linux/Documentation/sh/new-machine.txt	Tue Dec 11 16:37:15 2001
@@ -0,0 +1,77 @@
+The multiple machine support relies on redirecting all functions which will
+need to be machine specific through a table of function pointers, the
+machvec. These functions fall into a number of categories:
+
+ - I/O functions to IO memory (inb etc) and PCI/main memory (readb etc).
+ - I/O remapping functions (ioremap etc)
+ - some initialisation functions
+ - a 'heartbeat' function
+ - some miscellaneous flags
+
+The tree can be built in two ways:
+ - as a fully generic build. All drivers are linked in, and all functions
+   go through the machvec
+ - as a machine specific build. In this case only the required drivers
+   will be linked in, and some macros may be redefined to not go through
+   the machvec where performance is important (in particular IO functions).
+
+There are three ways in which IO can be performed:
+ - none at all. This is really only useful for the 'unknown' machine type,
+   which us designed to run on a machine about which we know nothing, and
+   so all all IO instructions do nothing.
+ - fully custom. In this case all IO functions go to a machine specific
+   set of functions which can do what they like
+ - a generic set of functions. These will cope with most situations,
+   and rely on a single function, mv_port2addr, which is called through the
+   machine vector, and converts an IO address into a memory address, which
+   can be read from/written to directly.
+
+Thus adding a new machine involves the following steps (I will assume I am
+adding a machine called fred):
+
+ - add a new file include/asm-sh/io_fred.h which contains prototypes for
+   any machine specific IO functions prefixed with the machine name, for
+   example fred_inb. These will be needed when filling out the machine
+   vector. In addition, a section is required which defines what to do when
+   building a machine specific version. For example:
+
+     #ifdef __WANT_IO_DEF
+     #define inb  fred_inb
+     ...
+     #endif
+
+   This is the minimum that is required, however there are ample
+   opportunities to optimise this. In particular, by making the prototypes
+   inline function definitions, it is possible to inline the function when
+   building machine specific versions. Note that the machine vector
+   functions will still be needed, so that a module built for a generic
+   setup can be loaded.
+
+ - add a new file arch/sh/kernel/mach_fred.c. This contains the definition
+   of the machine vector. When building the machine specific version, this
+   will be the real machine vector (via an alias), while in the generic
+   version is used to initialise the machine vector, and then freed, by
+   making it initdata. This should be defined as:
+
+     struct sh_machine_vector mv_fred __initmv = {
+       mv_name: "Fred"
+     }
+     ALIAS_MV(se)
+
+ - finally add a file arch/sh/kernel/io_fred.c, which contains
+   definitions of the machine specific io functions.
+
+A note about initialisation functions. Three initialisation functions are
+provided in the machine vector:
+ - mv_arch_init - called very early on from setup_arch
+ - mv_init_irq - called from init_IRQ, after the generic SH interrupt
+   initialisation
+ - mv_init_pci - currently not used
+
+Any other remaining functions which need to be called at start up can be
+added to the list using the __initcalls macro (or module_init if the code
+can be built as a module). Many generic drivers probe to see if the device
+they are targeting is present, however this may not always be appropriate,
+so a flag can be added to the machine vector which will be set on those
+machines which have the hardware in question, reducing the probe to a
+single conditional.
diff -ruN3p v2.5.1-pre9/arch/sh/config.in linux/arch/sh/config.in
--- v2.5.1-pre9/arch/sh/config.in	Tue Oct 16 05:36:48 2001
+++ linux/arch/sh/config.in	Tue Dec 11 16:37:15 2001
@@ -189,7 +189,7 @@ if [ "$CONFIG_PCI" = "y" ]; then
    if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
       define_bool CONFIG_PCI_DIRECT y
    fi
-   define_bool CONFIG_SH_PCIDMA_NONCOHERENT n
+   bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT n
 fi
 
 source drivers/pci/Config.in
diff -ruN3p v2.5.1-pre9/arch/sh/kernel/io_7751se.c linux/arch/sh/kernel/io_7751se.c
--- v2.5.1-pre9/arch/sh/kernel/io_7751se.c	Sun Sep  9 04:29:09 2001
+++ linux/arch/sh/kernel/io_7751se.c	Tue Dec 11 16:37:15 2001
@@ -17,7 +17,7 @@
 #include <asm/hitachi_7751se.h>
 #include <asm/addrspace.h>
 
-#include <asm/pci.h>
+#include <linux/pci.h>
 #include <asm/pci-sh7751.h>
 
 #if 0
@@ -70,7 +70,7 @@ port2adr(unsigned int port)
 	else
 		return (volatile __u16 *) (PA_SUPERIO + (port << 1));
 #endif
-	maybebadio(name,port);
+	maybebadio(name,(unsigned long)port);
 	return (volatile __u16*)port;
 }
 
@@ -276,6 +276,7 @@ void sh7751se_writel(unsigned int b, uns
 /* ISA page descriptor.  */
 static __u32 sh_isa_memmap[256];
 
+#if 0
 static int
 sh_isa_mmap(__u32 start, __u32 length, __u32 offset)
 {
@@ -286,12 +287,11 @@ sh_isa_mmap(__u32 start, __u32 length, _
 
 	idx = start >> 12;
 	sh_isa_memmap[idx] = 0xb8000000 + (offset &~ 0xfff);
-#if 0
 	printk("sh_isa_mmap: start %x len %x offset %x (idx %x paddr %x)\n",
 	       start, length, offset, idx, sh_isa_memmap[idx]);
-#endif
 	return 0;
 }
+#endif
 
 unsigned long
 sh7751se_isa_port2addr(unsigned long offset)
diff -ruN3p v2.5.1-pre9/arch/sh/kernel/pci-7751se.c linux/arch/sh/kernel/pci-7751se.c
--- v2.5.1-pre9/arch/sh/kernel/pci-7751se.c	Sun Sep  9 04:29:09 2001
+++ linux/arch/sh/kernel/pci-7751se.c	Tue Dec 11 16:37:15 2001
@@ -37,7 +37,6 @@
  */
 int __init pcibios_init_platform(void)
 {
-   unsigned long data;
    unsigned long bcr1, wcr1, wcr2, wcr3, mcr;
    unsigned short bcr2;
 
diff -ruN3p v2.5.1-pre9/arch/sh/kernel/traps.c linux/arch/sh/kernel/traps.c
--- v2.5.1-pre9/arch/sh/kernel/traps.c	Sun Sep  9 04:29:09 2001
+++ linux/arch/sh/kernel/traps.c	Tue Dec 11 16:37:15 2001
@@ -560,3 +560,8 @@ void dump_stack(void)
 		}
 	}
 }
+
+void show_trace_task(struct task_struct *tsk)
+{
+	printk("Backtrace not yet implemented for SH.\n");
+}
diff -ruN3p v2.5.1-pre9/drivers/char/shwdt.c linux/drivers/char/shwdt.c
--- v2.5.1-pre9/drivers/char/shwdt.c	Tue Oct 16 05:36:48 2001
+++ linux/drivers/char/shwdt.c	Tue Dec 11 16:37:15 2001
@@ -10,7 +10,6 @@
  * Free Software Foundation; either version 2 of the License, or (at your
  * option) any later version.
  */
-
 #include <linux/config.h>
 #include <linux/module.h>
 #include <linux/init.h>
@@ -177,7 +176,7 @@ static int sh_wdt_close(struct inode *in
  * 	sh_wdt_read - Read from Device
  *
  * 	@file: file handle of device
- * 	@char: buffer to write to
+ * 	@buf: buffer to write to
  * 	@count: length of buffer
  * 	@ppos: offset
  *
@@ -193,7 +192,7 @@ static ssize_t sh_wdt_read(struct file *
  * 	sh_wdt_write - Write to Device
  *
  * 	@file: file handle of device
- * 	@char: buffer to write
+ * 	@buf: buffer to write
  * 	@count: length of buffer
  * 	@ppos: offset
  *
@@ -269,7 +268,7 @@ static int sh_wdt_ioctl(struct inode *in
 static int sh_wdt_notify_sys(struct notifier_block *this,
 			     unsigned long code, void *unused)
 {
-	if (code == SYS_DOWN || SYS_HALT) {
+	if (code == SYS_DOWN || code == SYS_HALT) {
 		sh_wdt_stop();
 	}
 
diff -ruN3p v2.5.1-pre9/include/asm-sh/pci.h linux/include/asm-sh/pci.h
--- v2.5.1-pre9/include/asm-sh/pci.h	Sat Oct 13 07:35:54 2001
+++ linux/include/asm-sh/pci.h	Tue Dec 11 16:37:15 2001
@@ -196,6 +196,11 @@ static inline int pci_dma_supported(stru
 	return 1;
 }
 
+/* Not supporting more than 32-bit PCI bus addresses now, but
+ * must satisfy references to this function.  Change if needed.
+ */
+#define pci_dac_dma_supported(pci_dev, mask) (0)
+
 /* Return the index of the PCI controller for device PDEV. */
 #define pci_controller_num(PDEV)	(0)
 
diff -ruN3p v2.5.1-pre9/include/asm-sh/stat.h linux/include/asm-sh/stat.h
--- v2.5.1-pre9/include/asm-sh/stat.h	Tue Aug  1 09:38:07 2000
+++ linux/include/asm-sh/stat.h	Tue Dec 11 16:37:15 2001
@@ -42,8 +42,16 @@ struct stat {
  * insane amounts of padding around dev_t's.
  */
 struct stat64 {
+#if defined(__BIG_ENDIAN__)
+	unsigned char   __pad0b[6];
 	unsigned short	st_dev;
-	unsigned char	__pad0[10];
+#elif defined(__LITTLE_ENDIAN__)
+	unsigned short	st_dev;
+	unsigned char	__pad0b[6];
+#else
+#error Must know endian to build stat64 structure!
+#endif
+	unsigned char	__pad0[4];
 
 	unsigned long	st_ino;
 	unsigned int	st_mode;
@@ -52,14 +60,25 @@ struct stat64 {
 	unsigned long	st_uid;
 	unsigned long	st_gid;
 
+#if defined(__BIG_ENDIAN__)
+	unsigned char	__pad3b[6];
+	unsigned short	st_rdev;
+#else /* Must be little */
 	unsigned short	st_rdev;
-	unsigned char	__pad3[10];
+	unsigned char	__pad3b[6];
+#endif
+	unsigned char	__pad3[4];
 
 	long long	st_size;
 	unsigned long	st_blksize;
 
+#if defined(__BIG_ENDIAN__)
+	unsigned long	__pad4;		/* Future possible st_blocks hi bits */
+	unsigned long	st_blocks;	/* Number 512-byte blocks allocated. */
+#else /* Must be little */
 	unsigned long	st_blocks;	/* Number 512-byte blocks allocated. */
-	unsigned long	__pad4;		/* future possible st_blocks high bits */
+	unsigned long	__pad4;		/* Future possible st_blocks hi bits */
+#endif
 
 	unsigned long	st_atime;
 	unsigned long	__pad5;
diff -ruN3p v2.5.1-pre9/include/asm-sh/uaccess.h linux/include/asm-sh/uaccess.h
--- v2.5.1-pre9/include/asm-sh/uaccess.h	Tue Oct 16 05:36:48 2001
+++ linux/include/asm-sh/uaccess.h	Tue Dec 11 16:37:15 2001
@@ -216,6 +216,7 @@ __asm__ __volatile__( \
 	: "r" (val), "m" (__m(addr)), "i" (-EFAULT) \
         : "memory"); })
 #else
+#define __put_user_u64(val,addr,retval) \
 ({ \
 __asm__ __volatile__( \
 	"1:\n\t" \
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 01:20, NIIBE Yutaka wrote:

> * 8139too driver
> 
>  >  Documentation/Configure.help                   |    6 
>  >  drivers/net/8139too.c                          |   25 +
> 
> This is changes for 8139too, I and Takeshi sent them to 8139too
> maintainer two or three times, but it has not yet included.
> I don't know the status of this change.  Takeshi?

Oh, I didn't notice this.  I don't know who you sent it to, but send it
to Jeff Garzick <jg...@ma...> and CC lkml and Marcelo.

I'll even do this if you like, I know Jeff.  Who did the 8139too work?

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 01:20, NIIBE Yutaka wrote:
> * MTD driver
> 
>  >  drivers/mtd/maps/solutionengine.c              |   47 +-
>  >  drivers/mtd/mtdpart.c                          |   11 
>  >  drivers/mtd/maps/Config.in                     |   11 
>  >  include/linux/mtd/partitions.h                 |    7 
> 
> Since these files are maintained by David Woodhouse, I don't send them to
> mainline.

I've CC'ed David.  David, we are working on syncing the SH tree.  Note
maintainer is not sending your mtd work off -- I just wanted to make
sure you were aware.

If you get the chance it would be great to merge your changes upstream
with Marcelo and Linus :)

	Robert Love