Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1120291pxf; Fri, 12 Mar 2021 02:22:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJzfgBeOK8sBLzTbmT6v/a80lxbZgoUnQocQJlLQfx5uYVJw2Xh/FslHWWf9ipOdXbVwHLZD X-Received: by 2002:a05:6402:2d0:: with SMTP id b16mr13489682edx.194.1615544522193; Fri, 12 Mar 2021 02:22:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615544522; cv=none; d=google.com; s=arc-20160816; b=QN5tZylI6bxkX4m8BADtKeBy2eJkj50uWgLh8dbldx1NOWOQnZmpzCjuHSHyOfrIww hpr1YV1tKHOwcmZOcvkL58InZ9qb6TeonX3xXU1giC9IcxWsVWbMqKqUS6AstxeWtUaa ba0Nj1bR24+wbV/Xp1K/zCwAgj9oDQZsDpMz9y2orBKge3DTpeVnhkxLqSC7TSL54acj IBC+Xq/sExQA7oos9kuWbSuWHuOILpi7mZaDyXabYgfZVRsqlliYqNQwL7lMyeoqzejp pY257ApUTRWY36u/ruCnq2jpawmTUoBtOHOqzF7lxMttH+7eSDPivgLVg0nUE2xyXoIP US1Q== 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=uNg49TjKE8cr/90BzQ+ezmq2SHozWLVxcyxSBXiK69o=; b=isazJCOuQaJTnDX/TaszAnfN/65ZoxtVql/2xe/6WxnN17m43QvzSM76d37uk+zAUk YfbZcuShe0o5v5Z1vwSMZuunb81hE7UE6xqC4sgAMvyYfFcrhWTd8gTHW1vF6xVrxGo+ RAInwLSVtk8QK8lVf/xys2aE2iU6DV5cQ9QDsL88hlfBZDtGsCF92ePuoJ+9en99AEPh fNmkKaJDHREEUDjsGfro/M3Gbxr4O7TviMUr75c+df2R2I8Z189JvCPYaCJxz8QPSmjC 5IcYrigwLOnhKn8TU+unxlFZU1eNJ5DoH6dwSwRkiEdhFcTkQFg10vnftdJrv27BaJ5l 3Yww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OeFAX9kP; 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 a9si3820534ejk.421.2021.03.12.02.21.39; Fri, 12 Mar 2021 02:22:02 -0800 (PST) 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=k20201202 header.b=OeFAX9kP; 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 S233393AbhCLKUh (ORCPT + 99 others); Fri, 12 Mar 2021 05:20:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:59092 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233158AbhCLKUU (ORCPT ); Fri, 12 Mar 2021 05:20:20 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 36AA265014; Fri, 12 Mar 2021 10:20:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615544420; bh=Ifsr9yM9IkQPwSwMx+ywHOlUP37f5ulHyfp022mvO2A=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OeFAX9kP3QepFXQNlgoNBt/rCJK6ttlPb2z66g1Fm9rBpVgFrq/J8kdQjGgUsInD4 gufTH3sTe9dQr7Dv3m1+s38h6IxRmnl+E95aqXEnsDLBUvAp6tR8rtqUgKcqpjxqp2 /PLNgpAvUkhC6Nro80THrKr0uqEtcFagUQuiAA0MxjNvaSxWM5vILNol9qLy+s28F6 J+T1KgsOG6jMO3vUye9dOowxxCxt5qUUjvK/5fFSPtD4TT0Oc8cjHH1n0ypjxeC82d 7Bak7Zg5DjTXfZcRczfdSQNNgm2GdpCsxPAV6Z1gx+V3gwNXNzj3L7oBFGUwlhPO3w 6fsJIXl0X2yqA== Received: by mail-oo1-f43.google.com with SMTP id i25-20020a4aa1190000b02901bbd9429832so1042119ool.0; Fri, 12 Mar 2021 02:20:20 -0800 (PST) X-Gm-Message-State: AOAM533k97eGVayFQI6keYBO7LQKA/Fe9Aiu0lnA2lImthZVNwReb6d2 edS4zM+Glo2wjHxtQLGRnW6k0jzghbcXCLlQ/9k= X-Received: by 2002:a4a:e9a2:: with SMTP id t2mr2692533ood.15.1615544419338; Fri, 12 Mar 2021 02:20:19 -0800 (PST) MIME-Version: 1.0 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> <332c0b9a-dcfd-4c3b-9038-47cbda90eb3f@marcan.st> In-Reply-To: From: Arnd Bergmann Date: Fri, 12 Mar 2021 11:20:03 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted To: Rob Herring Cc: Hector Martin , 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" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 11, 2021 at 7:10 PM Rob Herring wrote: > > On Thu, Mar 11, 2021 at 9:48 AM Arnd Bergmann wrote: > > > > On Thu, Mar 11, 2021 at 5:10 PM Rob Herring wrote: > > > On Thu, Mar 11, 2021 at 2:12 AM Arnd Bergmann wrote: > > > > On Wed, Mar 10, 2021 at 6:01 PM Rob Herring wrote: > > > > Ok, makes sense. > > > > > > > > Conceptually, I'd like to then see a check that verifies that the > > > > property is only set for nodes whose parent also has it set, since > > > > that is how AXI defines it: A bus can wait for the ack from its > > > > child node, or it can acknowledge the write to its parent early. > > > > However, this breaks down as soon as a bus does the early ack: > > > > all its children by definition use posted writes (as seen by the > > > > CPU), even if they wait for stores that come from other masters. > > > > > > > > Does this make sense to you? > > > > > > BTW, I don't think it's clear in this thread, but the current > > > definition proposed for the spec[1] and schema is 'nonposted-mmio' is > > > specific to 'simple-bus'. I like this restriction and we can expand > > > where 'nonposted-mmio' is allowed later if needed. > > > > That sounds ok, as long as we can express everything for the mac > > at the moment. Do we need to explicitly add a description to allow > > the property in the root node in addition to simple-bus to be able > > to enforce the rule about parent buses also having it? > > IMO it should not be allowed in the root node. That's a failure to > define a bus node. My interpretation would be that the root node defines the first bus connected to the CPU(s) themselves, which may already have posted writes. If writes on that bus are posted, then no child could be non-posted. I suppose it depends a bit on the mental model of what the nodes refer to. If you say that there cannot be a device with registers directly on the root node, but every bus defines its own space, then we don't need this, but I think a lot of machines would break if you try to enforce the rule that there cannot be devices on the root node. > Also, would that mean your memory has to be non-posted!? Good question. You could argue that this should not be because you don't want to use ioremap_np() flags but instead want this to be normal cacheable memory instead of device memory. On the other hand, you definitely don't want memory stores to be posted, as that would break coherency between the CPUs when a wmb() no longer has an effect. Arnd