From: Auger Eric <eric.auger@redhat.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
Baptiste Reynal <b.reynal@virtualopensystems.com>,
Alex Williamson <alex.williamson@redhat.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
KVM list <kvm@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kaya Sinan <okaya@codeaurora.org>
Subject: Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support
Date: Thu, 12 Apr 2018 13:49:04 +0200 [thread overview]
Message-ID: <2e09425d-0f27-3069-3421-e454ee70e3b2@redhat.com> (raw)
In-Reply-To: <CAMuHMdU5m=vV9nuVoRkX6tX-A=az3aK6HT7yFqgDam_rCNEfSg@mail.gmail.com>
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.auger@redhat.com> wrote:
>> 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 reset controller.
>>> If the reset hierarchy is described in DT using "resets" properties,
>>> such devices can be reset in a generic way through the reset controller
>>> subsystem. Hence add support for this, avoiding the need to write
>>> device-specific reset drivers for each single device on affected SoCs.
>>>
>>> Devices that do require a more complex reset procedure can still provide
>>> a device-specific reset driver, as that takes precedence.
>>>
>>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>>> becomes a no-op (as in: "No reset function found for device") if reset
>>> controller support is disabled.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
>
>>> --- a/drivers/vfio/platform/vfio_platform_common.c
>>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>
>>> @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
>>> vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>>> &vdev->reset_module);
>>> }
>>> + if (vdev->of_reset)
>>> + return 0;
>>> +
>>> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>>
>> Shouldn't we prefer the top level reset_control_get_exclusive()?
>
> I guess that should work, too.
>
>> To make sure about the exclusive/shared terminology, does
>> get_reset_control_get_exclusive() check we have an exclusive wire
>> between this device and the reset controller?
>
> AFAIU, the "exclusive" means that only a single user can obtain access to
> the reset, and it does not guarantee that we have an exclusive wire between
> the device and the reset controller.
>
> The latter depends on the SoC's reset topology. If a reset wire is shared
> by multiple devices (e.g. resets shared by PWM or Display Unit devices on
> R-Car SoCs), exporting a subset of these devices to a guest is a bad idea,
> indeed.
So who's going to check this assigned device will not trigger a reset of
other non assigned devices sharing the same reset controller?
>
> I guess the same thing can happen with the ACPI "_RST" method?
ACPI spec _RST chapter says about _RST object:
"This object executes a reset on the associated device
or devices. If included in a device context, the
reset must not affect any other ACPI-described de
vices; if included in a power resource for reset
(_PRR, Section 7.3.26) the reset must affect all ACPI-described devices
that reference it. When this object is described in
a device context, it executes a function level reset that only affects
the device it is associated with; neither parent nor children should be
affected by the execution of this reset. Executing this must only result
in this device resetting without the device appearing as if it
has been removed from the bus altogether, to prevent OSPM re-enumeration
of devices on hot-pluggable buses (e.g. USB)."
Adding Sinan in copy for clarification.
Thanks
Eric
>
> Gr{oetje,eeting}s,
>
> Geert
>
next prev parent reply other threads:[~2018-04-12 11:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-11 9:15 [PATCH] vfio: platform: Fix using devices in PM Domains Geert Uytterhoeven
2018-04-11 9:15 ` [PATCH v3 0/2] vfio: platform: Improve reset support Geert Uytterhoeven
2018-04-11 9:15 ` [PATCH v3 1/2] vfio: platform: Fix reset module leak in error path Geert Uytterhoeven
2018-04-13 8:55 ` Auger Eric
2018-05-11 19:45 ` Alex Williamson
2018-04-11 9:15 ` [PATCH v3 2/2] vfio: platform: Add generic DT reset support Geert Uytterhoeven
2018-04-12 7:00 ` Simon Horman
2018-04-12 10:31 ` Auger Eric
2018-04-12 11:32 ` Geert Uytterhoeven
2018-04-12 11:49 ` Auger Eric [this message]
2018-04-12 12:36 ` Sinan Kaya
2018-04-12 13:12 ` Geert Uytterhoeven
2018-04-12 14:10 ` Philipp Zabel
2018-04-12 16:02 ` Geert Uytterhoeven
2018-04-13 8:52 ` Auger Eric
2018-04-13 9:02 ` Geert Uytterhoeven
2018-04-13 9:22 ` Philipp Zabel
2018-04-13 10:05 ` Auger Eric
2018-04-13 11:56 ` Geert Uytterhoeven
2018-04-11 9:21 ` [PATCH] vfio: platform: Fix using devices in PM Domains Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e09425d-0f27-3069-3421-e454ee70e3b2@redhat.com \
--to=eric.auger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=b.reynal@virtualopensystems.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=okaya@codeaurora.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).