[PATCH 1/2] [ARM] Introduce 'struct machine_class' for SoC level abstraction
eric.y.miao at gmail.com
Mon Jun 21 11:44:02 EDT 2010
On Mon, Jun 21, 2010 at 11:38 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> 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))
>> 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:
>> .phys_io = INVALID_ADDRESS,
>> .io_pg_offst = INVALID_ADDRESS,
> 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.
Hrm... that makes sense. I'll add some comment to the 'struct machine_class'
and get this patch updated later.
More information about the linux-arm-kernel