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=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 EEC2DC433DB for ; Fri, 5 Mar 2021 16:06:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C3AC86508D for ; Fri, 5 Mar 2021 16:06:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230211AbhCEQFt (ORCPT ); Fri, 5 Mar 2021 11:05:49 -0500 Received: from mail.kernel.org ([198.145.29.99]:58324 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231150AbhCEQFW (ORCPT ); Fri, 5 Mar 2021 11:05:22 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 45B7365092; Fri, 5 Mar 2021 16:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614960322; bh=ChyQh3jUOf3mpcLiwmUiTp3mAW4ljibFzKZwZJvYMcg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TaVWfxx4/vllC7hR6YYISHmND4Na36dmQm1N7qtCjMqLrOljM3V4QVNTIJr2Q7MzX 8Mdq1njeGpl00EUjSWfKgk5KOmIoNd0BIGbuZx6U1oQY5+7DU3KGWUeiSta1GOHZAl zw2h4zndDgOaeFsFrI+v6I6ZmRks5IiVdtT7YjuYcN/MMibqGV+QqWudpCusRoVN7J r5cf4v/UlOh/381LqQhLzLxmPZmenrTNwALp3rDJ7ju/rTDDGShcgc7RTz2M7QwwOx YxCJDPqhTkDLQEKTNEHtEKofYboTBlMvJsV99zUz6QESINCFUmHsgfFInqmtFsiDtf +KbobAmBDhlNg== Received: by mail-ej1-f46.google.com with SMTP id w1so4440407ejf.11; Fri, 05 Mar 2021 08:05:22 -0800 (PST) X-Gm-Message-State: AOAM531weEzW8sJSNcbA8txXXKYvQDTDEA+25tJjnHAgHdV9McM5OVoE ObExncvd6cKulToQG/AmAzCXCZYpCRdXU1WxVA== X-Google-Smtp-Source: ABdhPJwUc4XxP2OrKgKoWP3l/xIeHgoelPjOuT9cmvaXTMfKex+qDw3goxqSBhbjX88yTcUVjAFeGozCqyLLXTE1hAc= X-Received: by 2002:a17:906:c405:: with SMTP id u5mr2843037ejz.341.1614960320807; Fri, 05 Mar 2021 08:05:20 -0800 (PST) MIME-Version: 1.0 References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-13-marcan@marcan.st> In-Reply-To: From: Rob Herring Date: Fri, 5 Mar 2021 10:05:08 -0600 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: Andy Shevchenko Cc: Hector Martin , linux-arm Mailing List , Marc Zyngier , Arnd Bergmann , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree , "open list:SERIAL DRIVERS" , Linux Documentation List , Linux Samsung SOC , Linux-Arch , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Fri, Mar 5, 2021 at 9:13 AM Andy Shevchenko wrote: > > On Thu, Mar 4, 2021 at 11:40 PM Hector Martin wrote: > > > > This implements the 'nonposted-mmio' and 'posted-mmio' boolean > > properties. Placing these properties in a bus marks all child devices as > > requiring non-posted or posted MMIO mappings. If no such properties are > > found, the default is posted MMIO. > > > > of_mmio_is_nonposted() performs the tree walking to determine if a given > > device has requested non-posted MMIO. > > > > of_address_to_resource() uses this to set the IORESOURCE_MEM_NONPOSTED > > flag on resources that require non-posted MMIO. > > > > of_iomap() and of_io_request_and_map() then use this flag to pick the > > correct ioremap() variant. > > > > This mechanism is currently restricted to Apple ARM platforms, as an > > optimization. > > ... > > > @@ -896,7 +899,10 @@ void __iomem *of_iomap(struct device_node *np, int index) > > if (of_address_to_resource(np, index, &res)) > > return NULL; > > > > - return ioremap(res.start, resource_size(&res)); > > + if (res.flags & IORESOURCE_MEM_NONPOSTED) > > + return ioremap_np(res.start, resource_size(&res)); > > + else > > + return ioremap(res.start, resource_size(&res)); > > This doesn't sound right. Why _np is so exceptional? Why don't we have > other flavours (it also rings a bell to my previous comment that the > flag in ioresource is not in the right place)? > > ... > > > + if (res.flags & IORESOURCE_MEM_NONPOSTED) > > + mem = ioremap_np(res.start, resource_size(&res)); > > + else > > + mem = ioremap(res.start, resource_size(&res)); > > + > > Ditto. > > ... > > > + while (node) { > > + if (!of_property_read_bool(node, "ranges")) { > > + break; > > + } else if (of_property_read_bool(node, "nonposted-mmio")) { > > + of_node_put(node); > > + return true; > > + } else if (of_property_read_bool(node, "posted-mmio")) { > > + break; > > + } > > + parent = of_get_parent(node); > > + of_node_put(node); > > + node = parent; > > + } > > I believe above can be slightly optimized. Don't we have helpers to > traverse to all parents? We don't. I only found a handful of cases mostly in arch/powerpc. Given that and this series is big enough already, I don't think we need a helper as part of it. But patches welcome. Rob