Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3938378ybi; Mon, 15 Jul 2019 01:11:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqwR60gji+K/xnGL00DdKBWIAwBj8+qNFP+VRa6WE4BsNtWIgnTO1Oz92QVqJJXYvPfCemmv X-Received: by 2002:a63:6b46:: with SMTP id g67mr25695002pgc.45.1563178280023; Mon, 15 Jul 2019 01:11:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563178280; cv=none; d=google.com; s=arc-20160816; b=P0cMzU4kvbUOaXtAomsgFDvRJZKhjw1/MPLyVCK1nII740KQxR6lBFGGs9Ag6KIQ3o e8Yl0k73tcPVHbUW3FGdzFMxVKkHEjzEcPlXuRsZ2qIpDTkwVynZkE+yJ5S/z7KRKMBq dPoboRa/aZWo86khk6Amw9tea6tkmpH8j/S1F4ZpiBV9JNvG1CrqpD53PegBnon9P2Rw 9uR+kddgag27JcB5zpAQJR56jcBgP9jr8vVYGao1xFNEe6fUqdemO/8yFsgMg4p2WJu9 GWsGAeOKsC1QLezSwcUR4uONZs6Nf085v5Qr/qO6Y83f9HBae0mzist8D1DUM9iYeSIV 0kUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=FUc4ZcD1QXF1Mk7clhqpY+iX5pQSBtLwMFfWfANOgss=; b=nToFdZqUUyk+/L3DkNjLX+foELaOJPV7NTJc/mmU34iv3rlI2HvvtBJ5eyi0heAoQd Fep7lg0TjbfrBtd5CK8aQRdbWrWVHPXzqSed8tIg0Wb+RVxdDAr0A/qoWUkb158Rio70 j0vlwH1drXRzCaelCpHMIyeDM1GuGMpiVNwVnjqPy4JyWQzQCCDJDPOW+UGVRQUpCIkw WxVgkSglND0ds5tNuAAAPQxucDSJiT1f0Dovek7rumjyS+hCWUOPcSOIA2JmAG5jP2ZE Z1OvMpSb6TDNhTIkbKxVgHaNOLpnxfJQzO+4+izOLCu7i8E11oZE2yB/BXkvfRJKJQOT eGcA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 10si7698456pgp.78.2019.07.15.01.11.03; Mon, 15 Jul 2019 01:11:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729334AbfGOIKn (ORCPT + 99 others); Mon, 15 Jul 2019 04:10:43 -0400 Received: from verein.lst.de ([213.95.11.211]:58764 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729207AbfGOIKn (ORCPT ); Mon, 15 Jul 2019 04:10:43 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 6670C68B05; Mon, 15 Jul 2019 10:10:41 +0200 (CEST) Date: Mon, 15 Jul 2019 10:10:41 +0200 From: Christoph Hellwig To: Benjamin Herrenschmidt Cc: linux-nvme@lists.infradead.org, "linux-kernel@vger.kernel.org" , Keith Busch , Jens Axboe , Christoph Hellwig , Paul Pawlowski Subject: Re: [PATCH] nvme: Add support for Apple 2018+ models Message-ID: <20190715081041.GB31791@lst.de> References: <71b009057582cd9c82cff2b45bc1af846408bcf7.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71b009057582cd9c82cff2b45bc1af846408bcf7.camel@kernel.crashing.org> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > + /* > + * Apple 2018 and latter variant has a few issues > + */ > + NVME_QUIRK_APPLE_2018 = (1 << 10), We try to have quirks for the actual issue, so this should be one quirk for the irq vectors issues, and another for the sq entry size. Note that NVMe actually has the concept of an I/O queue entry size (IOSQES in the Cc register based on values reported in the SQES field in Identify Controller. Do these controllers report anything interesting there? At the very least I'd make all the terminology based on that and then just treat the Apple controllers as a buggy implementation of that model. Btw, are there open source darwin NVMe driver that could explain this mess a little better? > @@ -504,8 +505,11 @@ static inline void nvme_write_sq_db(struct nvme_queue *nvmeq, bool write_sq) > static void nvme_submit_cmd(struct nvme_queue *nvmeq, struct nvme_command *cmd, > bool write_sq) > { > + u16 sq_actual_pos; > + > spin_lock(&nvmeq->sq_lock); > - memcpy(&nvmeq->sq_cmds[nvmeq->sq_tail], cmd, sizeof(*cmd)); > + sq_actual_pos = nvmeq->sq_tail << nvmeq->sq_extra_shift; > + memcpy(&nvmeq->sq_cmds[sq_actual_pos], cmd, sizeof(*cmd)); This is a little too magic. I think we'd better off making sq_cmds a void array and use manual indexing, at least that makes it very obvious what is going on. > - nvmeq->sq_cmds, SQ_SIZE(nvmeq->q_depth)); > + nvmeq->sq_cmds, SQ_SIZE(nvmeq)); Btw, chaning SQ_SIZE to take the queue seems like something that should be split into a prep patch, making the main change a lot smaller. > - if (!polled) > + if (!polled) { > + > + /* > + * On Apple 2018 or later implementations, only vector 0 is accepted Please fix the > 80 char line.