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

[Christoffer Dall <christoffer.dall@linaro.org>]

On Wed, Sep 02, 2015 at 11:49:12AM +0200, Baptiste Reynal wrote:
> On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > 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@linaro.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?
> >
> 
> By using an IOCTL, we define an API that allows to retrieve device
> properties from userspace. The way it is retrieved is handled by the
> kernel (For example for now if OF is unavailable, the kernel will
> retrieve the property using ACPI) and is totally transparent from the
> userspace point of view.

ok, I thought that this series was targeting device tree specifically,
but I see that you changed this approach in v3.

> 
> My point is that we can go with the current naive implementation for
> now, and we might extend it later according to the needs of future
> devices, without changing anything from the userspace point of view.
> 
fair enough.

Is this series exporting properties not already exported through sysfs?

-Christoffer