[patch 0/8] RFC: m68k patches for 2.6.28

[patch 0/8] RFC: m68k patches for 2.6.28

[Geert Uytterhoeven]

These are the m68k patches I have queued for 2.6.28 that haven't been posted
for review yet:
  [1] [PATCH] m68k: Use new printk() extension %pS to print symbols
  [2] [PATCH] m68k: Reverse platform MMU logic so Sun 3 is last
  [3] [PATCH] m68k: Disable Amiga serial console support if modular
  [4] [PATCH] m68k: Modular Amiga keyboard needs key_maps
  [5] [PATCH] m68k: Remove unused atari_kbd_translate()
  [6] [PATCH] m68k: Define rtc_lock on Atari
  [7] [PATCH] m68k: Add missing dma_sync_single_range_for_{cpu,device}()
  [8] [PATCH] m68k: <asm/pci.h> needs <asm-generic/pci-dma-compat.h>

My full patch queue is at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-m68k-patches-2.6/

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

[patch 1/8] m68k: Use new printk() extension %pS to print symbols

[Geert Uytterhoeven]

[-- Attachment #1: m68k-use-percent-pS-infrastructure.diff --]
[-- Type: text/plain, Size: 1514 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

This changes the oops and backtrace code to use the new `%pS' printk()
extension to print out symbols rather than manually calling print_symbol.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/kernel/traps.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -883,8 +883,7 @@ void show_trace(unsigned long *stack)
 			if (i % 5 == 0)
 				printk("\n       ");
 #endif
-			printk(" [<%08lx>]", addr);
-			print_symbol(" %s\n", addr);
+			printk(" [<%08lx>] %pS\n", addr, (void *)addr);
 			i++;
 		}
 	}
@@ -900,10 +899,8 @@ void show_registers(struct pt_regs *regs
 	int i;
 
 	print_modules();
-	printk("PC: [<%08lx>]",regs->pc);
-	print_symbol(" %s", regs->pc);
-	printk("\nSR: %04x  SP: %p  a2: %08lx\n",
-	       regs->sr, regs, regs->a2);
+	printk("PC: [<%08lx>] %pS\n", regs->pc, (void *)regs->pc);
+	printk("SR: %04x  SP: %p  a2: %08lx\n", regs->sr, regs, regs->a2);
 	printk("d0: %08lx    d1: %08lx    d2: %08lx    d3: %08lx\n",
 	       regs->d0, regs->d1, regs->d2, regs->d3);
 	printk("d4: %08lx    d5: %08lx    a0: %08lx    a1: %08lx\n",

-- 
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

[patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Geert Uytterhoeven]

[-- Attachment #1: m68k-reverse-platform-mmu-logic-so-sun3-is-last.diff --]
[-- Type: text/plain, Size: 4455 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

Currently Sun 3 support is the first platform option, as the Sun 3 MMU is
incompatible with standard Motorola MMUs. However, this means that
`allmodconfig' enables support for Sun 3, and thus disables support for all
other platforms.

Reverse the logic and move Sun 3 last, so `allmodconfig' enables all
platforms except for Sun 3, increasing compile-coverage.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/Kconfig |   43 ++++++++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 21 deletions(-)

--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -107,21 +107,9 @@ config PCMCIA
 	  To compile this driver as modules, choose M here: the
 	  modules will be called pcmcia_core and ds.
 
-config SUN3
-	bool "Sun3 support"
-	select M68020
-	select MMU_SUN3 if MMU
-	help
-	  This option enables support for the Sun 3 series of workstations
-	  (3/50, 3/60, 3/1xx, 3/2xx systems). Enabling this option requires
-	  that all other hardware types must be disabled, as Sun 3 kernels
-	  are incompatible with all other m68k targets (including Sun 3x!).
-
-	  If you don't want to compile a kernel exclusively for a Sun 3, say N.
-
 config AMIGA
 	bool "Amiga support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  This option enables support for the Amiga series of computers. If
 	  you plan to use this kernel on an Amiga, say Y here and browse the
@@ -129,7 +117,7 @@ config AMIGA
 
 config ATARI
 	bool "Atari support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  This option enables support for the 68000-based Atari series of
 	  computers (including the TT, Falcon and Medusa). If you plan to use
@@ -155,7 +143,7 @@ config PCI
 
 config MAC
 	bool "Macintosh support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  This option enables support for the Apple Macintosh series of
 	  computers (yes, there is experimental support now, at least for part
@@ -176,14 +164,14 @@ config M68K_L2_CACHE
 
 config APOLLO
 	bool "Apollo support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  Say Y here if you want to run Linux on an MC680x0-based Apollo
 	  Domain workstation such as the DN3500.
 
 config VME
 	bool "VME (Motorola and BVM) support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  Say Y here if you want to build a kernel for a 680x0 based VME
 	  board.  Boards currently supported include Motorola boards MVME147,
@@ -220,7 +208,7 @@ config BVME6000
 
 config HP300
 	bool "HP9000/300 and HP9000/400 support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  This option enables support for the HP9000/300 and HP9000/400 series
 	  of workstations. Support for these machines is still somewhat
@@ -239,7 +227,7 @@ config DIO
 
 config SUN3X
 	bool "Sun3x support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	select M68030
 	help
 	  This option enables support for the Sun 3x series of workstations.
@@ -252,7 +240,7 @@ config SUN3X
 
 config Q40
 	bool "Q40/Q60 support"
-	depends on !MMU_SUN3
+	select MMU_MOTOROLA if MMU
 	help
 	  The Q40 is a Motorola 68040-based successor to the Sinclair QL
 	  manufactured in Germany.  There is an official Q40 home page at
@@ -260,6 +248,19 @@ config Q40
 	  Q60. Select your CPU below.  For 68LC060 don't forget to enable FPU
 	  emulation.
 
+config SUN3
+	bool "Sun3 support"
+	depends on !MMU_MOTOROLA
+	select MMU_SUN3 if MMU
+	select M68020
+	help
+	  This option enables support for the Sun 3 series of workstations
+	  (3/50, 3/60, 3/1xx, 3/2xx systems). Enabling this option requires
+	  that all other hardware types must be disabled, as Sun 3 kernels
+	  are incompatible with all other m68k targets (including Sun 3x!).
+
+	  If you don't want to compile a kernel exclusively for a Sun 3, say N.
+
 comment "Processor type"
 
 config M68020
@@ -297,10 +298,10 @@ config M68060
 config MMU_MOTOROLA
 	bool
 	depends on MMU && !MMU_SUN3
-	default y
 
 config MMU_SUN3
 	bool
+	depends on MMU && !MMU_MOTOROLA
 
 config M68KFPU_EMU
 	bool "Math emulation support (EXPERIMENTAL)"

-- 
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 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Adrian Bunk]

On Wed, Sep 03, 2008 at 09:15:44AM +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> 
> Currently Sun 3 support is the first platform option, as the Sun 3 MMU is
> incompatible with standard Motorola MMUs. However, this means that
> `allmodconfig' enables support for Sun 3, and thus disables support for all
> other platforms.
>...

I hope it isn't too heretical to ask whether Sun 3 support actually has 
users and works?

Apollo support was broken for over 7 years without anyone noticing, and 
it might not be the only m68k platform that is long unused.

Do you have any overview of which m68k platforms still have users?

> Gr{oetje,eeting}s,
> 
> 						Geert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Laurent Vivier]

Le mercredi 03 septembre 2008 à 10:36 +0300, Adrian Bunk a écrit :
> On Wed, Sep 03, 2008 at 09:15:44AM +0200, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > 
> > Currently Sun 3 support is the first platform option, as the Sun 3 MMU is
> > incompatible with standard Motorola MMUs. However, this means that
> > `allmodconfig' enables support for Sun 3, and thus disables support for all
> > other platforms.
> >...
> 
> I hope it isn't too heretical to ask whether Sun 3 support actually has 
> users and works?
> 
> Apollo support was broken for over 7 years without anyone noticing, and 
> it might not be the only m68k platform that is long unused.
> 
> Do you have any overview of which m68k platforms still have users?

At least 4 users for amiga and 2 for mac :-P

#rank name                            inst  vote   old recent no-files
42014 linux-image-2.6-amiga              4     0     0     0     4
53844 linux-image-2.6-mac                2     0     0     0     2

from http://popcon.debian.org/by_inst

I'm a mac m68k user (who is the other one ???)

Laurent
-- 
----------------- Laurent.Vivier@bull.net  ------------------
  "La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Adrian Bunk]

On Wed, Sep 03, 2008 at 01:13:41PM +0200, Laurent Vivier wrote:
> Le mercredi 03 septembre 2008 à 10:36 +0300, Adrian Bunk a écrit :
> > On Wed, Sep 03, 2008 at 09:15:44AM +0200, Geert Uytterhoeven wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > 
> > > Currently Sun 3 support is the first platform option, as the Sun 3 MMU is
> > > incompatible with standard Motorola MMUs. However, this means that
> > > `allmodconfig' enables support for Sun 3, and thus disables support for all
> > > other platforms.
> > >...
> > 
> > I hope it isn't too heretical to ask whether Sun 3 support actually has 
> > users and works?
> > 
> > Apollo support was broken for over 7 years without anyone noticing, and 
> > it might not be the only m68k platform that is long unused.
> > 
> > Do you have any overview of which m68k platforms still have users?
> 
> At least 4 users for amiga and 2 for mac :-P
> 
> #rank name                            inst  vote   old recent no-files
> 42014 linux-image-2.6-amiga              4     0     0     0     4
> 53844 linux-image-2.6-mac                2     0     0     0     2
> 
> from http://popcon.debian.org/by_inst
> 
> I'm a mac m68k user (who is the other one ???)

Debian 3.1 (the last release to support m68k) supported
Amiga, Atari, Mac and VME.

These were also the most popular m68k platforms at about
10 years ago. [1]

But what about the rest?

As long as a platform has at one or more users it is worth keeping it,
but at least for Apollo it seems to be clear that noone ever used
kernel 2.4 or 2.6 on this platform.

> Laurent

cu
Adrian

[1] http://www.linux-m68k.org/Registry/Statistics.html

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Riccardo]

Hi,

On Wednesday, September 3, 2008, at 02:07  PM, Adrian Bunk wrote:

> As long as a platform has at one or more users it is worth keeping it,
> but at least for Apollo it seems to be clear that noone ever used
> kernel 2.4 or 2.6 on this platform.

well, I have mac and the bet kernel is still the 2.2 on my Q950.

I've been looking for an Apollo here in Italy, but they appear to be 
rare beasts.

Riccardo

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Brad Boyer]

On Wed, Sep 03, 2008 at 01:13:41PM +0200, Laurent Vivier wrote:
> Le mercredi 03 septembre 2008 à 10:36 +0300, Adrian Bunk a écrit :
> > Do you have any overview of which m68k platforms still have users?
> 
> At least 4 users for amiga and 2 for mac :-P
> 
> #rank name                            inst  vote   old recent no-files
> 42014 linux-image-2.6-amiga              4     0     0     0     4
> 53844 linux-image-2.6-mac                2     0     0     0     2
> 
> from http://popcon.debian.org/by_inst
> 
> I'm a mac m68k user (who is the other one ???)

I have only Macs, but I still haven't gotten any of them updated
properly to etch-m68k. My Mac IIfx has bad enough disk performance
with the current SCSI driver that I don't do anything more than
try out kernels with a simple root filesystem. My other older
systems are mostly packed away.

It seems like Mac, Amiga, and Atari are the only ones regularly
discussed on the mailing list.

	Brad Boyer
	flar@allandria.com

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Riccardo]

Hi;

>
> I have only Macs, but I still haven't gotten any of them updated
> properly to etch-m68k. My Mac IIfx has bad enough disk performance
> with the current SCSI driver that I don't do anything more than
> try out kernels with a simple root filesystem. My other older
> systems are mostly packed away.

Indeed, poor IIfx, mine is a dedicated linux box, meaning that the mac 
partition is only used to boot linux, still the about 50-60 K/s you get 
from the HD scare you away. Still I have hopes in the 2.6 kernels

Ric

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Lance Tagliapietra]

On Wed, Sep 03, 2008 at 01:13:41PM +0200, Laurent Vivier wrote:
> Le mercredi 03 septembre 2008 ?? 10:36 +0300, Adrian Bunk a ??crit :
> > On Wed, Sep 03, 2008 at 09:15:44AM +0200, Geert Uytterhoeven wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > 
> > > Currently Sun 3 support is the first platform option, as the Sun 3 MMU is
> > > incompatible with standard Motorola MMUs. However, this means that
> > > `allmodconfig' enables support for Sun 3, and thus disables support for all
> > > other platforms.
> > >...
> > 
> > I hope it isn't too heretical to ask whether Sun 3 support actually has 
> > users and works?
> > 
> > Apollo support was broken for over 7 years without anyone noticing, and 
> > it might not be the only m68k platform that is long unused.
> > 
> > Do you have any overview of which m68k platforms still have users?
> 
> At least 4 users for amiga and 2 for mac :-P
> 
> #rank name                            inst  vote   old recent no-files
> 42014 linux-image-2.6-amiga              4     0     0     0     4
> 53844 linux-image-2.6-mac                2     0     0     0     2
> 
> from http://popcon.debian.org/by_inst
> 
> I'm a mac m68k user (who is the other one ???)
> 
> Laurent
> -- 
> ----------------- Laurent.Vivier@bull.net  ------------------
>   "La perfection est atteinte non quand il ne reste rien ??
> ajouter mais quand il ne reste rien ?? enlever." Saint Exup??ry
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

OK OK, looks like I have to do the upgrade to 2.6 to get on this list
(currently running a self-compiled 2.4.30, with just the drivers I need
to have the smallest kernel footprint for the 16M RAM on my A2000) but I
do run popularity contest, so the common m68k packages that I use daily
should show up (mutt, apache, etc).  

Also, I have found that NFS works nicely between my A2000 and my PC
linux box, thought you typically don't want to burn the RAM on the 8
processes it is going to default to.  Apache, there are some ways to get
it to not use up all the RAM resources of the system too.  If anyone is
interested, I could put together a list of apps that I have configured
to make the Amiga still be a useful box?

--Lance

Re: [patch 2/8] m68k: Reverse platform MMU logic so Sun 3 is last

[Geert Uytterhoeven]

On Wed, 3 Sep 2008, Adrian Bunk wrote:
> On Wed, Sep 03, 2008 at 09:15:44AM +0200, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > 
> > Currently Sun 3 support is the first platform option, as the Sun 3 MMU is
> > incompatible with standard Motorola MMUs. However, this means that
> > `allmodconfig' enables support for Sun 3, and thus disables support for all
> > other platforms.
> >...
> 
> I hope it isn't too heretical to ask whether Sun 3 support actually has 
> users and works?

Sammy regularly (a few times per year) submits patches for Sun 3/3x, so
I assume it still works.

> Apollo support was broken for over 7 years without anyone noticing, and 
> it might not be the only m68k platform that is long unused.

Apollo had probably less than a handful of users ever.

> Do you have any overview of which m68k platforms still have users?

As already mentioned, Amiga, Atari (especially ARAnyM these days), and Mac
are the biggest m68k platforms in active use. Not all drivers receive the
same amount of regression testing, but especially the network and SCSI (the
ones we still have; people regularly complain about the removed NCR53C9x
drivers) drivers should be in good shape.

The VME boards have always been quite exotic, just like the HP9000/300 and /400
workstations.

Q40/Q60 probably lost their last few users, too.

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 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Geert Uytterhoeven]

	Hi Michael,

On Thu, 4 Sep 2008, Michael Schmitz wrote:
> as you've probably noticed, my previous EtherNAT patch does not compile
> without this one being applied as well.
> 
> Comments welcome (is there anyone on this list with access to an EtherNAT
> card,
> besides cts and myself?).
> 
> Regarding performance afforded by having a 100 Mbit PHY instead of a 10 Mbit
> one:
> 
> EtherNAT: 210 KB/s out, 140 KB/s in (scp of a 35 MB vmlinux file)
> EtherNEC: 175 KB/s out, 128 KB/s in (same file)
> 
> Hardly worth it, eh?

That's slower than my Ariadne?

BTW, do you have a patch for this?

| drivers/net/atari_91C111.c:2317: error: 'struct smc91x_platdata' has no member named 'irq_flags'
| drivers/net/atari_91C111.c:2361: error: 'struct smc91x_platdata' has no member named 'irq_flags'
| drivers/net/atari_91C111.c:2371: error: 'struct smc91x_platdata' has no member named 'irq_flags'
| drivers/net/atari_91C111.c:2411: error: 'struct smc91x_platdata' has no member named 'irq_flags'

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 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Michael Schmitz]

Hi Geert,

>> Regarding performance afforded by having a 100 Mbit PHY instead of a 10 Mbit
>> one:
>>
>> EtherNAT: 210 KB/s out, 140 KB/s in (scp of a 35 MB vmlinux file)
>> EtherNEC: 175 KB/s out, 128 KB/s in (same file)
>>
>> Hardly worth it, eh?
>
> That's slower than my Ariadne?

Still no interrupts.

> BTW, do you have a patch for this?
>
> | drivers/net/atari_91C111.c:2317: error: 'struct smc91x_platdata' has no member named 'irq_flags'
> | drivers/net/atari_91C111.c:2361: error: 'struct smc91x_platdata' has no member named 'irq_flags'
> | drivers/net/atari_91C111.c:2371: error: 'struct smc91x_platdata' has no member named 'irq_flags'
> | drivers/net/atari_91C111.c:2411: error: 'struct smc91x_platdata' has no member named 'irq_flags'

Not yet - I was working on that when I went into headless-chicken mode at work a 
few weeks back. I'll resync my kernel tree and restart.

There's been extensive changes to the parent driver that make me feel it's 
better to start from scratch anyway. I'll think about that (the need to set up 
the timer D and the interrupt wrapper thing is about the only thing I can 
imagine that would be problematic there).

Don't hold your breath just yet :')

 	Michael

Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Geert Uytterhoeven]

On Fri, 31 Oct 2008, Michael Schmitz wrote:
> > > > Looking at the SCSI driver in 2.6.26, it's no surprise - the error handling 
> > > > update that I did for 2.6.18 is not included in Geert's current 2.6 patch 
> > > > series. Looks like I botched the patch submission way back when. 
> > > 
> > > It's a pity. You put so much work in it but none of your patches
> > > (EtherNEC, EtherNAT or SCSI) got it into a current kernel.
> > > 
> > > Is there a reason why?
> > 
> > When Michael thinks they're ready, he can submit them to netdev or linux-scsi
> > ;-)
> 
> I'm happy for them to live in linux-m68k :-)
> 
> EtherNEC and EtherNAT are 'ready' in the sense they are working reliably. They 
> are by no means 'ready in the sense that mainline kernel maintainers would be 
> happy to take my patches. 

Or should we get them into linux-staging?

http://kerneltrap.org/Linux/Introducing_the_Linux_Staging_Tree

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 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Michael Schmitz]

Hi Geert,

> > > When Michael thinks they're ready, he can submit them to netdev or linux-scsi
> > > ;-)
> > 
> > I'm happy for them to live in linux-m68k :-)
> > 
> > EtherNEC and EtherNAT are 'ready' in the sense they are working reliably. They 
> > are by no means 'ready in the sense that mainline kernel maintainers would be 
> > happy to take my patches. 
> 
> Or should we get them into linux-staging?
> 
> http://kerneltrap.org/Linux/Introducing_the_Linux_Staging_Tree

That would be an option - I'd first like to rewrite EtherNEC to use a platform 
device for init, though. 

SCSI will be a different matter though. Not a new driver :-)

	Michael

[patch 3/8] m68k: Disable Amiga serial console support if modular

[Geert Uytterhoeven]

[-- Attachment #1: amiga-amiserial-no-serial-console-if-modular.diff --]
[-- Type: text/plain, Size: 1780 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

If CONFIG_AMIGA_BUILTIN_SERIAL=m, I get the following warnings:

| drivers/char/amiserial.c: At top level:
| drivers/char/amiserial.c:2138: warning: data definition has no type or storage class
| drivers/char/amiserial.c:2138: warning: type defaults to 'int' in declaration of 'console_initcall'
| drivers/char/amiserial.c:2138: warning: parameter names (without types) in function declaration
| drivers/char/amiserial.c:2134: warning: 'amiserial_console_init' defined but not used

Apparently console_initcall() is not defined in the modular case.

Disable serial console support if the driver is modular.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Any better alternative fix?

 drivers/char/amiserial.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/char/amiserial.c
+++ b/drivers/char/amiserial.c
@@ -2077,12 +2077,13 @@ module_init(rs_init)
 module_exit(rs_exit)
 
 
+#if defined(CONFIG_SERIAL_CONSOLE) && !defined(MODULE)
+
 /*
  * ------------------------------------------------------------
  * Serial console driver
  * ------------------------------------------------------------
  */
-#ifdef CONFIG_SERIAL_CONSOLE
 
 static void amiga_serial_putc(char c)
 {
@@ -2136,6 +2137,7 @@ static int __init amiserial_console_init
 	return 0;
 }
 console_initcall(amiserial_console_init);
-#endif
+
+#endif /* CONFIG_SERIAL_CONSOLE && !MODULE */
 
 MODULE_LICENSE("GPL");

-- 
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

[patch 4/8] m68k: Modular Amiga keyboard needs key_maps

[Geert Uytterhoeven]

[-- Attachment #1: amiga-export-key_maps.diff --]
[-- Type: text/plain, Size: 1198 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

| ERROR: "key_maps" [drivers/input/keyboard/amikbd.ko] undefined!

Export key_maps in the Amiga core code, as its defined in an autogenerated
file (drivers/char/defkeymap.c)

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/amiga/config.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -24,6 +24,7 @@
 #include <linux/interrupt.h>
 #include <linux/zorro.h>
 #include <linux/module.h>
+#include <linux/keyboard.h>
 
 #include <asm/bootinfo.h>
 #include <asm/setup.h>
@@ -984,3 +985,11 @@ static int amiga_get_hardware_list(char 
 
 	return len;
 }
+
+/*
+ * The Amiga keyboard driver needs key_maps, but we cannot export it in
+ * drivers/char/defkeymap.c, as it is autogenerated
+ */
+#ifdef CONFIG_HW_CONSOLE
+EXPORT_SYMBOL_GPL(key_maps);
+#endif

-- 
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

[patch 5/8] m68k: Remove unused atari_kbd_translate()

[Geert Uytterhoeven]

[-- Attachment #1: atari-kill-unused-atari_kbd_translate.diff --]
[-- Type: text/plain, Size: 1150 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

If CONFIG_VT=n, I get:

| arch/m68k/atari/built-in.o: In function `atari_kbd_translate':
| arch/m68k/atari/atakeyb.c:640: undefined reference to `shift_state'

Just remove atari_kbd_translate(), as it's unused.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/atari/atakeyb.c |   12 ------------
 1 file changed, 12 deletions(-)

--- a/arch/m68k/atari/atakeyb.c
+++ b/arch/m68k/atari/atakeyb.c
@@ -635,15 +635,3 @@ int atari_keyb_init(void)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(atari_keyb_init);
-
-int atari_kbd_translate(unsigned char keycode, unsigned char *keycodep, char raw_mode)
-{
-#ifdef CONFIG_MAGIC_SYSRQ
-	/* ALT+HELP pressed? */
-	if ((keycode == 98) && ((shift_state & 0xff) == 8))
-		*keycodep = 0xff;
-	else
-#endif
-		*keycodep = keycode;
-	return 1;
-}

-- 
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 5/8] m68k: Remove unused atari_kbd_translate()

[Michael Schmitz]

Hi Geert,

> From: Geert Uytterhoeven <geert@linux-m68k.org>
>
> If CONFIG_VT=n, I get:
>
> | arch/m68k/atari/built-in.o: In function `atari_kbd_translate':
> | arch/m68k/atari/atakeyb.c:640: undefined reference to `shift_state'
>
> Just remove atari_kbd_translate(), as it's unused.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks for cleaning this up! No need to ack these, is there?

 	Michael

Re: [patch 5/8] m68k: Remove unused atari_kbd_translate()

[Geert Uytterhoeven]

On Thu, 4 Sep 2008, Michael Schmitz wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > 
> > If CONFIG_VT=n, I get:
> > 
> > | arch/m68k/atari/built-in.o: In function `atari_kbd_translate':
> > | arch/m68k/atari/atakeyb.c:640: undefined reference to `shift_state'
> > 
> > Just remove atari_kbd_translate(), as it's unused.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> 
> Thanks for cleaning this up! No need to ack these, is there?

Please do.  If you ack it, I'll add it to the patch for final submission.

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 5/8] m68k: Remove unused atari_kbd_translate()

[Michael Schmitz]

Hi Geert,

acked as requested.

> If CONFIG_VT=n, I get:
>
> | arch/m68k/atari/built-in.o: In function `atari_kbd_translate':
> | arch/m68k/atari/atakeyb.c:640: undefined reference to `shift_state'
>
> Just remove atari_kbd_translate(), as it's unused.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Acked-by: Michael Schmity <schmitz@debian.org>

> ---
> arch/m68k/atari/atakeyb.c |   12 ------------
> 1 file changed, 12 deletions(-)
>
> --- a/arch/m68k/atari/atakeyb.c
> +++ b/arch/m68k/atari/atakeyb.c
> @@ -635,15 +635,3 @@ int atari_keyb_init(void)
> 	return 0;
> }
> EXPORT_SYMBOL_GPL(atari_keyb_init);
> -
> -int atari_kbd_translate(unsigned char keycode, unsigned char *keycodep, char raw_mode)
> -{
> -#ifdef CONFIG_MAGIC_SYSRQ
> -	/* ALT+HELP pressed? */
> -	if ((keycode == 98) && ((shift_state & 0xff) == 8))
> -		*keycodep = 0xff;
> -	else
> -#endif
> -		*keycodep = keycode;
> -	return 1;
> -}
>
> --
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[patch 6/8] m68k: Define rtc_lock on Atari

[Geert Uytterhoeven]

[-- Attachment #1: atari-define-rtc_lock.diff --]
[-- Type: text/plain, Size: 1156 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

The nvram and rtc-cmos drivers use the spinlock rtc_lock to protect against
concurrent accesses to the CMOS memory. As m68k doesn't support SMP or preempt
yet, the spinlock calls tend to get optimized away, but not for all
configurations, causing in some rare cases:

| ERROR: "rtc_lock" [drivers/rtc/rtc-cmos.ko] undefined!
| ERROR: "rtc_lock" [drivers/char/nvram.ko] undefined!

Add the spinlock to the Atari core code to avoid this.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 arch/m68k/atari/time.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -20,6 +20,9 @@
 
 #include <asm/atariints.h>
 
+DEFINE_SPINLOCK(rtc_lock);
+EXPORT_SYMBOL_GPL(rtc_lock);
+
 void __init
 atari_sched_init(irq_handler_t timer_routine)
 {

-- 
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 6/8] m68k: Define rtc_lock on Atari

[Michael Schmitz]

Hi Geert,

Acked as well ...

> The nvram and rtc-cmos drivers use the spinlock rtc_lock to protect against
> concurrent accesses to the CMOS memory. As m68k doesn't support SMP or preempt
> yet, the spinlock calls tend to get optimized away, but not for all
> configurations, causing in some rare cases:
>
> | ERROR: "rtc_lock" [drivers/rtc/rtc-cmos.ko] undefined!
> | ERROR: "rtc_lock" [drivers/char/nvram.ko] undefined!
>
> Add the spinlock to the Atari core code to avoid this.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Acked-by: Michael Schmitz <schmitz@debian.org>

> ---
> arch/m68k/atari/time.c |    3 +++
> 1 file changed, 3 insertions(+)
>
> --- a/arch/m68k/atari/time.c
> +++ b/arch/m68k/atari/time.c
> @@ -20,6 +20,9 @@
>
> #include <asm/atariints.h>
>
> +DEFINE_SPINLOCK(rtc_lock);
> +EXPORT_SYMBOL_GPL(rtc_lock);
> +
> void __init
> atari_sched_init(irq_handler_t timer_routine)
> {
>
> --
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[patch 7/8] m68k: Add missing dma_sync_single_range_for_{cpu,device}()

[Geert Uytterhoeven]

[-- Attachment #1: m68k-add-dma_sync_single_range_for_cpu-device.diff --]
[-- Type: text/plain, Size: 2655 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

| include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_range_for_cpu':
| include/linux/ssb/ssb.h:517: error: implicit declaration of function 'dma_sync_single_range_for_cpu'
| include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_range_for_device':
| include/linux/ssb/ssb.h:538: error: implicit declaration of function 'dma_sync_single_range_for_device'

Add the missing dma_sync_single_range_for_{cpu,device}(), and remove the bogus
`inline' for the non-static function dma_sync_single_for_device().

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

---
 arch/m68k/kernel/dma.c         |    4 ++--
 include/asm-m68k/dma-mapping.h |   16 ++++++++++++++++
 2 files changed, 18 insertions(+), 2 deletions(-)

--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -66,8 +66,8 @@ void dma_free_coherent(struct device *de
 }
 EXPORT_SYMBOL(dma_free_coherent);
 
-inline void dma_sync_single_for_device(struct device *dev, dma_addr_t handle, size_t size,
-				       enum dma_data_direction dir)
+void dma_sync_single_for_device(struct device *dev, dma_addr_t handle,
+				size_t size, enum dma_data_direction dir)
 {
 	switch (dir) {
 	case DMA_TO_DEVICE:
--- a/include/asm-m68k/dma-mapping.h
+++ b/include/asm-m68k/dma-mapping.h
@@ -74,6 +74,14 @@ extern void dma_sync_single_for_device(s
 extern void dma_sync_sg_for_device(struct device *, struct scatterlist *, int,
 				   enum dma_data_direction);
 
+static inline void dma_sync_single_range_for_device(struct device *dev,
+		dma_addr_t dma_handle, unsigned long offset, size_t size,
+		enum dma_data_direction direction)
+{
+	/* just sync everything for now */
+	dma_sync_single_for_device(dev, dma_handle, offset + size, direction);
+}
+
 static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t handle,
 					   size_t size, enum dma_data_direction dir)
 {
@@ -84,6 +92,14 @@ static inline void dma_sync_sg_for_cpu(s
 {
 }
 
+static inline void dma_sync_single_range_for_cpu(struct device *dev,
+		dma_addr_t dma_handle, unsigned long offset, size_t size,
+		enum dma_data_direction direction)
+{
+	/* just sync everything for now */
+	dma_sync_single_for_cpu(dev, dma_handle, offset + size, direction);
+}
+
 static inline int dma_mapping_error(struct device *dev, dma_addr_t handle)
 {
 	return 0;

-- 
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 7/8] m68k: Add missing dma_sync_single_range_for_{cpu,device}()

[Roman Zippel]

Hi,

On Wed, 3 Sep 2008, Geert Uytterhoeven wrote:

> Add the missing dma_sync_single_range_for_{cpu,device}(), and remove the bogus
> `inline' for the non-static function dma_sync_single_for_device().

It's not bogus, it's a hint to gcc to inline the function into the callers 
in the same file, but also to provide an external version.

bye, Roman

Re: [patch 7/8] m68k: Add missing dma_sync_single_range_for_{cpu, device}()

[Geert Uytterhoeven]

On Wed, 3 Sep 2008, Roman Zippel wrote:
> On Wed, 3 Sep 2008, Geert Uytterhoeven wrote:
> 
> > Add the missing dma_sync_single_range_for_{cpu,device}(), and remove the bogus
> > `inline' for the non-static function dma_sync_single_for_device().
> 
> It's not bogus, it's a hint to gcc to inline the function into the callers 
> in the same file, but also to provide an external version.

IIRC, gcc actually complained about it. I'll check again...

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 7/8] m68k: Add missing dma_sync_single_range_for_{cpu, device}()

[Geert Uytterhoeven]

On Wed, 3 Sep 2008, Geert Uytterhoeven wrote:
> On Wed, 3 Sep 2008, Roman Zippel wrote:
> > On Wed, 3 Sep 2008, Geert Uytterhoeven wrote:
> > 
> > > Add the missing dma_sync_single_range_for_{cpu,device}(), and remove the bogus
> > > `inline' for the non-static function dma_sync_single_for_device().
> > 
> > It's not bogus, it's a hint to gcc to inline the function into the callers 
> > in the same file, but also to provide an external version.
> 
> IIRC, gcc actually complained about it. I'll check again...

| arch/m68k/include/asm/dma-mapping.h:73: warning: 'dma_sync_single_for_device' declared inline after being called
| arch/m68k/include/asm/dma-mapping.h:73: warning: previous declaration of 'dma_sync_single_for_device' was here

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 7/8] m68k: Add missing dma_sync_single_range_for_{cpu, device}()

[Roman Zippel]

Hi,

On Wed, 3 Sep 2008, Geert Uytterhoeven wrote:

> > IIRC, gcc actually complained about it. I'll check again...
> 
> | arch/m68k/include/asm/dma-mapping.h:73: warning: 'dma_sync_single_for_device' declared inline after being called
> | arch/m68k/include/asm/dma-mapping.h:73: warning: previous declaration of 'dma_sync_single_for_device' was here

In the same patch you've also added that user, simply don't inline that 
function. :)

bye, Roman

Re: [patch 7/8] m68k: Add missing dma_sync_single_range_for_{cpu,device}()

[Adrian Bunk]

On Wed, Sep 03, 2008 at 12:59:04PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Wed, 3 Sep 2008, Geert Uytterhoeven wrote:
> 
> > Add the missing dma_sync_single_range_for_{cpu,device}(), and remove the bogus
> > `inline' for the non-static function dma_sync_single_for_device().
> 
> It's not bogus, it's a hint to gcc to inline the function into the callers 
> in the same file, but also to provide an external version.

"hint" = "we force gcc"

either we want it inlined into all callers or we want one external copy.
Doing both is suboptimal.

> bye, Roman

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch 7/8] m68k: Add missing dma_sync_single_range_for_{cpu,device}()

[Roman Zippel]

Hi,

On Wed, 3 Sep 2008, Adrian Bunk wrote:

> either we want it inlined into all callers or we want one external copy.
> Doing both is suboptimal.

Not so much in this case, usually only a subset of these functions is 
used, so the actual worker functions have the expanded version, but they
aren't inlined themselves.
You could create a separate "static inline" function and use that there, 
but the result should be the same.

bye, Roman

[patch 8/8] m68k: <asm/pci.h> needs <asm-generic/pci-dma-compat.h>

[Geert Uytterhoeven]

[-- Attachment #1: m68k-asm-pci-h-needs-asm-generic-pci-dma-compat.h.diff --]
[-- Type: text/plain, Size: 2797 bytes --]

From: Geert Uytterhoeven <geert@linux-m68k.org>

Several multi-bus subsystems:

| include/linux/ssb/ssb.h: In function 'ssb_dma_mapping_error':
| include/linux/ssb/ssb.h:430: error: implicit declaration of function 'pci_dma_mapping_error'
| include/linux/ssb/ssb.h: In function 'ssb_dma_map_single':
| include/linux/ssb/ssb.h:444: error: implicit declaration of function 'pci_map_single'
| include/linux/ssb/ssb.h: In function 'ssb_dma_unmap_single':
| include/linux/ssb/ssb.h:458: error: implicit declaration of function 'pci_unmap_single'
| include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_for_cpu':
| include/linux/ssb/ssb.h:475: error: implicit declaration of function 'pci_dma_sync_single_for_cpu'
| include/linux/ssb/ssb.h: In function 'ssb_dma_sync_single_for_device':
| include/linux/ssb/ssb.h:493: error: implicit declaration of function 'pci_dma_sync_single_for_device'

or legacy drivers:

| drivers/net/hp100.c: In function 'pdl_map_data':
| drivers/net/hp100.c:291: error: implicit declaration of function 'pci_map_single'
| drivers/net/hp100.c: In function 'hp100_probe1':
| drivers/net/hp100.c:707: error: implicit declaration of function 'pci_alloc_consistent'
| drivers/net/hp100.c:782: error: implicit declaration of function 'pci_free_consistent'
| drivers/net/hp100.c: In function 'hp100_clean_txring':
| drivers/net/hp100.c:1614: error: implicit declaration of function 'pci_unmap_single'

and

| drivers/scsi/aic7xxx_old.c: In function 'aic7xxx_allocate_scb':
| drivers/scsi/aic7xxx_old.c:2573: error: implicit declaration of function 'pci_alloc_consistent'
| drivers/scsi/aic7xxx_old.c: In function 'aic7xxx_done':
| drivers/scsi/aic7xxx_old.c:2697: error: implicit declaration of function 'pci_unmap_single'
| drivers/scsi/aic7xxx_old.c: In function 'aic7xxx_handle_seqint':
| drivers/scsi/aic7xxx_old.c:4275: error: implicit declaration of function 'pci_map_single'
| drivers/scsi/aic7xxx_old.c: In function 'aic7xxx_free':
| drivers/scsi/aic7xxx_old.c:8460: error: implicit declaration of function 'pci_free_consistent'

rely on PCI DMA operations to be always available.

Add #include <asm-generic/pci-dma-compat.h> to <asm/pci.h> to make them happy.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 include/asm-m68k/pci.h |    1 +
 1 file changed, 1 insertion(+)

--- a/include/asm-m68k/pci.h
+++ b/include/asm-m68k/pci.h
@@ -8,6 +8,7 @@
  */
 
 #include <asm/scatterlist.h>
+#include <asm-generic/pci-dma-compat.h>
 
 struct pci_ops;
 

-- 
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