Re: [PATCH v3] nvme: retain split access workaround for capability reads

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Christoph Hellwig <hch@lst.de>
Cc: axboe@fb.com, Keith Busch <kbusch@kernel.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	sagi@grimberg.me, linux-nvme@lists.infradead.org
Subject: Re: [PATCH v3] nvme: retain split access workaround for capability reads
Date: Mon, 7 Oct 2019 14:32:43 +0200	[thread overview]
Message-ID: <CAKv+Gu8cyR6Wcp4bSy4iDs0ALfzvOBwNmqx-_SbiPwwSGSFZVA@mail.gmail.com> (raw)
In-Reply-To: <20191007122738.GA24804@lst.de>

On Mon, 7 Oct 2019 at 14:27, Christoph Hellwig <hch@lst.de> wrote:
>
> 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.

OK, that is good to know. Mind you, I used 'interconnect' in the
abstract sense, meaning whatever sits between the CPU doing the read
and the 64-bit register in the BAR space.

But I fail to see your point. Why is it relevant for deciding whether
to apply a NVMe fix if the affected hardware can or cannot use other
types of PCIe devices? Note that I am not proposing some hacky
workaround to be applied, but just to stick with the workaround that
was already accepted (and I'm pretty sure that this Apple hardware got
broken too with commit 7fd8930f26be4)

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme