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

On Mon, Jun 21, 2010 at 5:02 PM, Russell King - ARM Linux
[off-list ref] wrote:

On Mon, Jun 21, 2010 at 04:23:22PM +0800, Eric Miao wrote:

quoted

So that from derivative POV, it can be expressed as:

? ? ? if (mdesc->class && mdesc->class->map_io)
? ? ? ? ? ? ? mdesc->class->map_io();
? ? ? if (mdesc->map_io())
? ? ? ? ? ? ? mdesc->map_io();

But this seems to make things a bit over complicated, so for such cases
I'd prefer:

1. have a separate machine_class for mainstone
2. or move the board specific map_io() separatedly

How about making the presence of mdesc->map_io override the class
version?

So if mainstone provides its own map_io() function, it is still
responsible (as is today) for calling the PXA specific map_io().
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

This, however, creates some incompatiblity in semantics from the functions.
That's why I chose a much simpler scheme: use the class version if class
is there, otherwise use the machine specific one.