Thread (10 messages) flat view 10 messages, 6 authors, 2010-06-21
STALE5891d

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

From: nico@fluxnic.net (Nicolas Pitre)
Date: 2010-06-21 15:38:27

On Mon, 21 Jun 2010, Eric Miao wrote:
On Mon, Jun 21, 2010 at 5:02 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help