Re: [PATCH V3 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

[Tony Lindgren <tony@atomide.com>]

* Thierry Reding <thierry.reding@avionic-design.de> [130409 14:01]:
> On Tue, Apr 09, 2013 at 01:17:46PM -0700, Tony Lindgren wrote:
> > * Thierry Reding <thierry.reding@avionic-design.de> [130409 12:45]:
> > > On Tue, Apr 09, 2013 at 09:40:04AM -0700, Tony Lindgren wrote:
> > > [...]
> > > > But then the regulator is not found and the driver should just exit,
> > > > or do nothing. If this is an optional regulator, then that should be
> > > > indicated in some platform data flags?
> > > 
> > > Yes, if the regulator isn't found then the driver fails. However the
> > > goal was to maintain bisectability. If we apply them in the wrong order
> > > we can't guarantee that because pwm-backlight will fail to work between
> > > both patches.
> > 
> > But it's fixing something that's not working anyways for board-4430sdp.c,
> > It seems so as these patches just add new features?
> 
> Not quite. It's adding a dummy regulator to represent hardware where the
> enable pin is always high. So I think pwm-backlight will work in the
> current state, but if we make the pwm-backlight driver change without
> adding the dummy regulator, then pwm-backlight will fail to probe and
> therefore the PWM won't be enabled either and the display will stay
> black.

OK
 
> > > > The driver parts really must be done in independently from any platform
> > > > data or .dts changes. The only common part needed should be changes
> > > > to include/linux/platform_data/*.h files.
> > > 
> > > We don't even need to touch platform data because the regulators are
> > > looked up via a global table. And the changes are all done independently
> > > but as I mentioned above, bisectability isn't maintained, so the
> > > preferred patch order is the one in which pwm-backlight keeps working at
> > > each point in the commit history.
> > 
> > Bisectability is a good point. But in the 4430sdp case I'm sure it's enough
> > that it builds and boots no matter how the patches get merged :)
> 
> If you don't mind some intermediary breakage, I will no longer object.

In this case it should be fine. If you are worried about it, you could
add something that enables the new features in the driver only in
a follow-up patch after the merge window. But I doubt that it's needed.

Regards,

Tony