linux-kernel - Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1492602451.2970.90.camel@pengutronix.de>
Date:   Wed, 19 Apr 2017 13:47:31 +0200
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Steve Longerbeam <slongerbeam@...il.com>
Cc:     Peter Rosin <peda@...ntia.se>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Sakari Ailus <sakari.ailus@....fi>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT
 bindings

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