[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 03/19] xen/arm: follow-up to allow DOM0 manage IRQ and MMIO
On Thu, 2014-07-03 at 12:23 +0100, Julien Grall wrote: > On 07/03/2014 12:02 PM, Ian Campbell wrote: > > On Wed, 2014-06-18 at 21:32 +0100, Julien Grall wrote: > >>>> @@ -865,10 +888,9 @@ static int handle_node(struct domain *d, struct > >>>> kernel_info *kinfo, > >>>> * property. Therefore these device doesn't need to be mapped. > >>>> This > >>>> * solution can be use later for pass through. > >>>> */ > >>>> - if ( !dt_device_type_is_equal(node, "memory") && > >>>> - dt_device_is_available(node) ) > >>>> + if ( !dt_device_type_is_equal(node, "memory") ) > >>>> { > >>>> - res = map_device(d, node); > >>>> + res = handle_device(d, node, dt_device_is_available(node)); > >>>> > >>>> if ( res ) > >>>> return res; > >>> > >>> We need a comment here > >> > >> Hmmm... I don't see what kind of comment I can add here. There is > >> already lots of comments explaining handle_device and the previous if. > > > > I'd be inclined to push the dt_device_is_available call down into the > > handle_function. > > > > Otherwise I would go with > > res = make_deevice_available(node) > > What will do make_device_available? The tweaking of the iocaps arrays etc (perhaps a badly chosen name given the dt_....available). > > if (!res && dt_...available(node) > > res = map_device(node). > > AFAIU, it would means to duplicate the loop to get interrupt/MMIO twice > which I think it's stupid. > > So, I prefer to push the dt_device_is_available call down into the > handle_function. Sure. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |