Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp395758pxk; Thu, 24 Sep 2020 08:11:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0/tBga8x1S++h859Kl+qtRf4uV+ibOFmsBHNDD1hMfEZi2ToxcQfEZZ5Sku7QVZ10JnfG X-Received: by 2002:a17:906:270f:: with SMTP id z15mr394489ejc.6.1600960302220; Thu, 24 Sep 2020 08:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600960302; cv=none; d=google.com; s=arc-20160816; b=w3v9DUSx3E6xZRC7EQniLOH6EJC8onobBBp+XZxEHNwsiqY5XC7n+sXrDMiSUcu0W1 OIQIV04VZ3qeHxxmgnyZPiZyhfHxP5I7gBW59zyRXHgTbJh1cYmHhftgNImT1tsbuG6z /tkaipLDfiZOGz42y4ocXYwssw1XWgGX2zse2CpyUIBlfXSPT1bbaEv+shU2vKSZ10gb 5xRZSLB7xW7ZwraY9FbuMlftS43lm0/11vKCwpFexhrEYiNKbXYgMNeUiuAvHzyReyO/ SdnMkVMEVr3AT27MFmvDaUd5Phql3giCd+VNrrSUoyDPruE3T0bharXFSLCAAC1/4hdb zJWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=lxvxvDh7et7IVobCtrz56Q52iGZbqlrTQM/CVng6X4Q=; b=m5POSyCdTyD8+q6OHl1Bj6UySeP/38aJ+6ofotrxMCeW1hR7qxoDSlkC2p7Gv73BdQ +To0v2K6qJ09YyvqC6LIitw1HbJGTiBszYREde7DpQR7LHikH8BlQSZmOt0oenty1G4m 5HhbYuNCgbHf1rDELik3SqQJFglaulCS1WiQoxefIDQ95VYvznSYE8m97DYOpCEe6Tjg 2OTttUXMfXpfCOK6P1PJTNAKFQVUU4Sw3YCxEVBOhQR4mHSr2it0S78j191mSSfFlBgO iOUrep2T2xkU9v2ZYmOeDzHAh3h2f2vTdXjxRqlqOt7VVHZEQWHqK71puBm7qvA+jnTP kDgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=S8PYFnSl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x26si2289681edi.79.2020.09.24.08.11.18; Thu, 24 Sep 2020 08:11:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=S8PYFnSl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728371AbgIXPKF (ORCPT + 99 others); Thu, 24 Sep 2020 11:10:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:41364 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728164AbgIXPKF (ORCPT ); Thu, 24 Sep 2020 11:10:05 -0400 Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 903BB2395C; Thu, 24 Sep 2020 15:10:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600960204; bh=lxvxvDh7et7IVobCtrz56Q52iGZbqlrTQM/CVng6X4Q=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=S8PYFnSlulVSQNvZcbzgPlSAE3e6XvCAP/gXbWv/l6OTrHmsZV1vd2R8tCTL1pjME jvYzHyJ+uHF6/3wHCcdtUmZVY4KOgfT8luYMfc1bQa+gLc9/apj8dRpTGZ38oXl5Mc BhNaM4Lk+oHu3z0ROTx/ertbLsY8t/IWycVbYems= Received: by mail-ot1-f48.google.com with SMTP id h17so3501956otr.1; Thu, 24 Sep 2020 08:10:04 -0700 (PDT) X-Gm-Message-State: AOAM5310hQzJeXzYBW46KuiwPwIqw8ZBw3sP0nn0xjPEENJTuvZ14W60 FNTfxGy2qxTZHGcBtnOk/qi5PGR31YAOPLONCw== X-Received: by 2002:a9d:6ada:: with SMTP id m26mr93595otq.192.1600960203773; Thu, 24 Sep 2020 08:10:03 -0700 (PDT) MIME-Version: 1.0 References: <20200923142607.10c89bd2@xhacker.debian> In-Reply-To: From: Rob Herring Date: Thu, 24 Sep 2020 09:09:51 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] PCI: dwc: Move allocate and map page for msi out of dw_pcie_msi_init() To: Ard Biesheuvel Cc: Jisheng Zhang , Kishon Vijay Abraham I , Lorenzo Pieralisi , Bjorn Helgaas , Jingoo Han , Gustavo Pimentel , Thierry Reding , Vidya Sagar , PCI , linux-omap , Linux Kernel Mailing List , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 8:33 AM Ard Biesheuvel wrote: > > On Thu, 24 Sep 2020 at 15:45, Ard Biesheuvel wrote: > > > > On Thu, 24 Sep 2020 at 15:28, Rob Herring wrote: > > > > > > On Thu, Sep 24, 2020 at 5:00 AM Ard Biesheuvel wrote: > > > > > > > > On Wed, 23 Sep 2020 at 08:28, Jisheng Zhang wrote: > > > > > > > > > > Currently, dw_pcie_msi_init() allocates and maps page for msi, then > > > > > program the PCIE_MSI_ADDR_LO and PCIE_MSI_ADDR_HI. The Root Complex > > > > > may lose power during suspend-to-RAM, so when we resume, we want to > > > > > redo the latter but not the former. If designware based driver (for > > > > > example, pcie-tegra194.c) calls dw_pcie_msi_init() in resume path, the > > > > > previous msi page will be leaked. > > > > > > > > > > Move the allocate and map msi page from dw_pcie_msi_init() to > > > > > dw_pcie_host_init() to fix this problem. > > > > > > > > > > Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") > > > > > Signed-off-by: Jisheng Zhang > > > > > > > > Why do you allocate a page for this in the first place? Isn't > > > > PCIE_MSI_ADDR_HI:PCIE_MSI_ADDR_LO simply a magic DMA address that > > > > never gets forwarded across to the CPU side of the host bridge, and > > > > triggers a SPI instead, which gets handled by reading > > > > PCIE_MSI_INTR0_STATUS ? > > > > > > My question too after digging into this some more. I've asked the > > > question on the thread that further complicated all this changing from > > > virt_to_phys() to dma_map_page()[1]. > > > > > > > Couldn't you just map the zero page instead? > > > > > > Why a page even? You could use PCIE_MSI_ADDR_LO address itself even. > > > Or just an address in the driver data which is what some other drivers > > > do. > > > > > > > PCIE_MSI_ADDR_LO itself could collide with an actual DRAM address if > > any translation is applied on inbound transactions. Using an actual > > DRAM address avoids that. Good point, and the inbound windows could be less than all DRAM if there's any restrictions. However, the DWC doesn't do any inbound setup (at least for platforms with iATU), so I guess the default is all traffic is forwarded. > ... although the MSI doorbell register on the GIC, for instance, needs > to be DMA addressable as well, of course. There's at least one DWC driver that has its own doorbell register too. I suppose there's a way for the host driver to retrieve the GIC address if configuration is needed. Doesn't seem to be needed on DWC given the above. Rob