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 50135ECAAA1 for ; Tue, 6 Sep 2022 16:30:23 +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=uCQfT0O0+E+w7p9fcxT1LaJHTl6CoF3WGHEc34heS9U=; b=gx4c2ZwQqaQflp eXi+62X9q/Az1SwV1a9NEVSJ5WrTSZX+FryG+4+mpEsnfOgFAxk1b2XWOeZOnwQsvq6rQWpQH36S3 /P9ZwQg0YrCX/US8eSxyMSpYFm0mgT4cU3KHzc3HPOqNz6Uc7BVfwz2TNuxiczcCPxsAmozTfjn0p IjZR5dAj7ubNSZWI1pPnEgzDq6AV9avzHx5H7hXTiTL9uF25kNCiCZwM6ZF/RiGzu2lyu1VYZu3PO lcmm2nGwhvNmAFEXuZ2GkoOaFJoi0IiJ4dObl8Ohi2u7xZjcXkMJ8asL16eDwEwvKj6kG9YIRqbi5 zGGFFxHjf8CkGcO/bwZg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVbRU-00FQ0V-53; Tue, 06 Sep 2022 16:28:52 +0000 Received: from mail-oa1-f48.google.com ([209.85.160.48]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVbA4-00FEhd-Jk for linux-arm-kernel@lists.infradead.org; Tue, 06 Sep 2022 16:10:54 +0000 Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-1274ec87ad5so14439029fac.0 for ; Tue, 06 Sep 2022 09:10:51 -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=0UoPNDaC8NCrfq0xjsW8qx2SIU/bt2Qiddj8DCUAP+M=; b=k01RYVLh+PD3l5zGwtjC39bIozwPWWi/X5I8q2LzEA7G+29noZ2j11HNe7jSe3dReA q6mX0YN0r8N5v7lP31esmTL/jm0PcWQKxs06rW3INWnk1GQPRKg8bhVeHNpKhtcnOZUk xTNHIg3g9XZY3qUxeiL7YoJg1+axb9IPgwDfS8aCX+YXIxFPqOrhHkFS08cZQ8HrVk5p IZPDUvuwB/wMzuZxT1XOreXG7T4Uh2uN3ZksiNWn4/Xwj5FKad02S6mHDy7M2iHY1zl3 9dm4IgBdmDr24/NdvZG5BSaO6Ag9mxKAJHaUsa95XEmIVv8Cv0Qy/s2agfIvG9+2aslU tyCg== X-Gm-Message-State: ACgBeo1EaFpl69JAZ+wl+VEOBoJl4gZ7AY9rZL1MjEpJPhn2MMB9nc7X e2kSjKbfwhUGYuuf1lDVGA== X-Google-Smtp-Source: AA6agR5Jt/pp6V/0cSJbLG/uZ3wRLl3rUFetLiWmtRsQju4iEwOlY/LWBZGhv3u72wd7Ebj6Z31rKA== X-Received: by 2002:a05:6870:d354:b0:126:6b86:449d with SMTP id h20-20020a056870d35400b001266b86449dmr8005579oag.107.1662480651214; Tue, 06 Sep 2022 09:10:51 -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 h6-20020a9d6406000000b00636f7059b27sm6062359otl.5.2022.09.06.09.10.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Sep 2022 09:10:50 -0700 (PDT) Received: (nullmailer pid 618747 invoked by uid 1000); Tue, 06 Sep 2022 16:10:49 -0000 Date: Tue, 6 Sep 2022 11:10:49 -0500 From: Rob Herring To: "Russell King (Oracle)" 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: <20220906161049.GC534217-robh@kernel.org> 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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220906_091052_752342_2EA2592F X-CRM114-Status: GOOD ( 42.10 ) 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 06, 2022 at 10:04:45AM +0100, Russell King (Oracle) wrote: > 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. It is, because you are creating the devices in the driver rather than creating devices based on child nodes that exist. > > 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. Yes, and that's how MFD devices with no child nodes work. The difference is those get any DT info out of the parent node. Here you are presumably manually getting the child DT node you want for each driver. > 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! I'm just looking for more information first. > 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. It's not strictly about number of properties. Though nodes with only a compatible string is generally a red flag for me. > Mark suggests that it would take six months for OpenBSD to transition to > some other description - for example, if we merged the nodes. The risk you take when using undocumented bindings... > 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.) 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. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel