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 51837C433E6 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 249376508C for ; Fri, 5 Mar 2021 16:51:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231307AbhCEQvF (ORCPT ); Fri, 5 Mar 2021 11:51:05 -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: linux-kernel@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 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 75E0AC433E0 for ; Fri, 5 Mar 2021 16:52:09 +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 13FC96509A for ; Fri, 5 Mar 2021 16:52:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13FC96509A 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=Gf30ntUy0770mH55LaM26FUnH3UXSE6p2YWSKmJsdf0=; b=BY23YTGksa6aJrICzo0vRi4Td hItNpPsnC317lRGcY0szF2MA3ggafgxUwPeL0VOrEaD/L8EI1cgBSp6I6RUSBD/9Q99JmyLl5JTOp dpGiz9+ZoSEYC6QDvQS/e5p/ONC+T1/FVK2cSD0kV1XJK1VfJEhG+X5PtaNlM8ouAIrKpuczvckCR /a5kyrRZldUqPozjOU/XdmJHBXYMxe33CYzIKLfU/reeOvGgoTiI5Ay3NCWPY9R00pYWAj1y4JFf+ OAWTujrI8DgWYc/xMNWiUzS1BoBQfr+B5NyKpboQtM7MHHGkv0bSoZL3RBAUyEoMcnB6vwt6rnyIN 1KJQOF15A==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lIDev-00FgG8-Um; Fri, 05 Mar 2021 16:50:38 +0000 Received: from marcansoft.com ([212.63.210.85] helo=mail.marcansoft.com) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lIDen-00FgET-JV for linux-arm-kernel@lists.infradead.org; Fri, 05 Mar 2021 16:50:32 +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)) (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-Language: es-ES X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210305_165029_999735_75F7C1DA X-CRM114-Status: GOOD ( 13.36 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel