[PATCH 1/2] [ARM] Introduce 'struct machine_class' for SoC level abstraction

[Nicolas Pitre]

On Mon, 21 Jun 2010, Eric Miao wrote:

> On Mon, Jun 21, 2010 at 5:02 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > The same behaviour seems sensible to apply to the other class
> > functions as well - allow platforms to override the class
> > version, and leave the replacement platform function responsible
> > for calling the class if that's what it needs to do.
> >
> 
> Yep, that's a good idea, and actually was as my first version. Yet my
> concern is this doesn't easily fit for the class data, i.e., allow the
> machine specific data to override the class data like below:
> 
> 	if (valid_value(mdesc->phys_io))
> 		use(mdesc->phys_io);
> 	else
> 		use(mdesc->class->phys_io);
> 
> but since phys_io could be valid for value zero (as if not explicitly
> initialized), so we may end up defining like below to allow use of the
> default class values:
> 
> MACHINE_START(....)
> 	.phys_io	= INVALID_ADDRESS,
> 	.io_pg_offst	= INVALID_ADDRESS,
> 	....
> MACHINE_END

No, please don't do that.  This is horribly ugly.

And in fact I would actually be highly surprised if 0 was a sensible 
value to use for either of those fields anyway.  No SOCs I know about 
has its IO at physical address0, and we're even less likely to remap 
them at virtual address 0 either.  So having 0 meaning uninitialized 
makes perfect sense in practice.


Nicolas