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,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 DBA45C433DB for ; Fri, 5 Mar 2021 18:20:04 +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 7717864DF4 for ; Fri, 5 Mar 2021 18:20:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7717864DF4 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:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hpj0yKMx8m/aKg8NNPdjfT66WLReStqyJljxNbxLV6s=; b=coHzMtnZkOCbqsETQCk1aHS7r G78ynR4ROYRK9x2NpJUV7SlAeveVHrtb5JzGBj69gj+lVp6SR28Mq4aw54ISkfuYFFmVv/0ifoRK5 h6Fq3YW/uYa9t9VItb4Q2St0YQeqR3L7YYPLQr2GFPlfJcAx3w1BnQ6Lrna30IicqVNdZ9DqnWRRP 1/v0GXfsKu1h2nM/Y9xsWESqE4/dWxsNktBYSQ0tTv3nWwFNuxIlaY2xuid8UR9NFLQqBZrNwNtMs pqQlWVxuQuFnjnexpZcSz7t6mlrtr1Myvr4Z5cD/Kp30/n049NfvQhCXGqWCSApU0k74UatPOILWK ZGsY4KpsQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lIF21-00Fvjs-6i; Fri, 05 Mar 2021 18:18:33 +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 1lIF1w-00Fvi2-GB for linux-arm-kernel@lists.infradead.org; Fri, 05 Mar 2021 18:18:31 +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 44CF842037; Fri, 5 Mar 2021 18:18:18 +0000 (UTC) To: Rob Herring Cc: linux-arm-kernel , Marc Zyngier , Arnd Bergmann , 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" , devicetree@vger.kernel.org, "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> From: Hector Martin Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted Message-ID: <6e4880b3-1fb6-0cbf-c1a5-7a46fd9ccf62@marcan.st> Date: Sat, 6 Mar 2021 03:18:16 +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-20210305_181828_885010_BF29BFEB X-CRM114-Status: GOOD ( 29.28 ) 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 06/03/2021 02.39, Rob Herring wrote: > I'm still a little hesitant to add these properties and having some > default. I worry about a similar situation as 'dma-coherent' where the > assumed default on non-coherent on Arm doesn't work for PowerPC which > defaults coherent. More below on this. The intent of the default here is that it matches what ioremap() does on other platforms already (where it does not make any claims of being posted, though it could be on some platforms). It could be per-platform what that means... but either way it should be what drivers get today without asking for anything special. >> - 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 and the devm variants all scream for a ioremap_extended() > function. IOW, it would be better if the ioremap flavor was a > parameter. Unless we could implement that just for arm64 first, that's > a lot of refactoring... I agree, but yeah... that's one big refactor to try to do now... > What's the code path using these functions on the M1 where we need to > return 'posted'? It's just downstream PCI mappings (PCI memory space), > right? Those would never hit these paths because they don't have a DT > node or if they do the memory space is not part of it. So can't the > check just be: > > bool of_mmio_is_nonposted(struct device_node *np) > { > return np && of_machine_is_compatible("apple,arm-platform"); > } Yes; the implementation was trying to be generic, but AIUI we don't need this on M1 because the PCI mappings don't go through this codepath, and nothing else needs posted mode. My first hack was something not too unlike this, then I was going to get rid of apple,arm-platform and just have this be a generic mechanism with the properties, but then we added the optimization to not do the lookups on other platforms, and now we're coming full circle... :-) If you prefer to handle it this way for now I can do it like this. I think we should still have the DT bindings and properties though (even if not used), as they do describe the hardware properly, and in the future we might want to use them instead of having a quirk. -- 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