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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05146C433FE for ; Thu, 3 Nov 2022 01:14:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230324AbiKCBOS (ORCPT ); Wed, 2 Nov 2022 21:14:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbiKCBOP (ORCPT ); Wed, 2 Nov 2022 21:14:15 -0400 Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68FAD25F6; Wed, 2 Nov 2022 18:14:13 -0700 (PDT) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 2A31DkdA074343; Wed, 2 Nov 2022 20:13:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1667438026; bh=g87VIu80dnT7p+aQPGGUELPndmBH8kRxZATib9cYrnI=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=V0bxZfgWWXTfn8KvvEtD7NMtJDipTdy4GaMym2mf4UZJxG8ZgPcTqMzNgcAyFmY75 oGAKtENQAhm0FNkSdz4Blcjiou9yl0TYLMRfxPEux1A0L8MK/44LmyDl4Gbcbi0D8K ulI9Vop5bfwL0EcobG5mV9f3nPb10kfq3I46ZrBc= Received: from DLEE102.ent.ti.com (dlee102.ent.ti.com [157.170.170.32]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 2A31DkFM090578 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 2 Nov 2022 20:13:46 -0500 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Wed, 2 Nov 2022 20:13:45 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Wed, 2 Nov 2022 20:13:45 -0500 Received: from [10.249.33.217] (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 2A31Djxv087808; Wed, 2 Nov 2022 20:13:45 -0500 Message-ID: <904b42ea-0655-2fae-98d6-17429533de2e@ti.com> Date: Wed, 2 Nov 2022 20:13:44 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v4 1/9] dt-bindings: mfd: Add TI-Nspire misc registers Content-Language: en-US To: Rob Herring CC: Lee Jones , Krzysztof Kozlowski , Arnd Bergmann , Linus Walleij , Geert Uytterhoeven , Daniel Tang , Fabian Vogt , , , References: <20221101215804.16262-1-afd@ti.com> <20221101215804.16262-2-afd@ti.com> <20221102173558.GA4193055-robh@kernel.org> <20221102212645.GA459441-robh@kernel.org> From: Andrew Davis In-Reply-To: <20221102212645.GA459441-robh@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/2/22 4:26 PM, Rob Herring wrote: > On Wed, Nov 02, 2022 at 02:05:28PM -0500, Andrew Davis wrote: >> On 11/2/22 12:35 PM, Rob Herring wrote: >>> On Tue, Nov 01, 2022 at 04:57:56PM -0500, Andrew Davis wrote: >>>> The TI Nspire devices contain a set of registers with a seemingly >>>> miscellaneous set of functionality. This area is known simply as the >>>> "misc" region. >>>> >>>> Signed-off-by: Andrew Davis >>>> --- >>>> .../bindings/mfd/ti,nspire-misc.yaml | 55 +++++++++++++++++++ >>>> 1 file changed, 55 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml >>>> new file mode 100644 >>>> index 0000000000000..d409eae7537bd >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml >>>> @@ -0,0 +1,55 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/mfd/ti,nspire-misc.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: TI Nspire MISC hardware block >>>> + >>>> +maintainers: >>>> + - Andrew Davis >>>> + >>>> +description: | >>>> + System controller node represents a register region containing a set >>>> + of miscellaneous registers. The registers are not cohesive enough to >>>> + represent as any specific type of device. The typical use-case is >>>> + for some other node's driver, or platform-specific code, to acquire >>>> + a reference to the syscon node (e.g. by phandle, node path, or >>>> + search using a specific compatible value), interrogate the node (or >>>> + associated OS driver) to determine the location of the registers, >>>> + and access the registers directly. >>> >>> Looks like you copied the generic description? Describe what MISC >>> contains. >>> >> >> I don't know what all MISC contains (or maybe I do, but it is not >> publicly available so I'm not going to add anything that hasn't >> already been found by clean-room reverse engineering [0]). > > Put whatever you are comfortable with, but not a duplicate generic > description. You know it at least it has reboot registers... > >> This is the point I was trying to make in that thread on v3. The >> node's content *is* the hardware description. Every time a new >> register is found it could have just been added to the DT. But now >> we also have to go back here and add the exact same information >> to the binding, every time. We don't require that for simple-bus, >> should simple-mfd be given the same flexibility? > > The thing with any MFD is it makes up a device even if it's 'simple', so > it's important to get a full picture of the device. It could evolve to > not being 'simple'. > It would not evolve as a generic simple-mfd binding would not allow any extra non-node properties. '^.*$': type: object additionalProperties: false Maybe I'm thinking about this group of registers wrong, maybe it is a simple-bus not a simple-mfd. I mean from software what else is a bus but a space of addressable registers.. The issue would be each child node of a simple-bus needs a unit-address and 'reg'. Which we *could* do here if not for all this syscon weirdness :( > For example, if you came along and wanted to make it a clock provider, > you'd probably create a clock child node that's just a compatible and > '#clock-cells'. The feedback would be just add '#clock-cells' to the > 'ti,nspire-misc' node. So yes, I want to see additions. > And then that would still fail the dtbs_check, since the simple-mfd binding would only allow for child nodes, nothing else, that's what makes them "simple". Each child node would need a compatible and therefor a binding. You would still see everything and could prevent malformed nodes just the same. Andrew 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 23A62C433FE for ; Thu, 3 Nov 2022 01:15: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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: 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=qZfFu/Q0B6k38rSZknH0INANy3mwrsBOuLix9hrsF6w=; b=XahHlyINFsaK7g FZQn1IDm3EcalYjyuv3futpkIKTqvLeWGAyqTMcIZlfd4dBk78rIHmw+kagkznCxa/VqVxlqwJBqe zqz0Kj0jG0wAimwmM633cCP/u/JvY+rJ8wKpCKpKCNMNrgAVAWLRiyq2kCpRIM7k953rZah2x3iTV AMe7/b3hHOOgIUAYBx/BNRUT34YrPwyTgqo2Mv6dloVJ6+knT8v0wuaFYqd3IneuTjCWDr5qsVVXI IfmS7mpzjtWeHG2wSQ+6ZrdWWKVrYBFnRJnpOsNvrTAuuS/mrjoqjnzuFXkXoN4wyrgAX+2nctDiu 3sQDk5t0H3bYGlHOea+A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqOo7-00FUN4-7q; Thu, 03 Nov 2022 01:14:11 +0000 Received: from fllv0016.ext.ti.com ([198.47.19.142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqOo4-00FULv-5S for linux-arm-kernel@lists.infradead.org; Thu, 03 Nov 2022 01:14:10 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 2A31DkdA074343; Wed, 2 Nov 2022 20:13:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1667438026; bh=g87VIu80dnT7p+aQPGGUELPndmBH8kRxZATib9cYrnI=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=V0bxZfgWWXTfn8KvvEtD7NMtJDipTdy4GaMym2mf4UZJxG8ZgPcTqMzNgcAyFmY75 oGAKtENQAhm0FNkSdz4Blcjiou9yl0TYLMRfxPEux1A0L8MK/44LmyDl4Gbcbi0D8K ulI9Vop5bfwL0EcobG5mV9f3nPb10kfq3I46ZrBc= Received: from DLEE102.ent.ti.com (dlee102.ent.ti.com [157.170.170.32]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 2A31DkFM090578 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 2 Nov 2022 20:13:46 -0500 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Wed, 2 Nov 2022 20:13:45 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Wed, 2 Nov 2022 20:13:45 -0500 Received: from [10.249.33.217] (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 2A31Djxv087808; Wed, 2 Nov 2022 20:13:45 -0500 Message-ID: <904b42ea-0655-2fae-98d6-17429533de2e@ti.com> Date: Wed, 2 Nov 2022 20:13:44 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v4 1/9] dt-bindings: mfd: Add TI-Nspire misc registers Content-Language: en-US To: Rob Herring CC: Lee Jones , Krzysztof Kozlowski , Arnd Bergmann , Linus Walleij , Geert Uytterhoeven , Daniel Tang , Fabian Vogt , , , References: <20221101215804.16262-1-afd@ti.com> <20221101215804.16262-2-afd@ti.com> <20221102173558.GA4193055-robh@kernel.org> <20221102212645.GA459441-robh@kernel.org> From: Andrew Davis In-Reply-To: <20221102212645.GA459441-robh@kernel.org> X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221102_181408_401943_DCCC71AF X-CRM114-Status: GOOD ( 32.99 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11/2/22 4:26 PM, Rob Herring wrote: > On Wed, Nov 02, 2022 at 02:05:28PM -0500, Andrew Davis wrote: >> On 11/2/22 12:35 PM, Rob Herring wrote: >>> On Tue, Nov 01, 2022 at 04:57:56PM -0500, Andrew Davis wrote: >>>> The TI Nspire devices contain a set of registers with a seemingly >>>> miscellaneous set of functionality. This area is known simply as the >>>> "misc" region. >>>> >>>> Signed-off-by: Andrew Davis >>>> --- >>>> .../bindings/mfd/ti,nspire-misc.yaml | 55 +++++++++++++++++++ >>>> 1 file changed, 55 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml >>>> new file mode 100644 >>>> index 0000000000000..d409eae7537bd >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml >>>> @@ -0,0 +1,55 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/mfd/ti,nspire-misc.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: TI Nspire MISC hardware block >>>> + >>>> +maintainers: >>>> + - Andrew Davis >>>> + >>>> +description: | >>>> + System controller node represents a register region containing a set >>>> + of miscellaneous registers. The registers are not cohesive enough to >>>> + represent as any specific type of device. The typical use-case is >>>> + for some other node's driver, or platform-specific code, to acquire >>>> + a reference to the syscon node (e.g. by phandle, node path, or >>>> + search using a specific compatible value), interrogate the node (or >>>> + associated OS driver) to determine the location of the registers, >>>> + and access the registers directly. >>> >>> Looks like you copied the generic description? Describe what MISC >>> contains. >>> >> >> I don't know what all MISC contains (or maybe I do, but it is not >> publicly available so I'm not going to add anything that hasn't >> already been found by clean-room reverse engineering [0]). > > Put whatever you are comfortable with, but not a duplicate generic > description. You know it at least it has reboot registers... > >> This is the point I was trying to make in that thread on v3. The >> node's content *is* the hardware description. Every time a new >> register is found it could have just been added to the DT. But now >> we also have to go back here and add the exact same information >> to the binding, every time. We don't require that for simple-bus, >> should simple-mfd be given the same flexibility? > > The thing with any MFD is it makes up a device even if it's 'simple', so > it's important to get a full picture of the device. It could evolve to > not being 'simple'. > It would not evolve as a generic simple-mfd binding would not allow any extra non-node properties. '^.*$': type: object additionalProperties: false Maybe I'm thinking about this group of registers wrong, maybe it is a simple-bus not a simple-mfd. I mean from software what else is a bus but a space of addressable registers.. The issue would be each child node of a simple-bus needs a unit-address and 'reg'. Which we *could* do here if not for all this syscon weirdness :( > For example, if you came along and wanted to make it a clock provider, > you'd probably create a clock child node that's just a compatible and > '#clock-cells'. The feedback would be just add '#clock-cells' to the > 'ti,nspire-misc' node. So yes, I want to see additions. > And then that would still fail the dtbs_check, since the simple-mfd binding would only allow for child nodes, nothing else, that's what makes them "simple". Each child node would need a compatible and therefor a binding. You would still see everything and could prevent malformed nodes just the same. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel