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 6B0BBECAAD5 for ; Tue, 6 Sep 2022 14:33:18 +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:In-Reply-To:Subject:From:References:Cc: To:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=f7IjZr/ts0Kfy3MR2aLD3Nw79pVTm/Vn2Ae//Xtv2fk=; b=Xs9BbTvaK5Cd9f nXKCgVrRLpBU1C15N/OPmxIsMW2vPzceEIeJWHQEdM62DcAOMSVMBzculIH/HHYG89EUCG4Q9muV1 2RXGmylzHUSf7aGaqKgxlno4rrnx2Y9dfLbzji/EklZg3xgLnL7ldh6xX1a5WyF5SzFemF1fXvFb/ byWkcy+896QiUJ7/GqxsMTMEbRI9utjZ10qozVBD1wb9OJ2ii4O/4N2bD7bHx0yW9P0AQ0pq5HpxR FtxZxlbB2VvCAkNhMk3qboC72NtGoy//3WKqqggJ35yCco8GvhispdVPFi37RZyh9nZzhaoD7Jmct G/GmYCarlyVz9EstpCfw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVZc2-00EKba-84; Tue, 06 Sep 2022 14:31:38 +0000 Received: from marcansoft.com ([212.63.210.85] helo=mail.marcansoft.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVZ1Z-00E2PJ-7u for linux-arm-kernel@lists.infradead.org; Tue, 06 Sep 2022 13:53:59 +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 D0F264195A; Tue, 6 Sep 2022 13:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=marcan.st; s=default; t=1662472433; bh=7eZyFfHV2eGca4y6uhLlwtiH1hdF6B1YQ3kNqVZg7Nc=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=qV0iUdBp+W3mMFbFHXpAoz5nmwIc8F9BZFqBHKOUJIrcv+6FhbE4R3TnCiJu4Jb2Z RPK7vDkNUdM8cWMFFOABmwCB9BD78BChO4RHY58gLuTavD3cLjsPwTepvcV7mDK81m fZMM7B4grPEoMdoDUri4UxHe03TNjlW6NBh0Rt8B3Az51MOpuAC7S+PS0+XK5OgCWb mNJfI7ri3M86n/wue5RqVTuV1Y0SNsUBW4o64zCxQed72+Try5vzsMUQIC9Wf8+kDB MpU9hbfmF2bDWgGpaaoIml0WafYz6vILPGSATlkv8iB+4mxs4ge5NBgPE8w7J8Py3D hQm90ht8+W6YQ== Message-ID: Date: Tue, 6 Sep 2022 22:53:47 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: es-ES To: "Russell King (Oracle)" Cc: Linus Walleij , Mark Kettenis , 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 References: <20220902172808.GB52527-robh@kernel.org> <909bb4e7-5bd2-2903-5bba-87ae37f3448a@marcan.st> <5b75dc7e-5337-73eb-450f-b72f479793c4@marcan.st> From: Hector Martin Subject: Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220906_065357_534181_BCA1D7CB X-CRM114-Status: GOOD ( 45.07 ) 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 06/09/2022 22.43, Russell King (Oracle) wrote: > On Tue, Sep 06, 2022 at 10:28:25PM +0900, Hector Martin wrote: >> Ultimately, we're working with a reverse engineered platform here, and >> DTs will inevitaby be incremental. But in this particular case, of >> hardware that has no known useful purpose to an OS, I don't see the >> point in gratuitously describing it. And besides, the way we set things >> up, forward-compatible DT upgrades are trivial, and no actual user on >> this platform is going to be stuck with an old DT and newer software (if >> their software supports the platform properly, and that takes more than >> the relatively trivial DT upgrade stuff anyway). I'm a lot more >> interested in getting bindings upstreamed ASAP (so we can start >> guaranteeing no backwards-compat breaks, which is important to avoid >> outright breakage) than I am in trying to be exhaustive up front with >> device instances. It's perfectly fine to say that users have to upgrade >> both their DTs and kernels to get newer hardware support, on these >> platforms. > > It's also a very common process for SoCs - almost no one writes the > DT first and then writes the drivers. You always see on the mailing > list series of patches that add a driver for some bit of hardware, > along with patches adding the DT binding and the DT description. > > I don't think you're doing anything different here to what is common > practice within the mainline kernel community with this approach. > > The exception to that is when adding a driver for feature X in a SoC, > it's common to add all instances of X to the dtsi with ``status = > "disabled"'' and only enable the appropriate blocks on platforms that > need it. > > So, for example, if a SoC has three network interfaces, all of them > identical, when adding a network driver and the bindings for the > network hardware, one would add all three to the SoC description > whether or not the platform one was working with makes use of them. Right, and that makes sense for SoCs that third parties can incorporate into any arbitrary platform, and which have documentation listing those instances, because then board-level DTs can just enable the ones they need. But here we're working with SoCs where the only reference for what hardware exists *is* Apple's DT, and it only lists hardware that is in use on existing platforms. So there is no sane way for us to know what hardware exists, except what we can infer from reading the tea leaves (e.g. you can tell how many UARTs there are from the power domains and leaked schematics, but this doesn't extend to everything else). For example, we also know that these SoCs have a second Neural Engine that Apple have disabled on all shipping platforms, that the t600x series has an unused USB3 controller, etc... but there's no way we can safely describe these things in the DT if we can't test that they work and we don't have documentation even telling us how they're supposed to work :) > In the case of gpio-macsmc, how would we later add support for the > slave PMU GPIOs, given that these use keys "gpXX" rather than "gPxx"? > How do we tell the gpio-macsmc code to use a different set of keys? > Should DT describe the key "prefix" (in other words "gp" vs "gP"), > or should it describe it some other way. What if Apple decides to > instantiate another GPIO controller in a later platform with a > different prefix, could that be accomodated without breaking any > solution we come up today? > > Maybe the solution to this would be to describe the key prefix in DT > as that's effectively its "reg". Or maybe we use "reg" to describe > it somehow (which is value of the key, which seems to have an > "address" like quality to it?) > > We don't have to implement code for this now, we just need to get a > reasonably correct DT binding for the gpio controller. I agree that this is something to think about (I was about to reply on the subject). I can think of two ways: using `reg` for the key name, but that feels icky since it's ASCII and not *really* a register number/address, or something like this: gpio@0 { apple,smc-key-base = "gP00"; ... } gpio@1 { apple,smc-key-base = "gp00"; ... } But this ties back to the device enumeration too, since right now the DT does not drive that (we'd have to add the subdevice to the mfd subdevice list somehow anyway, if we don't switch to compatibles). I'd love to hear Rob's opinion on this one, and also whether the existing Linux and OpenBSD code would currently find gpio@0 {} instead of gpio {} for backwards compat. - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel