linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	myron.stowe@redhat.com, bodong@mellanox.com, eli@mellanox.com,
	laine@redhat.com
Subject: Re: [PATCH] PCI: Always allow probing with driver_override
Date: Thu, 13 Jun 2019 16:50:08 -0500	[thread overview]
Message-ID: <20190613215008.GN13533@google.com> (raw)
In-Reply-To: <155742996741.21878.569845487290798703.stgit@gimli.home>

On Thu, May 09, 2019 at 01:27:22PM -0600, Alex Williamson wrote:
> Commit 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control
> VF driver binding") introduced the sriov_drivers_autoprobe attribute
> which allows users to prevent the kernel from automatically probing a
> driver for new VFs as they are created.  This allows VFs to be spawned
> without automatically binding the new device to a host driver, such as
> in cases where the user intends to use the device only with a meta
> driver like vfio-pci.  However, the current implementation prevents any
> use of drivers_probe with the VF while sriov_drivers_autoprobe=0.  This
> blocks the now current general practice of setting driver_override
> followed by using drivers_probe to bind a device to a specified driver.
> 
> The kernel never automatically sets a driver_override therefore it seems
> we can assume a driver_override reflects the intent of the user.  Also,
> probing a device using a driver_override match seems outside the scope
> of the 'auto' part of sriov_drivers_autoprobe.  Therefore, let's allow
> driver_override matches regardless of sriov_drivers_autoprobe, which we
> can do by simply testing if a driver_override is set for a device as a
> 'can probe' condition.
> 
> Fixes: 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding")
> Link: https://lore.kernel.org/linux-pci/155672991496.20698.4279330795743262888.stgit@gimli.home/T/#u
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

Applied to pci/enumeration for v5.3, thanks!

> ---
> 
>  drivers/pci/pci-driver.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index da7b82e56c83..9b9e9c63cde8 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -399,7 +399,8 @@ void __weak pcibios_free_irq(struct pci_dev *dev)
>  #ifdef CONFIG_PCI_IOV
>  static inline bool pci_device_can_probe(struct pci_dev *pdev)
>  {
> -	return (!pdev->is_virtfn || pdev->physfn->sriov->drivers_autoprobe);
> +	return (!pdev->is_virtfn || pdev->physfn->sriov->drivers_autoprobe ||
> +		pdev->driver_override);
>  }
>  #else
>  static inline bool pci_device_can_probe(struct pci_dev *pdev)
> 

      reply	other threads:[~2019-06-13 21:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 19:27 [PATCH] PCI: Always allow probing with driver_override Alex Williamson
2019-06-13 21:50 ` Bjorn Helgaas [this message]

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=20190613215008.GN13533@google.com \
    --to=helgaas@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=bodong@mellanox.com \
    --cc=eli@mellanox.com \
    --cc=laine@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=myron.stowe@redhat.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;
as well as URLs for NNTP newsgroup(s).