Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761726AbdDSLrm (ORCPT ); Wed, 19 Apr 2017 07:47:42 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:52185 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759678AbdDSLri (ORCPT ); Wed, 19 Apr 2017 07:47:38 -0400 Message-ID: <1492602451.2970.90.camel@pengutronix.de> Subject: Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings From: Philipp Zabel To: Steve Longerbeam Cc: Peter Rosin , Rob Herring , Mark Rutland , Sakari Ailus , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@pengutronix.de Date: Wed, 19 Apr 2017 13:47:31 +0200 In-Reply-To: References: <20170413154812.19597-1-p.zabel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:3ad5:47ff:feaf:1a17 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1170 Lines: 45 On Thu, 2017-04-13 at 18:03 -0700, Steve Longerbeam wrote: > > On 04/13/2017 08:48 AM, Philipp Zabel wrote: > > This adds device tree binding documentation for mmio-based syscon > > multiplexers controlled by a single bitfield in a syscon register > > range. > > Nice! (you beat me to it, I was about to embark on this myself :) > > Looks good to me, just some minor comments below. > [...] > > +Define a syscon bitfield to be used to control a multiplexer. The parent > I think "Define a register bitfield to be used ..." is more clear. [...] > > +- compatible : "gpio-mux" > Er, "mmio-mux" I'll change those, thanks. [...] > > +Example: > > + > > + syscon { > > + compatible = "syscon"; > > + > > + mux: mux-controller@3 { > > + compatible = "mmio-mux"; > > + reg = <0x3>; > > + bit-mask = <0x1>; > > + bit-shift = <5>; > > + #mux-control-cells = <0>; > > + }; > > + }; > > + > > + video-mux { > > I like this as an example consumer of a mmio-mux, but just > the same some might argue this doesn't really fit here. I don't think this is a problem, of course assuming that this video-mux binding will actually come into existence. regards Philipp