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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 431B2C433E9 for ; Thu, 21 Jan 2021 17:10:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1767423A58 for ; Thu, 21 Jan 2021 17:10:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388442AbhAURKr (ORCPT ); Thu, 21 Jan 2021 12:10:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:39862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388393AbhAURKD (ORCPT ); Thu, 21 Jan 2021 12:10:03 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id CA17F23A5A for ; Thu, 21 Jan 2021 17:09:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611248963; bh=J9sLSBrU9hb4mIKGiZo00a1/NV2jBKZiWpKW1M26qj4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=StZ1hRPZlXlMl/uyJKraA4iaSYtiDV9HfiMy141VRYlyivPNw7ELfz/J+lv5Vhd9V WSo5/q0r2ga4bBvgpt1eNqQJwwcssTVrG4m/zQg9825UGIEzo8HR/OVwYvGDfJMQ8A 6CRAEJ1kItoWtInpaGMVfDXQZ2nxRr5U5jl7mO2w0oHcAmFXr9jdZXFoRLA2ZnCQ9j KBpBxRes6gUIueWdLgaos4NxB+jjKQdyzSiNdeYeY4xHQWVD3wgZrDl9lMneQshYHb 2KtVrhg8q4Ei6KDwbiaEWdZQ0Mf86hnY/EebL2GYPCnk2Pu41o9O2YQbCqhFBCH+W1 XHHY51LXU7T1Q== Received: by mail-ed1-f44.google.com with SMTP id h16so3360730edt.7 for ; Thu, 21 Jan 2021 09:09:22 -0800 (PST) X-Gm-Message-State: AOAM5301bWIAeGEZrhg1l28E4cnx6TR6+saZ3GTdAql+/78hksbu/Mw8 JevaQ77UDnizzPanFOPwdq7QoKp5aBTaHyyf6Q== X-Google-Smtp-Source: ABdhPJyJxp5MBbYxFzxkgYUIxAf0TzbC1KcTjT0BlKEd/RLbPE+2BdjNDA2uT4emWkBLvv2pQ5GRfs2aVnUqWSif1WQ= X-Received: by 2002:a05:6402:1751:: with SMTP id v17mr75464edx.289.1611248961278; Thu, 21 Jan 2021 09:09:21 -0800 (PST) MIME-Version: 1.0 References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-5-mohamed.mediouni@caramail.com> In-Reply-To: From: Rob Herring Date: Thu, 21 Jan 2021 11:09:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC To: "Hector Martin 'marcan'" Cc: Arnd Bergmann , Linus Walleij , Mark Rutland , Marc Zyngier , "linux-kernel@vger.kernel.org" , Catalin Marinas , Mohamed Mediouni , Will Deacon , Linux ARM , Stan Skowronek Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 21, 2021 at 9:31 AM Hector Martin 'marcan' wrote: > > On 21/01/2021 19.37, Arnd Bergmann wrote: > > On Thu, Jan 21, 2021 at 10:48 AM Linus Walleij wrote: > >> > >> However weird it may seem, Apple is not in the file > >> Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > Since Apple are already using both the "AAPL" and the "apple" > > prefix themselves, I have a bad feeling about reusing either of > > them for defining the devicetree.org bindings that we add to > > linux/Documentation/devicetree/bindings. The question is: if > > not "apple", what else should we use here? > > This ties into the larger question of how we should handle devicetrees > in general on these platforms. > > The two extremes are: > > 1) Have the bootloader outright convert ADT to FDT and make Linux > support the entirety of Apple's devicetree structure, or > > 2) Maintain our own devicetrees and ignore Apple's entirely > > My feeling is that 1) is a non-starter, because Linux ARM device trees > and Apple ARM device trees have seen independent evolution from the > PowerPC era, and many details are completely different. Plus conversion > is non-trivial, because the endianness is different and the format is > too ambiguous to do programmatically without complex logic. You are right it's a non-starter. Apple's DT even from PowerPC days were weird and the hardware was much simpler then. Given we're still maintaining that code I don't care to add what they've evolved on their own over the last 15 years and support it for the next 20+ years (given folks notice when we break 1998 era Macs). > On the other hand, cranking out devicetrees by hand for every device > variant that Apple puts out is a waste of time. > > Obviously at the bare minimum the bootloader will need to move some > dynamic information from the ADT to the FDT, but that can be a very > specific set of properties (memory layout, MAC addresses, etc). > > My current thinking is that we should write offline, automated tooling > to parse, diff, and automatically convert portions of Apple devicetrees > into Linux ones. Then we can more easily maintain our own, but still > ultimately have humans decide what goes into the Linux device trees. Seems reasonable. > It's worth noting that AIUI Apple does not consider their devicetree > layout to be stable, and it may change any time. Yeah, also not something we want to support. > On M1 devices, the > devicetree is provided as part of the iBoot2 firmware bundle, which > means it changes from one macOS version to the next (this is paired with > the Darwin kernel itself, and they are upgraded as a unit). It includes > placeholder values that iBoot2 then replaces with data from NOR before > handing control over to the kernel. My goal for our long-term project > [1] is to keep up with iBoot2 updates so that we do not have to instruct > users to dig up old macOS versions. > > Quick TL;DR on how these things boot: > - Boot ROM boots > - iBoot1 (system firmware) in NOR flash which looks for a bootable OS in > internal storage (only!) in the form of an APFS container+volume and > then boots > - iBoot2 (OS loader) which loads a bunch of firmware blobs and the > devicetree off of storage, customizes it with system data from NOR, and > then loads a wrapped mach-o file containing > - A Darwin kernel, or in our case a Linux bootloader which then boots > - A standard arm64 Linux blob > > The boot ROM is ROM. iBoot1 only ever rolls forward (downgrades > impossible). iBoot2 downgrades are possible but Apple already proved > they can break this willingly or not, at least in betas (macOS 11.2 > Beta2 iBoot1 cannot boot Beta1 iBoot2). The secureboot chain goes all > the way up to the mach-o kernel load, that is the first point where we > can change boot policy to load anything we want (with user consent). > > [1] https://asahilinux.org/ > > -- > Hector Martin "marcan" (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 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=-4.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 87EDDC433DB for ; Thu, 21 Jan 2021 17:11:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 344E923A54 for ; Thu, 21 Jan 2021 17:11:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 344E923A54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2GWNuSY472K/TuJ8a8N1RVadQF4YqSUhVMe/j3kngj0=; b=SeFX3q0v7GqQHCq0BIaEfldU0 I8pBx5dRWSoIgUD9pso36oV+F4ixlj/DPB0xFo0QrUZJLbLutlQhc6AFD2xpZwrckavabX4bAD+6D 12IKY3KFsifcaetbcVCrWlKU+Bg1urF0HDyqkVb3fEhjWUJhOCxHW7z7FBHbF4FJK3j3uoLQcax5o A2YeRnECHc83I0/+FPy1dXDxOFVzBewmtNCiQ8fBP6yk3XempNoGcHMNIbhcMc/Uf44qjUFviLRAn Z2HxArYOQlmqTNqOC8W2pUry8H/GDsZEtj+a9SMvwiLiyNnsZt52Dv7SkzNcDcMCGokyZ9p9RgEvv /QTNXMCIw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2dSZ-0008W3-R3; Thu, 21 Jan 2021 17:09:27 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2dSW-0008VL-TY for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 17:09:25 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C54E223A54 for ; Thu, 21 Jan 2021 17:09:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611248963; bh=J9sLSBrU9hb4mIKGiZo00a1/NV2jBKZiWpKW1M26qj4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=StZ1hRPZlXlMl/uyJKraA4iaSYtiDV9HfiMy141VRYlyivPNw7ELfz/J+lv5Vhd9V WSo5/q0r2ga4bBvgpt1eNqQJwwcssTVrG4m/zQg9825UGIEzo8HR/OVwYvGDfJMQ8A 6CRAEJ1kItoWtInpaGMVfDXQZ2nxRr5U5jl7mO2w0oHcAmFXr9jdZXFoRLA2ZnCQ9j KBpBxRes6gUIueWdLgaos4NxB+jjKQdyzSiNdeYeY4xHQWVD3wgZrDl9lMneQshYHb 2KtVrhg8q4Ei6KDwbiaEWdZQ0Mf86hnY/EebL2GYPCnk2Pu41o9O2YQbCqhFBCH+W1 XHHY51LXU7T1Q== Received: by mail-ed1-f47.google.com with SMTP id g24so3335567edw.9 for ; Thu, 21 Jan 2021 09:09:22 -0800 (PST) X-Gm-Message-State: AOAM531OLWQeg3lS4mBSp6mdpu8iSO2GOvJN1zAM4bgyockvD6rh/T0E S/BeCVVZryu9023l2GlThacVbRfG2FRyVf21aQ== X-Google-Smtp-Source: ABdhPJyJxp5MBbYxFzxkgYUIxAf0TzbC1KcTjT0BlKEd/RLbPE+2BdjNDA2uT4emWkBLvv2pQ5GRfs2aVnUqWSif1WQ= X-Received: by 2002:a05:6402:1751:: with SMTP id v17mr75464edx.289.1611248961278; Thu, 21 Jan 2021 09:09:21 -0800 (PST) MIME-Version: 1.0 References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-5-mohamed.mediouni@caramail.com> In-Reply-To: From: Rob Herring Date: Thu, 21 Jan 2021 11:09:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC To: "Hector Martin 'marcan'" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_120925_092962_809202F6 X-CRM114-Status: GOOD ( 33.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Arnd Bergmann , Catalin Marinas , Linus Walleij , "linux-kernel@vger.kernel.org" , Marc Zyngier , Mohamed Mediouni , Will Deacon , Linux ARM , Stan Skowronek Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 21, 2021 at 9:31 AM Hector Martin 'marcan' wrote: > > On 21/01/2021 19.37, Arnd Bergmann wrote: > > On Thu, Jan 21, 2021 at 10:48 AM Linus Walleij wrote: > >> > >> However weird it may seem, Apple is not in the file > >> Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > Since Apple are already using both the "AAPL" and the "apple" > > prefix themselves, I have a bad feeling about reusing either of > > them for defining the devicetree.org bindings that we add to > > linux/Documentation/devicetree/bindings. The question is: if > > not "apple", what else should we use here? > > This ties into the larger question of how we should handle devicetrees > in general on these platforms. > > The two extremes are: > > 1) Have the bootloader outright convert ADT to FDT and make Linux > support the entirety of Apple's devicetree structure, or > > 2) Maintain our own devicetrees and ignore Apple's entirely > > My feeling is that 1) is a non-starter, because Linux ARM device trees > and Apple ARM device trees have seen independent evolution from the > PowerPC era, and many details are completely different. Plus conversion > is non-trivial, because the endianness is different and the format is > too ambiguous to do programmatically without complex logic. You are right it's a non-starter. Apple's DT even from PowerPC days were weird and the hardware was much simpler then. Given we're still maintaining that code I don't care to add what they've evolved on their own over the last 15 years and support it for the next 20+ years (given folks notice when we break 1998 era Macs). > On the other hand, cranking out devicetrees by hand for every device > variant that Apple puts out is a waste of time. > > Obviously at the bare minimum the bootloader will need to move some > dynamic information from the ADT to the FDT, but that can be a very > specific set of properties (memory layout, MAC addresses, etc). > > My current thinking is that we should write offline, automated tooling > to parse, diff, and automatically convert portions of Apple devicetrees > into Linux ones. Then we can more easily maintain our own, but still > ultimately have humans decide what goes into the Linux device trees. Seems reasonable. > It's worth noting that AIUI Apple does not consider their devicetree > layout to be stable, and it may change any time. Yeah, also not something we want to support. > On M1 devices, the > devicetree is provided as part of the iBoot2 firmware bundle, which > means it changes from one macOS version to the next (this is paired with > the Darwin kernel itself, and they are upgraded as a unit). It includes > placeholder values that iBoot2 then replaces with data from NOR before > handing control over to the kernel. My goal for our long-term project > [1] is to keep up with iBoot2 updates so that we do not have to instruct > users to dig up old macOS versions. > > Quick TL;DR on how these things boot: > - Boot ROM boots > - iBoot1 (system firmware) in NOR flash which looks for a bootable OS in > internal storage (only!) in the form of an APFS container+volume and > then boots > - iBoot2 (OS loader) which loads a bunch of firmware blobs and the > devicetree off of storage, customizes it with system data from NOR, and > then loads a wrapped mach-o file containing > - A Darwin kernel, or in our case a Linux bootloader which then boots > - A standard arm64 Linux blob > > The boot ROM is ROM. iBoot1 only ever rolls forward (downgrades > impossible). iBoot2 downgrades are possible but Apple already proved > they can break this willingly or not, at least in betas (macOS 11.2 > Beta2 iBoot1 cannot boot Beta1 iBoot2). The secureboot chain goes all > the way up to the mach-o kernel load, that is the first point where we > can change boot policy to load anything we want (with user consent). > > [1] https://asahilinux.org/ > > -- > Hector Martin "marcan" (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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel