Re: [PATCH v5] vfio: platform: Add generic reset controller support

Hi Geert, On 11/13/18 2:15 PM, Geert Uytterhoeven wrote: > Vfio-platform requires dedicated reset support, provided either by ACPI, > or, on DT platforms, by a device-specific reset driver matching against > the device's compatible value. > > On many SoCs, devices are connected to an SoC-internal

Re: [PATCH v3] vfio: platform: Fix using devices in PM Domains

Hi Geert, On 05/28/2018 05:26 PM, Geert Uytterhoeven wrote: > If a device is part of a PM Domain (e.g. power and/or clock domain), its > power state is managed using Runtime PM. Without Runtime PM, the device > may not be powered up or clocked, causing subtle failures, crashes, or > system

Re: [PATCH v2] vfio: platform: Fix using devices in PM Domains

Hi Geert, On 05/18/2018 12:55 PM, Geert Uytterhoeven wrote: > If a device is part of a PM Domain (e.g. power and/or clock domain), its > power state is managed using Runtime PM. Without Runtime PM, the device > may not be powered up or clocked, causing subtle failures, crashes, or > system

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Philipp, On 13/04/18 11:22, Philipp Zabel wrote: [..] > That also means it is impossible to use just one of the devices that > share a reset line for vfio individually, while the other ones are still > in use by the host. Currently the reset line is a shared resource > similar to the iommu for

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

Hi Geert, On 13/04/18 11:19, Geert Uytterhoeven wrote: > Hi Eric, > > On Fri, Apr 13, 2018 at 11:14 AM, Auger Eric <eric.au...@redhat.com> wrote: >> On 11/04/18 11:24, Geert Uytterhoeven wrote: >>> If a device is part of a PM Domain (e.g. power and/or cloc

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

Hi Geert, On 11/04/18 11:24, Geert Uytterhoeven wrote: > If a device is part of a PM Domain (e.g. power and/or clock domain), its > power state is managed using Runtime PM. Without Runtime PM, the device > may not be powered up, causing subtle failures, crashes, or system > lock-ups when the

Re: [PATCH v3 1/2] vfio: platform: Fix reset module leak in error path

Hi Geert, On 11/04/18 11:15, Geert Uytterhoeven wrote: > If the IOMMU group setup fails, the reset module is not released. > > Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by > default") > Signed-off-by: Geert Uytterhoeven > Reviewed-by:

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

nan Kaya <ok...@codeaurora.org> wrote: >>>> On 4/12/2018 7:49 AM, Auger Eric wrote: >>>>> On 12/04/18 13:32, Geert Uytterhoeven wrote: >>>>>> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric <eric.au...@redhat.com> >>>>>>

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Geert, On 12/04/18 13:32, Geert Uytterhoeven wrote: > Hi Eric, > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric <eric.au...@redhat.com> wrote: >> On 11/04/18 11:15, Geert Uytterhoeven wrote: >>> Vfio-platform requires reset support, provided either by ACPI, or, on

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

Hi Geert, Philipp, On 11/04/18 11:15, Geert Uytterhoeven wrote: > Vfio-platform requires reset support, provided either by ACPI, or, on DT > platforms, by a device-specific reset driver matching against the > device's compatible value. > > On many SoCs, devices are connected to an SoC-internal

Re: [PATCH 1/2] vfio: platform: Fix reset module leak in error path

Hi Geert, On 13/02/18 17:36, Geert Uytterhoeven wrote: > If the IOMMU group setup fails, the reset module is not released. > > Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by > default") > Signed-off-by: Geert Uytterhoeven Reviewed-by: Eric

Re: [PATCH 1/2] vfio: platform: Fix reset module leak in error path

Hi Geert, On 21/02/18 17:07, Geert Uytterhoeven wrote: > Hi Eric, > > On Wed, Feb 14, 2018 at 10:32 AM, Geert Uytterhoeven > <ge...@linux-m68k.org> wrote: >> On Wed, Feb 14, 2018 at 9:36 AM, Auger Eric <eric.au...@redhat.com> wrote: >>> If I am

Re: [PATCH/RFC 5/5] hw/arm/sysbus-fdt: Enable rcar-gen3-gpio dynamic instantiation

Hi Geert, On 09/02/18 16:17, Geert Uytterhoeven wrote: > Allow the instantiation of a Renesas R-Car Gen3 GPIO controller device > from the QEMU command line: > > -device vfio-platform,host=,manufacturer=renesas,model=rcar-gen3-gpio > -device >

Re: [PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

Hi Geert, On 09/02/18 16:17, Geert Uytterhoeven wrote: > Allow the instantation of generic dynamic sysbus devices again, without > the need to create a new device-specific vfio type. > > This is a partial revert of commit 6f2062b9758ebc64 ("hw/arm/virt: > Allow only supported dynamic sysbus

Re: [PATCH 2/2] vfio: platform: Add generic DT reset support

Hi Geert, On 14/02/18 10:43, Geert Uytterhoeven wrote: > Hi Eric, > > On Wed, Feb 14, 2018 at 10:09 AM, Auger Eric <eric.au...@redhat.com> wrote: >> On 13/02/18 17:36, Geert Uytterhoeven wrote: >>> Vfio-platform requires reset support, provided either by

Re: [PATCH 2/2] vfio: platform: Add generic DT reset support

Hi Geert, On 13/02/18 17:36, Geert Uytterhoeven wrote: > Vfio-platform requires reset support, provided either by ACPI, or, on DT > platforms, by a device-specific reset driver matching against the > device's compatible value. > > On many SoCs, devices are connected to an SoC-internal reset

Re: [PATCH 1/2] vfio: platform: Fix reset module leak in error path

Hi Geert, On 13/02/18 17:36, Geert Uytterhoeven wrote: > If the IOMMU group setup fails, the reset module is not released. > > Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by > default") > Signed-off-by: Geert Uytterhoeven > --- >