[uClinux-dev] [PATCH 3/4] m68knommu: Make empty_zero_page "void *", like on m68k
This allows to get rid of the casts.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/mm/init_no.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/mm/init_no.c b/arch/m68k/mm/init_no.c
index 7cbd7bd..fdbe679 100644
--- a/arch/m68k/mm/init_no.c
+++ b/arch/m68k/mm/init_no.c
@@ -42,7 +42,7 @@
* ZERO_PAGE is a special page that is used for zero-initialized
* data and COW.
*/
-unsigned long empty_zero_page;
+void *empty_zero_page;
extern unsigned long memory_start;
extern unsigned long memory_end;
@@ -62,8 +62,8 @@ void __init paging_init(void)
unsigned long end_mem = memory_end & PAGE_MASK;
unsigned long zones_size[MAX_NR_ZONES] = {0, };
- empty_zero_page = (unsigned long)alloc_bootmem_pages(PAGE_SIZE);
- memset((void *)empty_zero_page, 0, PAGE_SIZE);
+ empty_zero_page = alloc_bootmem_pages(PAGE_SIZE);
+ memset(empty_zero_page, 0, PAGE_SIZE);
/*
* Set up SFC/DFC registers (user data space).
--
1.7.0.4
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH 4/4] m68knommu: Fix printk() format in free_initrd_mem()
arch/m68k/mm/init_no.c:123: warning: format ‘%d’ expects type ‘int’, but
argument 2 has type ‘long unsigned int’
And use pr_notice() while we're at it.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/mm/init_no.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/mm/init_no.c b/arch/m68k/mm/init_no.c
index fdbe679..50cd12c 100644
--- a/arch/m68k/mm/init_no.c
+++ b/arch/m68k/mm/init_no.c
@@ -120,7 +120,8 @@ void free_initrd_mem(unsigned long start, unsigned long end)
totalram_pages++;
pages++;
}
- printk (KERN_NOTICE "Freeing initrd memory: %dk freed\n", pages *
(PAGE_SIZE / 1024));
+ pr_notice("Freeing initrd memory: %luk freed\n",
+ pages * (PAGE_SIZE / 1024));
}
#endif
@@ -141,7 +142,7 @@ void free_initmem(void)
free_page(addr);
totalram_pages++;
}
- printk(KERN_NOTICE "Freeing unused kernel memory: %ldk freed (0x%x -
0x%x)\n",
+ pr_notice("Freeing unused kernel memory: %luk freed (0x%x - 0x%x)\n",
(addr - PAGE_ALIGN((long) &__init_begin)) >> 10,
(int)(PAGE_ALIGN((unsigned long)(&__init_begin))),
(int)(addr - PAGE_SIZE));
--
1.7.0.4
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 3/4] m68knommu: Make empty_zero_page "void *", like on m68k
Hi Geert,
On 25/05/11 19:10, Geert Uytterhoeven wrote:
This allows to get rid of the casts.
Signed-off-by: Geert Uytterhoeven
Looks good:
Acked-by: Greg Ungerer
Do you want me to add to the m68knommu git tree?
Or are these part of a series you intend pushing yourself?
Regards
Greg
---
arch/m68k/mm/init_no.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/mm/init_no.c b/arch/m68k/mm/init_no.c
index 7cbd7bd..fdbe679 100644
--- a/arch/m68k/mm/init_no.c
+++ b/arch/m68k/mm/init_no.c
@@ -42,7 +42,7 @@
* ZERO_PAGE is a special page that is used for zero-initialized
* data and COW.
*/
-unsigned long empty_zero_page;
+void *empty_zero_page;
extern unsigned long memory_start;
extern unsigned long memory_end;
@@ -62,8 +62,8 @@ void __init paging_init(void)
unsigned long end_mem = memory_end& PAGE_MASK;
unsigned long zones_size[MAX_NR_ZONES] = {0, };
- empty_zero_page = (unsigned long)alloc_bootmem_pages(PAGE_SIZE);
- memset((void *)empty_zero_page, 0, PAGE_SIZE);
+ empty_zero_page = alloc_bootmem_pages(PAGE_SIZE);
+ memset(empty_zero_page, 0, PAGE_SIZE);
/*
* Set up SFC/DFC registers (user data space).
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 4/4] m68knommu: Fix printk() format in free_initrd_mem()
Hi Geert,
On 25/05/11 19:11, Geert Uytterhoeven wrote:
arch/m68k/mm/init_no.c:123: warning: format æ%dÆ expects type æintÆ, but
argument 2 has type ælong unsigned intÆ
And use pr_notice() while we're at it.
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/mm/init_no.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/mm/init_no.c b/arch/m68k/mm/init_no.c
index fdbe679..50cd12c 100644
--- a/arch/m68k/mm/init_no.c
+++ b/arch/m68k/mm/init_no.c
@@ -120,7 +120,8 @@ void free_initrd_mem(unsigned long start, unsigned long end)
totalram_pages++;
pages++;
}
- printk (KERN_NOTICE "Freeing initrd memory: %dk freed\n", pages *
(PAGE_SIZE / 1024));
+ pr_notice("Freeing initrd memory: %luk freed\n",
+ pages * (PAGE_SIZE / 1024));
}
#endif
@@ -141,7 +142,7 @@ void free_initmem(void)
free_page(addr);
totalram_pages++;
}
- printk(KERN_NOTICE "Freeing unused kernel memory: %ldk freed (0x%x -
0x%x)\n",
+ pr_notice("Freeing unused kernel memory: %luk freed (0x%x - 0x%x)\n",
(addr - PAGE_ALIGN((long)&__init_begin))>> 10,
(int)(PAGE_ALIGN((unsigned long)(&__init_begin))),
(int)(addr - PAGE_SIZE));
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 3/4] m68knommu: Make empty_zero_page "void *", like on m68k
Hi Greg,
On Thu, May 26, 2011 at 06:39, Greg Ungerer wrote:
> On 25/05/11 19:10, Geert Uytterhoeven wrote:
>> This allows to get rid of the casts.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> Looks good:
>
> Acked-by: Greg Ungerer
>
> Do you want me to add to the m68knommu git tree?
> Or are these part of a series you intend pushing yourself?
Please add it to your tree.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 3/4] m68knommu: Make empty_zero_page "void *", like on m68k
Hi Geert, On 26/05/11 15:11, Geert Uytterhoeven wrote: Hi Greg, On Thu, May 26, 2011 at 06:39, Greg Ungerer wrote: On 25/05/11 19:10, Geert Uytterhoeven wrote: This allows to get rid of the casts. Signed-off-by: Geert Uytterhoeven Looks good: Acked-by: Greg Ungerer Do you want me to add to the m68knommu git tree? Or are these part of a series you intend pushing yourself? Please add it to your tree. Done! Thanks Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Hi Andreas, Geert, On 24/05/11 18:06, Andreas Schwab wrote: Geert Uytterhoeven writes: What exactly do you mean by "does not support anything less"? It seems it does restrict instruction generation to 68000 if you ask for it. The point is that Linux/m68k requires 68020+, so compiling for 68000 does not make sense (at least back when the gcc configuration was created). Yeah, used to be true :-) This seems very much to me to be a "broken compiler" issue. Is it worth putting some form of compiler version limits to protect compilation in the m68000 case? (Probably no need to limit it for the existing 68020+ case). Are there any other gcc defines that we could use instead? We need to check with your old compiler Geert :-) I really don't want to use CONFIG_MMU here (or in bitops.h either). When I work in the ColdFire MMU code this won't be right. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, May 26, 2011 at 08:23, Greg Ungerer wrote:
> On 24/05/11 18:06, Andreas Schwab wrote:
>> Geert Uytterhoeven writes:
>>
>>> What exactly do you mean by "does not support anything less"? It seems it
>>> does
>>> restrict instruction generation to 68000 if you ask for it.
>>
>> The point is that Linux/m68k requires 68020+, so compiling for 68000
>> does not make sense (at least back when the gcc configuration was
>> created).
>
> Yeah, used to be true :-)
> This seems very much to me to be a "broken compiler" issue.
>
> Is it worth putting some form of compiler version limits to protect
> compilation in the m68000 case? (Probably no need to limit it for
> the existing 68020+ case).
>
> Are there any other gcc defines that we could use instead?
> We need to check with your old compiler Geert :-)
>
> I really don't want to use CONFIG_MMU here (or in bitops.h either).
> When I work in the ColdFire MMU code this won't be right.
I was more thinking along the lines of !CONFIG_M68000 && !CONFIG_M68010
&& !CONFIG_.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
