Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@meta.com>,
	linux-nvme@lists.infradead.org, sagi@grimberg.me
Subject: Re: [PATCH] nvme: simplify request ready check for pci
Date: Tue, 11 Mar 2025 08:53:02 +0100	[thread overview]
Message-ID: <20250311075302.GA14844@lst.de> (raw)
In-Reply-To: <Z87-43riMPw3jWqU@kbusch-mbp>

On Mon, Mar 10, 2025 at 09:01:55AM -0600, Keith Busch wrote:
> On Mon, Mar 10, 2025 at 02:24:48PM +0100, Christoph Hellwig wrote:
> > On Fri, Mar 07, 2025 at 03:26:55PM -0800, Keith Busch wrote:
> > > From: Keith Busch <kbusch@kernel.org>
> > > 
> > > The criteria for pci transports' request ready check is simpler than
> > > fabrics. Move the pci check to a different function. This also makes the
> > > existing ready check simpler since it doesn't need to repeatedly test if
> > > the controller is a fabrics type.
> > 
> > The change looks good, but now that this is split, the PCI version
> > should move to pci.c, and the fabrics version should move to fabrics.c
> > and into the nvmf_* namespace.
> 
> I don't think we can move it to pci.c. The apple device isn't fabrics
> either, but is built without the pci.c module, so needs to be in a
> header or common core.

Indeed, Apple messes this up a bit.  But that also means the _pci namespace
is wrong.  It's about all memory transport including the (unspecified)
apple one.  So either rename it to something reflecting that, or just
duplicate it in apple.c as we'd done with a few similar things.


      reply	other threads:[~2025-03-11  8:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 23:26 [PATCH] nvme: simplify request ready check for pci Keith Busch
2025-03-10 13:24 ` Christoph Hellwig
2025-03-10 15:01   ` Keith Busch
2025-03-11  7:53     ` Christoph Hellwig [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=20250311075302.GA14844@lst.de \
    --to=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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