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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EB77C433DB for ; Mon, 15 Feb 2021 17:34:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EF4D26024A for ; Mon, 15 Feb 2021 17:34:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF4D26024A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=WEtq6wBCXv+G4Cevjznfz8OiTXu1Fk/3iMeu9nzDJW4=; b=qPmxsufV6uykhHkK+C+v7/+rD mVB7ax97mbX+A6Hm1nQxtGbcBpCidAUdeUshBjH2yyeX9vTIzP37axtioA1l/ZvKKucAvDh5Vy1St kk13fCONpf7Gi5F4uFaZ69puKRqMZkYkVIb0UGYAFNNTlHX01/FC6pfd92ZOeL1wB6wzSN3ZvGK0t PuU2JXkmT0KzntDMcKGALJylsacz/Qi+wBgg7pJ726GGhCeD0f3z/7IPzqr9YTz5AFwDMUfh4gt40 rQT8fvnWzmPRWHN2vgYxwHu9XC+oB3WIXSvj7w6RzIUrQfy7D/V9vstXqbVjjSH/Y5zQ9TzvbTzeD jSpG3jytQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lBhjo-0006LU-Ic; Mon, 15 Feb 2021 17:32:44 +0000 Received: from relay11.mail.gandi.net ([217.70.178.231]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lBhjl-0006Kx-9s for linux-arm-kernel@lists.infradead.org; Mon, 15 Feb 2021 17:32:42 +0000 Received: from localhost (lfbn-lyo-1-13-140.w86-202.abo.wanadoo.fr [86.202.109.140]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 0C6B3100002; Mon, 15 Feb 2021 17:32:32 +0000 (UTC) Date: Mon, 15 Feb 2021 18:32:32 +0100 From: Alexandre Belloni To: Steen Hegelund Subject: Re: [PATCH v5 1/3] dt-bindings: reset: microchip sparx5 reset driver bindings Message-ID: <20210215173232.GM6798@piout.net> References: <20210210091952.2013027-1-steen.hegelund@microchip.com> <20210210091952.2013027-2-steen.hegelund@microchip.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210210091952.2013027-2-steen.hegelund@microchip.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210215_123241_455143_CAA03C8F X-CRM114-Status: GOOD ( 18.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , devicetree@vger.kernel.org, Gregory Clement , linux-kernel@vger.kernel.org, Microchip Linux Driver Support , Rob Herring , Philipp Zabel , linux-arm-kernel@lists.infradead.org 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 10/02/2021 10:19:50+0100, Steen Hegelund wrote: > Document the Sparx5 reset device driver bindings > > The driver uses two IO ranges on sparx5 for access to > the reset control and the reset status. > > Signed-off-by: Steen Hegelund > --- > .../bindings/reset/microchip,rst.yaml | 55 +++++++++++++++++++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml > > diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml > new file mode 100644 > index 000000000000..80046172c9f8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Microchip Sparx5 Switch Reset Controller > + > +maintainers: > + - Steen Hegelund > + - Lars Povlsen > + > +description: | > + The Microchip Sparx5 Switch provides reset control and implements the following > + functions > + - One Time Switch Core Reset (Soft Reset) > + > +properties: > + $nodename: > + pattern: "^reset-controller@[0-9a-f]+$" > + > + compatible: > + const: microchip,sparx5-switch-reset > + > + reg: > + items: > + - description: cpu block registers > + - description: global control block registers > + > + reg-names: > + items: > + - const: cpu > + - const: gcb > + I still think this is not right because then you will be mapping the same set of register using multiple drivers without any form of synchronisation which will work because you are mapping the region without requesting it. But this may lead to issues later. At least, you should make cpu start at 0x80 and of size 4. Else, you won't be able to define and use the GPRs that are in front of CPU_REGS:RESET. I would still keep DEVCPU_GCB:CHIP_REGS as a syscon, especially since you are mapping the whole set of registers. > + "#reset-cells": > + const: 1 > + > +required: > + - compatible > + - reg > + - reg-names > + - "#reset-cells" > + > +additionalProperties: false > + > +examples: > + - | > + reset: reset-controller@0 { > + compatible = "microchip,sparx5-switch-reset"; > + #reset-cells = <1>; > + reg = <0x0 0xd0>, > + <0x11010000 0x10000>; > + reg-names = "cpu", "gcb"; > + }; > + > -- > 2.30.0 > -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 246A3C433E0 for ; Mon, 15 Feb 2021 17:34:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E67B764DE8 for ; Mon, 15 Feb 2021 17:34:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230223AbhBORdt (ORCPT ); Mon, 15 Feb 2021 12:33:49 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:45605 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232733AbhBORd2 (ORCPT ); Mon, 15 Feb 2021 12:33:28 -0500 Received: from localhost (lfbn-lyo-1-13-140.w86-202.abo.wanadoo.fr [86.202.109.140]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 0C6B3100002; Mon, 15 Feb 2021 17:32:32 +0000 (UTC) Date: Mon, 15 Feb 2021 18:32:32 +0100 From: Alexandre Belloni To: Steen Hegelund Cc: Philipp Zabel , Rob Herring , Andrew Lunn , Microchip Linux Driver Support , Gregory Clement , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org Subject: Re: [PATCH v5 1/3] dt-bindings: reset: microchip sparx5 reset driver bindings Message-ID: <20210215173232.GM6798@piout.net> References: <20210210091952.2013027-1-steen.hegelund@microchip.com> <20210210091952.2013027-2-steen.hegelund@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210210091952.2013027-2-steen.hegelund@microchip.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 10/02/2021 10:19:50+0100, Steen Hegelund wrote: > Document the Sparx5 reset device driver bindings > > The driver uses two IO ranges on sparx5 for access to > the reset control and the reset status. > > Signed-off-by: Steen Hegelund > --- > .../bindings/reset/microchip,rst.yaml | 55 +++++++++++++++++++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml > > diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml > new file mode 100644 > index 000000000000..80046172c9f8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > + > +title: Microchip Sparx5 Switch Reset Controller > + > +maintainers: > + - Steen Hegelund > + - Lars Povlsen > + > +description: | > + The Microchip Sparx5 Switch provides reset control and implements the following > + functions > + - One Time Switch Core Reset (Soft Reset) > + > +properties: > + $nodename: > + pattern: "^reset-controller@[0-9a-f]+$" > + > + compatible: > + const: microchip,sparx5-switch-reset > + > + reg: > + items: > + - description: cpu block registers > + - description: global control block registers > + > + reg-names: > + items: > + - const: cpu > + - const: gcb > + I still think this is not right because then you will be mapping the same set of register using multiple drivers without any form of synchronisation which will work because you are mapping the region without requesting it. But this may lead to issues later. At least, you should make cpu start at 0x80 and of size 4. Else, you won't be able to define and use the GPRs that are in front of CPU_REGS:RESET. I would still keep DEVCPU_GCB:CHIP_REGS as a syscon, especially since you are mapping the whole set of registers. > + "#reset-cells": > + const: 1 > + > +required: > + - compatible > + - reg > + - reg-names > + - "#reset-cells" > + > +additionalProperties: false > + > +examples: > + - | > + reset: reset-controller@0 { > + compatible = "microchip,sparx5-switch-reset"; > + #reset-cells = <1>; > + reg = <0x0 0xd0>, > + <0x11010000 0x10000>; > + reg-names = "cpu", "gcb"; > + }; > + > -- > 2.30.0 > -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com