|
[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 |