Re: [PATCH v14 00/20] VFIO support for platform devices

[Baptiste Reynal <b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>]

Thanks Eric and Alex for your reviews.

I can confirm we can drop the dependency, as I re-tested without it.
Do you need a fix for the headers issue underlined by Eric ?

Best regards,
Baptiste

On Wed, Mar 11, 2015 at 9:40 AM, Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 03/10/2015 07:04 PM, Alex Williamson wrote:
>> On Tue, 2015-03-10 at 18:42 +0100, Eric Auger wrote:
>>> Hi Baptiste,
>>>
>>> Please add:
>>> Reviewed-by: Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> on the whole series
>>> Tested-by: Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> on the whole series except
>>> AMBA specific patches.
>>>
>>> I currently exercise the following functionalities on Calxeda Midway HW:
>>> - MMIO read/write/mmap,
>>> - automasked IRQ + mask/unmask (NONE flag),
>>> - virqfd (unmask handler only).
>>>
>>> Despite a new thorough review I failed in pointing out any new
>>> interesting issues in this series.
>>>
>>> just minor points below:
>>>
>>> - PIO regions: currently read/write/mmap is not supported. I can't
>>> figure out how much this is a problem at this point?
>>
>> AIUI, nobody has any way to test this, which is why it's not
>> implemented.  I think we've done due diligence in accommodating PIO into
>> the vfio-platform framework though and hopefully it will be a simple
>> matter to add when someone has a use case for it.
>>
>>> - nit: vfio_pci_intrs.c: may not need wait.h anymore after removal of
>>> virqfd code. may be added in vfio.h
>>> - nit: interrupt.h not needed at early stage in vfio_platform_private.h,
>>> until irq introduction
>>> - version of the driver: 0.10?
>>
>> None of these seem like blockers, I'd be willing to accept header
>> cleanups as follow-on and driver versions are mostly arbitrary anyway.
>>
>>> Since there is no real dependency on "[PATCH v4 0/6] vfio: type1:
>>> support for ARM SMMUS with VFIO_IOMMU_TYPE1" I hope we can get this
>>> upstreamed soon.
>>
>> Me too, I also re-reviewed the series yesterday.  If Baptiste agrees
>> that there's no dependency on the other series, I can add your R-b/T-b,
>> do some additional testing, and queue the series for linux-next.
>> Thanks,
>
> Hi Alex,
>
> I let Baptiste answer. If he agrees please do as proposed. I am looking
> forward to seeing the series in linux-next!
>
> Best Regards
>
> Eric
>>
>> Alex
>>
>