[PATCH] SiS55x, another x86 CPU

[PATCH] SiS55x, another x86 CPU

[Hans Schou]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 972 bytes --]

Hi

Here is the unknown CPU mensioned earlier.

It is a SiS55x CPU from Silicon Integrated Systems Corp.

This is a Pentium 5 like CPU primary target embedded devices. It is a 
System-On-Chip with several i/o devices like AC97, USB, IDE and net on 
board. The same core is used in SiS550, SiS551 and SiS552 as the 
difference is only which periferial devices which is added. Then the 
CPU can not detect the model but the kernel should be able to detect 
the other devices connected internally to SiS551 and SiS552. So, the 
model_id would be '0' and then the text 'SiS55x' as model_name.

Detected CPU flags in /proc/cpuinfo and in the datasheet:
flags           : fpu tsc cx8 mmx

Instruction and data cache is 8KB each it says in the datasheet. I'm 
not sure but it does not look like it is written in dmesg.

ACPI sleep supports S1 S2 S3 S4 S5.

CPU power states supports C0 C1 C2 C3.

See attachment. (I hope it gets here!)

Signed-off-by: Hans Schou <linux@schou.dk>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 4277 bytes --]

diff -Naur a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
--- a/arch/x86/Kconfig.cpu	2008-10-11 23:03:47.000000000 +0200
+++ b/arch/x86/Kconfig.cpu	2008-10-12 00:30:08.000000000 +0200
@@ -242,6 +242,13 @@
 	  Select this for a VIA C7.  Selecting this uses the correct cache
 	  shift and tells gcc to treat the CPU as a 686.
 
+config MSIS55X
+	bool "SiS55x"
+	depends on X86_32
+	help
+	  Select this for a SiS550/551/552 SoC. Selecting this uses the
+	  correct cache shift and tells gcc to treat the CPU as a 586.
+
 config MPSC
 	bool "Intel P4 / older Netburst based Xeon"
 	depends on X86_64
@@ -309,7 +316,7 @@
 	int
 	default "7" if MPENTIUM4 || X86_GENERIC || GENERIC_CPU || MPSC
 	default "4" if X86_ELAN || M486 || M386 || MGEODEGX1
-	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
+	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX || MSIS55X
 	default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MVIAC7
 
 config X86_XADD
@@ -351,7 +358,7 @@
 
 config X86_ALIGNMENT_16
 	def_bool y
-	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1
+	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1 || MSIS55X
 
 config X86_INTEL_USERCOPY
 	def_bool y
@@ -387,7 +394,7 @@
 
 config X86_TSC
 	def_bool y
-	depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ) || X86_64
+	depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MSIS55X || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ) || X86_64
 
 config X86_CMPXCHG64
 	def_bool y
@@ -464,6 +471,13 @@
 	help
 	  This enables extended support for UMC processors
 
+config CPU_SUP_SIS_32
+	default y
+	bool "Support SiS processors" if PROCESSOR_SELECT
+	depends on !64BIT
+	help
+	  This enables extended support for SIS processors
+
 config X86_DS
 	bool "Debug Store support"
 	default y
diff -Naur a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
--- a/arch/x86/kernel/cpu/Makefile	2008-10-11 23:03:47.000000000 +0200
+++ b/arch/x86/kernel/cpu/Makefile	2008-10-03 23:56:53.000000000 +0200
@@ -15,6 +15,7 @@
 obj-$(CONFIG_CPU_SUP_CENTAUR_64)	+= centaur_64.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_CPU_SUP_SIS_32)		+= sis.o
 
 obj-$(CONFIG_X86_MCE)	+= mcheck/
 obj-$(CONFIG_MTRR)	+= mtrr/
diff -Naur a/arch/x86/kernel/cpu/sis.c b/arch/x86/kernel/cpu/sis.c
--- a/arch/x86/kernel/cpu/sis.c	1970-01-01 01:00:00.000000000 +0100
+++ b/arch/x86/kernel/cpu/sis.c	2008-10-11 11:04:23.000000000 +0200
@@ -0,0 +1,25 @@
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/processor.h>
+#include "cpu.h"
+
+static unsigned int __cpuinit sis_size_cache(struct cpuinfo_x86 *c, unsigned int size)
+{
+	return 8;
+}
+
+static struct cpu_dev sis_cpu_dev __cpuinitdata = {
+	.c_vendor	= "SiS",
+	.c_ident 	= { "SiS SiS SiS " },
+	.c_models = {
+		{ .vendor = X86_VENDOR_SIS, .family = 5, .model_names =
+		  { 
+			  [0] = "SiS55x", 
+		  }
+		},
+	},
+	.c_size_cache	= sis_size_cache,
+	.c_x86_vendor	= X86_VENDOR_SIS,
+};
+
+cpu_dev_register(sis_cpu_dev);
diff -Naur a/include/asm-x86/processor.h b/include/asm-x86/processor.h
--- a/include/asm-x86/processor.h	2008-10-11 23:03:47.000000000 +0200
+++ b/include/asm-x86/processor.h	2008-10-03 23:53:00.000000000 +0200
@@ -119,7 +119,8 @@
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_SIS		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 

Re: [PATCH] SiS55x, another x86 CPU

[Andi Kleen]

Hans Schou <linux@schou.dk> writes:


> flags           : fpu tsc cx8 mmx
>
> Instruction and data cache is 8KB each it says in the datasheet. I'm
> not sure but it does not look like it is written in dmesg.
>
> ACPI sleep supports S1 S2 S3 S4 S5.
>
> CPU power states supports C0 C1 C2 C3.
>
> See attachment. (I hope it gets here!)

Your attachment seems to be windows line end damaged.
Also the changes are so small that it's not worth adding a CONFIG
for it. Just add it unconditionally.
And hardcoding the cache size for all of SiS seems a bit extreme.
What happens when SiS ever brings out another part with different caches?
Ideally figure out some way to detect this particular CPU and only
use 8 KB only for that. Alternatively ignore it (there's nothing
really in the kernel that uses the cache sizes anyways)

-Andi

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Mon, 13 Oct 2008, Andi Kleen wrote:

> Hans Schou <linux@schou.dk> writes:
>
>
>> flags           : fpu tsc cx8 mmx
>>
>> Instruction and data cache is 8KB each it says in the datasheet. I'm
>> not sure but it does not look like it is written in dmesg.
>>
>> ACPI sleep supports S1 S2 S3 S4 S5.
>>
>> CPU power states supports C0 C1 C2 C3.
>>
>> See attachment. (I hope it gets here!)
>
> Your attachment seems to be windows line end damaged.

Strange, Pine usually do it right with file attachments.
(what is "windows line end damaged"?)

> Also the changes are so small that it's not worth adding a CONFIG 
> for it. Just add it unconditionally.

I was not trying to invent anything. It is almost a copy of the UMC 
CPU, except that it is 586 code.

> And hardcoding the cache size for all of SiS seems a bit extreme. 
> What happens when SiS ever brings out another part with different 
> caches? Ideally figure out some way to detect this particular CPU 
> and only use 8 KB only for that. Alternatively ignore it (there's 
> nothing really in the kernel that uses the cache sizes anyways)

In that case the cache could be deleted.

One annoying thing is that the "model name" in /proc/cpuinfo is 
written as "00/55" instead of "SiS55x" when the CPU is not detected.

The worst problem is that an unknown CPU writes:
printk(KERN_ERR "CPU: Your system may be unstable.\n");
and the SiS55x is not unstable. Not until now at least and it has been 
on the market for 5 years.

Maybe the message could be changed to something less catastrophic when 
CPU is unknown.

So, many solutions could be be better than the one there is now.
And if the new solution will be usefull for other unknown CPU's it 
will be even better.

/hans

Re: [PATCH] SiS55x, another x86 CPU

[Andi Kleen]

> >Your attachment seems to be windows line end damaged.
> 
> Strange, Pine usually do it right with file attachments.

It likely was added on some Windows system.

> (what is "windows line end damaged"?)

It used MSDOS style \r\n line terminators instead of Unix style \n.

> 
> >Also the changes are so small that it's not worth adding a CONFIG 
> >for it. Just add it unconditionally.
> 
> I was not trying to invent anything. It is almost a copy of the UMC 
> CPU, except that it is 586 code.

Then the comment applies to that one too.

> 
> >And hardcoding the cache size for all of SiS seems a bit extreme. 
> >What happens when SiS ever brings out another part with different 
> >caches? Ideally figure out some way to detect this particular CPU 
> >and only use 8 KB only for that. Alternatively ignore it (there's 
> >nothing really in the kernel that uses the cache sizes anyways)
> 
> In that case the cache could be deleted.
> 
> One annoying thing is that the "model name" in /proc/cpuinfo is 
> written as "00/55" instead of "SiS55x" when the CPU is not detected.

Is that really so bad?

> 
> The worst problem is that an unknown CPU writes:
> printk(KERN_ERR "CPU: Your system may be unstable.\n");

Perhaps it would be better to just remove that printk.
Its truth seems doubtful.

> and the SiS55x is not unstable. Not until now at least and it has been 
> on the market for 5 years.
> 
> Maybe the message could be changed to something less catastrophic when 
> CPU is unknown.

Yes that would be a good idea.

-Andi

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Tue, 14 Oct 2008, Andi Kleen wrote:

>>> Your attachment seems to be windows line end damaged.
>>
>> Strange, Pine usually do it right with file attachments.
>
> It likely was added on some Windows system.

>> (what is "windows line end damaged"?)
>
> It used MSDOS style \r\n line terminators instead of Unix style \n.

Yes, I do know what a CR/LF (Carriage Return Line Feed) is but I 
didn't send any. I really dont understand what you are talking about.

I looked at the mail returned from vger.kernel.org which was fine, and 
this web-page is also OK.
http://www.gossamer-threads.com/lists/linux/kernel/983150

There is no CR here:
od -t x1 patch-sis55x | grep 0d

If any CR/LF in your file you must have added them yourself.

/hans

Re: [PATCH] SiS55x, another x86 CPU

[Andi Kleen]

> If any CR/LF in your file you must have added them yourself.

There were definitely CR/LFs in the patch attachment you sent.
And no my mailer doesn't add them.

-Andi

-- 
ak@linux.intel.com

Re: [PATCH] SiS55x, another x86 CPU

[Geert Uytterhoeven]

On Wed, 15 Oct 2008, Andi Kleen wrote:
> > If any CR/LF in your file you must have added them yourself.
> 
> There were definitely CR/LFs in the patch attachment you sent.
> And no my mailer doesn't add them.

Interesting. I didn't see any CR/LFs neither, after exporting the
attachment to a file (I'm using pine).

However, when doing a base64 decode on the raw attachment data, the
CR/LFs did pop up.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Wed, 15 Oct 2008, Geert Uytterhoeven wrote:

> On Wed, 15 Oct 2008, Andi Kleen wrote:
>>> If any CR/LF in your file you must have added them yourself.
>>
>> There were definitely CR/LFs in the patch attachment you sent.
>> And no my mailer doesn't add them.
>
> Interesting. I didn't see any CR/LFs neither, after exporting the
> attachment to a file (I'm using pine).

As far as I could see, Pine does this:

1. If file has not extension like: .zip .jpg .exe, see it as ASCII
2. Add CR/LF to the file
3. Encode file as base64

On reception of the file:

1. Decode file as specified (in this case base64)
2. If it looks like a text file, convert CR/LF to LF.

> However, when doing a base64 decode on the raw attachment data, the
> CR/LFs did pop up.

I think time is up for getting rid of Pine and there stupid license. 
I'll check if "nail" can handle attachment correctly.

/hans

Re: [PATCH] SiS55x, another x86 CPU

[Geert Uytterhoeven]

On Thu, 16 Oct 2008, Hans Schou wrote:
> On Wed, 15 Oct 2008, Geert Uytterhoeven wrote:
> > On Wed, 15 Oct 2008, Andi Kleen wrote:
> > > > If any CR/LF in your file you must have added them yourself.
> > > 
> > > There were definitely CR/LFs in the patch attachment you sent.
> > > And no my mailer doesn't add them.
> > 
> > Interesting. I didn't see any CR/LFs neither, after exporting the
> > attachment to a file (I'm using pine).
> 
> As far as I could see, Pine does this:
> 
> 1. If file has not extension like: .zip .jpg .exe, see it as ASCII
> 2. Add CR/LF to the file
> 3. Encode file as base64
> 
> On reception of the file:
> 
> 1. Decode file as specified (in this case base64)
> 2. If it looks like a text file, convert CR/LF to LF.
> 
> > However, when doing a base64 decode on the raw attachment data, the
> > CR/LFs did pop up.
> 
> I think time is up for getting rid of Pine and there stupid license. I'll
> check if "nail" can handle attachment correctly.

alpine?

But, why do you send patches as attachments in the first place?
It's recommended to _not_ do that, for easier review.
Pine can handle that fine since ages (I switched from elm to pine 13 or
so years ago).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Thu, 16 Oct 2008, Geert Uytterhoeven wrote:

>> I think time is up for getting rid of Pine and there stupid license. I'll
>> check if "nail" can handle attachment correctly.
>
> alpine?

Well, Gentoo didn't have it and it is probably a "wrong" license.

> But, why do you send patches as attachments in the first place?

Ingo said I could do so when it was something to do with x86 patches.
Anyway, it looks like ^R in Pine did work correctly.

> It's recommended to _not_ do that, for easier review.

OK.

> Pine can handle that fine since ages (I switched from elm to pine 13 or
> so years ago).

Yes, my so called friends have been bullying me for that long with the Pine 
license. Mutt is not an option either.

/hans

Re: [PATCH] SiS55x, another x86 CPU

[Maciej W. Rozycki]

On Thu, 16 Oct 2008, Hans Schou wrote:

> > But, why do you send patches as attachments in the first place?
> 
> Ingo said I could do so when it was something to do with x86 patches.
> Anyway, it looks like ^R in Pine did work correctly.

 You've got:

Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

in your headers -- it may be good for poetry, but will guarantee you 
breakage with inline patches.  There's an option to disable it.

  Maciej

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Thu, 16 Oct 2008, Maciej W. Rozycki wrote:

> On Thu, 16 Oct 2008, Hans Schou wrote:
> 
> > > But, why do you send patches as attachments in the first place?
> > 
> > Ingo said I could do so when it was something to do with x86 patches.
> > Anyway, it looks like ^R in Pine did work correctly.
> 
>  You've got:
> 
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Thanks:
[X]  quell-flowed-text

> in your headers -- it may be good for poetry, but will guarantee you 
> breakage with inline patches.  There's an option to disable it.

Maybe I should start on poetry instead of kernel-patching.

"Tired of bugs?
Then try Linux."

...I don't think I can do that for a living.

/hans

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Tue, 14 Oct 2008, Hans Schou wrote:

> If any CR/LF in your file you must have added them yourself.

Sorry, you are right. Pine do change attachment which is recognized as 
ASCII text files. Pine thinks the right thing to do, based on the file 
extension, is to convert a text file to CR/LF:
http://www.washington.edu/pine/faq/attachments.html#7.2.1

I could not find a way within Pine where I could attach a file in way 
where everything is preserved as is, but regarding the actual case 
with SiS55x I don't think there is a need for posting the patch 
correctly anyway. The patch was not that popular after all.

rgds/hans

Re: [PATCH] SiS55x, another x86 CPU

[Hans Schou]

On Wed, 15 Oct 2008, H. Peter Anvin wrote:

> Hans Schou wrote:
>>
>>  Detected CPU flags in /proc/cpuinfo and in the datasheet:
>>  flags           : fpu tsc cx8 mmx
>>
>>  Instruction and data cache is 8KB each it says in the datasheet. I'm not
>>  sure but it does not look like it is written in dmesg.
>> 
>
> Could you post /proc/cpuinfo from this machine?

Sure. Here it is with a kernel 2.6.25 - not the patch below:

processor	: 0
vendor_id	: SiS SiS SiS 
cpu family	: 5
model		: 0
model name	: 05/00
stepping	: 5
cpu MHz		: 200.008
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu tsc cx8 mmx
bogomips	: 401.32
clflush size	: 32

Please note that the vendor_id has a space in the end:
"SiS SiS SiS "

> P.S. Please send x86 patches to x86@kernel.org as well as LKML.

OK. I had a problem with Pine doing linewrap. I try again.

diff -Naur a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
--- a/arch/x86/Kconfig.cpu	2008-10-11 23:03:47.000000000 +0200
+++ b/arch/x86/Kconfig.cpu	2008-10-12 00:30:08.000000000 +0200
@@ -242,6 +242,13 @@
  	  Select this for a VIA C7.  Selecting this uses the correct cache
  	  shift and tells gcc to treat the CPU as a 686.

+config MSIS55X
+	bool "SiS55x"
+	depends on X86_32
+	help
+	  Select this for a SiS550/551/552 SoC. Selecting this uses the
+	  correct cache shift and tells gcc to treat the CPU as a 586.
+
  config MPSC
  	bool "Intel P4 / older Netburst based Xeon"
  	depends on X86_64
@@ -309,7 +316,7 @@
  	int
  	default "7" if MPENTIUM4 || X86_GENERIC || GENERIC_CPU || MPSC
  	default "4" if X86_ELAN || M486 || M386 || MGEODEGX1
-	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
+	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX || MSIS55X
  	default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MVIAC7

  config X86_XADD
@@ -351,7 +358,7 @@

  config X86_ALIGNMENT_16
  	def_bool y
-	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1
+	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || X86_ELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2 || MGEODEGX1 || MSIS55X

  config X86_INTEL_USERCOPY
  	def_bool y
@@ -387,7 +394,7 @@

  config X86_TSC
  	def_bool y
-	depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ) || X86_64
+	depends on ((MWINCHIP3D || MCRUSOE || MEFFICEON || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2 || MVIAC7 || MSIS55X || MGEODEGX1 || MGEODE_LX || MCORE2) && !X86_NUMAQ) || X86_64

  config X86_CMPXCHG64
  	def_bool y
@@ -464,6 +471,13 @@
  	help
  	  This enables extended support for UMC processors

+config CPU_SUP_SIS_32
+	default y
+	bool "Support SiS processors" if PROCESSOR_SELECT
+	depends on !64BIT
+	help
+	  This enables extended support for SiS processors
+
  config X86_DS
  	bool "Debug Store support"
  	default y
diff -Naur a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
--- a/arch/x86/kernel/cpu/Makefile	2008-10-11 23:03:47.000000000 +0200
+++ b/arch/x86/kernel/cpu/Makefile	2008-10-03 23:56:53.000000000 +0200
@@ -15,6 +15,7 @@
  obj-$(CONFIG_CPU_SUP_CENTAUR_64)	+= centaur_64.o
  obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
  obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_CPU_SUP_SIS_32)		+= sis.o

  obj-$(CONFIG_X86_MCE)	+= mcheck/
  obj-$(CONFIG_MTRR)	+= mtrr/
diff -Naur a/arch/x86/kernel/cpu/sis.c b/arch/x86/kernel/cpu/sis.c
--- a/arch/x86/kernel/cpu/sis.c	1970-01-01 01:00:00.000000000 +0100
+++ b/arch/x86/kernel/cpu/sis.c	2008-10-11 11:04:23.000000000 +0200
@@ -0,0 +1,25 @@
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/processor.h>
+#include "cpu.h"
+
+static unsigned int __cpuinit sis_size_cache(struct cpuinfo_x86 *c, unsigned int size)
+{
+	return 8;
+}
+
+static struct cpu_dev sis_cpu_dev __cpuinitdata = {
+	.c_vendor	= "SiS",
+	.c_ident 	= { "SiS SiS SiS " },
+	.c_models = {
+		{ .vendor = X86_VENDOR_SIS, .family = 5, .model_names =
+		  { 
+			  [0] = "SiS55x", 
+		  }
+		},
+	},
+	.c_size_cache	= sis_size_cache,
+	.c_x86_vendor	= X86_VENDOR_SIS,
+};
+
+cpu_dev_register(sis_cpu_dev);
diff -Naur a/include/asm-x86/processor.h b/include/asm-x86/processor.h
--- a/include/asm-x86/processor.h	2008-10-11 23:03:47.000000000 +0200
+++ b/include/asm-x86/processor.h	2008-10-03 23:53:00.000000000 +0200
@@ -119,7 +119,8 @@
  #define X86_VENDOR_CENTAUR	5
  #define X86_VENDOR_TRANSMETA	7
  #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_SIS		9
+#define X86_VENDOR_NUM		10

  #define X86_VENDOR_UNKNOWN	0xff