public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Michał Winiarski" <michal.winiarski@intel.com>
Cc: linux-pci@vger.kernel.org, intel-xe@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Michal Wajdeczko" <michal.wajdeczko@intel.com>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Matt Roper" <matthew.d.roper@intel.com>
Subject: Re: [PATCH v3 4/5] PCI/IOV: Allow extending VF BAR within original resource boundary
Date: Thu, 10 Oct 2024 17:27:35 -0500	[thread overview]
Message-ID: <20241010222735.GA580854@bhelgaas> (raw)
In-Reply-To: <20241010103203.382898-5-michal.winiarski@intel.com>

On Thu, Oct 10, 2024 at 12:32:02PM +0200, Michał Winiarski wrote:
> VF MMIO resource reservation, either created by system firmware and
> inherited by Linux PCI subsystem or created by the subsystem itself,
> contains enough space to fit the BAR of all SR-IOV Virtual Functions
> that can potentially be created (total VFs supported by the device).

It's *possible* that this is true, but there's no guarantee that
firmware has assigned enough space for all BARs of all possible VFs.

> This can be leveraged when the device is exposing lower than optimal BAR
> size as a default, allowing access to the entire resource when lower
> number of VFs are created.
> It is achieved by dynamically resizing the BAR to largest possible value
> that allows to fit all newly created VFs within the original resource
> boundary.

Add blank lines between paragraphs.

This log doesn't actually say what the patch does.  It describes a
possible configuration and ways that it may be used, and even *how*
something might be done, but something along the lines of the subject
line should be included in the commit log.

> +static void pci_iov_resource_do_extend(struct pci_dev *dev, int resno, u16 num_vfs)

Please wrap to fit in 80 columns like the rest of the file.

> +int pci_iov_resource_extend(struct pci_dev *dev, int resno, bool enable)

Please add kerneldoc here to help users of this exported function.

> @@ -480,6 +560,11 @@ static ssize_t sriov_numvfs_store(struct device *dev,
>  		goto exit;
>  	}
>  
> +	for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> +		if (pdev->sriov->rebar_extend[i])
> +			pci_iov_resource_do_extend(pdev, i + PCI_IOV_RESOURCES, num_vfs);

Wrap to fit in 80 columns.

Bjorn

  reply	other threads:[~2024-10-10 22:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10 10:31 [PATCH v3 0/5] PCI: VF resizable BAR Michał Winiarski
2024-10-10 10:31 ` [PATCH v3 1/5] PCI/IOV: Restore VF resizable BAR state after reset Michał Winiarski
2024-10-10 11:01   ` Ilpo Järvinen
2024-10-10 22:31   ` Bjorn Helgaas
2024-10-10 10:32 ` [PATCH v3 2/5] PCI: Add a helper to identify IOV resources Michał Winiarski
2024-10-10 10:46   ` Ilpo Järvinen
2024-10-10 22:30   ` Bjorn Helgaas
2024-10-10 10:32 ` [PATCH v3 3/5] PCI: Allow IOV resources to be resized in pci_resize_resource Michał Winiarski
2024-10-10 11:17   ` Ilpo Järvinen
2024-10-10 11:42     ` Michał Winiarski
2024-10-10 22:36   ` Bjorn Helgaas
2024-10-10 10:32 ` [PATCH v3 4/5] PCI/IOV: Allow extending VF BAR within original resource boundary Michał Winiarski
2024-10-10 22:27   ` Bjorn Helgaas [this message]
2024-10-10 10:32 ` [PATCH v3 5/5] drm/xe/pf: Extend the VF LMEM BAR Michał Winiarski

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=20241010222735.GA580854@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=airlied@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=michal.winiarski@intel.com \
    --cc=mripard@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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