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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F1D4FC2D0F2 for ; Thu, 2 Apr 2020 02:21:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C6B822072E for ; Thu, 2 Apr 2020 02:21:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="fKlJIQaa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732498AbgDBCVM (ORCPT ); Wed, 1 Apr 2020 22:21:12 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:44950 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732664AbgDBCVM (ORCPT ); Wed, 1 Apr 2020 22:21:12 -0400 Received: by mail-ed1-f67.google.com with SMTP id i16so2261793edy.11 for ; Wed, 01 Apr 2020 19:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1M7OKSUxjChEcoYNZEaRS2w/Ep5Pr9E1TfTyAyCSCGU=; b=fKlJIQaa53eGN4Fy8VcYUy2a7XjrwmByQurko1/ikVYzWFoz/xwrPeVDsSf75GRHNb 29jlaC2ZDgSU9LJNvdMKB2kqVdFMrpnwMZFTKVBFD0Q0IH+V60MrGYiSLW6wns572Moy 3r8nX5Vf0MvcNdCoe9xvYjC9IHbGlkESNk9f03WyB4aU/VG0I2Q1raTqiD8iFz2q1BK2 h23PBhxaU5/ij1/ndAfqXEZepXeK5tLctgdeE4W5Gzab9mcgnE8lC2HOge7jRFDvN8p9 FachXdeFSlB+iofoxgQfzaORIvhx6yVpZflU+kgmz6DsHLDYWrct1S2aAcni+Qie0rNI Znyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1M7OKSUxjChEcoYNZEaRS2w/Ep5Pr9E1TfTyAyCSCGU=; b=tZkwpM1pyQ4KMHwuNgOx6R+8OlGYAIpEj0yqZ/j4S9S00qq5T7+WTrFUlVLJ8UZul0 hAIfmNpYLmVsMUAvyjAmATaaIvqqbPV2iZrGvmneBGeQyD4OWpjIRDHpjRQbb8tJfM0R z8HDAAeRzjbRju99ryN+l9r8Yv5BV0gRfyfFGbq+Glt5l3oFa++15I/ZFKIokHNIJJ51 ooY/h50HmEWHwGh/rP5HIhcQAbmOq/IRMbe2HKEZ71JUOeyasr1nzQdyHNWgvtAZgTUs unyteLK/Dmk1J3ZNQd/gy7DAPA0097j1olivEV91nRIQKSaL3MG20yh4MLz1tSb5kOwH Od1g== X-Gm-Message-State: AGi0PuZ2Rpy1yHdFl5j9oPdQrjt9QdVCotIgl2CglfCBwhNSV6lgt63f RkFsvlxZEYjPHvlObHxlOZWDS9x9mcw8C1Jw9m2RmQ== X-Google-Smtp-Source: APiQypLfWzzdPhYu8JstE8xaJceriFzU0asNEFuyamP/TyOhBMVKn0U8IqjgkCH+xJCJO/KoFgheuGPAIuQ9Y/y0nk8= X-Received: by 2002:aa7:c609:: with SMTP id h9mr755033edq.93.1585794070492; Wed, 01 Apr 2020 19:21:10 -0700 (PDT) MIME-Version: 1.0 References: <158560290392.6059.16921214463585182874.stgit@djiang5-desk3.ch.intel.com> <158560362665.6059.11999047251277108233.stgit@djiang5-desk3.ch.intel.com> <20200401071851.GA31076@infradead.org> In-Reply-To: <20200401071851.GA31076@infradead.org> From: Dan Williams Date: Wed, 1 Apr 2020 19:20:59 -0700 Message-ID: Subject: Re: [PATCH 3/6] pci: add PCI quirk cmdmem fixup for Intel DSA device To: Christoph Hellwig Cc: Dave Jiang , Vinod Koul , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Bjorn Helgaas , Greg KH , Arnd Bergmann , Linux Kernel Mailing List , X86 ML , dmaengine@vger.kernel.org, "Raj, Ashok" , Fenghua Yu , linux-pci@vger.kernel.org, "Luck, Tony" , Jing Lin , Sanjay K Kumar Content-Type: text/plain; charset="UTF-8" Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Apr 1, 2020 at 12:19 AM Christoph Hellwig wrote: > > On Mon, Mar 30, 2020 at 02:27:06PM -0700, Dave Jiang wrote: > > Since there is no standard way that defines a PCI device that receives > > descriptors or commands with synchronous write operations, add quirk to set > > cmdmem for the Intel accelerator device that supports it. > > Why do we need a quirk for this? Even assuming a flag is needed in > struct pci_dev (and I don't really understand why that is needed to > start with), it could be set in ->probe. The consideration in my mind is whether this new memory type and instruction combination warrants a new __attribute__((noderef, address_space(X))) separate from __iomem. If it stays a single device concept layered on __iomem then yes, I agree it can all live locally in the driver. However, when / if this facility becomes wider spread, as the PCI ECR in question is trending, it might warrant general annotation. The enqcmds instruction does not operate on typical x86 mmio addresses, only these special device portals offer the ability to have non-posted writes with immediate results in the cpu condition code flags.