Re: [asahilinux:nvme/dev 13/17] drivers/nvme/host/pci.c:2249:2-3: Unneeded semicolon

From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Sven Peter <sven@svenpeter.dev>,
	linux-nvme@lists.infradead.org
Subject: Re: [asahilinux:nvme/dev 13/17] drivers/nvme/host/pci.c:2249:2-3: Unneeded semicolon
Date: Mon, 9 Aug 2021 17:53:49 +0200	[thread overview]
Message-ID: <CAK8P3a1bDeJ56uk74qWxPjyuZwaDf-0mCsH3D5bP+yXWLKLGtA@mail.gmail.com> (raw)
In-Reply-To: <YRE7vCyn9d1ClhRm@infradead.org>

On Mon, Aug 9, 2021 at 4:29 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Mon, Aug 09, 2021 at 12:02:55PM +0200, Arnd Bergmann wrote:
> > Do you have any further suggestions? Should we just duplicate
> > the driver and then simplify the platform version as much as possible
> > as you suggested above, or try to share some of the code according
> > to my original plan?
>
> Yes, please duplicate it.  The tradeoff between absolute performance
> requirements and various bits of broken consumer hardware already
> is hard enough as-is that we don't need to support apples frankenchip
> in the same codebase.
>
> Note that I suspect you can probably drop a whole lot of the duplicate
> code for the apple driver.  I doubt it supports things like CMB, HMB
> T10 protection information, shadow doorbells, SGLs, etc.

Ok, fair enough. That will probably also help adding some of the
special bits that are still not implemented. I was originally thinking
that this driver could be used with other SoCs that want to support
NVMe without having a full PCIe host, but it is quite likely that nobody
else other than Apple will ever do it this way.

> Also given that it only supports a single I/O queue there is no need
> to support read queues or poll queues or any kind of queue mapping.

This one seems possible to get added in the future. Also the HMB
support, since Apple currently has their own non-standard way
of doing the same thing from their firmware, using a boot-time memory
carve-out. But since the code is already there for the PCIe version,
I suppose that could both be added back in the future.

> Also can one of you look how PRPs are actually used by MacOS?  Given
> that this device always seems to be behind a IOMMU creating one entry
> per page seems rather weird given that the apple_nvmmu_tcb structure
> already contains the full length.  Maybe it actually ignores all but
> the first PRP?

I'll leave this up to Sven to answer. He also wrote the iommu driver,
so he probably has a good idea of what is going on here already.

      Arnd

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