[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.