linux-kernel - Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support

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]

Message-ID: <20130925053922.GE1916@verge.net.au>
Date:	Wed, 25 Sep 2013 14:39:22 +0900
From:	Simon Horman <horms@...ge.net.au>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	Eric Miao <eric.y.miao@...il.com>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Ben Dooks <ben-linux@...ff.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Magnus Damm <magnus.damm@...il.com>,
	Guan Xuetao <gxt@...c.pku.edu.cn>, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	openezx-devel@...ts.openezx.org, linux-samsung-soc@...r.kernel.org,
	linux-sh@...r.kernel.org, linux-pwm@...r.kernel.org,
	linux-kernel@...r.kernel.org, Olof Johansson <olof@...om.net>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 00/10] pwm-backlight: Add GPIO and power supply support

On Tue, Sep 24, 2013 at 11:00:24AM +0200, Thierry Reding wrote:
> On Tue, Sep 24, 2013 at 05:14:46PM +0900, Simon Horman wrote:
> > [ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ]
> > 
> > On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote:
> > > This series adds the ability to specify a GPIO and a power supply to
> > > enable a backlight.
> > > 
> > > Patch 1 refactors the power on and power off sequences into separate
> > > functions in preparation for subsequent patches.
> > > 
> > > Patch 2 adds an optional GPIO to enable a backlight. This patch only
> > > includes the field within the platform data so that it can be properly
> > > setup before actually being put to use.
> > > 
> > > Patches 3 to 7 convert all users of the pwm-backlight driver to use the
> > > new field. For most of them, this just initializes the field to -1,
> > > marking the field as unused.
> > >
> > > Patch 8 uses the new field within the pwm-backlight driver and at the
> > > same time allows it to be parsed from device tree.
> > > 
> > > Patch 9 implements support for an optional power supply. This relies on
> > > the regulator core to return a dummy regulator when no supply has been
> > > otherwise setup so the driver doesn't have to handle that specially nor
> > > require all users to be updated.
> > > 
> > > Patch 10 adds a way to keep a backlight turned off at boot. This is
> > > useful when hooking up a backlight with a subsystem such as DRM which
> > > has more explicit semantics as to when a backlight should be turned on.
> > > 
> > > Due to the dependencies within the series, I propose to take all these
> > > patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung,
> > > shmobile and Unicore32 maintainers.
> > 
> > I received some feedback regarding shmobile conflicts when
> > arm-soc was merged between v3.11 and v3.12-rc1. With this
> > in mind I now have a strong preference for changes inside
> > arch/arm/mach-shmobile/ to be taken through my renesas
> > tree and thus more importantly through arm-soc if possible.
> 
> I understand. Unfortunately the nature of patche series such as this is
> that they require the whole series to be applied atomically (or at least
> in a very specific order). So the patch that uses the new enable_gpio
> field can only be applied after all previous patches. The only
> reasonable way to ensure that is to take all of the patches through one
> tree. Furthermore this patch is tiny (it adds a single line) and touches
> code that's unlikely to be modified by anyone else.
> 
> But if it makes you more comfortable, I could provide a stable branch
> that contains this series for you to merge into the shmobile tree. That
> should enable you to handle all conflict resolution prior to submitting
> to arm-soc.

After some further thought I have reasoned that:

1. It is only a one line change on the shmobile side
2. It is to a file that is not seeing much chainge and in
   a block of code that is seeing even less change.

And thus the chance of a conflict is small.

With this in mind I will ack the shmobile patch.

--
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/