[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