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 D66EDECAAA1 for ; Tue, 6 Sep 2022 09:06:17 +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=+/EY3nXjxkZmjI8vwHks9F/nDV348RNXG8Nc+ecDpos=; b=x1gprXzqX/tX2D vltKWuUYRpLh4Qm/PfA9zqbKvivswMv3sLx/pU8SisOJaFYq4bmAG933IANBA8Cx7kebgXuT4IW3i OrE9JRt7RbFHyQZKxdSp1pm00Jln+Iaw7KMP6jW7CLUJds0SLSeVlI6CnJ8aWGg8R83mlOOcp9vR1 zF+FegClUSYPPCNC5TOmO7TUwN3ws+bakPAOzSBguu2uHjTChCsKLlalmUUqciYyvlIvhqZUUToLR vaiJRCDFDkps3OJXAa+ULOGCcnGuXfzRt5Y+7db+Z4K7PSx+5dNGGRUsoQ+XRb9LaSiu+yVgYLNET waKBk+Nf9lxo2bQaaQ1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVUW1-00BcKN-Ng; Tue, 06 Sep 2022 09:05:05 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVUVx-00BcGD-6B for linux-arm-kernel@lists.infradead.org; Tue, 06 Sep 2022 09:05:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zD51EHbUMEGF34YrRuNppOWB4NaAsrvsQWAlBIvtq70=; b=WKZULGD3yfXwyVmbbYgw+9fy1Y YPu5oQIPHhCQyZBY5eJLPtRD5DE/4LTd4R3pHzvTp18gSj8Lnj0hrBT3u77EYgUAu/9VpPw2Vm+Hu vXBllKnTTILtAfDOzApwbLIzHe+Qnhjae7h78U9OQVq8Li0QZ1XPzj9gW3t4qIsAsNTUTyWL+8ymq A25EvLzvxMHuJGyX6hbfyuHJf5twn9+56foueY+7KMd37iXQ7WFKAJKGQfl7hVNAHgwMhRnRyLyGo d9K+x36Ipek1NL/pGvkbuN0wRaO9p1elxpXtR10UEzxnNxrNARQQKwVtNeiN6WnLXDhB9hk68QXKo 8gC85/pQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34142) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oVUVl-0003eF-S3; Tue, 06 Sep 2022 10:04:49 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1oVUVh-00088w-Rq; Tue, 06 Sep 2022 10:04:45 +0100 Date: Tue, 6 Sep 2022 10:04:45 +0100 From: "Russell King (Oracle)" To: Rob Herring Cc: 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, marcan@marcan.st, 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: References: <928ddeff-efac-920c-7bbf-dda35a942b93@linaro.org> <2fedff34-6a20-f1ce-a756-2bd8671fcd52@linaro.org> <20220902172808.GB52527-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220902172808.GB52527-robh@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220906_020501_269704_8172BBE5 X-CRM114-Status: GOOD ( 28.20 ) 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 Fri, Sep 02, 2022 at 12:28:08PM -0500, Rob Herring wrote: > This one is actually pretty odd in that the child nodes don't have a > compatible string which breaks the automagical probing. I don't think that is necessarily true, and I don't think it's true in this case. The SMC core driver instructs the MFD core to create devices for the individual functional items: static const struct mfd_cell apple_smc_devs[] = { { .name = "macsmc-gpio", }, { .name = "macsmc-hid", }, { .name = "macsmc-power", }, { .name = "macsmc-reboot", }, { .name = "macsmc-rtc", }, }; Since MFD uses platform devices for these, they get all the normal functionality that these devices have, which include matching by device name ot the driver name, and udev events being appropriately triggered. As long as the platform drivers for these devices have the correct modalias lines, autoloading of the modules will work and the drivers will be correctly matched and probed. The Asahi kernel builds most of the platform support as modules, including these, so we know it works (if it didn't, then lots of module autoloading would be broken on non-DT platforms.) > > Again the separate nodes are there because the RTC and the reboot > > functionality are logically separate and handled by different MFD > > sub-drivers in Linux. > > It's really a question of whether the subset of functionality is going > to get reused on its own or has its own resources in DT. MFD bindings > are done both ways. I think the current position on what to do about these is that everyone is looking for someone else to make a decision, and no one wants to! Firstly, I don't think that the number of properties in a node should have a bearing on the design of the DT binding - what should have a bearing is the logical partitioning of functionality. Mark suggests that it would take six months for OpenBSD to transition to some other description - for example, if we merged the nodes. Hector says that MacOS's firmware description has the nodes merged, but their description is a mess. The overall preference seems to be to keep the sub-nodes unless there is a strong technical reason not to. The feeling I am getting from the review is that there doesn't seem to be a strong technical reason to merge the nodes - there are desires and preferences, but nothing concrete. 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.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel