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 929D6C4332B for ; Fri, 5 Mar 2021 16:51:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6D7B86508F for ; Fri, 5 Mar 2021 16:51:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230406AbhCEQvE (ORCPT ); Fri, 5 Mar 2021 11:51:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230387AbhCEQuc (ORCPT ); Fri, 5 Mar 2021 11:50:32 -0500 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63224C061574; Fri, 5 Mar 2021 08:50:30 -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)) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 5A63A42037; Fri, 5 Mar 2021 16:50:22 +0000 (UTC) Subject: Re: [RFT PATCH v3 27/27] arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree To: Mark Kettenis Cc: krzysztof.kozlowski@canonical.com, linux-arm-kernel@lists.infradead.org, maz@kernel.org, robh@kernel.org, arnd@kernel.org, olof@lixom.net, tony@atomide.com, mohamed.mediouni@caramail.com, stan@corellium.com, graf@amazon.com, will@kernel.org, linus.walleij@linaro.org, mark.rutland@arm.com, andy.shevchenko@gmail.com, gregkh@linuxfoundation.org, corbet@lwn.net, catalin.marinas@arm.com, hch@infradead.org, davem@davemloft.net, devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-28-marcan@marcan.st> <2a4c461a-51d1-60b7-b698-edb3c0bfb243@marcan.st> From: Hector Martin Message-ID: Date: Sat, 6 Mar 2021 01:50:20 +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: devicetree@vger.kernel.org On 06/03/2021 00.59, Mark Kettenis wrote: > It may be better to handle the memory reserved by the firmware using a > "/reserved-memory" node. I think the benefit of that could be that it > communicates the entire range of physical memory to the kernel, which > means it could use large mappings in the page tables. Unless the > "/reserved-memory" node defines a region that has the "no-map" > property of course. We actually need no-map, because otherwise the CPU could speculate its way into these carveouts (it's not just firmware, there's stuff in here the CPU really can't be allowed to touch, e.g. the SEP carveout). It also breaks simplefb mapping the framebuffer. I thought of the reserved-memory approach, but then figured it wouldn't buy us anything for this reason. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub