These three patches get rid of a few more warnings for me.
abuild tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
PS. It looks like part of the reason we have so many warnings is the misuse of #define __ROMCC__ to mean "early code before the device tree is available" __ROMCC__ is also used to get rid of prototypes because romcc doesn't support them. What's the right thing to do here? Maybe we should split the meanings so that we test for __GNUC__ when we mean "not romcc", and we test for __ROMCC__ (renamed, of course, later) when we mean early init?
Thanks, Myles
Myles Watson wrote:
These three patches get rid of a few more warnings for me.
abuild tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Peter Stuge peter@stuge.se
PS. It looks like part of the reason we have so many warnings is the misuse of #define __ROMCC__ to mean "early code before the device tree is available" __ROMCC__ is also used to get rid of prototypes because romcc doesn't support them. What's the right thing to do here? Maybe we should split the meanings so that we test for __GNUC__ when we mean "not romcc", and we test for __ROMCC__ (renamed, of course, later) when we mean early init?
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
//Peter
On Thu, Oct 29, 2009 at 7:35 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
These three patches get rid of a few more warnings for me.
abuild tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Acked-by: Peter Stuge peter@stuge.se
Rev 4890.
Thanks, Myles
PS. It looks like part of the reason we have so many warnings is the misuse of #define __ROMCC__ to mean "early code before the device tree is available" __ROMCC__ is also used to get rid of prototypes because romcc doesn't support them. What's the right thing to do here? Maybe we should split the meanings so that we test for __GNUC__ when we mean "not romcc", and we test for __ROMCC__ (renamed, of course, later) when we mean early init?
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
How about __PRE_RAM__, since it could be CAR but it is before RAM init?
On Thu, Oct 29, 2009 at 8:17 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
How about __PRE_RAM__, since it could be CAR but it is before RAM init?
I like __PRE_RAMINIT__ a lot!
I'm using __PRE_RAMINIT__ for now. The only problem with it is that then you have to define __PRE_RAMINIT__ during RAM initialization. I'd like to get this so that it's obvious what it means and when it should be used.
Thanks, Myles
On 30.10.2009 04:56, Myles Watson wrote:
On Thu, Oct 29, 2009 at 8:17 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
How about __PRE_RAM__, since it could be CAR but it is before RAM init?
I like __PRE_RAMINIT__ a lot!
I'm using __PRE_RAMINIT__ for now. The only problem with it is that then you have to define __PRE_RAMINIT__ during RAM initialization. I'd like to get this so that it's obvious what it means and when it should be used.
__NO_RAM_YET__ ?
Regards, Carl-Daniel
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
How about __PRE_RAM__, since it could be CAR but it is before RAM
init?
I like __PRE_RAMINIT__ a lot!
I'm using __PRE_RAMINIT__ for now. The only problem with it is that
then
you have to define __PRE_RAMINIT__ during RAM initialization. I'd like
to
get this so that it's obvious what it means and when it should be used.
__NO_RAM_YET__ ?
Close. It's more obvious what it means, but maybe it could be more clear when it should be used.
__USE_NO_RAM__ ?
Thanks, Myles
Peter Stuge wrote:
Myles Watson wrote:
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
How about __PRE_RAM__, since it could be CAR but it is before RAM init?
I like __PRE_RAMINIT__ a lot!
wouldn't __DURING_RAMINIT__ be more precise? ;-)
On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer stepan@coresystems.dewrote:
Peter Stuge wrote:
Myles Watson wrote:
I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch.
How about __PRE_RAM__, since it could be CAR but it is before RAM init?
I like __PRE_RAMINIT__ a lot!
wouldn't __DURING_RAMINIT__ be more precise? ;-)
It's close, but it needs to be defined for failover and AP init too.
Thanks, Myles
Myles Watson wrote:
On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer <stepan@coresystems.de mailto:stepan@coresystems.de> wrote:
Peter Stuge wrote: > Myles Watson wrote: > >>> I'd like __ROMCC__ to stay, but I agree very much with a new #define >>> BEFOREDEVICETREE or somesuch. >>> >> How about __PRE_RAM__, since it could be CAR but it is before RAM init? >> > > I like __PRE_RAMINIT__ a lot! > wouldn't __DURING_RAMINIT__ be more precise? ;-)It's close, but it needs to be defined for failover and AP init too.
Why AP init? Can't we get rid of this? It causes incredibly nasty trouble.
On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer <stepan@coresystems.de mailto:stepan@coresystems.de> wrote:
Peter Stuge wrote: > Myles Watson wrote: > >>> I'd like __ROMCC__ to stay, but I agree very much with a new #define >>> BEFOREDEVICETREE or somesuch. >>> >> How about __PRE_RAM__, since it could be CAR but it is before RAM init? >> > > I like __PRE_RAMINIT__ a lot! > wouldn't __DURING_RAMINIT__ be more precise? ;-)It's close, but it needs to be defined for failover and AP init too.
Why AP init? Can't we get rid of this? It causes incredibly nasty trouble.
I have no idea. I've never used it, but I just know that that's a place where __ROMCC__ was used.
Thanks, Myles
-
Carl-Daniel Hailfinger -
Myles Watson -
Peter Stuge -
Stefan Reinauer