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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 F3D9DC4332B for ; Wed, 10 Mar 2021 08:28:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D620C64FEF for ; Wed, 10 Mar 2021 08:28:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231249AbhCJI1j (ORCPT ); Wed, 10 Mar 2021 03:27:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229516AbhCJI1F (ORCPT ); Wed, 10 Mar 2021 03:27:05 -0500 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FCC2C06174A; Wed, 10 Mar 2021 00:27:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 1091B3FA1B; Wed, 10 Mar 2021 08:26:56 +0000 (UTC) Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted To: Rob Herring Cc: Arnd Bergmann , linux-arm-kernel , Marc Zyngier , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , DTML , "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , "open list:GENERIC INCLUDE/ASM HEADER FILES" , "linux-kernel@vger.kernel.org" References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-13-marcan@marcan.st> <6e4880b3-1fb6-0cbf-c1a5-7a46fd9ccf62@marcan.st> <20210308211306.GA2920998@robh.at.kernel.org> From: Hector Martin Message-ID: <332c0b9a-dcfd-4c3b-9038-47cbda90eb3f@marcan.st> Date: Wed, 10 Mar 2021 17:26:54 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/03/2021 07.06, Rob Herring wrote: >> My main concern here is that this creates an inconsistency in the device >> tree representation that only works because PCI drivers happen not to >> use these code paths. Logically, having "nonposted-mmio" above the PCI >> controller would imply that it applies to that bus too. Sure, it doesn't >> matter for Linux since it is ignored, but this creates an implicit >> exception that PCI buses always use posted modes. > > We could be stricter that "nonposted-mmio" must be in the immediate > parent. That's kind of in line with how addressing already works. > Every level has to have 'ranges' to be an MMIO address, and the > address cell size is set by the immediate parent. > >> Then if a device comes along that due to some twisted fabric logic needs >> nonposted nGnRnE mappings for PCIe (even though the actual PCIe ops will >> end up posted at the bus anyway)... how do we represent that? Declare >> that another "nonposted-mmio" on the PCIe bus means "no, really, use >> nonposted mmio for this"? > > If we're strict, yes. The PCI host bridge would have to have "nonposted-mmio". Works for me; then let's just make it non-recursive. Do you think we can get rid of the Apple-only optimization if we do this? It would mean only looking at the parent during address resolution, not recursing all the way to the top, so presumably the performance impact would be quite minimal. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub 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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 B4728C433DB for ; Wed, 10 Mar 2021 08:29:07 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 230F064F8A for ; Wed, 10 Mar 2021 08:29:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 230F064F8A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marcan.st Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kQ9xDEviX9zy3zcj1hTh7VUIxDpwoFWTjZ6Gvn6CJqI=; b=fHLn6KTNTD5rqhWq1ceKTnpiL ViiivWPOesFHJqvwIGNmFlo9iYuJ5JLd465b8EZLQiFPqRmoq/LJrn7mxyYS16ggbgnnckk7WQzaJ E6E+8onWC0PkXy/jT4wAXzO68dugiPl9HGqyaRlojzewSRdlMzDyGwEEWkX0ZDHJs1NVQ7+U1mIFD oHTFBHJe1ZvcjYjGVxuLHxhp5IABQA4DHZYXEwPTGyN3S/Ggf/1PKaQm1ameTsGfwBcqQtkQmjTyQ je1ILaH1TDoJykSrt4VLZFfOq+o3B1i9cMr1LnR3yLoBWErjrHfPWfSj69QUNPIIWtFcDAd+uVUO1 g1RWegzVg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJuBh-006ITm-1j; Wed, 10 Mar 2021 08:27:25 +0000 Received: from marcansoft.com ([2a01:298:fe:f::2] helo=mail.marcansoft.com) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJuBN-006ISC-Ow for linux-arm-kernel@lists.infradead.org; Wed, 10 Mar 2021 08:27:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 1091B3FA1B; Wed, 10 Mar 2021 08:26:56 +0000 (UTC) Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted To: Rob Herring Cc: Arnd Bergmann , linux-arm-kernel , Marc Zyngier , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , DTML , "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , "open list:GENERIC INCLUDE/ASM HEADER FILES" , "linux-kernel@vger.kernel.org" References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-13-marcan@marcan.st> <6e4880b3-1fb6-0cbf-c1a5-7a46fd9ccf62@marcan.st> <20210308211306.GA2920998@robh.at.kernel.org> From: Hector Martin Message-ID: <332c0b9a-dcfd-4c3b-9038-47cbda90eb3f@marcan.st> Date: Wed, 10 Mar 2021 17:26:54 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: es-ES X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_082706_012236_3425A445 X-CRM114-Status: GOOD ( 20.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10/03/2021 07.06, Rob Herring wrote: >> My main concern here is that this creates an inconsistency in the device >> tree representation that only works because PCI drivers happen not to >> use these code paths. Logically, having "nonposted-mmio" above the PCI >> controller would imply that it applies to that bus too. Sure, it doesn't >> matter for Linux since it is ignored, but this creates an implicit >> exception that PCI buses always use posted modes. > > We could be stricter that "nonposted-mmio" must be in the immediate > parent. That's kind of in line with how addressing already works. > Every level has to have 'ranges' to be an MMIO address, and the > address cell size is set by the immediate parent. > >> Then if a device comes along that due to some twisted fabric logic needs >> nonposted nGnRnE mappings for PCIe (even though the actual PCIe ops will >> end up posted at the bus anyway)... how do we represent that? Declare >> that another "nonposted-mmio" on the PCIe bus means "no, really, use >> nonposted mmio for this"? > > If we're strict, yes. The PCI host bridge would have to have "nonposted-mmio". Works for me; then let's just make it non-recursive. Do you think we can get rid of the Apple-only optimization if we do this? It would mean only looking at the parent during address resolution, not recursing all the way to the top, so presumably the performance impact would be quite minimal. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel