Re: [RFC PATCH v3 0/3] vfio: platform: return device properties for a platform device

[Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
> On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Tue, Sep 01, 2015 at 05:32:21PM +0200, Baptiste Reynal wrote:
> >> Hi everyone,
> >>
> >> The usefullness of this patch has already been discussed during the
> >> first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html).
> >> I underline the fact that it avoids implementing the logic on the
> >> userspace program, as VFIO can be used for many usage (userspace
> >> drivers and device assignment).
> >>
> >> If you're interested in the implementation on the userspace side, an
> >> RFC has been suggested for QEMU:
> >> http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html
> >
> > This one-year-old discussion is hardly exhaustive.
> >
> > I think you missed the gist of the question for Eric a bit as well.
> >
> > One important question for me is whether seeing the host DT is always
> > sufficient or if the kernel and physical device driver can have more
> > information about the device and its configuration which userspace may
> > need, which cannot be directly read in the DT (for example because the
> > driver has initialized the device in a specific way).  My point is, it's
> > really not about DT-specific things (what if you used ACPI?), but it's
> > about retrieving properties of a device and its configuration from
> > userspace.
> >
> > Have we thought about the possible ways to achieve this and weight one
> > option against the other?
> 
> Problem is that now we only have a very few platform devices behind an
> IOMMU, so we don't have the visibility to know if such a case will
> occur. With the current use cases, the interface seems to be
> sufficient. 

Ideally we can think about future use cases based on the experience of
people in the community and come up with a solution considering future
use cases.

> By using IOCTL, we can always change the implementation
> later without any change on the userspace.

Can you be more concrete with what you mean here?

> 
> Do you think we can valid the API, then if such a case occurs (when
> the device informations changes between the device tree and the
> running state) we can change the kernel implementation ?
> 

Sorry, I don't understand this paragraph.

-Christoffer