On 02.10.2013, at 13:21, Antonios Motakis wrote:
> On Tue, Oct 1, 2013 at 9:32 PM, Yoder Stuart-B08248
> <B08248@xxxxxxxxxxxxx> wrote:
>>> Antonios Motakis wrote
>>>> Alex Williamson <alex.williamson@xxxxxxxxxx> wrote:
>>>> I notice all the open firmware calls here and I'm curious,
>>>> will all platform devices be making use of open firmware?
>>>> I don't know if this is synonymous with device tree or not.
>>>> Thanks,
>>>
>>> This VFIO driver will support only devices implemented
>>> on the device tree. While there can be platform devices
>>> outside the device tree, I don't think it makes sense
>>> to support them from the same driver. This is why I
>>> originally called the driver VFIO_DT, however I renamed
>>> it to VFIO_PLATFORM after feedback from the first
>>> RFC. However personally, I still think the VFIO_DT name
>>> is more appropriate since we don't support all platform
>>> devices, only those that use the device tree.
>>
>> But there is no 'device tree' bus. The bus type we're
>> dealing with is a platform bus.
>>
>> vfio for platform devices should be independent of whether
>> the device was discovered in a device tree or not.
>> All you're doing is exposing mappable regions and IRQs
>> to user space and it does not matter where the info originated.
>>
>> You should be using platform bus structs here not
>> reparsing device tree nodes. The struct
>> platform_device already has resource info in the
>> struct:
>>
>> struct platform_device {
>> const char *name;
>> u32 id;
>> struct device dev;
>> u32 num_resources;
>> struct resource *resource;
>> };
>>
>> Stuart
>>
>
> I will look into this. However, can we rely to have access to all
> device resources through platform abstractions, for every type of
> platform device? It seems to me that platform devices that are not
> backed by a specific description mechanism (such as device tree) may
> include a lot of hard coded values etc in their drivers.
The same can be true for device tree based drivers. We should tell user space which device tree node this is based off of so it can go and find properties itself, similar to how a kernel driver can still read dt properties for a platform device. But this is optional - we could just as well give user space a hint on an acpi interface.
What exactly would you consider not abstracted information that the kernel driver would need to know about? All cases I can think of (reset logic, power constraints) are very device specific and would require a new vfio-dt-mydevice driver on top of your generic framework to handle these small device specific bits.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
