From: Joel Stanley <joel@jms.id.au> To: Rob Herring <robh@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de>, Mark Rutland <mark.rutland@arm.com>, devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Andrew Jeffery <andrew@aj.id.au> Subject: Re: [PATCH v2 1/2] dt-bindings: reset: Add bindings for basic reset controller Date: Mon, 3 Jul 2017 16:21:29 +0930 [thread overview] Message-ID: <CACPK8Xd86gAtR5sLb1LAy49Rc-dw4mAnZtk9_vwYvBe+Qefa1Q@mail.gmail.com> (raw) In-Reply-To: <20170607204916.n3wh3fkwbfctdv6s@rob-hp-laptop> On Thu, Jun 8, 2017 at 6:19 AM, Rob Herring <robh@kernel.org> wrote: > On Tue, May 30, 2017 at 03:38:50PM +0930, Joel Stanley wrote: >> This adds the bindings documentation for a basic single-register reset >> controller. >> >> The bindings describe a single 32-bit register that contains up to 32 >> reset lines, each deasserted by clearing the appropriate bit in the >> register. Optionally a property can be provided that changes this >> behaviour to assert on clear. >> > > I think this is a good idea for kernel code, but not for bindings. We > don't really want per register bindings. > > The problem with any generic/simple/basic binding is they always start > that way. Then we add one property at a time not in any well planned > way. I can easily come up with additions. For example, what about > self-clearing reset bits. Or 2 bits per reset. Or multiple resets that > have to be controlled together. 8 or 16-bit registers. Thanks for the explanation. I will send a v3 with aspeed specific bindings. How should I handle the driver? Were you suggesting I keep it generic, but with my aspeed compatible? Cheers, Joel > > IRQs and GPIOs could also be described in some cases with just groups of > 32-bit registers for set,clear,status,mask,etc., but we don't do that in > bindings for the same reasons. > > Rob
WARNING: multiple messages have this Message-ID (diff)
From: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> Subject: Re: [PATCH v2 1/2] dt-bindings: reset: Add bindings for basic reset controller Date: Mon, 3 Jul 2017 16:21:29 +0930 [thread overview] Message-ID: <CACPK8Xd86gAtR5sLb1LAy49Rc-dw4mAnZtk9_vwYvBe+Qefa1Q@mail.gmail.com> (raw) In-Reply-To: <20170607204916.n3wh3fkwbfctdv6s@rob-hp-laptop> On Thu, Jun 8, 2017 at 6:19 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > On Tue, May 30, 2017 at 03:38:50PM +0930, Joel Stanley wrote: >> This adds the bindings documentation for a basic single-register reset >> controller. >> >> The bindings describe a single 32-bit register that contains up to 32 >> reset lines, each deasserted by clearing the appropriate bit in the >> register. Optionally a property can be provided that changes this >> behaviour to assert on clear. >> > > I think this is a good idea for kernel code, but not for bindings. We > don't really want per register bindings. > > The problem with any generic/simple/basic binding is they always start > that way. Then we add one property at a time not in any well planned > way. I can easily come up with additions. For example, what about > self-clearing reset bits. Or 2 bits per reset. Or multiple resets that > have to be controlled together. 8 or 16-bit registers. Thanks for the explanation. I will send a v3 with aspeed specific bindings. How should I handle the driver? Were you suggesting I keep it generic, but with my aspeed compatible? Cheers, Joel > > IRQs and GPIOs could also be described in some cases with just groups of > 32-bit registers for set,clear,status,mask,etc., but we don't do that in > bindings for the same reasons. > > Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-07-03 6:51 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-30 6:08 [PATCH v2 0/2] reset: Basic reset controller Joel Stanley 2017-05-30 6:08 ` Joel Stanley 2017-05-30 6:08 ` [PATCH v2 1/2] dt-bindings: reset: Add bindings for basic " Joel Stanley 2017-05-30 6:08 ` Joel Stanley 2017-06-07 20:49 ` Rob Herring 2017-07-03 6:51 ` Joel Stanley [this message] 2017-07-03 6:51 ` Joel Stanley 2017-05-30 6:08 ` [PATCH v2 2/2] reset: Add basic single-register reset driver Joel Stanley 2017-06-06 6:33 ` [v2,2/2] " Russell Currey 2017-06-06 6:33 ` Russell Currey
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACPK8Xd86gAtR5sLb1LAy49Rc-dw4mAnZtk9_vwYvBe+Qefa1Q@mail.gmail.com \ --to=joel@jms.id.au \ --cc=andrew@aj.id.au \ --cc=benh@kernel.crashing.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=p.zabel@pengutronix.de \ --cc=robh@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.