public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: eric.auger.pro@gmail.com, treding@nvidia.com,
	vbhadram@nvidia.com, jonathanh@nvidia.com, mperttunen@nvidia.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	clg@redhat.com, alexandre.torgue@foss.st.com,
	joabreu@synopsys.com, msalter@redhat.com
Subject: Re: [RFC PATCH 3/5] vfio_platform: reset: Introduce new open and close callbacks
Date: Wed, 11 Sep 2024 14:18:42 +0200	[thread overview]
Message-ID: <3e7824f9-4934-49a7-a0e7-531dae4e57ee@redhat.com> (raw)
In-Reply-To: <20240904134028.796b2670.alex.williamson@redhat.com>

Hi Alex,

On 9/4/24 21:40, Alex Williamson wrote:
> On Mon, 2 Sep 2024 18:03:23 +0200
> Eric Auger <eric.auger@redhat.com> wrote:
>
>> Hi Alex,
>>
>> On 8/30/24 01:21, Alex Williamson wrote:
>>> On Thu, 29 Aug 2024 18:11:07 +0200
>>> Eric Auger <eric.auger@redhat.com> wrote:
>>>  
>>>> Some devices may require resources such as clocks and resets
>>>> which cannot be handled in the vfio_platform agnostic code. Let's
>>>> add 2 new callbacks to handle those resources. Those new callbacks
>>>> are optional, as opposed to the reset callback. In case they are
>>>> implemented, both need to be.
>>>>
>>>> They are not implemented by the existing reset modules.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>> ---
>>>>  drivers/vfio/platform/vfio_platform_common.c  | 28 ++++++++++++++++++-
>>>>  drivers/vfio/platform/vfio_platform_private.h |  6 ++++
>>>>  2 files changed, 33 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
>>>> index 3be08e58365b..2174e402dc70 100644
>>>> --- a/drivers/vfio/platform/vfio_platform_common.c
>>>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>>>> @@ -228,6 +228,23 @@ static int vfio_platform_call_reset(struct vfio_platform_device *vdev,
>>>>  	return -EINVAL;
>>>>  }
>>>>  
>>>> +static void vfio_platform_reset_module_close(struct vfio_platform_device *vpdev)
>>>> +{
>>>> +	if (VFIO_PLATFORM_IS_ACPI(vpdev))
>>>> +		return;
>>>> +	if (vpdev->reset_ops && vpdev->reset_ops->close)
>>>> +		vpdev->reset_ops->close(vpdev);
>>>> +}
>>>> +
>>>> +static int vfio_platform_reset_module_open(struct vfio_platform_device *vpdev)
>>>> +{
>>>> +	if (VFIO_PLATFORM_IS_ACPI(vpdev))
>>>> +		return 0;
>>>> +	if (vpdev->reset_ops && vpdev->reset_ops->open)
>>>> +		return vpdev->reset_ops->open(vpdev);
>>>> +	return 0;
>>>> +}  
>>> Hi Eric,
>>>
>>> I didn't get why these are no-op'd on an ACPI platform.  Shouldn't it
>>> be up to the reset ops to decide whether to implement something based
>>> on the system firmware rather than vfio-platform-common?  
>> In case of ACPI boot, ie. VFIO_PLATFORM_IS_ACPI(vpdev) is set, I
>> understand we don't use the vfio platform reset module but the ACPI _RST
>> method. see vfio_platform_acpi_call_reset() and
>> vfio_platform_acpi_has_reset() introduced by d30daa33ec1d ("vfio:
>> platform: call _RST method when using ACPI"). I have never had the
>> opportunity to test acpi boot reset though.
> Aha, I was expecting that VFIO_PLATFORM_IS_ACPI() wouldn't exclusively
> require _RST support, but indeed in various places we only look for the
> acpihid for the device without also checking for a _RST method.  In
> fact commit 7aef80cf3187 ("vfio: platform: rename reset function")
> prefixed the reset function pointer with "of_" to try to make that
> exclusion more clear, but the previous patch of this series introducing
> the ops structure chose a more generic name.  Should we instead use
> "of_reset_ops" to maintain that we have two distinct paths, ACPI vs DT?
Yes I will rename with of_ prefix.
>
> TBH I'm not sure why we couldn't check that an acpihid also supports a
> _RST method and continue to look for reset module support otherwise,
> but that's not the way it's coded and there's apparently no demand for
> it.
I agree. Without explicit request I am reluctant to change that because
I can't test atm
>
>>>> +
>>>>  void vfio_platform_close_device(struct vfio_device *core_vdev)
>>>>  {
>>>>  	struct vfio_platform_device *vdev =
>>>> @@ -242,6 +259,7 @@ void vfio_platform_close_device(struct vfio_device *core_vdev)
>>>>  			"reset driver is required and reset call failed in release (%d) %s\n",
>>>>  			ret, extra_dbg ? extra_dbg : "");
>>>>  	}
>>>> +	vfio_platform_reset_module_close(vdev);
>>>>  	pm_runtime_put(vdev->device);
>>>>  	vfio_platform_regions_cleanup(vdev);
>>>>  	vfio_platform_irq_cleanup(vdev);
>>>> @@ -265,7 +283,13 @@ int vfio_platform_open_device(struct vfio_device *core_vdev)
>>>>  
>>>>  	ret = pm_runtime_get_sync(vdev->device);
>>>>  	if (ret < 0)
>>>> -		goto err_rst;
>>>> +		goto err_rst_open;
>>>> +
>>>> +	ret = vfio_platform_reset_module_open(vdev);
>>>> +	if (ret) {
>>>> +		dev_info(vdev->device, "reset module load failed (%d)\n", ret);
>>>> +		goto err_rst_open;
>>>> +	}
>>>>  
>>>>  	ret = vfio_platform_call_reset(vdev, &extra_dbg);
>>>>  	if (ret && vdev->reset_required) {
>>>> @@ -278,6 +302,8 @@ int vfio_platform_open_device(struct vfio_device *core_vdev)
>>>>  	return 0;
>>>>  
>>>>  err_rst:
>>>> +	vfio_platform_reset_module_close(vdev);
>>>> +err_rst_open:
>>>>  	pm_runtime_put(vdev->device);
>>>>  	vfio_platform_irq_cleanup(vdev);
>>>>  err_irq:
>>>> diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
>>>> index 90c99d2e70f4..528b01c56de6 100644
>>>> --- a/drivers/vfio/platform/vfio_platform_private.h
>>>> +++ b/drivers/vfio/platform/vfio_platform_private.h
>>>> @@ -74,9 +74,13 @@ struct vfio_platform_device {
>>>>   * struct vfio_platform_reset_ops - reset ops
>>>>   *
>>>>   * @reset:	reset function (required)
>>>> + * @open:	Called when the first fd is opened for this device (optional)
>>>> + * @close:	Called when the last fd is closed for this device (optional)  
>>> This doesn't note any platform firmware dependency.  We should probably
>>> also note here the XOR requirement enforced below here.  Thanks,  
>> To me this is just used along with dt boot, hence the lack of check.
> Per the above comment, I'd just specify the whole struct as a DT reset
> ops interface and sprinkle "_of_" into the name to make that more
> obvious.  Thanks,

agreed

Thanks

Eric
>
> Alex
>
>>>>   */
>>>>  struct vfio_platform_reset_ops {
>>>>  	int (*reset)(struct vfio_platform_device *vdev);
>>>> +	int (*open)(struct vfio_platform_device *vdev);
>>>> +	void (*close)(struct vfio_platform_device *vdev);
>>>>  };
>>>>  
>>>>  
>>>> @@ -129,6 +133,8 @@ __vfio_platform_register_reset(&__ops ## _node)
>>>>  MODULE_ALIAS("vfio-reset:" compat);				\
>>>>  static int __init reset ## _module_init(void)			\
>>>>  {								\
>>>> +	if (!!ops.open ^ !!ops.close)				\
>>>> +		return -EINVAL;					\
>>>>  	vfio_platform_register_reset(compat, ops);		\
>>>>  	return 0;						\
>>>>  };								\  


  reply	other threads:[~2024-09-11 12:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29 16:11 [RFC PATCH 0/5] vfio: platform: reset: Introduce tegra234 mgbe reset module Eric Auger
2024-08-29 16:11 ` [RFC PATCH 1/5] vfio_platform: Introduce vfio_platform_get_region helper Eric Auger
2024-08-29 16:11 ` [RFC PATCH 2/5] vfio_platform: reset: Prepare for additional reset ops Eric Auger
2024-08-29 16:11 ` [RFC PATCH 3/5] vfio_platform: reset: Introduce new open and close callbacks Eric Auger
2024-08-29 23:21   ` Alex Williamson
2024-09-02 16:03     ` Eric Auger
2024-09-04 19:40       ` Alex Williamson
2024-09-11 12:18         ` Eric Auger [this message]
2024-08-29 16:11 ` [RFC PATCH 4/5] vfio-platform: Add a new handle to store reset data Eric Auger
2024-08-29 16:11 ` [RFC PATCH 5/5] vfio/platform: Add tegra234-mgbe vfio platform reset module Eric Auger

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=3e7824f9-4934-49a7-a0e7-531dae4e57ee@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=clg@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=joabreu@synopsys.com \
    --cc=jonathanh@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mperttunen@nvidia.com \
    --cc=msalter@redhat.com \
    --cc=treding@nvidia.com \
    --cc=vbhadram@nvidia.com \
    /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