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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4C1D5ECAAA1 for ; Tue, 6 Sep 2022 11:59:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc: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=AC5dzMFP+A0J5mpGVi1bkgjPttWhRUOP8S+q15adqg0=; b=V4/E4l1gNrEtA5 32BlnTnVvfa+J95jaL5qbno9V8R8pKT6hYDF9bZQrAC7KaZ3d5s4LNH6fW1QImhoagxE3bQ1OCdAZ GV+cj7HMXI97bP81JpBwHIZyo2E2yzPEMmhhoXqG3JQoTqAr0AI9o7os7gWxtQz5zw9fCvBQMV2Ct plJNeUqOyXs39mhAOdFaON23gS2TvvrK/GP3WLnuwqIL8NFrbFaqUHUbBrnHxxLjfjExjUza+Zd0G sqMub4zyv2SI0VRUwWzDYSHG5pdX4aO1Q1pKc/zCKJUDCISNd2NiMhDAeOdun/uWyWCdRuLbOxlEL XHZ6UDG8G6fKBSR/jlog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVXDD-00D51j-CE; Tue, 06 Sep 2022 11:57:51 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVXD6-00D4yM-KP for linux-arm-kernel@lists.infradead.org; Tue, 06 Sep 2022 11:57:47 +0000 Received: by mail-ej1-x632.google.com with SMTP id gb36so22605330ejc.10 for ; Tue, 06 Sep 2022 04:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=/+p0wzFj/upkv9e1wiwyvWP1+FT9YhrV1TfR4whLT7A=; b=WPj6KNJpdx4ESLURazeomIr7jVFWSOZYDwnp3ZjB0SezHdvdUickHDnsxSGgA1VqWQ 8dPftpgpnFr0XB7Uj16cBasmDTHGwe90H2XfLCV+/YSo/dw2p/nor0fgixin+8kYnZXK JT/Z7GeeUEQQ8NWrZwRggD8Z29+Vdgn/gLLRUymV5grVbEw6K28FPJvrK2m3H+1DUryi Oyg7bID4CxSu9YFBMP1oY0EgjCATJNnD0t0NGgpxrM9Rh9ZUVnT50THlikeVppp+Z4td V2Sjn7ZMjpFBkJE54SuXF3VauV8IUQCo70wMpvTtZKdKRcEKoyVa210h0zM8GDnCvJ19 L+qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=/+p0wzFj/upkv9e1wiwyvWP1+FT9YhrV1TfR4whLT7A=; b=pV0me7PzdqbVuqlZESvEqyos8SbpnLC4mjSjf1xX6BIE3RNv7KNZpK4YRCxmIvEJ54 cgq9sHvoD/IHnu9aPPeOa1u2984dInUHqXlVLzHfHVwUSgNl4uE97Ju50Hv1qX7vDeGW scmhLUMtev2AY3Ku4VKAI4yekWuVjMpqx7iAGu7JHDOzE7w+OdyMCZAEyPDNw3OD0bbx b6UhiEpfFwAOMzQOS+2JDwrlRj0/sPIjV29ye3j2eq5w+obCiLqF5/8xUcckz7MTGD3w W72rz6QGugnEsh+sihaMx27dLB5NPjfkkXiRKnKKfKzpLzZcBpK+W+eYdWb/8osHtg7S zI4w== X-Gm-Message-State: ACgBeo1WCTbShSYWEkDrvKwAJIQmP8b6fIXQ6My2bo8Fn5nB9p3Ic7o7 QIGl/YV+HXi9BgJJGFnWSaWC1o69k2K4fDuGlkw8Ng== X-Google-Smtp-Source: AA6agR4l1xB762o3DaSOS5+KZCpE8WDptXDx0mKu9slBlWSXdcqJncsF4brvN7CKb06geMDtHrbRW0K/th1I6X+zY0I= X-Received: by 2002:a17:907:2707:b0:741:7c18:4e76 with SMTP id w7-20020a170907270700b007417c184e76mr27550306ejk.690.1662465462649; Tue, 06 Sep 2022 04:57:42 -0700 (PDT) MIME-Version: 1.0 References: <928ddeff-efac-920c-7bbf-dda35a942b93@linaro.org> <2fedff34-6a20-f1ce-a756-2bd8671fcd52@linaro.org> <20220902172808.GB52527-robh@kernel.org> <909bb4e7-5bd2-2903-5bba-87ae37f3448a@marcan.st> In-Reply-To: <909bb4e7-5bd2-2903-5bba-87ae37f3448a@marcan.st> From: Linus Walleij Date: Tue, 6 Sep 2022 13:57:31 +0200 Message-ID: Subject: Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller To: Hector Martin Cc: Mark Kettenis , "Russell King (Oracle)" , robh@kernel.org, krzysztof.kozlowski@linaro.org, arnd@arndb.de, lee@kernel.org, alyssa@rosenzweig.io, asahi@lists.linux.dev, brgl@bgdev.pl, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, sven@svenpeter.dev, krzysztof.kozlowski+dt@linaro.org, devicetree@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220906_045744_733671_72713E2E X-CRM114-Status: GOOD ( 31.75 ) 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-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 Tue, Sep 6, 2022 at 1:36 PM Hector Martin wrote: > On 06/09/2022 20.22, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis wrote: > > > >> Another argument for having sub-nodes is that the firmware actually > >> exposes *two* GPIO controllers. For now we only support the "master" > >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a > >> separate set of SMC "keys". We currently don't need any of the pins > >> on the "slave", so we don't expose it in the DT yet. > > > > That sounds backward, like we don't expose device X as DT node > > because $OS doesn't use it yet. DT should just expose (by nodes or > > other ways) all hardware that exist or at least all hardware we know > > about no matter what $OS is using. > > How so? The are piles and piles of unused hardware not exposed in the > DT, and piles and piles of hardware that will be used but we haven't > figured out how to do it yet, so it's not exposed. For example, we know > there are like 8 or so UARTs, but we don't define them in the DT because > they are not connected to anything on any existing device and we don't > need them. Apple does the same thing in their DTs (only used hardware is > defined). > > I don't really see the point of exposing a GPIO controller when we don't > actually do anything with the pins yet, and might never do so. Having > drivers bind and stay unused just increases the amount of code running > without any ultimate purpose, so why do it? It's not like any other OS > would use the hardware either - GPIOs are only useful if they are > referenced in the DT for something, and we don't have anything that > would reference these. This comes from the FDT background in OpenFirmware, and there is definitely a timeline perspective (also called "waterfall model") in that line of thinking: a DT is written that describes the hardware and flashed into the BIOS and never changed, then the operating system is implemented at a later point. This is how e.g. the PC ACPI BIOS tables are also thinking about themselves. Of course the world does not work like that, but as a standard process DT and ACPI works with the same ambition as any such process: slowly and impersonal, like the planets, or the plants. The ambition that a DT should always remain backward compatible comes from the same historical root and reasoning. Any agile development or (heh) hardware discovers through reverse engineering will of course drive a truck through that line of thinking. Realistically, use the same approach as with everything else, I like the IETF motto "rough consensus and running code", any ambition taken too far will just stifle development. So I'd say make an honest effort to resonably describe the nodes we see will be useful in the foreseeable future. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel