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

[Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Tue, 2013-10-01 at 19:32 +0000, Yoder Stuart-B08248 wrote:
> > Antonios Motakis wrote
> > > Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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