From: Christoph Hellwig <hch@lst.de>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: sagi@grimberg.me, Ilias Apalodimas <ilias.apalodimas@linaro.org>,
linux-nvme@lists.infradead.org, axboe@fb.com,
Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v3] nvme: retain split access workaround for capability reads
Date: Mon, 7 Oct 2019 14:27:38 +0200 [thread overview]
Message-ID: <20191007122738.GA24804@lst.de> (raw)
In-Reply-To: <CAKv+Gu_mYpopYMCiq=TqHBkzZoRLJD_0Xi8J0GB8+sCHJSmK9A@mail.gmail.com>
On Mon, Oct 07, 2019 at 02:24:58PM +0200, Ard Biesheuvel wrote:
> > If you interconnect doesn't support 8-byte MMIO read/write TLPs you
> > have a much deeper problem, as this will break all drivers using
> > readq/writeq. And we currently only have compile time detection for
> > readq/writeq, not runtime so you'll have to invent a scheme if this
> > works at all or not.
>
> Sure. But the practical reality is that the hardware in question
> (including the Apple controller) worked perfectly fine until commit
> 7fd8930f26be4 introduced a readq() call into a file that had
> deliberately been switched to using lo_hi_readq() because readq()
> doesn't work reliably for all hardware we would like it to support.
> Theorizing about *why* readq() doesn't work reliably in which
> particular case doesn't seem that useful to me, given how trivial the
> fix is.
My point here is that if it isn't the PCIe device that is broken like
in the apple case, but your interconnect you have a problem that can't
be fixed just in the nvme driver. We have tons of other drivers relying
in readq/writeq working if it is available. You'll need to find a more
general workaround, independent of the fact that we have a few NVMe
controllers that always need this workaround. And at least for NVMe
the spec specically allows split 32-bit access at least.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2019-10-07 12:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 11:42 [PATCH v3] nvme: retain split access workaround for capability reads Ard Biesheuvel
2019-10-07 12:07 ` Christoph Hellwig
2019-10-07 12:24 ` Ard Biesheuvel
2019-10-07 12:27 ` Christoph Hellwig [this message]
2019-10-07 12:32 ` Ard Biesheuvel
2019-10-07 12:47 ` Christoph Hellwig
2019-10-07 12:48 ` Keith Busch
2019-10-07 13:20 ` Ard Biesheuvel
2019-10-07 13:32 ` Keith Busch
2019-10-07 13:33 ` Ard Biesheuvel
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=20191007122738.GA24804@lst.de \
--to=hch@lst.de \
--cc=ard.biesheuvel@linaro.org \
--cc=axboe@fb.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kbusch@kernel.org \
--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 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.