From: "Michael S. Tsirkin" <mst@redhat.com>
To: phasta@kernel.org
Cc: schalla@marvell.com, vattunuru@marvell.com,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Shijith Thotton" <sthotton@marvell.com>,
"Dan Carpenter" <dan.carpenter@linaro.org>,
"Satha Rao" <skoteshwar@marvell.com>,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] vdpa/octeon_ep: Control PCI dev enabling manually
Date: Thu, 15 May 2025 07:28:16 -0400 [thread overview]
Message-ID: <20250515072724-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f6e5e4c0f32f8ecb3be71181042082d2d8a9533b.camel@mailbox.org>
On Thu, May 15, 2025 at 09:14:22AM +0200, Philipp Stanner wrote:
> On Thu, 2025-05-08 at 10:51 +0200, Philipp Stanner wrote:
> > PCI region request functions such as pci_request_region() currently
> > have
> > the problem of becoming sometimes managed functions, if
> > pcim_enable_device() instead of pci_enable_device() was called. The
> > PCI
> > subsystem wants to remove this deprecated behavior from its
> > interfaces.
> >
> > octeopn_ep enables its device with pcim_enable_device() (for VF. PF
> > uses
> > manual management), but does so only to get automatic disablement.
> > The
> > driver wants to manage its PCI resources for VF manually, without
> > devres.
> >
> > The easiest way not to use automatic resource management at all is by
> > also handling device enable- and disablement manually.
> >
> > Replace pcim_enable_device() with pci_enable_device(). Add the
> > necessary
> > calls to pci_disable_device().
> >
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
> > Acked-by: Vamsi Attunuru <vattunuru@marvell.com>
>
> Hi again,
>
> this is the last of 12 drivers blocking me from removing a few hundred
> lines of broken code from PCI. Would be great if it could be sent to
> Linus next merge window.
>
> Can someone take this patch in?
>
> Thx
> P.
I intend to, working on packing things up for -next as we speak.
> > ---
> > Changes in v4:
> > - s/AF/PF
> > - Add Vamsi's AB
> >
> > Changes in v3:
> > - Only call pci_disable_device() for the PF version. For AF it
> > would
> > cause a WARN_ON because pcim_enable_device()'s callback will also
> > try to disable.
> > ---
> > drivers/vdpa/octeon_ep/octep_vdpa_main.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/vdpa/octeon_ep/octep_vdpa_main.c
> > b/drivers/vdpa/octeon_ep/octep_vdpa_main.c
> > index f3d4dda4e04c..9b49efd24391 100644
> > --- a/drivers/vdpa/octeon_ep/octep_vdpa_main.c
> > +++ b/drivers/vdpa/octeon_ep/octep_vdpa_main.c
> > @@ -454,6 +454,9 @@ static void octep_vdpa_remove_pf(struct pci_dev
> > *pdev)
> > octep_iounmap_region(pdev, octpf->base,
> > OCTEP_HW_MBOX_BAR);
> >
> > octep_vdpa_pf_bar_expand(octpf);
> > +
> > + /* The pf version does not use managed PCI. */
> > + pci_disable_device(pdev);
> > }
> >
> > static void octep_vdpa_vf_bar_shrink(struct pci_dev *pdev)
> > @@ -825,7 +828,7 @@ static int octep_vdpa_probe_pf(struct pci_dev
> > *pdev)
> > struct octep_pf *octpf;
> > int ret;
> >
> > - ret = pcim_enable_device(pdev);
> > + ret = pci_enable_device(pdev);
> > if (ret) {
> > dev_err(dev, "Failed to enable device\n");
> > return ret;
> > @@ -834,15 +837,17 @@ static int octep_vdpa_probe_pf(struct pci_dev
> > *pdev)
> > ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> > if (ret) {
> > dev_err(dev, "No usable DMA configuration\n");
> > - return ret;
> > + goto disable_pci;
> > }
> > octpf = devm_kzalloc(dev, sizeof(*octpf), GFP_KERNEL);
> > - if (!octpf)
> > - return -ENOMEM;
> > + if (!octpf) {
> > + ret = -ENOMEM;
> > + goto disable_pci;
> > + }
> >
> > ret = octep_iomap_region(pdev, octpf->base,
> > OCTEP_HW_MBOX_BAR);
> > if (ret)
> > - return ret;
> > + goto disable_pci;
> >
> > pci_set_master(pdev);
> > pci_set_drvdata(pdev, octpf);
> > @@ -856,6 +861,8 @@ static int octep_vdpa_probe_pf(struct pci_dev
> > *pdev)
> >
> > unmap_region:
> > octep_iounmap_region(pdev, octpf->base, OCTEP_HW_MBOX_BAR);
> > +disable_pci:
> > + pci_disable_device(pdev);
> > return ret;
> > }
> >
prev parent reply other threads:[~2025-05-15 11:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 8:51 [PATCH v4] vdpa/octeon_ep: Control PCI dev enabling manually Philipp Stanner
2025-05-15 7:14 ` Philipp Stanner
2025-05-15 11:28 ` Michael S. Tsirkin [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=20250515072724-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=dan.carpenter@linaro.org \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phasta@kernel.org \
--cc=schalla@marvell.com \
--cc=skoteshwar@marvell.com \
--cc=sthotton@marvell.com \
--cc=vattunuru@marvell.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.