On Tue, 2013-10-01 at 19:32 +0000, Yoder Stuart-B08248 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;
> };
It seems likely(?) that platform devices could be described via ACPI at
some point, so keeping this abstraction would be a plus. Thanks,
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
