[PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[KOSAKI Motohiro]

I guess nobody don't test m68knommu at all last three month.
Do we still need to maintain this architecture?


==
Currently, m68knommu defconfig can't build. it cause following error.

net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_mapping_error'
net/built-in.o: In function `skb_dma_unmap':
: undefined reference to `dma_unmap_single'
net/built-in.o: In function `skb_dma_unmap':
: undefined reference to `dma_unmap_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_map_single'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_map_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_unmap_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_unmap_single'

because
 - CONFIG_DMA depend on !NO_DMA
 - m68knommu always doesn't turn on NO_DMA
 - if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
    asm-generic/dma-mapping-broken.h
 - dma-mapping-broken.h generate link time error.
 - m68knommu defconfig doesn't have CONFIG_PCI
 - On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
   dma related function is callable

So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.


CC: David S. Miller <davem@davemloft.net>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Roman Zippel <zippel@linux-m68k.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: linux-m68k@lists.linux-m68k.org
---
 arch/m68knommu/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

Index: b/arch/m68knommu/Kconfig
===================================================================
--- a/arch/m68knommu/Kconfig	2008-12-25 08:26:37.000000000 +0900
+++ b/arch/m68knommu/Kconfig	2008-12-28 21:09:58.000000000 +0900
@@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
 config NO_IOPORT
 	def_bool y
 
+config NO_DMA
+	def_bool !PCI
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[Greg Ungerer]

Hi Kosako,

KOSAKI Motohiro wrote:
> I guess nobody don't test m68knommu at all last three month.
> Do we still need to maintain this architecture?

Yes, we do.

Regards
Greg



> ==
> Currently, m68knommu defconfig can't build. it cause following error.
> 
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_mapping_error'
> net/built-in.o: In function `skb_dma_unmap':
> : undefined reference to `dma_unmap_single'
> net/built-in.o: In function `skb_dma_unmap':
> : undefined reference to `dma_unmap_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_map_single'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_map_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_unmap_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_unmap_single'
> 
> because
>  - CONFIG_DMA depend on !NO_DMA
>  - m68knommu always doesn't turn on NO_DMA
>  - if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
>     asm-generic/dma-mapping-broken.h
>  - dma-mapping-broken.h generate link time error.
>  - m68knommu defconfig doesn't have CONFIG_PCI
>  - On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
>    dma related function is callable
> 
> So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.
> 
> 
> CC: David S. Miller <davem@davemloft.net>
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> CC: Roman Zippel <zippel@linux-m68k.org>
> CC: Greg Ungerer <gerg@uclinux.org>
> CC: linux-m68k@lists.linux-m68k.org
> ---
>  arch/m68knommu/Kconfig |    3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: b/arch/m68knommu/Kconfig
> ===================================================================
> --- a/arch/m68knommu/Kconfig	2008-12-25 08:26:37.000000000 +0900
> +++ b/arch/m68knommu/Kconfig	2008-12-28 21:09:58.000000000 +0900
> @@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
>  config NO_IOPORT
>  	def_bool y
>  
> +config NO_DMA
> +	def_bool !PCI
> +
>  source "init/Kconfig"
>  
>  source "kernel/Kconfig.freezer"
> 
> 
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[KOSAKI Motohiro]

> Hi Kosako,
>
> KOSAKI Motohiro wrote:
>>
>> I guess nobody don't test m68knommu at all last three month.
>> Do we still need to maintain this architecture?
>
> Yes, we do.

ok. I don't have objection.
thank you.

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[Paul Mundt]

On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> Hi Kosako,
> 
> KOSAKI Motohiro wrote:
> >I guess nobody don't test m68knommu at all last three month.
> >Do we still need to maintain this architecture?
> 
> Yes, we do.
> 
Any effort to get m68knommu folded in to m68k proper? This might help
with some of your bitrot issues.. And likely less work to do in
supporting those m68knommu parts that ship with MMUs ;-)

m68knommu is the only one of the mmu/nommu variants left that ships in
its own architecture directory rather than being folded in to its parent.
It would be good to get rid of it one of these days.

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[Sam Ravnborg]

On Mon, Jan 12, 2009 at 07:44:47PM +0900, Paul Mundt wrote:
> On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> > Hi Kosako,
> > 
> > KOSAKI Motohiro wrote:
> > >I guess nobody don't test m68knommu at all last three month.
> > >Do we still need to maintain this architecture?
> > 
> > Yes, we do.
> > 
> Any effort to get m68knommu folded in to m68k proper? This might help
> with some of your bitrot issues.. And likely less work to do in
> supporting those m68knommu parts that ship with MMUs ;-)
> 
> m68knommu is the only one of the mmu/nommu variants left that ships in
> its own architecture directory rather than being folded in to its parent.
> It would be good to get rid of it one of these days.

>From the outside it looks like there are indeed a whish to do so
but both m68k and m68knommu maintainers seems to be busy with other stuff.

Not that I can think of what is more important than to merge the two
architectures ;-)

If I get some spare time one day I have actually planned to try to
help a little - but that would require an active maintainer..

We just did the exercise with sparc/sparc64 unification and
if you forget the few times I broke sparc32 then it went well
with only limited problems.

One key factor why it went well was that patches were reviewed
and applied within a few days whch is why I stresses that the
maintainer needs spare time to support the effort.

	Sam

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> We just did the exercise with sparc/sparc64 unification and if you 
> forget the few times I broke sparc32 then it went well with only limited 
> problems.

We also had the x86 unification finished in the past year which went very 
well too, so i can only encourage similar efforts.

> One key factor why it went well was that patches were reviewed and 
> applied within a few days whch is why I stresses that the maintainer 
> needs spare time to support the effort.

Yes.

Unification is the Linux meme of the century i guess ;-)

There's two main unification themes:

 - per arch unification (x86, powerpc, sparc

 - cross-arch unification: the moving of useful stuff out of architectures 
   into the core kernel (genirq, gtod, etc.).

	Ingo

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[Paul Mundt]

On Mon, Jan 12, 2009 at 11:59:42AM +0100, Sam Ravnborg wrote:
> On Mon, Jan 12, 2009 at 07:44:47PM +0900, Paul Mundt wrote:
> > On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> > > Hi Kosako,
> > > 
> > > KOSAKI Motohiro wrote:
> > > >I guess nobody don't test m68knommu at all last three month.
> > > >Do we still need to maintain this architecture?
> > > 
> > > Yes, we do.
> > > 
> > Any effort to get m68knommu folded in to m68k proper? This might help
> > with some of your bitrot issues.. And likely less work to do in
> > supporting those m68knommu parts that ship with MMUs ;-)
> > 
> > m68knommu is the only one of the mmu/nommu variants left that ships in
> > its own architecture directory rather than being folded in to its parent.
> > It would be good to get rid of it one of these days.
> 
> From the outside it looks like there are indeed a whish to do so
> but both m68k and m68knommu maintainers seems to be busy with other stuff.
> 
> Not that I can think of what is more important than to merge the two
> architectures ;-)
> 
> If I get some spare time one day I have actually planned to try to
> help a little - but that would require an active maintainer..
> 
> We just did the exercise with sparc/sparc64 unification and
> if you forget the few times I broke sparc32 then it went well
> with only limited problems.
> 
> One key factor why it went well was that patches were reviewed
> and applied within a few days whch is why I stresses that the
> maintainer needs spare time to support the effort.
> 
I have some experience with developing a nommu port within an mmu-only
one. If you start some of the legwork on this I can try to chip in some
spare cycles, though ultimately some m68k person will still have to regain
consciousness at some point :-)

Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

[Greg Ungerer]

Paul Mundt wrote:
> On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
>> Hi Kosako,
>>
>> KOSAKI Motohiro wrote:
>>> I guess nobody don't test m68knommu at all last three month.
>>> Do we still need to maintain this architecture?
>> Yes, we do.
>>
> Any effort to get m68knommu folded in to m68k proper? This might help

Some :-)
The header merge is the first step.


> with some of your bitrot issues.. And likely less work to do in
> supporting those m68knommu parts that ship with MMUs ;-)
> 
> m68knommu is the only one of the mmu/nommu variants left that ships in
> its own architecture directory rather than being folded in to its parent.
> It would be good to get rid of it one of these days.

Yep. I think we will likely make some progress on this over
the next few months...



-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com