Re: [Xen-devel] [PATCH v4 33/33] docs/misc: arm: Add documentation about non-PCI passthrough

[Julien Grall <julien.grall.oss@xxxxxxxxx>]

On 31/03/15 14:21, Ian Campbell wrote:
> On Tue, 2015-03-31 at 14:03 +0100, Julien Grall wrote:
> 
>>>> +    passthrough {
>>>> +        compatible = "simple-bus";
>>>> +        ranges;
>>>> +        #address-cells = <2>;
>>>> +        #size-cells = <2>;
>>>> +          mac0: ethernet@10000000 {
>>>> +          compatible = "calxeda,hb-xgmac";
>>>> +            reg = <0 0x10000000 0 0x1000>;
>>>> +                  interrupts = <0 80 4  0 81 4  0 82 4>;
>>>
>>> Tabs vs spaces?
>>
>> I think so. I will fix it.
>>
>>>
>>> Is it worth making reference to looking at the host entry and copying
>>> some of the relevant bits of that, or would that be more confusing?
>>
>> I don't understand the question here.
> 
> Should we give people a hint that to discover the contents of this node
> they should refer to the equivalent entry in the host db.

I don't think it's necessary.

In the current state, DT passthrough is very primitive and only a user
who is aware of device tree concept can use it (some properties can't be
added in the DT...).

>>
>>>> +          };
>>>> +    };
>>>> +};
>>>> +
>>>> +Note:
>>>> +    * The interrupt-parent property will be added by the toolstack in the
>>>> +    root node;
>>>> +    * The properties compatible, ranges, #address-cells and #size-cells
>>>> +    in /passthrough are mandatory.
>>>
>>> The following properties are mandatory within the /passthrough node:
>>>   * compatible
>>>   * ranges
>>>   * ...
>>>
>>> Are the values of any of them mandatory, i.e. simply-bus or empty
>>> ranges?
>>
>> "simple-bus" is mandatory. The empty ranges not.
> 
> It's worth saying the former I think.
> 
> For the latter a non-empty ranges would require exciting calculations
> and changes to the iomem parameter to match etc, so perhaps recommend
> that it be empty?

I think the user is smart enough to decide which solution is better for him.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel