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

[Simon Horman]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/