All of lore.kernel.org
 help / color / mirror / Atom feed
From: dmukhin@ford.com
To: Teddy Astie <teddy.astie@vates.tech>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>
Subject: Re: [PATCH 1/5] pci: Introduce parse_pci_sbdf{_seg}()
Date: Wed, 20 May 2026 18:32:21 -0700	[thread overview]
Message-ID: <ag5gpWNFGHg79gay@kraken> (raw)
In-Reply-To: <1779271208.8631fc262581453bbf619ec5b2062170.19e44d40e68000f373@vates.tech>

On Wed, May 20, 2026 at 12:00:07PM +0200, Teddy Astie wrote:
> Le 20/05/2026 à 04:43, dmukhin@ford.com a écrit :
> > On Mon, May 18, 2026 at 05:21:25PM +0200, Teddy Astie wrote:
> > > In many places, we're parsing a PCI string into individual parts
> > > (seg, bus, dev, fn) and then transform it into a pci_sbdf_t using PCI_SBDF
> > > macro. Rather than converting from parts to pci_sbdf_t and vice versa,
> > > introduce a new function that parses a PCI string into a pci_sbdf_t structure
> > > directly.
> > > 
> > > Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> > > ---
> > >   xen/drivers/pci/pci.c | 18 ++++++++++++++++++
> > >   xen/include/xen/pci.h |  3 +++
> > >   2 files changed, 21 insertions(+)
> > > 
> > > diff --git a/xen/drivers/pci/pci.c b/xen/drivers/pci/pci.c
> > > index 084be3880c..1d06cb035b 100644
> > > --- a/xen/drivers/pci/pci.c
> > > +++ b/xen/drivers/pci/pci.c
> > > @@ -202,3 +202,21 @@ const char *__init parse_pci_seg(const char *s, unsigned int *seg_p,
> > >       return s;
> > >   }
> > > +
> > > +const char *parse_pci_sbdf(const char *s, pci_sbdf_t *sbdf)
> > > +{
> > > +    unsigned int seg, bus, dev, func;
> > > +    const char *out = parse_pci(s, &seg, &bus, &dev, &func);
> > 
> > IMO, both parse_pci() and parse_pci_seg() should be merged into
> > parse_pci_sbdf() and parse_pci_sbdf_seg() at the end of the series,
> > since there will be no remaining consumers of the old APIs.
> > 
> > What do you think?
> > 
> 
> That was my plan, but parse_phantom_dev() (in xen/drivers/passthrough/pci.c)
> wants to parse the PCI string without the function part (i.e XXXX:YY:ZZ)
> which can't be expressed with a full SBDF parse function.

I see.
Perhaps adding "SBD" parsing in-place in parse_phantom_dev() is OK?
Like duplicate a small amount of code but drop old APIs.

> 
> It currently works by passing NULL to `func_p`, which has special handling
> in parse_pci.
> 
> We could eventually allow omitting PCI function and make default it to zero,
> so that we will be able migrate parse_phantom_dev to this new function (so
> it now allows parsing full SBDF, but ignore the function part of it).
> 


  reply	other threads:[~2026-05-21  1:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1779116255.git.teddy.astie@vates.tech>
2026-05-18 15:21 ` [PATCH 1/5] pci: Introduce parse_pci_sbdf{_seg}() Teddy Astie
2026-05-20  2:39   ` dmukhin
2026-05-20 10:00     ` Teddy Astie
2026-05-21  1:32       ` dmukhin [this message]
2026-05-18 15:21 ` [PATCH 2/5] vtd: Use pci_sbdf_t in acpi_parse_dev_scope() Teddy Astie
2026-05-20  3:00   ` dmukhin
2026-05-20  3:23     ` dmukhin
2026-05-20  6:32       ` Jan Beulich
2026-05-20 10:08     ` Teddy Astie
2026-05-18 15:21 ` [PATCH 3/5] pci: Use pci_sbdf_t in pci_device_detect() Teddy Astie
2026-05-20  3:21   ` dmukhin
2026-05-20  6:37     ` Jan Beulich
2026-05-18 15:21 ` [PATCH 4/5] pci: Parse into pci_sbdf_t directly Teddy Astie
2026-05-20  3:31   ` dmukhin
2026-05-18 15:21 ` [PATCH 5/5] RFC: pci: Migrate pci_mmcfg_{read,write} to pci.c Teddy Astie
2026-05-18 17:35   ` Andrew Cooper
2026-05-19  6:02     ` Jan Beulich
2026-05-19 17:15       ` Andrew Cooper
2026-05-19 13:42     ` Teddy Astie
2026-05-18 17:20 ` [PATCH 0/5] Small PCI refactoring Teddy Astie
2026-05-19 17:41   ` Andrew Cooper
2026-05-20  6:30     ` Jan Beulich
2026-05-20  3:34   ` dmukhin

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=ag5gpWNFGHg79gay@kraken \
    --to=dmukhin@ford.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=teddy.astie@vates.tech \
    --cc=xen-devel@lists.xenproject.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 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.