From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FAKE_REPLY_C,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 760E8C43331 for ; Tue, 31 Mar 2020 22:00:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3ACF820842 for ; Tue, 31 Mar 2020 22:00:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585692010; bh=uFEXfr40AqoZXAxCEJwdvVfv+OabBqG3OZjMDRScCaQ=; h=Date:From:To:Cc:Subject:In-Reply-To:List-ID:From; b=fObRitiwdeRtjLy5/iVJpw5pIpRvmC03ZG7hLA1ItA7OiRoUXy3snMVX0KTgivHq8 bQI8JI0Ol/hbJErZbnBIJ69Y6v1d7m44VJ+ytIMTHpjCciIZKxChiu9ycVH47lMKr7 46ts8IXZ35QaZYWR9dYoRbhkvU4tC/JGloCA1//U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731319AbgCaWAJ (ORCPT ); Tue, 31 Mar 2020 18:00:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:50748 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730589AbgCaWAJ (ORCPT ); Tue, 31 Mar 2020 18:00:09 -0400 Received: from localhost (mobile-166-175-186-165.mycingular.net [166.175.186.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7C49E2080C; Tue, 31 Mar 2020 22:00:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585692009; bh=uFEXfr40AqoZXAxCEJwdvVfv+OabBqG3OZjMDRScCaQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=vzrV6sPZ7Ml571IhMEX3RIQ4QoKtnw5U+ou6jXlEpDBlmYIn++dHrH1UzlXqf8US2 JRBcYAuOthBeXYNqjpqW2GWHaDbntt4itk83r9fGLcXGv0WxTOlNXY1pidG/SCgPJJ x9vXF1do6BeUn9+xDOyxvX5jIrWCrITmJ/+T+yAg= Date: Tue, 31 Mar 2020 17:00:06 -0500 From: Bjorn Helgaas To: Dave Jiang Cc: vkoul@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, gregkh@linuxfoundation.org, arnd@arndb.de, linux-kernel@vger.kernel.org, x86@kernel.org, dmaengine@vger.kernel.org, dan.j.williams@intel.com, ashok.raj@intel.com, fenghua.yu@intel.com, linux-pci@vger.kernel.org, tony.luck@intel.com, jing.lin@intel.com, sanjay.k.kumar@intel.com Subject: Re: [PATCH 2/6] device/pci: add cmdmem cap to pci_dev Message-ID: <20200331220006.GA37376@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Tue, Mar 31, 2020 at 10:59:44AM -0700, Dave Jiang wrote: > On 3/31/2020 9:03 AM, Bjorn Helgaas wrote: > > On Mon, Mar 30, 2020 at 02:27:00PM -0700, Dave Jiang wrote: > > > Since the current accelerator devices do not have standard PCIe capability > > > enumeration for accepting ENQCMDS yet, for now an attribute of pdev->cmdmem has > > > been added to struct pci_dev. Currently a PCI quirk must be used for the > > > devices that have such cap until the PCI cap is standardized. Add a helper > > > function to provide the check if a device supports the cmdmem capability. > > > > > > Such capability is expected to be added to PCIe device cap enumeration in > > > the future. > > This needs some sort of thumbnail description of what "synchronous > > write notification" and "cmdmem" mean. > > I will add more explanation. > > > Do you have a pointer to a PCI-SIG ECR or similar? > > Deferrable Memory Write (DMWr) ECR > > https://members.pcisig.com/wg/PCI-SIG/document/13747 > > From what I'm told it should be available for public review by EOW. Please use terminology from the spec instead of things like "synchronous write notification". AIUI, ENQCMDS is an x86 instruction. That would have no meaning in the PCIe domain. I'm not committing to acking any part of this before the ECR is accepted, but if you're adding support for the feature described by the ECR, you might as well add support for discovering the DMWr capability via Device Capabilities 2 as described in the ECR. If you have hardware that supports DMWr but doesn't advertise it via Device Capabilities 2, you can always have a quirk that works around that lack.