Re: [PATCH 3/7] Return info for device and its memory regions and interrupts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux