linux-kernel - Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 13 Oct 2015 01:22:45 +0300
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Javier Martinez Canillas <javier@....samsung.com>
Cc:	Tony Lindgren <tony@...mide.com>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	linux-tegra@...r.kernel.org, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Benoit Cousson <bcousson@...libre.com>,
	Jason Cooper <jason@...edaemon.net>,
	Andrew Lunn <andrew@...n.ch>,
	Gregory Clement <gregory.clement@...e-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Kukjin Kim <kgene@...nel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <kernel@...gutronix.de>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

Hi Javier,

On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> > * Laurent Pinchart <laurent.pinchart@...asonboard.com> [151012 14:17]:
> >> Hello,
> >> 
> >> While working on regulators, GPIOs and DT I noticed that many of our DT
> >> source files incorrectly describe fixed regulators. The common error
> >> patterns are
> >> 
> >> - Usage of the undefined (and never parsed) enable-active-low property
> >> - Usage of the enable-active-high property without specifying an enable
> >>   GPIO
> >> - Typos in the enabl GPIO property name (gpios instead of gpio)
> >> - Mismatch between the enable-active-high property (or the lack thereof)
> >>   and the enable GPIO flags
> >> 
> >> This patch series fixes those issues in all the DT sources after locating
> >> the errors using the following script.
> >> 
> >> -------------------------------------------------------------------------
> >> !/bin/sh
> >> 
> >> echo $1
> >> cat $1 | awk '
> >> BEGIN {
> >> 	open_drain = 0;
> >> 	active_high = 0;
> >> 	gpio = 0;
> >> 	flags = 0;
> >> }
> >> 
> >> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
> >> 	name = ary[1];
> >> }
> >> 
> >> /compatible.*"regulator-fixed"/ {
> >> 	found = 1;
> >> }
> >> 
> >> /enable-active-high/ {
> >> 	active_high = 1;
> >> }
> >> 
> >> /gpio-open-drain/ {
> >> 	open_drain = 1;
> >> }
> >> 
> >> match($0, /gpio += <.* ([^ ]*)>/, ary) {
> >> 	gpio = 1;
> >> 	flags = ary[1];
> >> 	if (flags == 0)
> >> 		flags = "GPIO_ACTIVE_HIGH";
> >> }
> >> 
> >> /}/ {
> >> 	if (found) {
> >> 		if (gpio) {
> >> 			print "\t" name ": active high " active_high " " flags " open 
drain "
> >> 			open_drain;
> >> 			if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
> >> 			    (!active_high && flags == "GPIO_ACTIVE_HIGH"))
> >> 				print "WARNING: enable-active-high and flags do not 
match"
> >> 		} else {
> >> 			if (active_high)
> >> 				print "WARNING: active high without GPIO"
> >> 			if (open_drain)
> >> 				print "WARNING: open drain without GPIO"
> >> 		}
> >> 	}
> >> 	
> >> 	gpio = 0;
> >> 	found = 0;
> >> 	active_high = 0;
> >> 	open_drain = 0;
> >> 	flags = 0;
> >> }
> >> '
> >> -------------------------------------------------------------------------
> >> 
> >> All patches except for the ones touching omap3-beagle-xm and
> >> omap3-overo-base are untested as I lack test hardware.
> >> 
> >> As there's no dependency between the patches touching different source
> >> files the appropriate maintainers could take their share of the patches
> >> in their tree. Alternatively I could send a single pull request after
> >> collecting all acks but that might be more complex.
> > 
> > Nice clean-up. For omaps, there's an earlier patch posted by
> > Javier Martinez Canillas <javier@....samsung.com> as "[PATCH] ARM: dts:
> > Use defined GPIO constants in flags cell for OMAP2+ boards". Can you guys
> > do some cross checking and let me know which combination I should appluy
> > for omaps?
>
> Since Laurent's changes for OMAP are part of a bigger series and my patch
> was only for OMAP, probably makes sense for you to pick his patches and I
> can re-spin mine on top of that.
> 
> BTW, I posted as a single patch since the changes were trivial but maybe
> that made handling these conflicts harder and I should split the changes
> instead, since I'll resend anyways.
> 
> What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
> per board DTS?

My series will likely miss the next merge window as more discussion is needed. 
I'll thus respin the patches on top of yours, please proceed without caring 
about this.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/