* [RFC] setup.c: get ride of CPHYSADDR()
@ 2006-10-03 14:44 Franck Bui-Huu
2006-10-03 15:16 ` Maciej W. Rozycki
0 siblings, 1 reply; 3+ messages in thread
From: Franck Bui-Huu @ 2006-10-03 14:44 UTC (permalink / raw)
To: linux-mips
Hi,
The following patch is an attempt to remove this macro in setup.c.
I'm not sure about why sometimes it is used and sometimes it is
not. By sending this RFC, I hope to get some feedbacks that will shed
some light on this obscure macro...
The reason why I'm trying to kick out this macro is that we should
rely on __pa() for address convertions instead of having several
helpers that do the same thing but differently. Futermore if some
tricks are needed for these conversions, they should be done in
one place.
Thanks
Franck
-- >8 --
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index fdbb508..00d62bd 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -204,12 +204,12 @@ static void __init finalize_initrd(void)
printk(KERN_INFO "Initrd not found or empty");
goto disable;
}
- if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) {
+ if (__pa(initrd_end) > PFN_PHYS(max_low_pfn)) {
printk("Initrd extends beyond end of memory");
goto disable;
}
- reserve_bootmem(CPHYSADDR(initrd_start), size);
+ reserve_bootmem(__pa(initrd_start), size);
initrd_below_start_ok = 1;
printk(KERN_INFO "Initial ramdisk at: 0x%lx (%lu bytes)\n",
@@ -256,7 +256,7 @@ static void __init bootmem_init(void)
* of usable memory.
*/
reserved_end = init_initrd();
- reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned long)&_end)));
+ reserved_end = PFN_UP(__pa(max(reserved_end, (unsigned long)&_end)));
/*
* Find the highest page frame number we have available.
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [RFC] setup.c: get ride of CPHYSADDR()
2006-10-03 14:44 [RFC] setup.c: get ride of CPHYSADDR() Franck Bui-Huu
@ 2006-10-03 15:16 ` Maciej W. Rozycki
2006-10-03 15:34 ` Franck Bui-Huu
0 siblings, 1 reply; 3+ messages in thread
From: Maciej W. Rozycki @ 2006-10-03 15:16 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: linux-mips
Franck,
> The following patch is an attempt to remove this macro in setup.c.
> I'm not sure about why sometimes it is used and sometimes it is
> not. By sending this RFC, I hope to get some feedbacks that will shed
> some light on this obscure macro...
>
> The reason why I'm trying to kick out this macro is that we should
> rely on __pa() for address convertions instead of having several
> helpers that do the same thing but differently. Futermore if some
> tricks are needed for these conversions, they should be done in
> one place.
Have you verified it works correctly for 64-bit kernels linked at a KSEG0
address?
Maciej
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] setup.c: get ride of CPHYSADDR()
2006-10-03 15:16 ` Maciej W. Rozycki
@ 2006-10-03 15:34 ` Franck Bui-Huu
0 siblings, 0 replies; 3+ messages in thread
From: Franck Bui-Huu @ 2006-10-03 15:34 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Franck Bui-Huu, linux-mips
Maciej W. Rozycki wrote:
> Franck,
>>
>> The reason why I'm trying to kick out this macro is that we should
>> rely on __pa() for address convertions instead of having several
>> helpers that do the same thing but differently. Futermore if some
>> tricks are needed for these conversions, they should be done in
>> one place.
>
> Have you verified it works correctly for 64-bit kernels linked at a KSEG0
> address?
>
Of course not ;). More seriously, I'm working on a 32 bits kernel. I'm
not familiar with MIPS 64 bits world and all tricks needed to compile
them, and that's the reason why I make this thread an RFC one.
I was suspecting something related to 64 bits kernels. Do you mean
that this macro exists because of a linker issue ?
Futhermore I noticed that some part of the code in setup.c do no rely
on this macro for address convertions. See for example in
resource_init():
code_resource.start = virt_to_phys(&_text);
code_resource.end = virt_to_phys(&_etext) - 1;
data_resource.start = virt_to_phys(&_etext);
data_resource.end = virt_to_phys(&_edata) - 1;
Why in that case we compute address converstion differently ?
Thanks
Franck
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-10-03 15:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-03 14:44 [RFC] setup.c: get ride of CPHYSADDR() Franck Bui-Huu
2006-10-03 15:16 ` Maciej W. Rozycki
2006-10-03 15:34 ` Franck Bui-Huu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox