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 ECACBECAAD5 for ; Tue, 6 Sep 2022 17:38: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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2aFbcZ/2F2YxImW3OyDVbL5fYJ8ik9yjJZz4uclommc=; b=w22Mz6QS2mpFIv +an9/JfM69yWfFi0HDU3hd2FcLHtBrlFTs4KropxU8VKAVU4T7yQD7O0OO9joHWFdhz44ZGcqQrkz 9hHb2Enk0MnKRerDdQgqi8PeWmrQAsdsoGJWBJXQ8gGynh1I2UINdw7l6A4kDlVMSkpO67gUt8K1c i/xQlqCwd6hGuUl38anxnqvnD3jlfTxYi09ytff20PnysKUvTyZqQFoI2gKy1SDGvz4Exq4sM8IDZ LPi2pACe/T0CfRr8NN9rJiPJbVXdb03qWw7dIqRDA3wS/EmDvNZ5W4OFPS9kvlTxw08s/0CYCjncv GZ2E4CltTN2JMEmOQZnQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVcVE-00G0eg-NF; Tue, 06 Sep 2022 17:36:50 +0000 Received: from mail-ot1-f50.google.com ([209.85.210.50]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVcU7-00G04R-95 for linux-arm-kernel@lists.infradead.org; Tue, 06 Sep 2022 17:35:40 +0000 Received: by mail-ot1-f50.google.com with SMTP id h9-20020a9d5549000000b0063727299bb4so8528651oti.9 for ; Tue, 06 Sep 2022 10:35:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Axl59O4YJWSYqFaxFX2s1YiQiL8KBb3VgOdRYMsp+Bs=; b=M2hAPPT1RHUS/02HjJIpBCyMtKwdzeWxYVJcxJyvKY9xhBG5bmV0ttaIuucH03WrwH dLaXPhPfgqiy2ghHgzb9xL+F8l9CMzORSuPnNkZJJ8m4qUi8eEmvGhUJQ77EJdZt/n6+ pmearYy/t9jkccdjzGYTCuxMcMFmS1kwYgYvyf2FJ5y4+RyetvnRECXKL6T7Pxq8KK1z VEp8qRWxG1KJcFAkV3Pds5B6wJc5j60WMN15l1QTIK80BTMm4sACoRZ5xYG6dVkTmEMC re1X1xXxiXu3KTJ/Ig30rTv8+uCw+uavyx46MX8Kyny/nugf+w17UH/E5SrbQixAb3Dd 9qMg== X-Gm-Message-State: ACgBeo0MuHwM+YtvSf6udIz343E9o6F9bkrCvgw9ebHlxzojrpQ3LUYV AIApD9aekQQTU5g4yXGi4w== X-Google-Smtp-Source: AA6agR6OFcjRQ+joH68tfuhOfhhZXRcOZk0l3kN/CH7MxvMkzhMCwdEmiPaXYJithfHs7z2Rp7Qi1w== X-Received: by 2002:a9d:65c2:0:b0:638:d9ec:4a9b with SMTP id z2-20020a9d65c2000000b00638d9ec4a9bmr22516719oth.83.1662485737027; Tue, 06 Sep 2022 10:35:37 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id 35-20020a9d0f26000000b0063b24357269sm6079404ott.13.2022.09.06.10.35.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Sep 2022 10:35:36 -0700 (PDT) Received: (nullmailer pid 761200 invoked by uid 1000); Tue, 06 Sep 2022 17:35:35 -0000 Date: Tue, 6 Sep 2022 12:35:35 -0500 From: Rob Herring To: Hector Martin Cc: "Russell King (Oracle)" , Mark Kettenis , krzysztof.kozlowski@linaro.org, arnd@arndb.de, lee@kernel.org, linus.walleij@linaro.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 Subject: Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller Message-ID: <20220906173535.GA734389-robh@kernel.org> References: <2fedff34-6a20-f1ce-a756-2bd8671fcd52@linaro.org> <20220902172808.GB52527-robh@kernel.org> <20220906161049.GC534217-robh@kernel.org> <91466e41-d3f7-0993-9082-80f94e53f375@marcan.st> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <91466e41-d3f7-0993-9082-80f94e53f375@marcan.st> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220906_103539_386569_5CDDA60A X-CRM114-Status: GOOD ( 29.77 ) 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 Wed, Sep 07, 2022 at 02:00:53AM +0900, Hector Martin wrote: > On 07/09/2022 01.10, Rob Herring wrote: > >> So at this point, I think it would make sense if I post a v2 with all > >> the updates so far (sorry, given the long drawn out discussions on > >> this, I've lost track of what changes have been made to the code, so > >> I won't include a detailed change log.) > > > > As I said elsewhere, sub-nodes is probably the right choice here. I > > think they need compatible strings in the child nodes, and addressing > > has to be sorted out which it seems may also break OpenBSD. > > So addressing only makes sense for GPIO, out of the nodes we have so far > - that's the only thing with two discrete instances whose access can be > entirely described by a single base key name, and which are otherwise > compatible. > > Everything else is pretty much single-instance, and talks to multiple > keys, so there isn't one single "address" key that would make semantic > sense to use as the node address. Unit-addresses are just the first address in 'reg'. So multiple addresses or not doesn't really matter. > There are some indexed keys, but at a > deeper level (e.g. multiple battery cells part of the charge control > subsystem, multiple Type C ports as part of the AC/power input > subsystem, etc.). And in those cases, these subdevices are mostly > homogeneous and we would never need multiple nodes for them at the DT > level, they'd just be implicitly handled by those drivers. Type-C will be fun depending on how much of the muxing/altmode details have to get exposed. > GPIO is quite special in that 1) it only has a single key type (which is > overloaded using advanced features to provide, effectively, > sub-registers to control all the GPIO features per pin), 2) a single key > represents a single pin, 3) keys are numbered in a reasoanble way, and > 4) there are two prefixes for two discrete GPIO controllers. For pretty > much everything else SMC does, we just have a bag of keys with no real > rhyme nor reason from the point of view of an "address space". > > Given that, how would this work? Is it legal/reasonable for only the > gpio nodes to have addressing/reg properties, and everything else to > just have a node name with no concept of address? Not ideal, but allowed. > Does it even make > sense to special case gpio in this way, vs. just having something like > gpio {} / gpio-sec {} (if we ever even need gpio-sec, which is an open > question)? If not unit-addresses, the 2nd choice we do is 'gpio-0', 'gpio-1', etc. Though that is mainly in the GPIO based consumer bindings like gpio-pwm, spi-gpio, etc. where there's really not anything to use for an address. If only those 2 nodes, then I really don't care so much and gpio-sec would be fine. It's 1 node in 1 binding. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel